1.概述
本次需要把量化金融交易系统从GCP迁移到AWS。
绿海数字交易公司是一家致力于为全球用户提供安全、高效的数字资产交易服务的公司。管理和运营区块链，实施有效的风险管理策略，保障用户资产安全，同时不断创新和优化交易系统和服务，提升用户体验。致力于探索区块链技术的应用，并严格遵守国际金融监管法规，确保交易平台的合法性和透明度。
1.1.项目目标&痛点
GCP托管服务迁移：客户技术团队深度使用GCP托管服务，在迁移至AWS时需要专业的技术服务商帮助客户匹配到对应的AWS服务，分别对GCP到AWS的服务适配、迁移可行性研究、迁移方法验证等工作；由于两个厂商的产品差异、系统架构和部署方式不同，等导致迁移和重建的工作量较大。如ES迁移、EKS重建等，我们也希望客户使用AWS的时候能有专业指导快速上手，减少不必要风险试错，帮助快速完成客户量化金融系统在AWS上的架构设计、迁移和部署。
客户自建数仓与Aurora PostgreSQL持续同步：客户自建的GreenPlum 7数仓与Postgre SQL兼容，处理的众多数据表需要在业务应用中使用，即需要同步到Postgre SQL数据库使用，大量表的同步会有繁杂的DMS工作以及PG性能问题处理。
Postgre SQL数据库所需要的表从数仓拉取同步一致的。客户的数据表提过有1张几千万行数据的大表，其他业务有几十张小的表需要同步。我们测试验证过很多表DMS CDC，其实对DMS Instance以及Aurora的IO等性能要求较高，这部分已经有DMS最佳实践给客户介绍了，会拆分很多个DMS实例分别同步不同的表，缓解压力也提高容错。
我们之前也推荐过Redshift替代客户自建GP数仓和PG数据库（但测试Redshift不支持大数）所以客户目前还是用更熟悉的自建数仓GP
1.2.预期项目成果
如果满足以下主要标准，客户将认为该项目成功的：
| No. | Descriptions | Measurements |
|---|---|---|
| 1 | Cloud Store文件及ES、PG数据库正常迁移，数据完整性通过验证 | 通过测试 |
| 2 | 应用各项服务功能测试正常 | 通过测试 |
| 3 | EKS集群弹性扩展完成时间≤ 10 min | 通过测试 |
| 4 | DMS可以实时同步到核心Aurora Postgre SQL数据库 | 通过测试 |
| 5 | AWS云资源和应用程序相关监控指标邮箱告警 | 通过测试 |
| 6 | 成本管控，账单清晰 | 通过测试 |
1.3.建议架构图
为满足客户的需求，整体业务系统部署的架构如图所示，将会重点配合实施以下方面：
架构说明
基于AWS架构设计考虑：
运营、安全、高可用、性能、成本、可持续性。
1、 我们规划Landing Zone帮助客户做合理的网络层级划分，项目主要是内部使用，做数据处理分析和模型策略训练使用，外网只放部分NAT和跳板机，主要业务集中在内网执行并做好路由规划和安全组等策略
2、多可用区放置资源执行业务，提高业务安全性，以及扩展上限，也降低单点故障的风险
3、会利用AWS的IAM、CloudTrail等服务，协助管理客户的权限，操作记录，账号资源异常使用情况等问题
监控告警通知设计：
1、 由于客户需要了解业务负载情况，需要协助配置CloudWatch监控告警信息如：EC2状态变化、Health事件、内存、CPU利用率等；对于核心数据库PG的负载和DMS故障提供定制告警，后续优化可能到企业微信或者飞书的方式
2、 推荐使用托管的Prometheus收集EKS集群，计算资源等监控指标结合CloudWatch；客户自己有监控告警方案，按需执行（架构图保留推荐设计，本次项目周期原因客户决定先沿用自建容器监控，后续有时间会测试和看效果考虑使用aws托管的监控）
核心业务EKS集群设计：
1、 WorkerNode使用多可用区域部署保证业务的可用性，在模型测试时会不定期快速启用批量资源测试效果，设计使用Karpenter作为Kubernetes auto scaling工具更快速灵活的方式扩缩容满足业务需求。
2、 核心业务均部署在EKS集群内；
3、 设计集群使用ALB Controller的ingress暴露Services；
4、 单EKS容器集群，节点数量容量为设置2-20台维持基础业务并控制成本，按当前GCP负载预估16台服务器；
5、 每台EC2初始配置50G GP3磁盘后续可按需扩容，并考虑EFS方式集中存放脚本等启动项内容和日志；
6、 将节点部署在Private Subnet，禁止暴露节点在公网保证Nodes的安全可控；
7、 节点组的安全组仅允许来自EKS集群和ELB的访问；
难点问题数据库迁移和同步：
1、 GCP的ES快照导入到AWS Opensearch；
计划使用快照拍摄导出上传到s3的方式完成迁移，ES的停机时间可以预先安排1或2天
如果迁移未完成，则后续增量部分需要考虑做实时增量迁移会增加复杂度。所以提前需要多几次评估测试在当前GCP中ES高负载的情况下执行1TB快照的时间，以及导入到aws端的时间来保障尽量静态迁移
2、 客户自建数仓多个表同步到核心数据库Postgre SQL（详情参考客户背景痛点部分）
1.4.迁移成功交付标准
- 方案符合要求；
- 迁移文档齐全，符合要求；
- 应用及数据迁移全部完成；
- 迁移后功能性符合要求；
- 完成约定范围的迁移设计与实施，业务切换后稳定运行15个工作日。
1.5.交付目标
- 架构优化报告
- 项目增量保驾护航
- AWS 云架构描述
- 账号&IAM 权限最佳实践
- 服务操作验证文件
2. 为什么选择Amazon Web Services
- 有成熟的跨境专线方案和解决能力
- 可扩展EC2开发机，满足高性能计算的要求
- Workspaces满足企业级的安全要求
3. 为什么选择达云
作为AWS APN Select Consulting Partner高级能力伙伴，达云在持续服务客户的过程中了解到客户当前所遇问题和需求，就开始着手和客户一起构建在AWS上的全球研发网络和有效的管理手段。在此期间达云向客户提供技术咨询，帮助客户弥补公有云网络的知识差，以合理的项目规划与管理确保满足客户各项技术要求，实现快速、优质交付，最终推进项目的成功落地。
作为MSP服务提供商，达云不仅帮助客户解决上云最后一公里的问题，同时也持续以专业角度分析和优化客户IT系统架构，以更快速的服务速度，完整、合理的服务流程，帮助客户完善系统架构，提升系统安全性，节约用云成本，为客户用好云保驾护航