本記事は 2025 年 2 月 25 日に公開された Dr. Tomasz Zemojtel、Christopher Gatsch、Dr. Manuel Delpero、Zhan Ying、Dr. Mueller Michael による “ Enhanced Genomic Data Storage and Workflows with MGI, Sentieon, and AWS ” を翻訳したものです。 ゲノム研究の分野はかつてないスピードで進化しており、データストレージと解析に堅牢かつスケーラブルなソリューションが求められています。MGI、Sentieon、Amazon Web Services (AWS) は協業により、ゲノム研究を支援する機能を提供します。研究者や臨床医は、AWS HealthOmics と Sentieon のワークフローを活用することで、MGI のシーケンシング技術の能力を最大限に引き出せるようになりました。これにより、効率的なデータの保管、取得、整理と、大規模で高精度なゲノム解析が可能になります。 本記事では、この統合的な協業のソリューションアーキテクチャ、ワークフローの選択肢、そして研究ラボにおけるハイスループットなゲノム解析の実装の詳細をご紹介します。 ベルリンのMGI 欧州本社におけるハイスループットなゲノムデータ解析 ハイスループットシーケンシング施設は、膨大なデータ量と解析ワークフローの管理に大きな課題を抱えています。ローカルストレージや計算基盤を利用する従来のアプローチでは、データ生成の規模に対応しきれず、処理のボトルネック、高いメンテナンスコスト、複雑なデータセキュリティ要件などが発生しがちです。ラボには、データストレージをシームレスに扱い、スケーラブルな計算リソースを提供し、セキュリティコンプライアンスを維持しつつ、予測可能なコストで利用できるソリューションが必要です。 MGI-tech はバイオテクノロジーイノベーションのリーダーであり、次世代シーケンシング (NGS) とラボオートメーション技術を開発・提供しています。同社のフラッグシップである DNBSEQ プラットフォームは、精密医療、農業、ヘルスケア分野に向けて、高精度かつハイスループットな遺伝子解析ソリューションを提供します。 ベルリンにあるMGI 欧州本社には 3 台のハイスループット T7 シーケンサーが設置されており、週あたり合計で最大 63 テラベース (Tb、テラ塩基) のゲノムデータを生成しています。3 台の T7 シーケンサーが生成したデータは AWS へ安全に転送され、ゲノムデータ向けにスケーラブルかつコストを最適化したストレージソリューションである AWS HealthOmics Sequence Store に取り込まれます。AWS HealthOmics 内では、Sentieon の高性能なプライベートワークフローが実行され、高速かつ高精度なデータ解析が行われます。 この統合型のハイスループットソリューションにより、MGI 欧州本社の研究者や臨床医は、重要なアプリケーションに向けて複雑なゲノムデータから価値ある知見を引き出せます。具体的には、遺伝性疾患の診断、がん研究、医薬品開発、大規模な集団ゲノミクスの研究などが含まれます。 AWS HealthOmics と Sentieon AWS HealthOmics は、ゲノムデータの保管、処理、解析のためのセキュアでスケーラブルなサービスです。HealthOmics Sequence Store は、大量のシーケンシングデータをコスト効率よく保管する手段を提供し、HealthOmics ワークフローとのシームレスな統合によって、下流解析ですぐに利用できる状態を保ちます。保存時の機密性の高い顧客データを保護するため、HealthOmics は AWS Key Management Service (AWS KMS) の AWS 所有のキーを用いてデフォルトで暗号化を行います。カスタマーマネージドキーもサポートされています。 Sentieon は 2014 年から AWS パートナーであり、高速かつ高精度なゲノムデータ処理のために最適化されたバイオインフォマティクスアルゴリズムを開発してきました。HealthOmics ワークフローでは、Sentieon の DNAscope および TNseq パイプラインを、あらかじめ定義された Ready2Run ワークフローとしても、カスタマイズ可能なプライベートワークフローとしても実行できます。 アーキテクチャの概要 図 1 – ベルリンのMGI 欧州本社で実装されたワークフローアーキテクチャ。 図 1 は次の流れを示しています。 MGI DNBSEQ-T7 シーケンサーが 1 週間で最大 21 Tb (テラベース) のデータを CAL 形式 (MGI シーケンサーのベースコールソフトウェアが生成するバイナリファイル形式) で出力します。 MGI ZTRON Lite Pro が CAL ファイルを FASTQ ファイルに変換し、データの受け渡しを可能にします。 FASTQ ファイルは AWS 上の Amazon Simple Storage Service (Amazon S3) に安全に転送されます。 これらのファイルは AWS HealthOmics Sequence Store にインポートされます。また、 HealthOmics Transfer Manager を通じて、ローカルストレージから FASTQ ファイルを HealthOmics Sequence Store に直接アップロードすることもできます。 DNAscope や TNseq パイプラインなどの Sentieon Genomics ソフトウェアは、HealthOmics ワークフロー上で Ready2Run ワークフローとしても、カスタマイズ可能なプライベートワークフローとしても実行できます。 ワークフロー実行の最後に、AWS HealthOmics は生成された BAM および VCF ファイルを S3 バケットへ転送します。 結果は臨床研究者などのユーザーによって参照されます。 Ready2Run ワークフロー: 迅速かつ簡単なセットアップ 迅速でシンプルなソリューションを求める研究者向けに、Sentieon の Ready2Run ワークフローは、あらかじめ構築・最適化されたパイプラインを提供します。数クリックまたはシンプルな API 呼び出しでデプロイでき、固定料金かつ予測可能な実行時間で動作します。これらのワークフローは、次のようなさまざまなゲノム解析タスクに対応するよう設計されています。 DNAscope : MGI シーケンシングプラットフォーム向けに最適化された、生殖細胞系列バリアントコール用パイプライン。 TNseq : 体細胞バリアントコール用パイプライン。GATK の Mutect2 と同等の精度を達成しながら、MGI データではより短い実行時間を実現します。 AWS HealthOmics ワークフローを利用することで、研究者は Sentieon の Ready2Run パイプラインから選択でき、さまざまな解析ニーズ、リファレンスゲノム、シーケンシングプラットフォームに対応する柔軟な選択肢を得られます。これらのワークフローは実行単位で課金されるため、コストを予測しやすく、ハイスループットなゲノミクスプロジェクトに必要なスケーラビリティを提供します。 プライベートワークフロー: 高度なユーザー向けの完全なカスタマイズ より高度な制御やカスタマイズを必要とするチーム向けに、Sentieon は AWS HealthOmics 上でパイプラインをプライベートワークフローとして実行することもサポートしています。これらのワークフローは完全な柔軟性を提供し、研究者が固有のニーズに合わせてワークフローをカスタマイズ・最適化できるようにします。 Sentieon のプライベートワークフローを実行することで、ユーザーは次のことが可能になります。 AWS 向けの Sentieon コンテナイメージを独自に構築する。 パラメーター、リファレンスゲノム、解析結果の出力内容をカスタマイズする。 パイプライン構成を制御しつつ、AWS HealthOmics のインフラストラクチャを活用する。 プライベートワークフローを始めるには、 Sentieon GitHub リポジトリ で提供されている詳細なセットアップ手順に従ってください。このリポジトリには、コンテナイメージ、セットアップスクリプト、WDL および Nextflow の両エンジン向けのワークフローサンプルなど、カスタマイズしたワークフローの構築とデプロイに必要なものがすべて含まれています。プライベートワークフロー向けに Sentieon ライセンスサーバーを有効化する手順については、 Requesting Sentieon licenses for private workflows を参照してください。 まとめ MGI、Sentieon、AWS の協業は、ゲノミクスラボ向けの堅牢なソリューションを提供します。MGI のシーケンシング技術を活用することで、合理化された、かつカスタマイズ可能なワークフローを AWS インフラストラクチャとシームレスに統合して利用できます。また、Sentieon の Ready2Run ワークフローを実行する場合でも、プライベートワークフローをセットアップする場合でも、研究者は AWS HealthOmics を活用して、セキュアでコンプライアンスに準拠した環境で大規模にゲノムデータを保管・解析できます。これにより、より迅速かつ高精度な発見が可能になります。 AWS KMS 暗号化などの組み込みのセキュリティ機能により、コンプライアンスに準拠した環境でのデータ保護が確保されます。また、固定料金の Ready2Run ワークフローは、予測可能なコストと自動化されたリソース管理を提供します。 MGI、Sentieon、AWS のこの協業は、MGI シーケンシング技術を活用するゲノミクスラボ向けに堅牢なソリューションを提供し、より迅速かつ高精度な発見を可能にします。このソリューションは、ハイスループットシーケンシング業務に一般的に伴う処理のボトルネックの解消に役立ちます。 この統合ソリューションをゲノム研究や臨床アプリケーションに実装する方法について詳しくは、 AWS HealthOmics のウェブページや Sentieon GitHub リポジトリ をご覧ください。また、この技術がお客様のゲノム解析ワークフローをどのように加速できるかについて、個別のご相談を承ります。 AWS 担当者 までお問い合わせください。 謝辞 本ブログの作成にご協力いただいた MGI-tech のバイオインフォマティクスサイエンティスト Dr. Liene Astica、フィールドバイオインフォマティクスサイエンティスト Ying Zhan、フィールドアプリケーションサイエンティスト Ongeziwe Mbhele の各氏に感謝申し上げます。 参考資料 AWS for Genomics Solutions AWS Healthcare & Life Sciences Blog Collection AWS Healthcare & Life Sciences – Security and Compliance Genomics Unlocked: MGI-tech の最新ウェビナーシリーズを視聴できます 著者について Dr. Tomasz Zemojtel Dr. Tomasz Zemojtel は、AWS の EMEA 地域におけるヘルスケアビジネス開発マネージャーです。ヘルスケアとテクノロジーのバックグラウンドを持ち、ヘルスケア組織や研究・臨床機関がクラウドサービスを活用してイノベーションを推進できるよう支援することを専門としています。Tomasz は、クラウドコンピューティングを通じて大規模な臨床データセットの可能性を引き出し、個別化医療や統合型ヘルスケアソリューションを前進させることに情熱を注いでいます。仕事以外では、ジョギングや山歩き、海辺で過ごす時間を楽しんでいます。 Christopher Gatsch Christopher Gatsch は MGI のフィールドバイオインフォマティクスサイエンティストで、顧客ワークフローの最適化や BIT 製品体験・ワークフロー効率の向上に注力しています。読書、アウトドア活動、さまざまな国への旅行に情熱を注いでいます。 Dr. Manuel Delpero Dr. Manuel Delpero は MGI のアプリケーションサイエンティスト部門のアソシエイトマネージャーで、顧客ワークフローの最適化と、バイオインフォマティクスとコマーシャル戦略の橋渡しを専門としています。分子遺伝学およびバイオインフォマティクスの博士号を持ち、バイオテクノロジーの技術面とビジネス面の両方において幅広い業界経験があります。ウェイトトレーニング、旅行、新しいビジネス機会の探求に情熱を注いでいます。 Zhan Ying Zhan Ying は人工知能のバックグラウンドを持つ IT スペシャリストで、包括的な BIT ソリューションを提供しています。マシン統合、ユーザーラボのネットワーキング、販売後のトラブルシューティングなど、BIT 関連の IT サポートを担当しています。 Dr. Mueller Michael Dr. Michael Mueller は AWS のシニアゲノミクスソリューションアーキテクトです。ゲノミクスとクラウドコンピューティングの力を組み合わせてヘルスケアを改善する取り組みを支援することに情熱を注いでいます。ロンドンの大都会の探索と、イギリスやヨーロッパのアウトドアの両方を楽しんでいます。 翻訳は Solutions Architect の吉村が担当いたしました。

