Amazon OpenSearch Service の GPU アクセラレーションで 10 億規模のベクトルデータベースを 1 時間以内に構築

本記事は 2025 年 12 月 8 日 に公開された「Build billion-scale vector databases in under an hour with GPU acceleration on Amazon OpenSearch Service」を翻訳したものです。

AWS は先日、Amazon OpenSearch Service での GPU アクセラレーションによるベクトル (k-NN) インデックス作成の一般提供を発表しました。10 億規模のベクトルデータベースを 1 時間以内に構築でき、ベクトルのインデックス作成を最大 10 倍高速化しながらコストを 4 分の 1 に削減できます。この機能は、CPU ベースのインスタンスで実行されているドメインやコレクションにサーバーレス GPU を動的にアタッチしてブーストします。この機能により、AI アプリケーションを迅速にスケールし、イノベーションを加速し、ベクトルワークロードを効率的に実行できます。

この記事では、GPU アクセラレーションによるベクトルインデックス作成の利点、主要なユースケース、パフォーマンスベンチマークについて説明します。

ベクトル検索とベクトルインデックスの概要

ベクトル検索は検索の関連性を向上させる技術であり、生成 AI アプリケーションの基盤となっています。埋め込みモデルを使用してコンテンツを数値エンコーディング (ベクトル) に変換し、キーワードだけでなくセマンティックな類似性によるコンテンツマッチングを可能にします。OpenSearch Service にベクトルを取り込んでインデックスを構築することで、数十億のベクトルをミリ秒単位で検索できるベクトルデータベースを構築できます。

ベクトルデータベースのスケーリングにおける課題

お客様は、生成 AI アプリケーション、製品カタログ、ナレッジベースなどを強化するために、OpenSearch Service 上で数十億規模のベクトルデータベースをスケーリングするケースが増えています。アプリケーションはますますエージェント化が進み、チャットベースのインタラクションや自動化を実現するために、エンタープライズデータソース全体で高品質な検索結果を得るためにベクトルデータベースに依存する AI エージェントを統合しています。

しかし、10 億規模への道のりには課題があります。まず、数百万から 10 億規模のベクトルインデックスの構築には数時間から数日かかります。これらのインデックスは、Hierarchal Navigable Small Worlds (HNSW) などのアルゴリズムを使用して、大規模でも高品質なミリ秒単位の検索を可能にします。ただし、従来のインデックスよりも多くの計算能力が必要です。さらに、ベンダーの切り替え、バージョンの変更、ファインチューニング後など、モデルが変更されるたびにインデックスを再構築する必要があります。パーソナライズド検索などのユースケースでは、進化するユーザー行動に適応するためにモデルを毎日ファインチューニングする必要があります。モデルが変更されるとすべてのベクトルを再生成する必要があるため、インデックスを再構築する必要があります。HNSW は大幅な更新や削除の後に精度が低下する可能性があるため、精度を回復するためにインデックスを再構築する必要があります。

最後に、エージェント型アプリケーションがより動的になるにつれて、ベクトルデータベースは低い検索レイテンシーを維持しながら、大量のストリーミング取り込み、更新、削除に対応してスケールする必要があります。検索とインデックス作成が同じインフラストラクチャを使用する場合、これらの集中的なプロセスが限られた計算リソースと RAM を奪い合うため、検索レイテンシーが低下する可能性があります。

ソリューションの概要

OpenSearch Service 3.1 以降のドメインまたはコレクションで GPU アクセラレーションによるインデックス作成を有効にすることで、これらの課題を克服できます。GPU アクセラレーションは、例えば 100 万以上のサイズのインデックスに対する reindex コマンドに応答して動的にアクティブ化されます。アクティブ化中、インデックスタスクは NVIDIA cuVS を実行する GPU サーバーにオフロードされ、HNSW グラフを構築します。ベクトル演算の並列化により、優れた速度と効率が実現されます。転置インデックスは、非ベクトルデータのインデックス作成と検索にクラスターの CPU を引き続き使用します。これらのインデックスは HNSW と並行して動作し、キーワード検索、ハイブリッド検索、フィルター付きベクトル検索をサポートします。転置インデックスの構築に必要なリソースは HNSW と比較して少なくなっています。

GPU アクセラレーションはクラスターレベルの設定として有効化されますが、個々のインデックスで無効にできます。この機能はサーバーレスであるため、GPU インスタンスを管理する必要はありません。OpenSearch Compute Units (OCU) を通じて従量課金で支払うだけです。

次の図は、この機能の仕組みを示しています。

ワークフローは以下のステップで構成されています。

