Autodesk 如何将23亿文档迁移至 Amazon OpenSearch Service

OpenSearch 是一个开源软件套件，用于搜索、分析、安全监控和可观测性应用程序，基于 Apache 许可证 2.0 版授权。Amazon OpenSearch Service 是一项托管服务，允许您在 AWS 云中部署、扩展和运营 OpenSearch 和 Elasticsearch 引擎。客户在 OpenSearch Service 上运行搜索工作负载，规模达数十亿份文档。当单个索引包含数百万到数十亿份文档时，您需要规划承载该索引的 OpenSearch Service 域的拓扑结构。本文介绍了 Autodesk 如何使用 Migration Assistant for Amazon OpenSearch Service 以及一个路由层（将每个查询定向到包含该查询数据的分片），将 Amazon OpenSearch Service 上的单索引 Elasticsearch 7.1.1 域重新架构为四个多索引 OpenSearch Service 域。

Autodesk 是一家科技公司，服务于三个行业垂直领域：建筑、工程和施工（AEC）、产品设计与制造，以及媒体和娱乐。Autodesk 的使命是赋能所有人，在任何地方设计和制造任何事物，帮助客户跨越项目、学科和行业的边界进行协作。

Autodesk Forma（前身为 Autodesk Construction Cloud 或 ACC）是一个基于云的施工管理和协作系统。全球客户使用 Autodesk Forma 进行文档管理、投标管理、工程量计算、协调、设计协作、项目管理和现场协作等工作流程。Autodesk Forma 使用 Amazon OpenSearch Service 为数百万用户提供搜索体验。随着客户添加数据，Forma 存储在 OpenSearch Service 中的数据不断增长。在 OpenSearch Service 域中，一个索引 是数据存储和组织的单元。当索引达到 100 TB 时，索引成为性能瓶颈并且难以扩展。随着 Autodesk Forma 的发展，Forma 数据管理（前身为 Autodesk Docs）遇到了性能和扩展限制。该组件支持项目目录的访问和搜索。

Autodesk 的起点

Forma 数据管理在 Amazon OpenSearch Service 上运行于单个 Elasticsearch 7.1.1 域，并带有一个索引。该域在超过 100 个数据节点上持有约 100 TB 数据，具有超过 400 个主分片 和复制因子 为 1。平均分片持有 200 GB。由于域的规模和生产状态，添加分片、添加索引或重新平衡数据等调优技术并不可行。

单索引、单域设计对未来数据增长带来了三个挑战：

1. 查询性能。 随着数据增长，查询延迟随时间恶化。
2. 垂直扩展。 团队已达到现有实例类可用的最大Amazon Elastic Compute Cloud（Amazon EC2） 实例大小的限制。
3. 水平扩展。 没有路由机制，添加节点会在 OpenSearch Service 域管理的集群内产生热节点。

具有智能路由的多域架构

垂直或水平扩展可以在短期内解决查询性能问题，但两者都不能解决底层单索引、单域的可扩展性限制。使用路由键的水平扩展方法让您可以控制每个查询触及哪些分片，而无需更大的硬件。Autodesk 团队应用了这种方法来重新架构搜索服务，而不影响生产流量。

图 1：具有智能路由的多域架构

该架构具有以下属性：

• 四个 OpenSearch 2.19 上的 Amazon OpenSearch Service 域，每个域运行 24 个m7i.4xlarge.search 节点。
• 总共 24 个索引（每个域 6 个）。
• 每个索引约 9500 万份文档。
• 52 TB 主存储。这比原始单索引域的主存储大小小 37%，主要是因为迁移跳过了已删除的文档。

该设置使用四个水平扩展的 OpenSearch Service 域，并带有一个路由层，将每个查询定向到持有项目数据的域。

该架构使用一个Amazon DynamoDB 表，存储 430 万条路由记录，每个项目一条记录。项目是 Forma 数据管理中的主要工作空间，团队、数据、文档、模型、工作流程、权限、问题和协作活动都集中在这里。Forma 应用程序查找 Amazon DynamoDB 表以获取项目到域的映射，然后将搜索查询发送到正确的域。

