Ola Money 实现了运营卓越，在亚太地区海得拉巴建立了灾难恢复站点，并通过使用 Amazo

Ola Money赢得运营卓越与灾难恢复，通过Amazon Aurora实现高达60的成本节约

重点总结

Ola Money成功迁移至Amazon Aurora，实现了显著的运营效率和灾难恢复能力，并在成本上节省了高达60。在这篇文章中，我们将讨论Ola Money的现代化历程，包括迁移至Amazon Aurora的过程、所面临的挑战以及最终的成果。

引言

Ola Money是由Ola金融服务OFS提供的一项金融服务，涵盖Ola集团的多个产品，包括Ola Money信用卡、Ola Money钱包和Ola Money后付。这些产品在印度与300多家合作伙伴集成，包括Ola Cabs和Ola Electric。Ola Money之前的工作负载托管在其他云服务提供商上，采用了“提升与转移”的方式迁移至AWS，AWS在实现公司的商业目标和扩张目标上扮演了重要角色，提供了可靠且可扩展的基础设施。

在本文中，我们将分享Ola Money的MySQL工作负载如何通过Amazon Aurora进行现代化。Aurora是一个针对云构建的关系数据库管理系统，具有MySQL和PostgreSQL兼容性，以十分之一的成本提供商业级数据库的性能和可用性。我们将涵盖迁移到Amazon Aurora MySQL兼容版过程中克服的架构和操作挑战，并讨论迁移带来的结果。

Ola Money之前的架构

在这一部分，我们了解Ola Money之前采用的架构模式，以支持业务需求。我们的数据库管理员DBA负责管理四个自我管理的MySQL集群，这些集群托管在Amazon EC2实例和Amazon EBS卷上。我们使用授权的第三方集群管理和监控工具来管理集群拓扑并扩展数据库读取实例。

Ola Money在处理微服务的高频写请求和商业智能BI仪表板的读取请求时，具有严格的亚毫秒延迟要求。为此，我们采用了命令与查询职责分离CQRS架构模式，该模式通过ProxySQL对写入和读取操作进行明确分离。

数据平台工程师负责管理数据工程平台，包括利用基于事务日志的变更数据捕获CDC记录MySQL数据库表中的数据变更，以便支持Ola的商业智能仪表板，帮助业务利益相关者在近实时中获得更新。

数据管道的关键组件包括：

以下是旧解决方案的架构表示：

关键挑战

我们的DBA团队在支持业务和合规需求方面面临多重挑战。以下是最关键的要求：

运营开销

在自我管理的MySQL数据库架构下，超过40的DBA团队的生产时间定期被无差异的繁重任务所占用。

首先，我们负责琐碎的日常活动，如执行管理任务如更新MySQL数据库库和插件、定期备份、管理集群拓扑等。

其次，我们还负责合规性相关的安全活动：

最后，我们还需要定期优化MySQL集群，包括释放连接到集群实例的EBS卷的空间。为实现我们的成本优化目标，必须逐步手动缩减每个集群及其所有读取节点的基本EBS卷。

成本增加

除了自我管理MySQL集群的基础设施费用，我们还面临额外费用：

迁移至Aurora MySQL

在这一部分，我们讨论从自我管理的Ola Money MySQL集群到Aurora MySQL的迁移过程。

AWS团队建议我们评估Aurora MySQL，并根据自我管理MySQL集群的配置和使用指标计算Aurora MySQL的总拥有成本TCO。结果显示，Aurora MySQL的TCO比Ola Money在Amazon EC2上管理的MySQL集群节省了超过50的成本。

我们迅速获得批准，开始进行Aurora MySQL的概念验证。选择一个自我管理的MySQL集群进行概念验证，使用mysqldump工具生成数据库转储文件，在亚太孟买区域启动Aurora MySQL实例并导入数据；详细信息见使用mysqldump从MySQL迁移到Amazon Aurora MySQL。随着对服务的信心提升，我们继续推进概念验证。

灾难恢复与架构考量

我们选择试点灯pilot light作为Ola Money工作负载的灾难恢复DR策略。在这一部分，我们分享迁移至Aurora MySQL时探索的架构选项及其当前架构设定。

我们评估了以下灾难恢复策略：

尽管Aurora全球数据库有许多优势，包括在区域广泛故障恢复时较低的恢复时间目标RTO和恢复点目标RPO，但我们主要基于MySQL二进制日志的需求选择了跨区域复制作为灾难恢复方案。