1. 既存の API (bulk、reindex、index、update、delete、force merge) を使用して、ドメインまたはコレクションにベクトルを書き込みます
2. インデックス化されたベクトルデータがリフレッシュ間隔内に設定されたしきい値を超えると、GPU アクセラレーションがアクティブ化されます
3. これにより、OpenSearch Service が管理するマルチテナントの GPU ウォームプールから、クラスターへの安全なシングルテナントの GPU サーバー割り当てが行われます
4. ミリ秒以内に、OpenSearch Service は HNSW 操作を開始してオフロードします
5. 書き込み量がしきい値を下回ると、GPU サーバーはスケールダウンされ、ウォームプールに戻されます

この自動化は完全にマネージドです。アクセラレーション時間に対してのみ支払いが発生し、Amazon CloudWatch からモニタリングできます。

この機能は使いやすさだけを目的として設計されているわけではありません。経済的な課題なしに GPU アクセラレーションの利点を実現できます。例えば、10 億 (1,024 次元) のベクトルを 32 倍に圧縮 (バイナリ量子化を使用) してホストするようにサイズ設定されたドメインには、必要な 1.15 TB の RAM を提供するために 3 つの r8g.12xlarge.search インスタンスが必要です。GPU インスタンスでドメインを実行する必要がある設計では、同じことを行うために 6 つの g6.12xlarge インスタンスが必要です。これではコストが 2.4 倍増加するうえに、GPU の過剰割り当てを招きます。このソリューションは、必要なときにのみ適切な量の GPU を提供することで効率性を実現し、コスト削減と速度向上を達成します。

ユースケースと利点

この機能には 3 つの主要な用途と利点があります。

• 大規模インデックスをより高速に構築し、生産性とイノベーション速度を向上
• Amazon OpenSearch Serverless のインデックス作成 OCU 使用量を削減するか、書き込み負荷の高いベクトルワークロードを持つドメインをダウンサイズしてコストを削減
• 書き込みを高速化し、検索レイテンシーを低減し、動的な AI アプリケーションのユーザーエクスペリエンスを向上

以下のセクションでは、これらのユースケースについて詳しく説明します。

大規模インデックスをより高速に構築

ドメインとコレクションの両方で速度向上を実証するために、1M、10M、113M、1B ベクトルのテストケースでインデックス構築のベンチマークを実施しました。速度向上は 6.4 倍から 13.8 倍の範囲でした。これらのテストは本番構成 (マルチ AZ によるレプリケーション) とデフォルトの GPU サービス制限で実行されました。すべてのテストは適切にサイズ設定された検索クラスターで実行され、CPU のみのテストではインデックス作成専用に CPU 使用率が最大化されました。次のグラフは、マネージドドメインでの GPU アクセラレーションによる相対的な速度向上を示しています。

ドメインでの合計インデックス構築時間には、検索パフォーマンスのために基盤となるストレージエンジンを最適化する force merge が含まれています。通常の運用中、マージは自動的に行われます。ただし、ドメインのベンチマーク時には、テスト間でマージの影響を一貫させるために、インデックス作成後に手動マージを実行します。次の表は、ドメインのインデックス構築ベンチマークとデータセット参照をまとめたものです。

コレクションでも同じパフォーマンステストを実行しました。OpenSearch Serverless のサーバーレスアーキテクチャには、ピークパフォーマンスに到達するまでのランプアップを導入する自動スケーリングなどのパフォーマンストレードオフが含まれるため、パフォーマンスは異なります。次の表はこれらの結果をまとめたものです。

OpenSearch Serverless は force merge をサポートしていないため、GPU アクセラレーションの完全な効果は、自動バックグラウンドマージが完了するまで遅延する可能性があります。100 万ベクトルを超えるテストでは、より高いインデックス作成スループットを処理するためにデフォルトの最小 OCU を増やす必要がありました。

コスト削減

サーバーレス GPU 設計は、速度向上とコスト削減を独自に実現します。OpenSearch Serverless では、GPU アクセラレーションをアクティブ化するのに十分なインデックス作成ワークロードがある場合、正味のインデックス作成コストが削減されます。次の表は、前述のインデックス構築テストからの OCU 使用量とコスト消費量を示しています。

ベクトルアクセラレーション OCU はインデックス作成 OCU をオフロードして削減します。GPU を使用すると、インデックスがより効率的に構築されるため、合計 OCU 使用量が少なくなり、コスト削減につながります。

マネージドドメインでは、OpenSearch Serverless のように検索とインデックス作成のインフラストラクチャが分離されていないため、コスト削減は状況に依存します。ただし、書き込み負荷が高く、計算バウンドのベクトル検索アプリケーション (つまり、書き込みスループットを維持するために vCPU 用にドメインがサイズ設定されている場合) がある場合は、ドメインをダウンサイズできる可能性があります。

