使用Fannie Mae和NRO进行大规模迁移的架构设计 (AWS re:Invent 2025 – WPS201)
Source: Dev.to
大规模迁移为何困难
本场会议首先回顾了熟悉的迁移驱动因素：降低计算成本和提升创新速度，组织从本地环境迁移到重新托管、重新平台化以及云原生架构。
演讲者将迁移策略框定为 “7 Rs”，强调大规模项目几乎总是混合使用这些方法，而不是单一模式。
Strategy
| Strategy | Description（描述） | Best For（适用场景） |
|---|---|---|
| Rehost | “Lift and shift” 到云 | 快速迁移，改动最少 |
| Relocate | 移动到不同的基础设施 | 虚拟机层面的迁移 |
| Repurchase | 迁移到 SaaS 解决方案 | 替换自定义应用程序 |
| Retain | 保持本地部署 | 合规或延迟要求 |
| Retire | 清除不再使用的应用 | 降低技术债务 |
| Replatform | 进行轻量级的云优化 | 中等收益且风险低 |
| Refactor | 为云原生重新设计 | 获得最大化的云收益 |
Key Message: 仅靠工具不足以应对多样的遗留系统、复杂的数据库和紧张的预算。缺乏云经验的组织必须提前投入自动化、治理以及可重复的账号管理机制。
会议建议使用 AWS Migration Readiness Assessment (MRA) 作为任何大项目的起点。MRA 过程帮助：
- 清点应用并发现依赖关系
- 为每个工作负载确定合适的迁移策略
- 避免一次性、无结构的决策
Migration Assessment Phases
| Phase（阶段） | Focus（关注点） | Key AWS Tools（关键 AWS 工具） |
|---|---|---|
| Assess | 发现与规划 | Application Discovery Service, Migration Readiness Assessment |
| Mobilize | 设置与准备 | Control Tower, Landing Zone, Account vending |
| Migrate/Modernize | 执行与优化 | Migration tools, Well‑Architected reviews |
与此同时，组织应建立 AWS Control Tower‑style landing zone 或 “account vending machine”，以快速且一致地供应新账号，并内置安全、合规和治理的防护栏。
AWS Well‑Architected Framework
该框架是设计与评审的骨干。六大支柱用于帮助在每个工作负载上权衡取舍，而不是迁移后才去检查的清单。
| Pillar（支柱） | Focus Area（关注领域） | Key Considerations（关键考量） |
|---|---|---|
| Operational Excellence | 运行与监控系统 | 自动化、流程、持续改进 |
| Security | 保护信息与系统 | 身份、权限、数据保护 |
| Reliability | 系统可用性与恢复 | 容错、备份、灾难恢复 |
| Performance Efficiency | 高效使用资源 | 合理规模、监控、技术选型 |
| Cost Optimization | 以最低成本交付价值 | 资源优化、计费模型 |
| Sustainability | 最小化环境影响 | 效率提升、可再生能源 |
Practical Tip: 向业务利益相关者询问每个应用最看重哪些支柱。有的工作负载可能更强调可靠性和运营卓越，而有的则优先考虑成本或性能。这些决定应驱动架构选择、容量规划和运行手册。
Cloud Center of Excellence (CCoE)
跨职能团队，涵盖：
- ☁️ 云架构
- 🖥️ 基础设施
- 🔒 安全
- ⚙️ 运维
- 💻 软件工程
CCoE Responsibilities
- ✅ 标准化 Landing Zone 与网络模式
- 🔐 定义 IAM 控制和安全策略
- 💰 建立成本管理实践
- 📚 编写最佳实践和经验教训文档
- 🚀 为各业务单元赋能创新
Fannie Mae 与 NRO 都利用 CCoE 在完成初始迁移后显著提升了 “创新速度”。
Fannie Mae 预测转型
Business Context
- Purchases 贷款机构的住房贷款
- Packages 将其打包成抵押贷款支持证券
- Sells 将证券出售给投资者
准确、及时的投资组合业绩预测是关键任务。
Challenges
| Challenge（挑战） | Impact（影响） |
|---|---|
| 电子表格密集的流程 | 手工错误，扩展性受限 |
| 系统碎片化 | 数据孤岛，集成复杂 |
| 生命周期终止的基础设施 | 性能瓶颈，维护成本 |
| 专业知识分散 | 知识孤岛，单点故障 |
| 重度定制化 | 变更周期慢，系统脆弱 |
Program Goals（预测转型计划 – 2023 年 9 月启动）
| Metric（指标） | Before（之前） | Target（目标） | Improvement（改进幅度） |
|---|---|---|---|
| 预测生命周期 | ~80 天 | ~10 天 | 降低 87.5 % |
| 压力测试执行 | 串行 | 并行 | 并发处理 |
| 系统整合 | ~80 套系统 | 1 平台 | 降低 98.75 % |
| 计算统一 | ~2,000 | 统一 | 单一真相源 |
| 贷款记录容量 | 有限 | 每次运行 1.5 B | 大幅扩容 |
解决方案的关键属性：
- ⚡ 根据需求自动弹性伸缩计算资源
- 🔒 严格遵守监管合规（安全、审计、数据质量）
- 🎭 全面方法 – 同时解决人员、流程、技术和治理
Architecture Overview
| Component（组件） | AWS Service（服务） | Purpose（用途） | Key Benefits（主要收益） |
|---|---|---|---|
| Data Backbone | Amazon S3 | 统一数据域 | 存储输入数据、模型输出、计算结果、分析数据 |
| Compute Engine | Amazon EMR | 大数据处理 | 处理数十亿贷款记录，多集群自动弹性伸缩 |
| Orchestration | AWS Step Functions | 端到端工作流 | 协调数据摄取、模型、计算、系统集成 |
| Metadata & Config | Aurora + DynamoDB | 配置管理 | 存储场景、模型参数、计算规则 |
| User Interface | Angular on AWS Fargate | 业务用户体验 | 支持场景定义、输入规范、执行触发 |
| Analytics | Amazon SageMaker + Tableau | 报告与分析 | 支持监管报告和内部分析 |
Business Rules in YAML
巧妙的设计将业务计算写入 YAML，实现：
- ✅ 将业务逻辑与应用代码解耦
- ✅ 业务方可在无需重新部署代码的情况下修改规则
- ✅ 缩短规则更新的开发周期
graph TD
A[Business User Input] --> B[Data Ingestion]
B --> C[S3 Data Backbone]
C --> D[Model Execution]
D --> E[EMR Calculations]
E --> F[Output Processing]
F --> G[Analytics & Reporting]Workflow steps（工作流步骤）
- User Input（用户输入）: 业务用户通过 UI 选择场景类型并输入假设。
- Data Ingestion（数据摄取）: 平台从多个记录系统拉取数据。
- Data Storage（数据存储）: 所有数据写入 S3 数据骨干。
- Model Execution（模型执行）: 调用现有及新平台特定模型。
- Rule Application（规则应用）: EMR 根据数千条 YAML 定义的业务规则进行计算。
- Output Distribution（输出分发）: 结果通过 API 与 SNS 发送至下游系统。
- Analytics Preparation（分析准备）: 为监管和管理工具准备数据。
Implementation Challenges
| Challenge（挑战） | Scale（规模） | Solution Approach（解决方案） |
|---|---|---|
| 团队协作 | 100+ 工程师 | 标准化防护栏、编码规范、集成模式 |
| 系统集成 | 76 个上下游系统 | 精细的 API 设计，最小化冲击方式 |
| 项目周期 | 多年时间 | 持续治理、增量交付、自动化测试 |
本次会议强调，结合成熟的迁移模式、强大的治理框架以及专职的 Cloud Center of Excellence，能够让 Fannie Mae 与 NRO 等组织在保持安全、合规和运营卓越的前提下，成功执行大规模迁移。