Autodesk が Migration Assistant とインテリジェントルーティングで 23 億ドキュメントを Amazon OpenSearch Service に移行した方法

本記事は 2026 年 8 月 14 日に公開された「How Autodesk migrated 2.3 billion documents to Amazon OpenSearch Service using Migration Assistant and intelligent routing」を翻訳したものです。

OpenSearch は、検索、分析、セキュリティモニタリング、オブザーバビリティのアプリケーション向けのオープンソースソフトウェアスイートで、Apache License 2.0 で提供されています。Amazon OpenSearch Service は、OpenSearch および Elasticsearch エンジンを AWS クラウド上でデプロイ、スケール、運用できるマネージドサービスです。お客様は OpenSearch Service 上で数十億ドキュメント規模の検索ワークロードを運用しています。単一のインデックスが数百万から数十億のドキュメントを保持する場合、そのインデックスを収容する OpenSearch Service ドメインのトポロジーを計画する必要があります。本記事では、Autodesk が Amazon OpenSearch Service 上の単一インデックスの Elasticsearch 7.1.1 ドメインを、Migration Assistant for Amazon OpenSearch Service と、各クエリを該当データを持つシャードへ振り分けるルーティング層を使って、4 つのマルチインデックス OpenSearch Service ドメインへ再設計した方法を紹介します。

Autodesk は、建築・エンジニアリング・建設 (AEC)、製品設計・製造、メディア・エンターテインメントという 3 つの業界に跨るお客様にサービスを提供するテクノロジー企業です。Autodesk のミッションは「誰もが、どこでも、あらゆるものをデザインし、創造できるようにする」ことであり、お客様がプロジェクト、専門分野、業界の境界を越えて働けるよう支援しています。

Autodesk Forma (旧 Autodesk Construction Cloud、ACC) は、クラウドベースの建設管理・コラボレーションシステムです。世界中のお客様が、ドキュメント管理、入札管理、数量算出、コーディネーション、設計コラボレーション、プロジェクト管理、現場コラボレーションといったワークフローに Autodesk Forma を利用しています。Autodesk Forma は Amazon OpenSearch Service を使って、数百万のユーザーに検索体験を提供しています。お客様がデータを追加するにつれ、Forma が OpenSearch Service に保存するデータも増加します。OpenSearch Service ドメインでは、インデックスがデータの保存と整理の単位です。インデックスが 100 TB に達すると、インデックスがパフォーマンスのボトルネックとなり、スケールが難しくなります。Autodesk Forma の成長にともない、Forma データ管理 (Forma data management、旧 Autodesk Docs) はパフォーマンスとスケーリングの限界に達しました。このコンポーネントは、プロジェクトカタログ全体へのアクセスと検索を担っています。

Autodesk の出発点

Forma データ管理は、Amazon OpenSearch Service 上の単一の Elasticsearch 7.1.1 ドメインで、1 つのインデックスを使って稼働していました。このドメインは 100 台を超えるデータノード上に約 100 TB のデータを保持し、プライマリシャードは 400 を超え、レプリケーションファクターは 1 でした。シャードの平均サイズは 200 GB でした。この規模とドメインが本番稼働中であることから、シャードの追加、インデックスの追加、データのリバランスといったチューニング手法は現実的ではありませんでした。

単一インデックス・単一ドメインの設計は、今後のデータ増加に対して 3 つの課題を抱えていました。

1. クエリパフォーマンス – データの増加にともない、クエリのレイテンシーが時間とともに悪化していました。
2. 垂直スケーリング – 既存のインスタンスクラスで利用できる最大の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスサイズに、すでに達していました。
3. 水平スケーリング – ルーティングの仕組みがないため、ノードを追加すると OpenSearch Service ドメインが管理するクラスター内にホットノードが発生しました。

インテリジェントルーティングを備えたマルチドメインアーキテクチャ

垂直または水平スケーリングで短期的にはクエリパフォーマンスに対処できますが、どちらも根本にある単一インデックス・単一ドメインのスケーラビリティ限界を解消しません。ルーティングキーを使った水平スケーリングのアプローチなら、より大きなハードウェアを必要とせずに、各クエリがどのシャードにアクセスするかを制御できます。Autodesk のチームはこのアプローチを採用し、本番トラフィックに影響を与えることなく検索サービスを再設計しました。