在四个域之间重新分配数百万条记录很困难。为了找到均匀的项目到索引分配，团队使用了装箱算法。装箱算法将不同大小的物品装入固定数量的箱子中，以最小化浪费并产生均匀分布。团队处理了 430 万个文档数量各异的项目，从每个项目几份文档到数百万份不等，分布在 24 个索引中，每个索引目标约为 4 亿份文档。团队实现了一种分层装箱算法，该算法使用工作负载的历史使用指标。该算法避免了迁移规划期间资源的过度或不足分配。为了避免过度分配，团队使用了第 95 百分位（P95）使用指标。应用该算法后，每个 OpenSearch Service 域的利用率约为 49%，留有 2 倍的增长缓冲。然后，应用程序使用基于路由键的查询 仅搜索相关分片，而不是索引中的每个分片。

该架构具有以下优点：

• 水平可扩展性。 团队可以根据需要添加更多域和索引。
• 高效路由。 查询命中特定分片，而不是域中的每个分片。
• 减小爆炸半径。 如果一个域不可用，只会影响约 25% 的流量，而不是单域设计下的完全停机。
• 独立扩展。团队可以根据每个域的负载模式进行扩展。
• 更多的搜索线程。四个域的聚合搜索线程池比单个域更大。

迁移步骤

以下章节描述了Autodesk团队完成迁移所遵循的四个步骤。

步骤1：按大小对项目进行分类

团队根据当前文档数量将项目分为四个大小类别，然后收集六个月的数据来计算每个类别的增长因子，并外推一年：

该表显示95%的项目是微小项目，但大型项目占文档量的大部分。按类别分层让算法能够适当处理每个类别。

Autodesk团队分析了每个项目六个月内的文档数量以估算增长。使用每类别的P95增长因子提供了保守的容量计划，覆盖95%的项目并避免过度配置。

步骤2：交错分布

如果先处理所有大型项目，会在各索引之间造成不平衡。为避免这种不平衡，装箱算法以轮询模式交错处理类别。团队使用以下顺序将文档均匀分布到各个Amazon OpenSearch Service域：

1. 在每个类别内对项目进行排序，最大的优先。
2. 为每个类别创建一个队列。队列是一种先进先出的数据结构，保存一个类别中排序后的项目。
3. 以轮询模式分布项目：从大型取一个，然后中型、小型、微小，重复此过程。

步骤3：负载均衡的最佳适应

在交错排序后，团队计算每个项目的预计大小并将项目分配到索引。以下步骤描述了该方法：

1. 计算预估的未来大小为当前大小 × 增长因子。
2. 使用优先队列来查找具有最大可用容量的索引。在优先队列中，每个元素都有一个优先级。这里，每个索引的优先级是其可用容量。与普通队列不同，优先队列首先返回优先级最高的元素，而不是最先插入的元素。
3. 将项目分配给具有最大可用容量的索引。
4. 更新索引的估计负载，并将索引重新插入优先队列，使用新的容量。重新插入步骤保持队列对下一个项目分配的准确性。

上述三个步骤产生了以下结果：

• 该算法分配了430万个项目，路由准确率为99.999%。
• 跨索引的项目分布保持0.15%的方差。
• 应用增长因子后，每个域的容量利用率达到了49.1%，为未来增长留出50.9%的空间。
• 该算法在大约10分钟内计算了430万个项目的分配。

团队将项目到索引的分配映射存储在Amazon DynamoDB中，用于实时查询路由。路由控制应用程序如何使用域资源以及每个域的性能。通过路由，应用程序仅搜索与该项目的路由键（projectId）匹配的分片。没有路由，相同的查询将搜索索引中的每个分片，这浪费域资源并导致查询速度变慢。团队还调整了分片大小，这对大型项目最为重要。最大的项目之一拥有700万个文档，每个文档约40 KB，总计约280 GB。要将该项目的数据拆分为20–25 GB的分片，团队将routing_partition_size设置为12。