はじめに はじめまして。東京海洋大学 海洋工学部2年の恩田梨那(@cs_riri)と申します。 今回 ...

本記事は 2026 年 8 月 11 日 に公開された「 How GPU acceleration builds billion-scale vector indexes on Amazon OpenSearch Service 」を翻訳したものです。 生成 AI アプリケーションが急速に増えるなか、いまの検索には高性能なベクトルインデックス作成とスケーラビリティが求められます。データセットが数十億件規模に達すると、従来の CPU ベースのインデックス作成がボトルネックになりがちで、生産性やイノベーションのスピードを鈍らせてしまいます。 GPU で高速化したベクトル (k-NN) インデックス作成が Amazon OpenSearch Service と Amazon OpenSearch Serverless で 利用できるようになり 、数十億件規模のベクトルにも効率よくスケールできます。この機能は、GPU アクセラレーションによるベクトル検索向けのオープンソースライブラリ NVIDIA cuVS を基盤としており、計算負荷の高いベクトルインデックスの構築を専用の GPU ワーカーにオフロードします。その間、既存の CPU インフラは検索の処理を続けられます。結果として、クエリ性能を犠牲にすることなく、大規模なベクトルインデックスをより速く、より低コストで構築できます。 以前の記事 では、性能とコスト面のメリットを詳しく紹介しました。本記事では、この機能の仕組みをさらに掘り下げます。まず、その土台にある分離型アーキテクチャを見ていきます。次に、GPU で構築したインデックスが、品質を落とすことなく CPU データノードで検索可能な形式に変換される過程を説明します。さらに、10 億件の 1024 次元ベクトルを使ったベンチマークで、大規模環境でもこの方式が通用することを示します。最後に、本番環境で GPU アクセラレーションによるインデックス構築を運用する際に推奨するベストプラクティスを紹介します。 ユースケースとメリット さまざまな業界の企業が、より豊かな顧客体験を提供するために AI やエージェント型のアプリケーションを構築しています。ベクトルインデックス作成の GPU アクセラレーションは、こうした幅広いユースケースで役立ちます。いくつか例を挙げます。 新しい埋め込みモデルへの移行を速める: より新しい埋め込みモデルにアップグレードすると、すべてのベクトルを生成し直してインデックスを作り直す必要があります。数億から数十億件規模になると、CPU での再構築には数日から数週間かかることもあります。GPU アクセラレーションなら再構築を数時間に短縮できるため、より高品質なモデルへ移行しつつ、再インデックスにかかる時間と可用性へのリスクを大幅に減らせます。 大規模な再インデックスを高速化する: 数十億件の商品リスト、カスタマーレビュー、行動シグナルを扱うグローバルな e コマースアプリケーションでは、新しい商品や埋め込みが追加されるたびに、ベクトルインデックスを素早く作り直す必要があります。GPU アクセラレーションは限られた運用時間内で再インデックスを完了し、検索の関連性を常に最新に保ちます。 急増する書き込みや高い持続書き込みを吸収する: ワールドカップやオリンピックといった大規模スポーツイベントを扱うメディア企業では、数百万件のリアルタイム埋め込みを同時にインデックスする必要があります。これらの埋め込みは、試合のハイライト、解説クリップ、選手のプロフィール、ファンが投稿したコンテンツにまたがり、同時に数百万人の視聴者が関連コンテンツを検索します。GPU ワーカーはこのインデックス作成の急増を吸収し、ライブ検索トラフィックを処理する CPU ノードと競合しません。そのため、大量書き込みにつきものの遅延の急増を避けられます。 読み書き混在のワークロードに合わせてクラスターを最適化する: 小売システムでは従来、カタログ更新時のピーク時のインデックス負荷と、同時に発生する検索トラフィックの両方に対応するため、CPU クラスターを過剰にプロビジョニングし、ピーク時の容量分を常時支払っていました。インデックス作成を GPU にオフロードすれば、CPU クラスターを検索専用に適正なサイズへ調整でき、性能を落とさずにインフラコストを削減できます。 セマンティック検索や OpenSearch への移行を速める: テキストベースのコーパスを初めてベクトル埋め込みに変換する場合でも、既存のベクトルワークロードを別のデータベースから Amazon OpenSearch Service へ移行する場合でも、GPU アクセラレーションによるインデックス作成なら、数日かかるインデックス構築を数時間に短縮できます。GPU による上流の埋め込み生成のスピードに歩調を合わせ、切り替え時のリスクも最小限に抑えられます。 GPU アクセラレーションはいつ有効になるのか GPU アクセラレーションは、オプトインすれば自動的に有効になります。OpenSearch Service ドメインでは、Vector Acceleration オプションをオンにするだけで有効になり、それ以降はコードや API フラグを変更する必要はありません。OpenSearch Serverless では、NextGen ベクトル検索コレクションで GPU によるインデックス構築の高速化がデフォルトで有効です。図 1 はインデックス構築のワークフローを示しています。OpenSearch はセグメントのサイズに応じてベクトルインデックス作成の処理を GPU と CPU に自動で振り分け、性能を最適化します。問題が発生した場合は CPU にフォールバックします。 OpenSearch がセグメントをフラッシュまたはマージするとき、そのセグメントのベクトルデータサイズを、 index.knn.remote_index_build.size.min と index.knn.remote_index_build.size.max で区切られた 設定可能な範囲 と比較します。下限のデフォルトは 50 MB です。下限を超えるセグメントはリモートの GPU ワーカーにオフロードされ、それより小さいセグメントはローカルの CPU で構築されます。セグメントのベクトルサイズは次の式で計算します。 segment_vector_size = num_vectors × dimensions × bytes_per_element そのため、ドキュメント数が同じ 2 つのワークロードでも、セグメントサイズが異なることがあります。 ベクトル数 次元数 エンコーディング セグメントのベクトルサイズ 100,000 1536 Float32 約 586 MB 100,000 768 Byte 約 74 MB どちらの例もデフォルトの下限 50 MB を超えているため、デフォルト設定では両方のセグメントが GPU ワーカーにオフロードされます。 図 1: インデックス構築の簡略化したフロー 分離型のインデックス作成アーキテクチャ OpenSearch のインデックスは内部的にセグメントに分割され、各セグメントが独自のベクトルグラフを持ちます。このセグメント単位の構造こそが、GPU へのオフロードを実用的にしています。各セグメントのグラフは、インデックス全体で調整をとらなくても、GPU ワーカー上で独立して構築できます。これを土台にした、アーキテクチャ上の重要な着想が、ベクトルをインデックスする場所と検索する場所を分離することです。既存の CPU データノードは、取り込み、検索、ベクトル以外のワークロードの処理を続けます。セグメントがベクトルインデックスの構築段階に入ると、負荷の高いグラフ構築の作業が専用の GPU ワーカーにオフロードされ、完成したインデックスがデータノードに返されて検索に使われます。 インデックス構築のワークフロー 取り込み – ベクトルフィールドを持つドキュメントは、通常どおり OpenSearch Service ドメインまたは OpenSearch Serverless コレクションに取り込まれます。ベクトルは CPU データノード上のセグメントに蓄積されていきます。 オフロード – セグメントがフラッシュまたはマージされ、そのベクトルデータが GPU の有効化範囲に収まると、データノードは元のベクトルを Amazon Simple Storage Service (Amazon S3) にアップロードし、構築リクエストを送信します。 構築 – マネージドなウォームプールの GPU ワーカーがジョブを受け取り、ベクトルを読み込んで、NVIDIA cuVS の GPU ネイティブなグラフアルゴリズムである CAGRA (CUDA ANN Graph) を使ってインデックスを構築します。できあがった CAGRA グラフは、その後 CPU ベースの検索と互換性のある Hierarchical Navigable Small World (HNSW) グラフに変換されます。 受け取り – 完成した HNSW インデックスは Amazon S3 に書き戻され、データノードがダウンロードします。データノードはそのインデックスを使って検索クエリに応答します。 フルマネージドな GPU インデックス構築 Vector Acceleration を有効にする だけで、あとは Amazon OpenSearch Service が処理します。 自動スケーリング – GPU ワーカーは、待機中の構築ジョブ数に応じて自動でスケールアップ・スケールダウンします。一括取り込みや再インデックスの際には、負荷に対応するために GPU ワーカーが増えます。キューが空になると、ゼロまで縮小します。 自動インスタンス選択 – サービスがセグメントサイズに基づいて、構築ジョブごとに適切な GPU インスタンスタイプを選びます。ユーザー側でキャパシティプランニングやインスタンスの選択を行う必要はありません。 アクティブな構築時のみ課金 – 課金されるのは GPU が実際にインデックスを構築している間だけで、アイドル状態のときは課金されません。ドメインやコレクションで Vector Acceleration を有効にしていても、OpenSearch Compute Unit (OCU) で計測される GPU の料金は、セグメントが有効化のしきい値に達してインデックス構築が始まったときにのみ発生します。GPU インフラを常時保有するコストはかかりません。 したがってコストは、インデックス作成の量に応じて直接増減します。急増する再インデックスのワークロードは構築が続く間だけ GPU 容量を消費し、次の構築まで GPU コストはゼロに戻ります。 図 2 は分離型の GPU ワークフローを示しています。Amazon S3 がデータノードと GPU ワーカーの仲介役となり、両者が独立して動作できるようにします。データノードは元のベクトルを Amazon S3 にアップロードし、GPU ワーカーが CAGRA グラフを構築して HNSW に変換します。完成したインデックスはデータノードに返されて検索に使われ、その間も検索は中断なく動き続けます。 図 2: GPU インデックスフローのアーキテクチャ CAGRA から HNSW への変換の中身 前のセクションでは、GPU ワーカーがベクトルインデックスを構築してデータノードに返す流れを説明しました。では、GPU で構築したグラフはどうやって CPU で検索可能になるのでしょうか。そして、この変換で品質は落ちるのでしょうか。結論から言うと、落ちません。 CAGRA アルゴリズム GPU ワーカーは、 Facebook AI Similarity Search (Faiss) ライブラリの cuVS GPU バックエンドを通じて統合された CAGRA アルゴリズムを使います。CAGRA は、GPU アクセラレーションを前提に一から設計されたグラフベースのインデックス作成手法です。まず、 Inverted File with Product Quantization (IVF-PQ) や Nearest Neighbor Descent (NN-Descent) といった別の近似最近傍探索の手法を使って k-NN グラフを構築します。次に、近傍間の冗長な経路を取り除き、探索しやすいグラフに整えます。 図 3: CAGRA グラフの構築フロー 出典: CAGRA: Highly Parallel Graph Construction and Approximate Nearest Neighbor Search for GPUs GPU ワーカーによるインデックス構築の流れ GPU ワーカーがベクトルインデックスの構築リクエストを受け取ると、そのリクエストにはセグメント固有のベクトルインデックスを構築するために必要なパラメータが含まれています。ベクトルインデックス構築コンポーネントは、まず Amazon S3 からベクトルファイルを取得して CPU メモリに読み込み、処理を開始します。読み込んだベクトルを使って、Faiss で CAGRA インデックスを構築します。GPU 上で CAGRA インデックスを構築したあと、CPU ベースの検索処理と互換性を持たせるために HNSW グラフ形式へ変換します。できあがったインデックスを Amazon S3 にアップロードして、構築リクエストが完了します。 CAGRA グラフを HNSW に変換する 一般的な HNSW インデックスは、複数の層からなる階層型グラフです。グラフの 最下層 (レイヤー 0) がベクトルを保持し、上位の層はナビゲーションだけに使われる疎なサブセットです。上位の層は、検索アルゴリズムが最下層への適切な入口を見つけるのを助けます。ただし、今回の HNSW 実装では CAGRA グラフを最下層として使い、CAGRA の検索手法と同じように、グラフへのランダムな入口から探索を始めます。そのため上位の層はまったく必要ありません。 つまり、基盤となる層のグラフを構築する重い処理は GPU が担います。そのグラフを HNSW の基盤層としてそのまま再利用することで、CPU で作り直す必要がなくなり、変換の負荷を低く抑えられます。図 4 のように、CAGRA グラフがそのまま基盤層になります。クエリの実行時には、グラフ内のノードをランダムに選び、最近傍へのリンクをたどってグラフを探索します。これは貪欲探索 (greedy search) と呼ばれる方法です。 図 4: HNSW に変換した CAGRA グラフの検索 同じ再現率で、より速い構築 これまでの ベンチマーク で、GPU で構築したインデックスが、 CPU で構築した HNSW と同じ再現率 を、品質を落とさずに達成することが確認されています。これは、CAGRA が生成する最下層のグラフ構造が、接続性と検索品質の点で、HNSW が CPU 上で構築するものと同等だからです。異なるのは構築の方法だけです。 GPU メモリを超える規模へのスケール GPU メモリに収まらないデータの構築 従来の GPU インデックス作成では、データセット全体を GPU メモリに載せる必要があり、利用できるハードウェアによってインデックスサイズに明確な上限が生まれていました。CAGRA は、データセット全体を一度に GPU メモリへ載せずに k-NN グラフを構築する方式 ( アウトオブコア構築 ) によって、この制約を取り除きます。CAGRA の初期 k-NN グラフの構築に IVF-PQ を使う場合、データはシステムメモリから GPU へバッチ単位でストリーミングされるため、データセット全体を一度に GPU メモリへ収める必要がありません。その一方で、計算負荷の高い距離計算やグラフの最適化は引き続き GPU が担います。 量子化 GPU アクセラレーションによるインデックス作成は、OpenSearch で利用できる量子化レベル (2 倍、8 倍、16 倍、32 倍の圧縮) に対応しています。量子化は、ベクトルを GPU に送る 前に 適用されます。これにより、GPU ワーカーへのデータ転送量と、グラフ構築時のメモリ使用量の両方を削減できます。その結果、より大きなセグメントに対してインデックスを構築でき、コスト効率が高まります。 GPU で 10 億件の 1024 次元ベクトルをインデックスする データセットの準備 現実的な大規模ワークロードを評価するために、1024 次元のベクトルを 10 億件含むデータセットを使いました。一様なランダムベクトルは、インデックス構築と再現率のどちらでも誤解を招く結果になるため、実世界の埋め込みの構造を保ったデータが必要でした。このデータセットは、 cuvs-bench に含まれる cuVS の合成データセットジェネレーターで作成しました。このジェネレーターは、Common Crawl から得た実際の埋め込みデータセットの分布を模した合成データを出力します。この方法を使えば、機微な元データを公開したり配布したりせずに、現実的なデータセットを用意できます。ジェネレーターは、10 億件のベクトルデータセット一式と 10,000 件のクエリベクトル、および対応する正解ラベルを、1 台の Amazon Elastic Compute Cloud (Amazon EC2) g6e.16xlarge インスタンス上で、約 2 時間で生成できます。 クラスター構成 ベンチマーク用のクラスターは、OpenSearch のベクトル検索のパフォーマンスチューニングの ベストプラクティス に従って OpenSearch Service 上に設計し、 OpenSearch Benchmark フレームワーク を使ってベンチマークを実施しました。 設定項目 値 理由 データノード 24 × r8g.4xlarge 大規模なベクトルインデックス向けのメモリ最適化インスタンス プライマリシャード 48 シャードサイズを扱いやすく保ち、並列性を最大化する レプリカ 0 インデックス作成のスループットを最大化する。レプリカは構築後に追加する GPU ワーカー 10 (事前スケール) 測定中のコールドスタートの影響を避ける 一括クライアント 160 24 ノードにわたって取り込みパイプラインを飽和させる 一括サイズ 500 ドキュメント/リクエスト リクエストごとの負荷とメモリ圧迫のバランスをとる リフレッシュ間隔 -1 (取り込み中) 小さなセグメントの生成を防ぐ。取り込み後に強制マージを実行する マージの自動スロットリング 無効 ベンチマーク中の人為的なボトルネックを避ける 適用した主なベストプラクティス メモリ最適化インスタンス – r8g.4xlarge は、構築後の HNSW グラフを読み込むのに十分なヒープとネイティブメモリを備えています。 一括取り込み中はリフレッシュを無効化 – 小さなセグメントが多数生成され、それぞれが個別の GPU 構築を発生させるのを防ぎます。 多数の一括クライアント – ノード全体で取り込みを飽和させ、GPU がインデックス構築で常に稼働している状態を保ちます。 HNSW の構築と検索の設定 ( m や ef_construction など) は OpenSearch のデフォルト値を使いました。ほとんどのユーザーがデフォルト値から始めるため、ベンチマークを実態に即したものに保てます。 ベンチマーク結果 データセット インデックス構築 (分) 再現率 @k =100 再現率 @1 P50 (検索) P90 (検索) P99 (検索) 使用した Vector Acceleration OCU 1024D 1B 274 0.93 0.93 26.47ms 32.5ms 66.6ms 44 構築時間はデータ量に比例してスケールする 以前の OpenSearch Service でのベンチマーク では、10 億件の 128 次元ベクトル (BigANN SIFT データセット) を約 35.5 分でインデックスしました。最新のベンチマークでは、次元数を 8 倍の 1024 次元に拡大し、274 分でインデックス構築を完了しました。これはデータ量の増加におおむね比例した結果です。GPU アクセラレーションが、次元数が増えても一貫したスループット効率を保つことを示しています。構築時間は固定的な起動コストではなくデータ量に応じてスケールするため、データセットのサイズからインデックス構築時間をあらかじめ見積もれます。この規模でも検索のレイテンシーは低いままだったため、できあがったインデックスは、構築の速さを犠牲にすることなく応答性の高いクエリに対応できました。 GPU アクセラレーション向けに一括取り込みを最適化する 大量のベクトルデータを読み込むとき、インデックスの動作を一時的に調整すると、GPU の処理負荷を大幅に減らせます。この方法は、ユースケースがデータの一時的な鮮度低下を許容できる場合に有効です。インデックス全体を構築している間は、新しく取り込んだベクトルはリフレッシュを再度有効にするまで検索対象にならないため、通常は問題ありません。一括取り込み中にリフレッシュを無効にする ( "index.refresh_interval": "-1" ) と、小さなセグメントが連続して生成されるのを防げます。そうしないと、小さなセグメントのそれぞれが個別の GPU 構築ジョブを発生させてしまいます。取り込みが完了したら、リフレッシュ間隔を有効に戻してリフレッシュを実行し、セグメントを検索可能にします。この方法により、GPU は多数の小さなセグメントに対して繰り返しインデックスを構築するのではなく、大きく密に詰まったセグメントに対して一度だけ構築するため、全体としてインデックス作成のスループットが速くなります。 GPU アクセラレーションを有効にしたあとは、 Amazon CloudWatch メトリクス (クラスターレベル) と OpenSearch k-NN Stats API (ノードごと) で構築状況を監視できます。GPU での構築が失敗した場合、システムは自動的に CPU ベースのインデックス構築にフォールバックするため、データは引き続きインデックスされます。 今後の最適化 現在は、完成した HNSW インデックス (グラフ構造とベクトル) が、GPU ワーカーから Amazon S3 を経由してデータノードに転送されています。データノードは元のベクトルをすでにローカルに保持しているため、今後の最適化ではグラフ構造 (近傍リスト) だけを転送するようにします。これにより、Amazon S3 への書き戻し量とデータノードへのダウンロード時間を大幅に削減できます。 まとめ GPU アクセラレーションによるインデックス作成を使うと、Amazon OpenSearch Service 上で 10 億規模のベクトルインデックスを、数日ではなく数時間で構築できます。しかも、OpenSearch Service ドメインと OpenSearch Serverless コレクションのどちらでも、クエリの処理方法を変える必要はありません。本記事では、OpenSearch Service が対象となるインデックス構築を GPU ワーカーにオフロードし、Faiss の NVIDIA cuVS バックエンドを通じて CAGRA グラフを構築し、それを CPU で検索可能な HNSW インデックスに変換する仕組みを紹介しました。さらに、10 億件の 1024 次元ベクトルで大規模にこの方式を実証し、一括取り込みの最適化や、構築状況と OCU 使用量の監視についてのベストプラクティスを共有しました。 使ってみる GPU アクセラレーションによるベクトルインデックス作成を試してみませんか。対応している AWS リージョンでは、OpenSearch 3.1 以降を実行する OpenSearch Service ドメインを作成または更新する際に、GPU アクセラレーションを有効にできます。設定には、AWS マネジメントコンソール、AWS Command Line Interface (AWS CLI)、または AWS SDK を使います。OpenSearch Serverless を新しくデプロイする場合は、 NextGen ベクトル検索コレクション を作成してください。このコレクションでは GPU によるインデックス構築の高速化がデフォルトで有効になっており、インデックスごとに制御できます。Classic ベクトルコレクションの場合は、コレクションレベルで GPU アクセラレーションを有効にします。 謝辞 著者一同、本記事への貢献に対し、NVIDIA の Ben Gardner、Manas Singh、Zack Meeks、Jiahong Liu、James Yi、Jinsol Park の各氏に感謝します。 著者について Navneet Verma Navneet は、 Navneet は AWS のプリンシパルソフトウェアエンジニアで、OpenSearch のコアなベクトル検索に取り組んでいます。スケーラビリティ、性能、そして大規模な AI ワークロードに向けたベクトル検索の発展に情熱を注いでいます。 Vamshi Vijay Nakkirtha Vamshi は、 Vamshi は、OpenSearch Project と Amazon OpenSearch Service に携わるソフトウェアエンジニアリングマネージャーです。分散システムに関心があります。 Gowri Balasubramanian Gowri は、 Gowri は、Amazon Web Services でデータスペシャリストソリューションアーキテクトチームを率いるシニアマネージャーです。AWS のデータベースサービスと分析サービスの導入を推進するとともに、リファレンスアーキテクチャからベストプラクティスまでの実践的なガイダンスを整備し、企業のデータと AI の変革を後押ししています。スケーラブルな分散データシステムに情熱を注いでいます。 Kshitiz Gupta Kshitiz は、 Kshitiz は NVIDIA のシニアソリューションアーキテクトで、クラウドのお客様が GPU 上で大規模な AI ワークロードを最適化できるよう支援しています。GPU アクセラレーションによるデータ処理、ベクトル検索、LLM の推論と幅広く手がけ、AWS や Amazon のチームと緊密に連携して、これらの機能を本番環境に届けています。仕事以外では、音楽、ヨガ、ハイキングを楽しんでいます。 Corey Nolet Corey は、 Corey は NVIDIA でベクトル検索、データマイニング、古典的な機械学習ライブラリを担当するディスティングイッシュトエンジニアで、極めて大きなデータ負荷を高速に処理するためのアルゴリズムの構築とスケールに注力しています。2018 年に NVIDIA に加わる前は、防衛業界のビッグデータや HPC 環境で、大規模な探索的データサイエンスとリアルタイム分析のプラットフォームを長年にわたり構築してきました。Corey はコンピューターサイエンスの博士号を持ち、データを使って世界をよりよく理解することに情熱を注いでいます。 Rajeshwari Devaramani Rajeshwari は、 Rajeshwari は NVIDIA のソリューションアーキテクトです。ジョージア工科大学で計算科学工学の修士号を取得しています。GPU プログラミング、ハイパフォーマンスコンピューティング、ディープラーニングを専門としてきました。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。