Autodesk 如何借助 Amazon Aurora 提升数据库可扩展性并降低复制延迟

Autodesk 是 3D 设计、工程和娱乐软件领域的领先企业。Autodesk 为创造事物的人提供软件。只要您开过高性能汽车，瞻仰过耸峙的摩天大楼，使用过智能手机，或者观赏过宏大的电影，您可能已经体验了数百万 Autodesk 用他们的软件取得的成就。

Autodesk 在 Amazon RDS 上运行的 MySQL 托管数据库和在 Amazon EC2 上托管的自我管理的 MySQL 数据库都已成功迁移到Amazon Aurora。本博文概括了这一经历，包括以下几个方面：

影响 Autodesk 决定迁移到 Amazon Aurora 的因素
具体的迁移优势
迁移和优化的最佳实践和经验教训

我们首先来看 Autodesk Access Control Management (ACM) 应用程序的迁移路径，此应用程序是在云中诞生的。我们一开始就选择了 Amazon RDS for MySQL，并迁移到 Aurora 以提高可扩展性、可用性和性能。ACM 的迁移非常成功，促使 Autodesk 将多个其他的应用程序也迁移到 Aurora。在将 EC2 上托管的自我管理的 MySQL 数据库迁移到 Amazon Aurora 方面，一个典型的例子是 BIM 360 Field Classic。

ACM 应用程序的架构以及在使用 MySQL 上面临的挑战

下图简要概括了 ACM 的初始架构。为了确保高可用性，应用程序层由跨多个可用区的 EC2 实例组成。流量使用 Elastic Load Balancing 服务进行分配。此外还使用 EC2 Auto Scaling 来调整 EC2 实例的数量，以处理应用程序的突增流量。

尽管这种架构允许 Autodesk 扩展和平衡应用程序的负载，但瓶颈很快就转移到数据库。应用程序连接单个 RDS MySQL 数据库实例，限制了可用的扩展选项。一个方法是增加数据库实例的大小。这种方法仍然受到可以预置的数据库实例的最大型号制约。ACM 很快就超出了最大可用实例的容量限制。

下一个选项是增加 RDS Read Replica 实例的数量以卸载主实例的读取流量，从而横向扩展数据库容量。Autodesk 希望复制延迟能低于一秒，从而为所有 ACM 用户提供稳定的体验。与只读副本有关的复制延迟取决于主实例和只读副本实例的工作负载压力。（这里的复制延迟是指写操作的结果在只读副本上可见所需的时间。）

除非重新设计 ACM 的架构，将数据跨多个 MySQL 数据库进行分拆，Autodesk 不得不对应用程序进行控制，限制指向数据库的负载以减少复制延迟。这种方法是不可持续的，因为 ACM 的采用受到所实施限制的严重制约。这导致 Autodesk 决定评估 Amazon Aurora 等替代方案。

Amazon Aurora 力挽狂澜

Autodesk 开始评估 Aurora 时的一些关键优先领域如下：

增强性能
低复制延迟以实现读取扩展
完全兼容 MySQL（直接迁移）
自动存储扩展

Aurora 的吞吐量最高可达标准 MySQL 数据库的五倍。这种性能的提升意味着 Autodesk 可以在不修改应用程序的前提下取消 MySQL 带来的节流限制，同时仍然拥有很大的裕度以满足未来增长之需。Aurora 采用分布式、容错型、自我修复式的存储系统，可自动最高扩展至 64 TB，无需手动扩展数据库的存储容量。它最高可配置 15 个低延迟的 Aurora 副本，提高了可用性并支持读取扩展，典型的复制延迟在 100 毫秒以下。

Autodesk 使用 Aurora 副本来卸载主实例的读取负载，并实现读取操作的横向扩展。此外，借助快速克隆、时间点还原和持续备份到 Amazon S3，以及跨三个可用区复制的能力，Aurora 帮助 Autodesk 进一步降低了运营开销。

下图显示了迁移到 Aurora 后的 ACM 应用程序架构。

在此架构中，Aurora 集群包含一个写实例和最高四个 Aurora 副本。Aurora Auto Scaling 将会启用以根据 CPU 利用率自动调整 Aurora 副本的数量。

迁移到 Aurora 后，数据库的性能超过了预期。Autodesk 发现，应用程序的扩展性提高了 20 倍，应用程序的响应时间缩短了 2 倍，并且 Aurora 支持的数据库连接数量增加了 7 倍。迁移的亮点在于 CPU 利用率比类似大小的数据库实例减少了 10 倍，为数据库跟随 ACM 的扩展增长留下了空间。我们获得了迁移之前和之后 MySQL 与 Amazon Aurora 的一些比较图，这进一步印证了这些提升。

Autodesk 的 CPU 利用率下降了 10 倍，从使用 MySQL 时高达 100% 的峰值水平降至使用 Amazon Aurora 后不到 10% 的水平。下图显示了迁移之前和之后的 CPU 利用率。

MySQL

Aurora

下图显示了迁移之前和之后的应用程序响应时间。

Autodesk 的响应时间缩短了 2 倍。

MySQL

Aurora