図 1: インテリジェントルーティングを備えたマルチドメインアーキテクチャ

このアーキテクチャには次の特性があります。

• OpenSearch 2.19 の Amazon OpenSearch Service ドメインが 4 つ。各ドメインは m7i.4xlarge.search ノード 24 台で稼働。
• インデックスは合計 24 (ドメインあたり 6)。
• インデックスあたり約 9,500 万ドキュメント。
• プライマリストレージは 52 TB。元の単一インデックスドメインのプライマリストレージより 37% 小さく、主な理由は移行時に削除済みドキュメントをスキップしたこと。

この構成では、水平にスケールした 4 つの OpenSearch Service ドメインと、各クエリをそのプロジェクトのデータを持つドメインへ振り分けるルーティング層を使います。

アーキテクチャでは、プロジェクトごとに 1 レコード、計数百万件のルーティングレコードを保存する Amazon DynamoDB テーブルを使用します。プロジェクトとは Forma データ管理における主要なワークスペースで、チーム、データ、ドキュメント、モデル、ワークフロー、権限、課題、コラボレーション活動がまとめて置かれる場所です。Forma アプリケーションは Amazon DynamoDB テーブルでプロジェクトとドメインの対応を参照し、正しいドメインに検索クエリを発行します。

数百万件のレコードを 4 つのドメインへ再配分するのは困難な作業でした。プロジェクトをインデックスへ均等に割り当てるため、チームはビンパッキングアルゴリズムを使いました。ビンパッキングアルゴリズムは、大きさの異なるアイテムを固定数の箱 (ビン) に詰め、無駄を最小化して均等な分布を得るアルゴリズムです。チームが扱ったのは、プロジェクトあたりのドキュメント数が数件から数百万件までさまざまな数百万のプロジェクトと、それぞれ約 4 億ドキュメントを目標とする 24 のインデックスです。チームは、ワークロードの過去の利用メトリクスを使う層別ビンパッキングアルゴリズムを実装しました。このアルゴリズムにより、移行計画時のリソースの過剰割り当てや不足を避けられます。過剰割り当てを避けるため、チームは 95 パーセンタイル (P95) の利用メトリクスを使いました。アルゴリズムを適用した結果、各 OpenSearch Service ドメインの使用率は約 49% となり、2 倍の成長余地が残りました。アプリケーションはルーティングキーに基づくクエリを使い、インデックス内のすべてのシャードではなく関連するシャードだけを検索します。

このアーキテクチャには次のメリットがあります。

• 水平スケーラビリティ – 必要に応じてドメインとインデックスを追加できる。
• 効率的なルーティング – クエリはドメイン内のすべてのシャードではなく、特定のシャードにだけ到達する。
• 影響範囲の縮小 – 1 つのドメインが利用不能になっても影響を受けるトラフィックは約 25% にとどまり、単一ドメイン設計のような全面ダウンタイムにはならない。
• 独立したスケーリング – 各ドメインをその負荷パターンに応じてスケールできる。
• 検索スレッドの増加 – 4 つのドメインを合計した検索スレッドプールは、1 つのドメインより大きい。

移行の手順

以下のセクションでは、Autodesk のチームが移行を完了するまでに踏んだ 4 つのステップを説明します。

ステップ 1: プロジェクトをサイズで分類する

チームはプロジェクトを現在のドキュメント数で 4 つのサイズカテゴリに分け、6 か月分のデータを収集してカテゴリごとの成長係数を算出し、1 年先まで外挿しました。

この表から、プロジェクトの 95% は TINY である一方、ドキュメント量の大半を占めるのは LARGE プロジェクトであることがわかります。カテゴリによる層別化によって、アルゴリズムは各カテゴリを適切に扱えます。

Autodesk のチームは、成長を見積もるためにプロジェクトあたりのドキュメント数を 6 か月間にわたって分析しました。カテゴリごとの P95 成長係数を使うことで、プロジェクトの 95% をカバーしつつ過剰なプロビジョニングを避ける、保守的なキャパシティプランが得られます。

