达云助力PhotonDB实现软件部署上云
1.概述
本次需要迁移整体平台系统从阿里云迁移到AWS。
客户自2021年起已在香港阿里云部署平台，考虑到海外业务需求旺盛，希望通过在AWS Global部署应用来提高全球覆盖率，同时也强烈希望通过使用AWS来提高大数据平台的效率 AWS 的解决方案。
帮助客户了解AWS服务，设计云上架构、协助项目测试、服务迁移和部署优化。
将从2023年1月开始帮助客户进行迁移，大约需要三个月时间完成。迁移前需要详细了解客户在友商上的资源使用情况、业务部署架构；梳理业务模块，了解数据使用量等诸多信息。后续持续保障业务稳定和增量。
本次项目涉及阿里云既有资源迁移，以及新增服务部署：
1）阿里云当前的托管服务有：RDS PostgreSQL、ACK、Redis、Elasticsearch、OSS、Kafka；
PostgreSQL目前在阿里云版本为12、13，多个业务的数据库加起来约有10T数据，部分用于数据分析数据库IO负载很高。有的迁移前需对PostgreSQL数据库升级版本后再行迁移，托管Redis 基本都用的兼容5.0的，有较多的小规格的实例；以及做检索标签，和日志查看用的Elastisearch 7.10，对应搭配Amazon OpenSearch的适配需要考虑；
2）阿里云CDN服务和对象存储，比较简单，CDN一部分是做动态网络加速，一部分少量下载使用配合网页，OSS做数据存储归档应用，需要迁移适配到CloudFront和S3的方式完成，做权限管控设计和存储分层；
3）本次需要迁移客户全部服务到AWS，使用了阿里云的ACK相关容器服务，涉及厂商的容器化平台到AWS EKS的迁移；迁移前需要详细了解客户在阿里云上的资源使用情况、业务部署架构；梳理业务模块，了解数据使用量等诸多信息；所涉及客户全部整体架构，业务逻辑API、支付充值、用户服务、业务鉴权等应用系统；客户 分析Greenplum数仓平台，以及Redshift测试改造
1.1.项目目标&痛点
- 阿里云网络无法满足业务需求：随着业务在海外的运营推广，后续规划业务发展用户群体会从东南亚到中东欧美等地区。为了业务扩展的同时保证用户体验，降低网络延迟，需要更好的海外网络基础设施；AWS在全球超过 400 个边缘站点并使用全球骨干网连接，坚实的基础设施符合客户的要求。
- 阿里云托管服务迁移：技术团队深度使用阿里云托管服务，在迁移至AWS时需要专业的技术服务商帮助客户匹配到对应的AWS服务，分别对阿里云到AWS的服务适配、迁移可行性研究、迁移方法验证等工作；由于两个厂商的产品差异、系统架构和部署方式不同，导致迁移工作量较大。
- 寻找快速部署和迁移能力的服务提供商：客户需要寻找 AWS经验丰富和技术能力较强的服务商，能够为客户提供优秀的迁移解决方案以及部署能力，帮助客户快速的完成客户平台应用的POC测试与迁移部署。客户运维人员较少，由于之前深度使用阿里云对AWS不熟悉，需要服务商能够提供足够强的技术和人力，帮助快速完成客户平台在AWS上的架构设计、迁移和部署。
也希望在接触使用AWS的时候能有专业指导快速上手，减少不必要风险试错，帮助快速完成客户广告投放平台在AWS上的架构设计、迁移和部署。
1.2.选择AWS的原因
- 安全合规：客户属于金融相关行业，需要遵守强制性法规。其中一项要求是维护可靠的灾难恢复计划。该公司需要一个可靠且享有盛誉的云合作伙伴，该合作伙伴还可以提供各种服务来帮助公司克服其 IT 基础架构挑战；
- 行业解决方案：AWS在东南亚拥有强大的影响力，新加坡拥有多个可用区。在此区域AWS拥有许多与 客户相似的客户。因此，客户信任AWS来运行其整个运营，包括关键的生产工作负载。AWS已经帮助了众多新加坡当地的金融科技公司。因此，AWS有丰富的经验来支持客户快速顺利地部署其工作负载并扩展其业务；
- 成本管理灵活：AWS平台能够灵活的选择资源的购买方式，动态调整使用资源，可以满足某些资源用量突增或者临时需要快速对服务器升配的需求；并且在存储、带宽以及成本优化方面帮助用户节约成本。
1.3.预期项目成果
如果满足以下主要标准，客户将认为该项目成功的：
| No. | Descriptions | Measurements |
|---|---|---|
| 1 | 数据库正常迁移，数据完整性通过验证 | 通过测试 |
| 2 | 相关应用各项服务功能测试正常 | 通过测试 |
| 3 | EKS集群弹性扩展完成时间≤ 30 minutes | 通过测试 |
| 4 | 数仓平台应用视图串接，用户画像、交易信息、活跃度成交量等页面正常展示 | 通过测试 |
| 5 | 各地办公室连接访问应用主站测试平均延迟，东南亚低于60ms，欧美地区低于300ms | 通过测试 |
| 6 | AWS云资源和应用程序相关监控指标告警至企业微信 | 通过测试 |
| 7 | 自建开源的prometheus+grafana服务器能正常监控服务器，应用，数据库，数仓等各项指标 | 通过测试 |
| 8 | 系统日志/AWS托管服务日志能正常写入Opensearch，呈现实时日志。另一部分Opensearch也被用于检索标签数据，即时分析 | 通过测试 |
1.4.建议架构图
为满足客户的需求，整体业务系统部署的架构如图所示，将会重点配合实施以下方面：
架构说明
本次项目涉及阿里云既有资源迁移，以及新增服务部署。环境现况以及难点如下：
阿里云当前的托管服务有：RDS PostgreSQL、ACK、Redis、Elasticsearch、OSS、Kafka；
PostgreSQL目前在阿里云版本为12、13，多个业务的数据库加起来约有10T数据，内部有部分大表较难处理，且用于数据分析数据库IO负载很高，导出速度受影响。部分数据库迁移前需对PostgreSQL数据库升级版本后再行迁移，托管Redis 基本都用的兼容5.0的，有较多的小规格的实例；以及做检索标签，和日志查看用的Elastisearch 7.10，对应搭配Amazon OpenSearch的适配需要考虑，后续还有对标阿里的日志服务做日志统一管理；
阿里云CDN服务和对象存储，比较简单，CDN一部分是做动态网络加速，一部分少量下载使用配合网页，OSS做数据存储归档应用，需要迁移适配到CloudFront和S3的方式完成，做权限管控设计和存储分层；
本次需要迁移客户全部服务到AWS，使用了阿里云的ACK相关容器服务，涉及厂商的容器化平台到AWS EKS的迁移；迁移前需要详细了解客户在阿里云上的资源使用情况、业务部署架构；梳理业务模块，了解数据使用量等诸多信息；所涉及客户全部整体架构，业务逻辑API、支付充值、用户服务、业务鉴权等应用系统；客户 分析Greenplum数仓平台，以及Redshift测试改造，无论是改造到Redshift还是自建Greenplum的迁移都是有较大挑战的。
网络设计：
1、在新加坡Region创建生产环境VPC网络
2、在两个可用区分别建立Public Subnet和Private Subnet；NAT Gateway、ELB，堡垒机部署在公有子网；EKS WorkerNodeGroup在私有子网，私有子网的WorkerNode通过NAT访问互联网；关系型数据库及非关系型数据库部署在私有子网中；使用CloudFront加速全球用户的访问。
安全设计：
1、IAM账号权限划分以及分组：为运维、开发、管理人员设置不同的IAM账号和权限，强制开启MFA；
2、配置EC2、RDS、等服务安全组，基于最小权限原则配置规则；
3、开启Cloud Trial日志审计，记录用户及资源的活动情况；
4、使用AWS Config统一管理配置信息；
EKS集群设计：
1、 WorkerNode使用多可用区域部署保证业务的可用性，因客户业务场景在APP推广期间会有较高的瞬时流量，对弹性扩缩有较高的要求。设计使用Karpenter作为Kubernetes auto scaling工具更快速灵活的方式满足客户的需求，大大降低了运维的工作量。
2、 客户核心业务均部署在EKS集群内，包含业务逻辑API、用户中心、交易系统、风控评估等等；
3、 设计集群使用ALB Controller的ingress暴露Services；
4、 节点数量最小容量为12台，最多30台以便在波峰时扩展集群；
5、 每台EC2初始配置100G GP3磁盘后续可按需扩容；
6、 将节点部署在Private Subnet，禁止暴露节点在公网保证Nodes的安全可控；
7、 节点组的安全组仅允许来自EKS集群和ELB的访问；
日志收集方案设计：
1、 日志收集方案采用AWS解决方案集中式日志记录，帮助客户在单个控制面板，收集、分析和显示。同时可以整合来自不同来源的日志文件，收集来自CloudFront、ELB、EKS应用日志文件；
2、 Kinesis Data Streams 可以快速、实时的收集和处理大量日志，并且实时聚合数据；使用Lambda 进行日志分析处理；Kinesis Data Firehose 捕获、转换流数据并将其加载到S3中，并且可以自动扩展以适应不同的吞吐量，还可以在加载数据前对其进行批处理、压缩和加密，从而最大程度的减少存储量，控制成本，同时提高安全性；
3、 借助OpenSearch 对日志进行实时的分析处理，并为管理者提供实时的搜索查询服务，使用OpenSearch Dashboard 可以方便技术人员更直观的去查看日志分析结果，简化了操作步骤，提高了便利性；使用Cognito 可以方便的管理用户，为不同的用户提供身份验证、授权，提高安全性。
监控告警通知设计：
1、 由于客户历史使用习惯，需要通过即时软件企业微信接受来自AWS资源的告警例如：EC2状态变化、Health事件、内存、CPU利用率等；
2、 设计使用EventBridge、SNS、Lambda 配置触发Webhook通过企业微信发送告警消息；
3、 使用托管的Prometheus收集EKS集群，数仓等计算资源等监控指标结合托管的AMG Grafana可视化；并集成到告警方案，触发SNS发送告警至企业微信
Greenplum数仓设计：
1、 Greenplum部署架构设计2分片2副本和3台Zookeeper节点；
2、 使用Greenplum Proxy实现集群的读写分离，负载路由，查询缓存；
3、 Prometheus实现Greenplum集群监控，监听并存储Greenplum各节点Greenplum_exporter和node_exporter的实时状态数据
4、 Greenplum提供了专用的S3表引擎，为客户配置交付S3分层存储，定义Greenplum热数据存储在本地盘，海量数据定时或者达到数据量交付至S3，帮助客户实现低成本的海联数据仓库。
5. 基于Greenplum数仓使用开源SuperSet BI工具，可视化用户数据包含：用户画像、留存分析、交易历史、风控指标、使用深度等。
1.5.迁移成功交付标准
- 方案符合要求；
- 迁移文档齐全，符合要求；
- 应用及数据迁移全部完成；
- 迁移后功能性符合要求；
- 完成约定范围的迁移设计与实施，业务切换后稳定运行15个工作日。
1.6.交付目标
- 架构优化报告
- 项目增量保驾护航
- AWS 云架构描述
- 账号&IAM 权限最佳实践
- 服务操作验证文件
2. 为什么选择达云
作为AWS APN Select Consulting Partner高级能力伙伴，达云在持续服务客户的过程中了解到客户当前所遇问题和需求，就开始着手和客户一起构建在AWS上的全球研发网络和有效的管理手段。在此期间达云向客户提供技术咨询，帮助客户弥补公有云网络的知识差，以合理的项目规划与管理确保满足客户各项技术要求，实现快速、优质交付，最终推进项目的成功落地。
作为MSP服务提供商，达云不仅帮助客户解决上云最后一公里的问题，同时也持续以专业角度分析和优化客户IT系统架构，以更快速的服务速度，完整、合理的服务流程，帮助客户完善系统架构，提升系统安全性，节约用云成本，为客户用好云保驾护航