下面我们进一步深入介绍迁移过程和经验教训。

迁移最佳实践和经验教训

Autodesk 与 AWS 专业服务接触以支持迁移到 Amazon Aurora。下文概括了所有考虑因素以及按照 AWS 架构完善的框架五大支柱分类的最佳实践：

可靠性

测试和验证：我们在暂存环境中进行了负载测试，使用 5 倍正常流量来测试一个 Aurora 写实例和四个 Aurora 副本，以验证性能的提升并确保未来的可扩展性。测试结果证明即使在持续的负载条件下，CPU 利用率也低于 10%。此外应用程序延迟要求也被超越。Aurora 在一个 Aurora 集群中最高支持 15 个 Aurora 副本。由于我们仅使用了四个 Aurora 副本，我们有充分的裕度以增加 Aurora 副本的数量，从而扩展读取能力。Aurora 可以自动将存储容量最高扩展至 64 TB。ACM 数据库大约为 1 TB，因此还有充分的存储容量增长空间。
多可用区部署：为了提高可用性并实现快速故障转移，我们在不同的可用区 (AZ) 创建了 Aurora 副本。使用 Aurora 副本的目的有两个：一是作为主实例的故障转移目标实例，二是卸载低延迟的读取操作，因为这些操作与主实例使用相同的存储。我们为每个 Aurora Replica 设置了故障转移优先级，以明确主实例不可用时调用 Aurora 副本的顺序。Aurora 存储会在三个可用区保存六个数据副本，并分布于数百个存储节点上。这种功能有利于即使整个可用区发生连接丢失（尽管可能性极低）时，认可确保完全的读写可用性。
分散负载：通过连接到读取终端节点，Aurora 可以对整个数据库集群中的副本连接进行负载平衡。这种方法有利于分散读取工作负载，从而可以提高性能，更均衡地利用每个副本可用的资源。ACM 数据库的工作负载以读取为主，大约 90% 的工作负载都为读取负载。配置四个 Aurora 副本可让我们将读取工作负载卸载并分配到副本上。与此同时，我们还提高了应用程序的连接池容量，从而更好地使用 Aurora 副本。
迁移期间共存：在首次迁移期间，我们还在 Aurora 和 RDS MySQL 之间建立了副本以确保能够安全回滚。成功完成生产转移一周后，我们取得了充分的信息，并决定不再需要回滚环境并在那时终止了该副本。给予 MySQL 二进制日志的副本要求极高的性能，可能导致写操作性能降级。除非出于运行的原因需要，否则我们建议关闭二进制日志功能。
持久性和灾难恢复 (DR)：Aurora 跨三个可用区建立了六个数据副本，并持续将数据备份到 S3 中。出于灾难恢复的原因，我们在另一个 AWS 区域增加了一个跨区域制度副本 Aurora 集群，并在暂存环境中模拟了灾难恢复演练，以帮助确保发生大型灾难时的运行就绪情况。

性能效率

合理调整大小：我们用不同的实例类型进行负载测试，并选择 r3.8xlarge 实例以保证最优的成本性能效益。此外，我们还比照 MySQL 进行负载测试结果的基准比较，以衡量通过迁移到 Aurora 实现的性能提升水平。我们调整主实例的大小以主要服务写操作，而不过度预置主实例以同时服务写操作和读取操作。然后增加 Aurora 副本来提升读取性能。
可选优化：虽然一般不会要求，您仍可以使用可用的 MySQL 参数来优化查询的执行。例如，我们增加了查询缓存的容量以提高重复读取的性能。此外，我们还监测长时间运行的查询并减少事务的长度。如需有关 MySQL 参数的详细信息，请参阅 MySQL 参考手册。

卓越运行

性能优化：我们按 5 秒的间隔为 Aurora 集群启用了增强监控，寻找长时间运行的查询。同时，我们还计划了分析表和收集新统计数据的周例行作业。这可让我们缩短事务处理时间，减少长时间运行的查询。
持续监控：我们创建了 Amazon CloudWatch 控制面板来保持对关键 Aurora 集群指标以及应用程序指标的可见性。默认情况下，AuroraReplicaLag 指标（代表主实例和 Aurora 副本之间的复制延迟值）将每隔一分钟发布到 CloudWatch。我们配置了一个自定义的 CloudWatch 指标，以每个一秒收集该值，以确保对复制延迟的更精细掌握。我们还创建了 CPU 利用率、内存利用率、DML 和 DDL 查询延迟和吞吐量以及缓冲区高速缓存命中率等关键指标的事件订阅和报警。另外，我们还使用 Amazon SNS 设置了自动向负责团队发送事件通知。
建立自动化机制：我们采用 AWS CloudFormation 模板来预置 Aurora 集群和自动扩展 Aurora 副本。这显著降低了预置新堆栈所需的时间。在此自动化机制的基础上，我们部署了蓝绿架构来实现零停机升级和发行管理。

安全性

我们在 Amazon VPC 服务中建立 Aurora 集群，并配置了安全组来隔离对 Aurora 集群的访问。Aurora 中也启用了加密来确保静态数据的安全。Aurora 上启用加密时，备份和快照都会自动加密。此外，我们还配置应用程序以使用安全套接字层 (SSL) 连接到 Aurora 实例。

