Autodesk 是 3D 设计、工程和娱乐软件领域的领先企业。Autodesk 为创造事物的人提供软件。只要您开过高性能汽车，瞻仰过耸峙的摩天大楼，使用过智能手机，或者观赏过宏大的电影，您可能已经体验了数百万 Autodesk 用他们的软件取得的成就。
Autodesk 在上运行的 MySQL 托管数据库和在上托管的自我管理的 MySQL 数据库都已成功迁移到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 时的一些关键优先领域如下：
Aurora 的吞吐量最高可达标准 MySQL 数据库的五倍。这种性能的提升意味着 Autodesk 可以在不修改应用程序的前提下取消 MySQL 带来的节流限制，同时仍然拥有很大的裕度以满足未来增长之需。Aurora 采用分布式、容错型、自我修复式的存储系统，可自动最高扩展至 64 TB，无需手动扩展数据库的存储容量。它最高可配置 15 个低延迟的 Aurora 副本，提高了可用性并支持读取扩展，典型的复制延迟在 100 毫秒以下。
Autodesk 使用 Aurora 副本来卸载主实例的读取负载，并实现读取操作的横向扩展。此外，借助快速克隆、时间点还原和持续备份到，以及跨三个可用区复制的能力，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 利用率。
下图显示了迁移之前和之后的应用程序响应时间。
Autodesk 的响应时间缩短了 2 倍。
下面我们进一步深入介绍迁移过程和经验教训。
迁移最佳实践和经验教训
Autodesk 与AWS 专业服务接触以支持迁移到 Amazon Aurora。下文概括了所有考虑因素以及按照AWS 架构完善的框架五大支柱分类的最佳实践：
可靠性
性能效率
卓越运行
安全性
我们在服务中建立 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 的环境进行评估后，我们得出以下发现：
虽然这种配置对 BIM 360 Field Classic 有效，但 Autodesk 仍然不得不管理从 EC2 实例级别的备份到数据库备份的大量领域。其中，确保数据库的高可用性并实施应用程序故障灾难恢复策略十分重要。同样，Autodesk 还需要管理应用程序节点以平衡查询负载，保持逻辑二进制日志复制的数据完整性。虽然这些操作是可行的，但它们的扩展性不好，要求大量的资源和规划。迁移到 Amazon Aurora 后实现了高可用率、故障转移和负载均衡机制的自动化和简化，因为这些都是 Amazon Aurora 的自带功能。
迁移到 Aurora
我们评估了Amazon Aurora 迁移手册介绍的不同迁移方法，然后为此迁移选择了使用开放源工具 Mydumper 的逻辑备份方法。使用 r4.16xlarge 实例并行配置总体数据传输进程，进一步加快了迁移的过程。
为了进一步优化成本并满足多个 Autodesk 应用程序的额外要求，我们执行了以下操作：
小结
借助 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。
作者介绍：
Piyush Patel
AWS 专业服务部的高级大数据顾问。他与客户一起工作，提供有关大数据和分析项目的指导和技术协助，帮助客户在使用 AWS 时提高其解决方案的价值。](https://static001.infoq.cn/resource/image/39/36/39d7074ef90a74849baf3850515a8f36.png)