ステップ 2: インターリーブ配置

LARGE プロジェクトをすべて先に処理すると、インデックス間に偏りが生じます。この偏りを避けるため、ビンパッキングアルゴリズムはカテゴリをラウンドロビンでインターリーブします。チームは次の順序で、ドキュメントを Amazon OpenSearch Service ドメインに均等に分配しました。

1. 各カテゴリ内でプロジェクトを大きいものから順に並べ替える。
2. カテゴリごとにキューを作る。キューは先入れ先出しのデータ構造で、1 つのカテゴリの並べ替え済みプロジェクトを保持する。
3. ラウンドロビンでプロジェクトを配分する。LARGE から 1 つ、次に MEDIUM、SMALL、TINY から 1 つずつ取り出し、これを繰り返す。

ステップ 3: 負荷分散を考慮したベストフィット

インターリーブの後、チームは各プロジェクトの予測サイズを計算し、プロジェクトをインデックスに割り当てました。手順は次のとおりです。

1. 将来の推定サイズを 現在のサイズ × 成長係数 で計算する。
2. 優先度付きキューを使って、空き容量が最も大きいインデックスを見つける。優先度付きキューでは各要素が優先度を持つ。ここでは各インデックスの優先度は、そのインデックスの空き容量である。通常のキューと異なり、優先度付きキューは最初に挿入された要素ではなく、優先度が最も高い要素を先に返す。
3. 空き容量が最も大きいインデックスにプロジェクトを割り当てる。
4. インデックスの推定負荷を更新し、新しい容量で優先度付きキューに再挿入する。この再挿入により、次のプロジェクト割り当てに向けてキューが正確に保たれる。

以上の 3 ステップにより、次の結果が得られました。

• アルゴリズムは数百万のプロジェクトを 99.999% のルーティング精度で配分した。
• インデックス間のプロジェクト配分のばらつきは 0.15% に収まった。
• 成長係数を適用した後の各ドメインの容量使用率は 49.1% で、将来の成長に向けて 50.9% の余裕が残った。
• アルゴリズムは数百万件のプロジェクト割り当てを約 10 分で計算した。

チームは、リアルタイムのクエリルーティングのために、プロジェクトとインデックスの割り当てマッピングを Amazon DynamoDB に保存しました。ルーティングは、アプリケーションがドメインのリソースをどう使うか、そして各ドメインのパフォーマンスを左右します。ルーティングを使うと、アプリケーションはそのプロジェクトのルーティングキー (projectId) に一致するシャードだけを検索します。ルーティングがなければ、同じクエリがインデックス内のすべてのシャードを検索することになり、ドメインのリソースを浪費してクエリも遅くなります。チームはシャードサイズもチューニングしました。これは大規模プロジェクトで最も重要になります。最大規模のプロジェクトの 1 つは 700 万ドキュメントを保持し、1 ドキュメントあたり約 40 KB、合計で約 280 GB でした。このプロジェクトのデータを 20〜25 GB のシャードに分割するため、チームは routing_partition_size を 12 に設定しました。

ステップ 4: Migration Assistant for Amazon OpenSearch Service による移行

Autodesk のチームは、23 億ドキュメントの移行に Migration Assistant for Amazon OpenSearch Service のスナップショットと再インデックスによる方式を使いました。Migration Assistant for Amazon OpenSearch Service は移行のプロファイルに合わせて適応し、AWS Identity and Access Management (IAM) のアクセス許可の境界、Amazon Virtual Private Cloud (Amazon VPC) のサポート、そして移行に必要なセキュリティポリシーを提供します。Migration Assistant for Amazon OpenSearch Service は、AWS Fargate を使う Amazon Elastic Container Service (Amazon ECS) 上でアプリケーションを動かす 400 を超えるタスクと統合されました。