成本优化

由于新环境中应用程序的负载是不确定的，我们决定使用四个 r3.8xlarge Aurora 副本对 Aurora 进行超额预置。成功迁移后，我们继续使用 CloudWatch 指标来监控数据库的性能和利用率。在我们对新系统的稳定性有了充分的信心后，我们使用收集的指标来合理调整环境的大小。为此，我们根据 CPU 利用率来配置 Aurora 以优化 Aurora 副本的利用率。今天，根据工作负载的不同，我们的 Aurora 集群包含一个主实例，并且最高可以扩展四个 Aurora 副本实例。

那么接下来呢？

Autodesk ACM 数据库成功迁移并且在迁移后取得了显著的性能提升后，Autodesk 已经开始为多个应用程序采用 Amazon Aurora。BIM 360 Field 团队执行的迁移工作就很好地展现了如何从自我管理的 MySQL 数据库迁移到 Amazon Aurora。

BIM 360 Field Classic

成功迁移 ACM 后，Autodesk 委托 AWS 专业服务部门执行另一项迁移。这次我们将在 Amazon EC2 上托管的 BIM 360 Field Classic 应用程序迁移到 Amazon Aurora，它采用自我管理的 MySQL 数据库，共有六个节点。这个 MySQL 数据库由一个主写实例和五个只读副本组成。在对 BIM 360 Field 的环境进行评估后，我们得出以下发现：

AWS BIM 360 Field 应用程序数据库含有大约 2 TB 的数据。
高可用率和故障转移通过位于应用程序和数据库之间的中间件层实现。
故障转移应用程序也托管在 EC2 上。
Aurora 副本通过基于 MySQL 二进制日志的副本连接到主实例，同时也作为故障转移的目标实例，以实现在 10 秒或以内完成故障转移。
应用程序根据每个副本配置的端口数量，手动将查询路由到所有五个节点。
备份通过每天运行 Percona XtraBackup 和 MySQLDump 脚本进行配置。此外还配置了 EC2 实例级别的快照脚本，以实现实例级别的恢复。

虽然这种配置对 BIM 360 Field Classic 有效，但 Autodesk 仍然不得不管理从 EC2 实例级别的备份到数据库备份的大量领域。其中，确保数据库的高可用性并实施应用程序故障灾难恢复策略十分重要。同样，Autodesk 还需要管理应用程序节点以平衡查询负载，保持逻辑二进制日志复制的数据完整性。虽然这些操作是可行的，但它们的扩展性不好，要求大量的资源和规划。迁移到 Amazon Aurora 后实现了高可用率、故障转移和负载均衡机制的自动化和简化，因为这些都是 Amazon Aurora 的自带功能。

迁移到 Aurora

我们评估了Amazon Aurora 迁移手册介绍的不同迁移方法，然后为此迁移选择了使用开放源工具 Mydumper 的逻辑备份方法。使用 r4.16xlarge 实例并行配置总体数据传输进程，进一步加快了迁移的过程。

为了进一步优化成本并满足多个 Autodesk 应用程序的额外要求，我们执行了以下操作：

启用 Aurora Auto Scaling 以根据 CPU 利用率自动调整 Aurora 副本的数量。不再持续运行多个副本，而仅在需要时增加副本，从而节约成本。
为所有 Aurora 集群部署 Aurora 快照工具，从而自动跨 AWS 区域复制快照副本并实施超过 35 天的 Aurora 快照保留规则。这是为了满足 Autodesk 对恢复点目标 (RPO) 和恢复时间目标 (RTO) 的要求。快照工具使用 AWS 生态系统中的多个 AWS 服务（例如 AWS Lambda 和 AWS Step Functions）来自动跨 AWS 区域和账户复制快照副本。
为 Amazon Aurora Audit 启用 CloudWatch Logs 以将审计日志发布到 CloudWatch Logs，创建 CloudWatch 指标和警报，从而持续监控 Aurora 数据库集群中的活动。

小结

借助 Amazon Aurora，ACM 和 BIM 360 Field Classic 应用程序都成功提高了可扩展性，提升了应用程序性能，降低了管理开销，优化了成本。

“ACM 数据库的大小约为 1 TB，只有少数的表超过十亿行。高峰时期我们每分钟会收到高达 25000 至 30000 条请求，”Autodesk 公司高级工程经理 Krishna Kumar 说。“我们在建立一个可以满足应用程序增长百倍需求的策略。我们肯定会将 Aurora 视为 ACM 路线图的重要组成部分，感觉 Aurora可以为我们提供解决这些扩展挑战的能力。”

ACM 成功迁移到 Aurora 让许多 Autodesk 团队明确了总体方向，也就是发挥 Aurora 更好的性能、可扩展性和可用性优势的方向。Autodesk 制定了向 Aurora 迁移的战略，正积极实施多个应用程序堆栈的迁移工作，以开始使用 Aurora，其中最典型的例子就是 BIM 360 Field Classic。

亚马逊AWS官方博客