道琼斯如何一次性迁移其业务关键型数据库并实现现代化以改善效率和成本效益

关于 Market Data 的平台架构

在峰值容量下，道琼斯通过 Market Data 平台每秒处理超过 3000 个请求。数据范围从交易所的官方收盘价到实时价格数据、公司信息和映射数据。之后，道琼斯 Market Data 平台会在道琼斯内部提取、规范化和展示这些市场数据。考虑到这些数据对业务的战略价值，该平台必须高度可靠、可扩展和快速高效，能够在几毫秒内向使用者提供实时市场数据，并避免停机。

在对该平台进行现代化改造之前，该系统由超过 44 个独立的应用程序组成，这些应用程序在四组（共 200 台）本地部署服务器上运行。

该平台的核心数据存储层是基于 Microsoft SQL Server 2008 R2 构建的本地部署 2 TB 关系数据库管理系统。此数据库充当与市场数据相关的所有项目的中央存储库，其中存储了应用程序系统的所有数据。例如，它保存了每个公司的内部数据，这些数据直接映射到每个证券交易所的上市公司名录。服务器数据库还存储了用于处理交易的 Market Data 的运营数据，包括可追溯到 20 世纪 70 年代的所有历史价格数据。

一些应用程序负责管理市场数据并将这些数据提供给使用者，这些应用程序的核心是 SQL Server 数据库。在迁移到 AWS 后，可以停用这些系统，包括：

• DJ Symbology System，它提供“公司代码”（例如道琼斯股票代码）与针对美国、加拿大和跨国公司的实时或延迟报价的实际映射。
• Real-time Feed Processor 应用程序组，负责在市场开放和股票交易时维护最新数据。这些应用程序已连接到多个来源，提取数据并将数据集成到 Market Data 平台中。
• Intraday Systems 负责维护市场状态。最后，迁移了面向客户端的 API。它们是用于为客户端和印刷产品生成 XML 文件的报告系统，还是图表系统和主要 Market Data API。

其中，每个应用程序均负责 Market Data 架构的一个不同部分，例如管理提示、计算股市指数、提供价格和更新其查询引擎。

从架构的角度来看，本地部署的 Market Data SQL Server 数据库由多达 15 个独立的数据库服务器实例组成，分布在美国的两个不同的数据中心中。道琼斯使用 SQL Server 数据库镜像来提高可用性，并在出现故障时保护数据。两个不同的数据中心中有四个主镜像实例，而其余的服务器实例分为 2 个分发服务器实例和 9 个订阅服务器实例。主要的主体服务器实例为来自单个数据中心的所有客户端提供数据库。同时，主镜像实例充当热备用服务器，以防主服务器出现故障。每个数据中心中的分发服务器实例处理到本地订阅服务器节点的同步复制。所有写入操作都由主数据中心的主体服务器处理，而读取操作由分布在两个数据中心的 9 个订阅服务器实例处理。

道琼斯的迁移和现代化概览

为了使投产速度最快，道琼斯团队采用了“直接迁移”云端迁移策略，将其 Market Data 应用程序的核心组件迁移到 AWS。此策略使道琼斯能够以最小的程度更改代码，以加速迁移过程，而无需重新设计整个应用程序。这种方法是过渡性的：道琼斯计划在直接迁移到 AWS 后，进行现代化改造，并转向云原生方法。AWS 的云服务和优化带来了显著的好处，使升级和重新架构系统变得更轻松。

为了在此过程中管理许可成本，该公司已将其现有的本地部署 2 TB MS SQL Server 数据库升级到云原生数据库，以便能够充分利用此类 AWS 数据库提供的可靠性、可扩展性、可管理性和成本优化。因此，Market Data 已使用 Amazon Aurora 进行重新架构。Amazon Aurora 是一种面向云构建的兼容 MySQL 的关系数据库，既具有高端商用数据库的性能和可用性，又具有开源数据库的简单性和成本效益。

据道琼斯的软件工程经理 Luke Sawatsky 说，从本地部署 SQL Server 数据库迁移到 Amazon Aurora MySQL 是一个包含多个关键阶段的简单过程。”