在AWS团队的指导下，我们为概念验证中的应用程序架构化，采用Aurora MySQL集群，利用读取副本Reader#1和Reader#2跨越亚太孟买区域的可用区设置高可用性，并在亚太海德拉巴区域通过跨区域复制设立灾难恢复站点，其中有一读取副本Reader#3。以下图示展示了这一架构。

这个架构包含以下关键服务：

Ola金融服务Aurora部署的实验

我们对Aurora MySQL数据库进行了性能测试，将负载增加五倍至生产负载，并使用不同的载荷大小进行插入、删除和更新操作，以验证吞吐量和响应时间。性能测试结果显示，响应时间符合Ola的SLA要求。

我们还利用AWS故障注入模拟器FIS进行混沌实验，模拟故障以提高Aurora MySQL部署的应用性能、可观察性和弹性。我们对Aurora MySQL集群执行了awsrdsfailoverdbcluster操作，观察到Aurora MySQL在30秒内自动切换到新的主实例。我们还进行灾难恢复演练，观察到在故障切换过程中的数据损失最小，但仍在我们的RPO SLA范围内。

这些实验帮助我们确认了使用Aurora MySQL的架构方案，并开始规划数据迁移策略。

数据迁移与切换到Aurora

数据库迁移是一项耗时且至关重要的任务，需要精确规划和实施。对于Ola Money来说，我们需要迁移大约10TB的数据库存储。以下是我们数据迁移计划的讨论，以及如何实现从自我管理的MySQL数据库切换到Aurora MySQL的近零停机时间。

对于自我管理MySQL集群的数据迁移，我们依次执行以下任务：

为了近零停机时间切换到Aurora MySQL，我们执行了以下任务：

我们在删除自我管理MySQL集群之前紧密监测了生产流量和Aurora MySQL集群的性能洞察，持续了几周。

成果

在这一部分中，我们讨论通过此次现代化努力所获得的关键优势。

运营卓越

我们能够将更多精力投入到产品的创新特性上，而不是花费时间和精力在无差异的繁重基础设施和数据库管理操作上。

例如，我们不再需要升级软件库和手动打补丁，因为Aurora提供了自动打补丁的功能，确保使用最新的补丁。与此同时，我们也不再需要管理EBS卷和存储回收操作，因为Aurora MySQL集群的卷会自动增长和缩减，以高效且高度分布的存储系统支持数据增长。迁移或优化表索引以删除数据时，所分配的空间会被释放。这不仅减轻了我们的存储管理任务，还减少了由于自动减少存储使用而产生的费用。

Aurora帮助我们对数据库、自动备份、快照和读副本进行加密，控制这些密钥通过AWS Key Management ServiceAWS KMS。这就使得我们不需要单独管理加密密钥和保险库基础设施，Aurora的磁盘级加密特性避免了表级加密的耗时过程。

成本优化

我们在多个方面实现了成本优化，以下是具体描述。

首先，在计算方面节省了成本。在自我管理MySQL架构下，计算实例需要过度配置以支持峰值扩展需求。但在当前的Aurora MySQL架构上，我们无需过度配置，只需点击几下就能为扩展需求配置一个读取副本。

其次，存储方面节省了成本。在自我管理MySQL架构中，我们通常会过度配置EBS卷以支持未来的数据增长以及像持续备份等附加进程。而在Aurora MySQL架构中，我们不需要再为未来的增长预留过多存储，因为存储卷会以10GB的增量扩展，最大可达128TiB，因此我们只需支付实际使用的存储费用。

使用Aurora时，我们不必为备份存储支付费用，额度可高达数据库集群大小的100。此外，Aurora会在一个区域内自动在三个可用区中确保数据耐久性，但我们只需为一份数据付费，减少了存储成本且提高了集群的容错能力。

第三，我们节省了数据传输成本。在自我管理MySQL架构中，在EC2实例上的写入实例与同一区域内的读取实例之间传输数据会产生区域间的数据传输费用。而在Aurora MySQL中，跨可用区复制的集群数据传输不再收费。

最后，我们节省了集群管理工具和支持费用。使用Aurora之后，我们不再需要第三方集群管理和监控软件，因为Aurora是一个完全托管的AWS服务，提供了管理MySQL数据库集群所需的所有功能。因此，我们在采用Aurora后，节省了第三方集群管理和监控软件的许可和支持费用。

性能提升

在之前自我管理的MySQL数据库架构中，主区域扩展MySQL读取副本经常花费数小时，因为这个过程依