发布于: Oct 10, 2022
Autodesk 公司多年之前就已经启动了自己的云计算现代化之旅，着手将工作负载从本地数据中心迁移至 Amazon EC2 及其他 Amazon Web Services 服务当中。Autodesk 之所以积极推进现代化改造，自然是为了获取必要的灵活性与可扩展性，支持业务的预期增长。2019年，该公司将其关键任务单点登录（SSO）应用从 EC2 上的自托管 SQL Server 中迁移至全托管 Amazon Aurora MySQL。此项服务需要应对全球各地超过1.42亿用户的身份验证请求，每分钟API请求响应数量超过14万5千次。此外，该应用还整合了300多种用于实现身份验证与授权操作的产品及服务。
此次迁移有助于简化 Autodesk SSO 服务的管理与弹性、优化运营成本并降低基础设施的维护开销。根据初步成本分析结果，该公司在使用 Amazon Aurora MySQL 之后每月总体数据库成本可下降约40%至50%。
通过本文，我们将探讨 Autodesk 公司如何在尽可能缩短停机时间的前提下，对关键任务数据库进行迁移。以下各章节将分别介绍迁移前架构、迁移策略等相关议题。
下图所示，为 Autodesk 以往使用的 SQL Server 架构。该数据库以自托管形式在 EC2 实例之上运行，且跨越多个可用区与另一区域内的单一节点建立起 Always On 机制，借此实现灾难恢复能力。
随着时间推移，Autodesk 团队发现现有配置中存在以下挑战：
- 中断——以往发生的诸多中断事件，正是由于这套复杂的自找托管数据库基础设施所导致。整个体系中涉及多个采用 Amazon EBS 加RAID 10 存储配置的 EC2 实例，结果就是 Windows Server 故障转移集群（WSFC）、存储以及 IOPS 等众多元素构成极为复杂的分层体系。更重要的是，运营团队越来越难以对事件根源进行分析与追溯。
- 备份——管理备份也带来可观的开销，特别是在跨区域设置层面。尽管我们使用了自动化脚本，但整个备份流程仍然需要人为介入与严格监控。
- 补丁修复——由于 Autodesk 公司拥有多个环境（包括测试环境、暂存环境与生产环境），因此补丁修复消费了管理员们大量宝贵的时间。
- 可扩展性——主节点负责填写只读路由请求，同时标记需要接入的辅助节点。尽管此功能能够保证连接始终被路由至运行状态良好的辅助节点，但从可扩展性的角度来看，主节点的存在本身即是最大的瓶颈。
- 副本数量——SQL Server 最多允许设置8个辅助副本，而 Aurora MySQL 最多可支持15个副本。
- 成本——原本的总体拥有成本，达到迁移至 Aurora 之后新体系的两倍
- 弹性——对基础设施进行规模伸缩需要耗费大量时间。
我们从概念验证起步，借此确定需要完成的应用程序变更、数据库变更、脚本自动化以及各类预创建服务。更重要的是，我们还借此确定迁移至 Aurora 这一举措能够有效解决前面提到的种种挑战。
在实施必要的变更之后，我们制定了计划，以分阶段方式迁移至不同环境。以此为基础，我们对策略进行微调，逐步明确了在不同环境上运行迁移时所带来的相应停机时间。我们的目标是在最少的停机时长之内完成迁移。为了在不同环境间灵活高效地实现迁移，我们利用 Terraform 自动执行数据库创建与 DMS 配置等步骤。当然，大家也可以使用 Amazon CloudFormation 实现相同的自动化效果。
在以下章节中，我们将具体探讨迁移过程中的各注意事项。
Amazon Schema 转换工具 是一款出色的 schema 迁移工具，能够将迁移工作量控制在最低水平。但在本示例中，由于存在大量定制化需求，我们只能放弃效率、选择更适合的 schema 转换方法。
作为 schema 转换流程中的一部分，我们首先为数据库选择了最佳字符集。如此一来，我们的数据库体积将缩减到原始大小的三分之一左右。对数据库的成功“瘦身”，将在迁移过程中带来巨大助益。
在确定目标数据库的最终架构之前，我们需要全面评估以下因素：
- 字符集与排序规则
- 数据类型选择
- 日期/时间模式
- 多字节字符存储
- 特殊字符存储
- 索引类型
我们对容量规划进行了广泛测试，包括迭代运行工作负载以确定合适的实例大小与对应容量。此外，我们还比较了来自各类监控工具（例如 Amazon CloudWatch、New Relic 以及 MonYog）的关键指标、分析慢查询日志，并对现有生产工作负载/流量及未来数据增长做出预测。
应用程序迁移将以无缝化形式进行，因为我们使用 NHibernate（ORM）进行数据访问。ORM 生成约80%的查询比例，因此我们可以在应用程序内以最少的 ORM 配置变更生成 MySQL 查询。这里也建议大家首先观察应用程序通过 ORM 生成了多少查询，并据此估算转换其余查询所需要的具体工作量。
我们在 SSO 应用程序中开发了一项功能，用于支持按需数据库连接切换并进一步实现对读取/写入流量的控制。以此为基础，我们能够在整个迁移计划中实现连续部署与跨环境执行。最后，这项举措还有助于最大程度减少数据库切换操作所带来的停机时间。
之前，我们使用的是完整 .NET 框架，遗憾的是带有 NHibernate 的 .NET 完整框架中的 MySQL 驱动程序并不支持 Aurora MySQL 故障转移功能。换句话说，我们的应用程序将无法自行实现故障恢复。为此，我们提出了一项自定义解决方案，针对 .NET 中 MySQL 驱动程序缺失的问题为 Aurora MySQL 故障转移提供新的支持方法，确保应用程序能够在迁移过程中继续正常支持业务流量。
数据迁移与验证是整个迁移流程中的重要一步。我们使用 Amazon DMS 以实现安全且经济的迁移效果。关于更多详细信息，请参阅 Amazon Database Migration Service 上手指南。