第 1 阶段：转换数据库模式

使用 AWS Schema Conversion Tool 自动转换模式

在将其 2 TB 数据库从 MS SQL Server 迁移到 Amazon Aurora MySQL 目标数据库之前，道琼斯需要创建目标模式。为了在此过程中提供帮助，该公司使用了 AWS Schema Conversion Tool（AWS SCT），帮助将其现有的数据库模式从 MS SQL Server 转换为 Amazon Aurora MySQL。

在此过程中，道琼斯生成了 AWS SCT 数据库迁移评估报告。该报告评估了使用 AWS Schema Conversion Tool 可以完成的项目数以及还需执行哪些操作才能完成转换。该报告是一个非常有用的工具，因为它总结了所有模式转换任务，并详细说明了无法转换为 Aurora MySQL 目标数据库实例的模式的操作项。

道琼斯在完成此分析后，发现 99.8% 的数据库存储对象（例如：模式、表、索引、类型、表类型等）和 52% 的数据库代码对象（例如：触发器、视图、过程、函数）可以自动进行转换，或者将 Amazon Aurora（与 MySQL 兼容）用作迁移目标，而只需进行最少量的更改。此外，在道琼斯的整个数据库模式中，有 97% 的对象可以自动转换为 Amazon Aurora（与 MySQL 兼容）。

手动转换模式

虽然大多数迁移工作可以自动实施，但有些方面需要手动干预。该报告使用需要手动干预的“重要操作”标记了一个数据库存储对象和 38 个数据库代码对象。

例如，一个重要的数据库代码对象问题与道琼斯使用全局游标有关：

事实证明，Aurora MySQL 游标框架比 SQL Server 简单得多，并且只提供基本类型的服务器。如果道琼斯使用的代码依赖于高级游标功能，就需要完全重写。相反，道琼斯能够使用临时表来解决此问题。

道琼斯遇到了第二个与 SQL Server 函数相关的问题。此函数使用嵌套的 SQL 语句来获取记录树及其父记录。由于无法在 MySQL 中重新创建此递归，因此，道琼斯不得不使用 C# 重写 SQL 语句。

对于每个转换问题，道琼斯修改了源 SQL Server 数据库上的对象，以便 AWS SCT 能够成功地将这些对象转换为目标 Aurora MySQL 数据库。通过使用 SCT，道琼斯能够在每次迭代后仔细检查评估报告。

在此阶段，几个小型概念验证将并行运行，以验证代码更改是否按预期执行。道琼斯继续执行此过程，直到不再发现其他转换问题。道琼斯估计，一名工程师重写存储过程的代码总共花了一个月的时间。道琼斯发现，修复一个代码问题通常能够同时修复其他问题，从而减少了花费的总时间。在所有转换都完成后，道琼斯将模式更改应用于 Aurora MySQL 数据库，并为下一阶段（数据迁移）做好准备。

第 2 阶段：使用 AWS Database Migration Service 迁移数据

通过使用 AWS Database Migration Service（AWS DMS），道琼斯能够快速安全地将其数据从本地部署 SQL Server 持续迁移到 Amazon Aurora MySQL。源数据库在迁移期间保持完全运行，最大限度地减少了依赖其数据库的 Market Data 应用程序的停机时间。在配置数据库迁移任务时，道琼斯选择了“迁移现有数据并复制正在进行的更改”选项。这确保了 AWS DMS 能够捕获和应用更改，即使在加载批量数据后也是如此。AWS DMS 成功应对了整个数据迁移过程的复杂性，并在 24 小时内成功完成了迁移。作为最后一步，AWS DMS 复制任务更新为“仅 CDC”，以确保两个数据库在最终转换前保持同步。

第 3 阶段：内部测试阶段和 AWS Well-Architected 审查