本番の切り替え前に、チームは概念実証 (PoC) を複数回繰り返し、移行設定をチューニングしてスループットを 18 GB/時から 228 GB/時に引き上げました。最初の PoC では m7g.large.search ノードで 18 GB/時でした。その後の各イテレーションで、水平スケール、より大きなインスタンス (m7g.2xlarge.search と m7g.4xlarge.search)、ドメインをまたいだ並列書き込み、移行中のレプリカ数ゼロを追加しました。4 回目となる最終の PoC で 228 GB/時に達しました。PoC を複数回行ったことで、チームは最適なインスタンスサイズとインスタンスクラスを選定でき、23 億ドキュメントをダウンタイムなし、お客様に影響するインシデントなしで 6 時間で移行できました。

移行後の分析

ルーティングを有効にして 23 億ドキュメントを移行した後、シャードは次のような状態になりました。

次の表は、移行前と移行後のアーキテクチャを比較したものです。

チームは 23 億ドキュメントを約 6 時間で移行しました。移行時に削除済みドキュメントを除外したため、ストレージは 83.3 TB から 52 TB へと約 37% 減少しました。移行により、平均 12.34 GB のシャードが 4,325 個生成され、4 つのドメインに分散されました。シャードの 75.5% が 10〜15 GB の範囲に収まりました。移行前の 210 GB と比べると、新しいアーキテクチャが大きすぎるシャードの問題を解決していることが確認できます。このシャードサイズは、検索レイテンシーを主要なパフォーマンス目標とする場合の一般的なガイダンスに沿ったものです。ドメイン間のばらつきが 2.3% (ドメインあたり 12.85〜13.15 TB) であることから、データが均等に分散されていることが確認できます。

移行後、projectId ルーティングキーを含むクエリは関連するシャードだけ (通常はインデックスあたり 180 シャード中 12) をスキャンするため、シャード全体の検索負荷が 93% 減少します。ルーティングは各ドメイン内の CPU とメモリの使用も均等化します。インデックスあたり 12 という routing_partition_size により、インデックスごとに適切なシャード数が得られました。全体の P99 レイテンシーは 17 秒から 5 秒へと 72% 改善しました。そのうち検索クエリの P99 は 2,500 ms から 200 ms へと 92% 改善しました。

学んだこと

PoC のイテレーションからいくつかの教訓が得られました。より大きなインスタンスタイプは短期的にはクエリパフォーマンスの助けになりますが、クエリルーティングと水平スケーリングの組み合わせの方が、持続的に高いスループットを生み出します。バルクロード中はレプリカを無効化し、リフレッシュ間隔を長くして書き込みのオーバーヘッドを減らします。アプリケーションをスケールアウトする際は、移行の途中でサービスの制限に当たらないよう、十分な IP アドレスとサブネットの容量を計画します。アプリケーションと OpenSearch Service ドメインの間の VPC ルーティング設定を検証します。水平スケールアウトの前に、OpenSearch Service のデータノード容量を AWS Support に確認します。Amazon DynamoDB ベースのルーティング層はクエリあたり約 20 ms のルーティングレイテンシーを追加しますが、全体の検索レイテンシーを削減し、水平スケールを可能にします。

まとめ

本記事では、Autodesk のチームが 23 億ドキュメントを単一インデックスのドメインから 4 つのマルチインデックスの Amazon OpenSearch Service ドメインへ、約 6 時間で移行した方法を紹介しました。

マルチドメインアーキテクチャへの移行や最新の OpenSearch バージョンへの更新は、従来は複雑な作業でした。また、本番トラフィックを移す前に移行の結果を予測することも難しいものでした。Migration Assistant for Amazon OpenSearch Service は、移行をワークフロー駆動で再現可能にし、切り替え前の検証をより簡単にすることで、こうした課題に対処します。

Migration Assistant for Amazon OpenSearch Service と Amazon DynamoDB ベースのインテリジェントルーティングを組み合わせることで、バランスの取れたシャードと検索クエリパフォーマンスの向上を実現しました。PoC を複数回行ったことで、本番切り替えの前にルーティングのバグ、サービスクォータの制約、インフラストラクチャのプロビジョニングの不足を見つけることができました。

OpenSearch Service ドメイン間で大規模なデータセットを移行する予定があれば、Migration Assistant for Amazon OpenSearch Service を利用できます。詳細は Migration Assistant for Amazon OpenSearch Service のドキュメントを参照してください。

著者について

翻訳はソリューションアーキテクトの久野康貴が担当しました。原文はこちらです。