首页 > 极客资料 博客日记

达云助力绿海数字交易公司实现软件部署上云

2024-09-06 19:30:04极客资料围观25

这篇文章介绍了达云助力绿海数字交易公司实现软件部署上云,分享给大家做个参考,收藏极客之家收获更多编程知识

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系统架构,以更快速的服务速度,完整、合理的服务流程,帮助客户完善系统架构,提升系统安全性,节约用云成本,为客户用好云保驾护航


版权声明:本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:jacktools123@163.com进行投诉反馈,一经查实,立即删除!

标签:

相关文章

本站推荐

标签云