在迁移的下一阶段，道琼斯启动了耗时漫长的内部测试，以确保 Market Data 平台已准备好投入生产。在此期间，道琼斯与 AWS 专家合作，对该平台进行了 AWS Well-Architected 审查（WAR）。通过这一关键举措，道琼斯得以使用最佳实践来确保卓越运营、安全性、可靠性和表现。为了确保获得成功，道琼斯制定了一项战略性的业务决策，即过度预置容量，而不是优化成本。之后，将成本优化纳入迁移后计划中。

Market Data WAR 有助于揭示当前 AWS 架构中需要立即关注和纠正的几个关键技术问题。更重要的一点是，Market Data 团队能够制定出一项切实可行的计划，其中详细列出了以下最佳实践建议：

• 为 Aurora 全局集群中的只读副本和写入器节点预置相同的数据库实例类型/大小，以便在出现故障时保护数据库。
• 使主区域和备份区域之间的实例数达到平衡。
• 为应用程序设置适当的 DNS TTL（1 秒）。
• 横向扩展以满足需求。
• 实施自动化以确保集群永远不会低于定义的阈值。
• 使用自动化/自动伸缩针对峰值和缩减数量和/或非高峰期实例类进行过度预置。
• 在上线日期之前，对 Aurora 数据库执行全面的“大规模”负载和弹性测试。

最终成果：道琼斯成功地将其本地部署的旧式 SQL Server 数据库实现现代化，变为可扩展且具有弹性的云原生数据库架构。此云原生数据库具有一个 Amazon Aurora 全局集群，其中一个写入器节点和五个读取器节点位于弗吉尼亚州（us-east-1），六个读取器节点位于俄亥俄州（us-east-2）。

第 4 阶段：将 Aurora MySQL 数据库切换到生产环境

在迁移过程的这个阶段，道琼斯为 Market Data 启动并运行了两个并行数据库环境：

1. 在 AWS 上以测试模式运行的云原生 Aurora MySQL 数据库；以及
2. 向客户端提供生产数据的本地部署 MS SQL Server。

接下来，道琼斯致力于加快向 Aurora MySQL 的转换，无需每个客户端更改其终端节点。为了应对这一挑战，Market Data 团队使用名为 NGINX 的代理服务将客户端数据请求从本地部署重定向到 AWS。这确保能够为道琼斯的客户端提供不间断的服务。在 8 小时内，完成了代理安装和 DNS 条目更新，并且 Market Data 客户端已成功连接到 AWS 上的 Aurora MySQL 数据库。两周后，本地部署的 MS SQL Server 数据库正式关闭，所有生产流量都转入 AWS 上的 Aurora MySQL 数据库。这表示完成了向 Aurora MySQL 的转换。

第 5 阶段：迁移后优化数据库

道琼斯的迁移之旅在迁移到 AWS 后并未结束，还存在一个迁移后阶段。在此阶段，道琼斯致力于在整个 AWS 基础设施中实现成本优化以及合理调整机会。道琼斯使用 Amazon CloudWatch 指标和 CloudHealth 管理软件来分析数据，根据 Market Data 工作负载的当前性能和使用要求快速判断出，它用于 Aurora MySQL 的数据库实例类型/大小明显过度预置。根据此分析，道琼斯采取了一些措施来调整 Aurora MySQL 数据库实例类型/大小，以更好地满足当前容量需求，并在每个区域消除两个读取器节点以进一步节省成本。重新部署后，道琼斯得以大大减少支出。

结论

道琼斯需要确保其任务关键型 Market Data 平台安全、高性能、具有弹性且高效。通过从本地部署的 Microsoft SQL Server 迁移到 Amazon Aurora 并实现现代化，道琼斯不仅体现了成本效益，而且还从云原生工具中受益。借助 Amazon Aurora 的自动存储预置和副本等功能，道琼斯能够更轻松地维护和复制其数据。

AWS 可以帮助您评估自己的公司如何充分利用云。诚邀您加入数百万 AWS 客户的行列，这些客户信任我们，让我们帮助他们在云中迁移他们最重要的应用程序并实现现代化。要了解有关现代化 Windows Server 或 SQL Server 的更多信息，请访问 AWS 上的 Windows。 请联系我们，立即开始您的迁移之旅。