步骤4：使用Amazon OpenSearch Service迁移助手进行迁移

Autodesk团队使用Amazon OpenSearch Service迁移助手中的快照和重新索引路径迁移了23亿个文档。Amazon OpenSearch Service迁移助手适应迁移配置，并提供AWS身份和访问管理（IAM）权限边界、Amazon Virtual Private Cloud（Amazon VPC）支持以及迁移所需的安全策略。Amazon OpenSearch Service迁移助手与在Amazon Elastic Container Service（Amazon ECS）上使用AWS Fargate运行应用程序的400多个任务集成。

在生产切换之前，团队进行了多次概念验证（PoC）迭代，并调整迁移配置，将吞吐量从18 GB/hr提高到228 GB/hr。第一次PoC迭代在m7g.large.search节点上达到18 GB/hr。随后每次迭代都增加了水平扩展、更大的实例（m7g.2xlarge.search和m7g.4xlarge.search）、跨域的并行写入以及迁移期间的零副本。第四次也是最后一次PoC迭代达到了228 GB/hr。多次PoC迭代帮助团队选择了最佳的实例大小和实例类型，在6小时内迁移了23亿个文档，零停机且无客户事件。

迁移后分析

团队在启用路由的情况下迁移了23亿个文档后，分片分布如下：

下表比较了迁移前后的架构：

团队在约 6 小时内迁移了 23 亿个文档。由于迁移删除了已删除的文档，存储量下降了约 37%，从 83.3 TB 降至 52 TB。迁移产生了 4,325 个分片，平均每个分片 12.34 GB，分布在四个域中。75.5% 的分片处于 10–15 GB 范围内，而迁移前为 210 GB，这证实了新架构解决了大分片问题。分片大小符合通用指南，其中搜索延迟是关键性能目标。2.3% 的跨域方差（每域 12.85 TB 至 13.15 TB）证实了数据分布均匀。

迁移后，包含 projectId 路由键的查询仅扫描相关分片（通常每个索引 180 个中的 12 个），这将跨分片的搜索负载降低了 93%。路由还平衡了每个域中 CPU 和内存的使用。每个索引的 routing_partition_size 为 12，产生了每个索引正确的分片数量。整体 P99 延迟提高了 72%，从 17 秒降至 5 秒。其中，搜索查询 P99 提高了 92%，从 2,500 毫秒降至 200 毫秒。

经验教训

PoC 迭代揭示了几条经验教训。较大的实例类型短期内有助于查询性能，但查询路由与水平扩展相结合可产生更高的持续吞吐量。在批量加载期间，禁用副本并增加刷新间隔以减少写入开销。在扩展应用程序时，规划足够的 IP 地址和子网容量，以免在迁移中途遇到服务限制。验证应用程序与 OpenSearch Service 域之间的 VPC 路由配置。在水平扩展前，与 AWS Support 确认 OpenSearch Service 数据节点容量。基于 Amazon DynamoDB 的路由层每次查询增加了约 20 毫秒的路由延迟，但路由层降低了整体搜索延迟并解锁了水平扩展。

结论

在本文中，您了解了 Autodesk 团队如何在约 6 小时内将 23 亿个文档从单索引域迁移到四个多索引 Amazon OpenSearch Service 域。

历史上，过渡到多域架构或更新到最新的 OpenSearch 版本一直很复杂。在生产流量切换之前预测迁移结果也可能很困难。Amazon OpenSearch Service 的 Migration Assistant 解决方案通过使迁移工作流驱动、可重复且在切换前更易于验证来应对这些挑战。

Amazon OpenSearch Service 的 Migration Assistant 与基于 Amazon DynamoDB 的智能路由相结合，帮助实现了分片均衡并提高了搜索查询性能。多次 PoC 迭代帮助在生产切换前发现路由错误、服务配额限制和基础设施配置缺口。

如果您计划在 OpenSearch Service 域之间迁移大型数据集，可以使用 Amazon OpenSearch Service 的 Migration Assistant。有关更多信息，请参阅 Migration Assistant for Amazon OpenSearch Service 文档。

关于作者