次のベンチマークは、GPU アクセラレーションによる効率向上を示しています。インデックス作成タスク中のインフラストラクチャコストを測定しています。GPU アクセラレーションには、OCU あたり $0.24/時間の GPU の追加コストがかかります。ただし、インデックスがより高速かつ効率的に構築されるため、GPU を使用してドメインの CPU 使用率を削減し、ダウンサイズする方が経済的です。

*ドメインはコスト最適化なしの高可用性構成で実行されています

書き込みの高速化と検索レイテンシーの低減

経験豊富な手にかかれば、ドメインは運用制御と優れたスケーラビリティ、パフォーマンス、コスト最適化を実現する能力を提供します。ただし、運用責任には共有インフラストラクチャでのインデックス作成と検索ワークロードの管理が含まれます。ベクトルデプロイメントに大量の持続的なストリーミング取り込み、更新、削除が含まれる場合、ドメインで検索時間が長くなることがあります。次のグラフに示すように、ベクトル書き込みを増やすと、HNSW グラフ構築をサポートするために CPU 使用率が増加します。計算リソースと RAM リソースの競合により、同時検索レイテンシーも増加します。

ドメインの計算能力を増やすためにデータノードを追加することで問題を解決できます。ただし、GPU アクセラレーションを有効にする方がシンプルで安価です。グラフに示すように、GPU はドメインの CPU と RAM を解放し、高い書き込みスループット下でも低く安定した検索レイテンシーを維持するのに役立ちます。

使用を開始する

使用を開始する準備はできましたか？既に OpenSearch Service のベクトルデプロイメントがある場合は、AWS マネジメントコンソール、AWS Command Line Interface (AWS CLI)、または API を使用して、OpenSearch 3.1 以降のドメインまたはベクトルコレクションで GPU アクセラレーションを有効化してください。既存のインデックス作成ワークロードでテストしてください。新しいベクトルデータベースを構築する予定の場合は、ベクトルの取り込み、インデックス作成、最適化の自動化を簡素化する新しいベクトル取り込み機能をお試しください。YouTube でのデモンストレーションをご覧ください。

謝辞

NVIDIA の Manas Singh、Nathan Stephens、Jiahong Liu、Ben Gardner、Zack Meeks、および AWS の Yigit Kiran と Jay Deng のこの記事への貢献に感謝します。

著者について

Dylan Tong Dylan は Amazon Web Services のシニアプロダクトマネージャーです。OpenSearch のベクトルデータベース機能を含む、OpenSearch の AI および機械学習 (ML) の製品イニシアチブをリードしています。Dylan は、データベース、アナリティクス、AI/ML 分野でお客様と直接協力し、製品やソリューションを作成してきた数十年の経験があります。Dylan は Cornell University でコンピューターサイエンスの学士号と修士号を取得しています。

Vamshi Vijay Nakkirtha Vamshi は OpenSearch Project と Amazon OpenSearch Service に取り組むソフトウェアエンジニアリングマネージャーです。主な関心分野は分散システムです。

Navneet Verma Navneet は AWS のプリンシパルソフトウェアエンジニアで、OpenSearch のコアベクトル検索に取り組んでいます。

Aruna Govindaraju Aruna は Amazon OpenSearch スペシャリストソリューションアーキテクトで、多くの商用およびオープンソースの検索エンジンに携わってきました。検索、関連性、ユーザーエクスペリエンスに情熱を持っています。エンドユーザーシグナルと検索エンジンの動作を相関させる専門知識により、多くのお客様の検索エクスペリエンスの向上を支援してきました。

Corey Nolet Corey は NVIDIA のベクトル検索、データマイニング、クラシカル ML ライブラリのプリンシパルアーキテクトで、極端なデータ負荷を光速でサポートするアルゴリズムの構築とスケーリングに注力しています。2018 年に NVIDIA に入社する前は、防衛産業でビッグデータと HPC 環境向けの大規模な探索的データサイエンスおよびリアルタイム分析プラットフォームの構築に長年携わっていました。Corey はコンピューターサイエンスの学士号と修士号を取得しています。また、グラフと機械学習の交差点でアルゴリズムを高速化することに焦点を当てた同分野の博士号取得を進めています。Corey はデータを使用して世界をより良く理解することに情熱を持っています。

Kshitiz Gupta Kshitiz は NVIDIA のソリューションアーキテクトです。NVIDIA が提供する GPU AI テクノロジーについてクラウドのお客様に教育し、機械学習およびディープラーニングアプリケーションの高速化を支援することを楽しんでいます。仕事以外では、ランニング、ハイキング、野生動物観察を楽しんでいます。

この記事は Kiro が翻訳を担当し、Solutions Architect の 榎本 貴之 がレビューしました。