Amazon OpenSearch Service の UltraWarm でベクトル検索が利用可能に

本記事は 2025 年 3 月 20 日 に公開された「Introducing vector search with UltraWarm in Amazon OpenSearch Service」を翻訳したものです。

Amazon OpenSearch Service は 2019 年から、k 近傍法 (k-NN) インデックスを使用したベクトル類似検索を可能にするベクトルデータベース機能を提供しています。セマンティック検索、大規模言語モデル (LLM) を使用した検索拡張生成 (RAG)、リッチメディア検索など、さまざまなユースケースに対応してきました。AI 機能の急速な発展と生成 AI アプリケーションの増加に伴い、お客様は豊富な機能を備えたベクトルデータベースを求めています。

OpenSearch Service は、UltraWarm 層と Cold 層という形で、マルチティアストレージソリューションも提供しています。UltraWarm は、アクセス頻度の低いデータに対して、ホットストレージよりもレイテンシーは高くなりますが、クエリ機能を維持しながらコスト効率の良いストレージを提供します。Cold 層は、必要に応じて再アタッチできるデタッチされたインデックス用に、さらに低コストのアーカイブストレージを提供します。UltraWarm にデータを移動すると、データは不変になります。これは、ログ分析のようにデータ更新が頻繁でないユースケースに適しています。

これまで、UltraWarm や Cold ストレージ層では k-NN インデックスを保存できないという制限がありました。お客様が OpenSearch Service をベクトルユースケースに採用する中で、メモリとストレージがボトルネックとなり、高コストに直面しているケースが見られました。

より大規模なデータセットでも同様のコスト削減効果を得られるよう、UltraWarm 層と Cold 層の両方で k-NN インデックスをサポートするようになりました。特に以下のようなワークロードでコスト削減を実現できます。

• ベクトルデータの大部分がアクセス頻度の低いデータ（過去の商品カタログ、アーカイブされたコンテンツの埋め込み、古いドキュメントリポジトリなど）
• アクセス頻度の高いワークロードと低いワークロードを分離し、ウォーム層に移動できるインデックスからの干渉を防ぐためにホット層インスタンスをスケールする必要性を最小限に抑えたい場合

本記事では、この新機能とユースケースについて説明し、さまざまなシナリオでのコスト効果分析を紹介します。

新機能: UltraWarm 層と Cold 層での k-NN インデックス

OpenSearch Service バージョン 2.17 以降で、k-NN インデックスに対して UltraWarm 層と Cold 層を有効にできるようになりました。この機能は、新規ドメインとバージョン 2.17 にアップグレードした既存ドメインの両方で利用できます。OpenSearch Service バージョン 2.x 以降で作成された k-NN インデックスは、ウォーム層と Cold 層への移行対象となります。さまざまなエンジン（FAISS、NMSLib、Lucene）を使用する k-NN インデックスが移行可能です。

ユースケース

k-NN ベクトル検索のマルチティアアプローチは、以下のようなユースケースに有効です。

• 長期的なセマンティック検索 – 法務、研究、コンプライアンス目的で、数年分の過去のテキストデータの検索性を維持
• 進化する AI モデル – 複数バージョンの AI モデルからの埋め込みを保存し、すべてのデータをホットストレージに保持するコストをかけずに比較や後方互換性を実現
• 大規模な画像・動画の類似検索 – データセットがホットストレージの実用的な制限を超えて拡大しても、効率的に検索できる大規模なビジュアルコンテンツライブラリを構築
• EC サイトの商品レコメンデーション – 膨大な商品カタログを保存・検索し、人気の低い商品や季節商品を検索機能を維持しながら低コストの層に移動

k-NN インデックスを UltraWarm および Cold ストレージ層で使用した場合のコスト効果を、実際のシナリオで見ていきましょう。これらのシナリオでは、代表的な AWS リージョンとして us-east-1 を使用します。

シナリオ 1: 混合ワークロードにおけるホットストレージとウォームストレージのバランス

768 次元のベクトルが 1 億件（約 330 GB の生ベクトル）あり、それぞれ 500 万ベクトル（約 16.5 GB）の Lucene エンジンインデックス 20 個に分散しているとします。そのうち 50%（約 10 インデックス、165 GB）はアクセス頻度が低いデータです。

UltraWarm サポートなしのドメイン構成

すべてのデータをホットストレージに保持して最大のパフォーマンスを優先し、ベクトルに対して最速のクエリレスポンスを提供します。6 台の r6gd.4xlarge インスタンスでクラスターをデプロイします。

構成の月額コストは、データインスタンスコスト $6,700 を含めて月額 $7,550 になります。

クエリに対してトップティアのパフォーマンスを提供しますが、データのアクセスパターンが混在していることを考えると、オーバープロビジョニングになっている可能性があります。

コスト削減戦略: UltraWarm ドメイン構成

このアプローチでは、観測されたアクセスパターンに合わせてストレージ戦略を調整し、パフォーマンスとコストの両方を最適化します。ホット層は頻繁にアクセスされるデータに対して最適なパフォーマンスを提供し続け、重要度の低いデータは UltraWarm ストレージに移動します。

UltraWarm のクエリはホットストレージと比較してレイテンシーが高くなりますが、アクセス頻度の低いデータではこのトレードオフは許容できることが多いです。また、UltraWarm のデータは不変になるため、この戦略は更新を必要としない安定したデータセットに最適です。

アクセス頻度の高い 50% のデータ（約 165 GB）をホットストレージに保持し、ホット層を 3 台の r6gd.4xlarge.search インスタンスに削減できます。アクセス頻度の低い 50% のデータ（約 165 GB）には、UltraWarm ノードとして 2 台の ultrawarm1.medium.search インスタンスを導入します。この層は、最速のアクセス時間を必要としないデータに対してコスト効率の良いソリューションを提供します。

アクセスパターンに基づいてデータを階層化することで、ホット層のフットプリントを大幅に削減しながら、重要度の低いデータ用に小規模なウォーム層を導入できます。この戦略により、頻繁なクエリに対して高いパフォーマンスを維持しながら、システム全体のコストを最適化できます。

ホット層は、頻繁にアクセスされるデータを対象とするクエリの大部分に対して最適なパフォーマンスを提供し続けます。ウォーム層では、アクセス頻度の低いデータに対するクエリのレイテンシーが増加しますが、UltraWarm ノードでの効果的なキャッシングによって軽減されます。全体として、システムは高い可用性と耐障害性を維持します。

バランスの取れたアプローチにより、月額コストは $5,350 に削減されます。ホット層が $3,350、ウォーム層が $350 で、月額コストは全体で約 29% 削減されます。

シナリオ 2: アクセスパターンに基づく成長するベクトルデータベースの管理

システムが大量のコンテンツ（テキスト、画像、動画）を処理・インデックス化し、高度なコンテンツレコメンデーションと類似検索のために Lucene エンジンを使用してベクトル埋め込みを生成しているとします。コンテンツライブラリが成長するにつれて、新しいコンテンツや人気のあるコンテンツは頻繁にクエリされる一方、古いコンテンツや人気の低いコンテンツはアクティビティが減少しますが、検索可能である必要があるという明確なアクセスパターンが観察されています。

OpenSearch Service の階層型ストレージを効果的に活用するには、予想されるクエリパターンに基づいてデータを別々のインデックスに整理することを検討してください。このインデックスレベルの整理が重要なのは、層間のデータ移行がインデックスレベルで行われるためです。アクセスパターンが変化するにつれて、特定のインデックスをコスト効率の良いストレージ層に移動できます。

現在のデータセットは 150 GB のベクトルデータで構成され、新しいコンテンツが追加されるにつれて月に 50 GB ずつ増加しています。データアクセスパターンは以下のとおりです。

• コンテンツの約 30% がクエリの 70% を受け取り、通常は新しいアイテムや人気のあるアイテム
• さらに 30% は中程度のクエリ量
• 残りの 40% はアクセス頻度が低いが、完全性と時折の詳細分析のために検索可能である必要がある

これらの特性を踏まえて、この成長するデータセットを効率的に管理するための単一層と複数層のアプローチを見ていきましょう。

単一層構成

単一層構成では、データセットが拡大するにつれて、ベクトルデータは 6 か月で約 400 GB に成長し、すべてホット（デフォルト）層に保存されます。r6gd.8xlarge.search インスタンスの場合、データインスタンス数は約 3 ノードになります。

単一層構成でのドメインの月額コストは、データインスタンスコスト約 $6,700 を含めて約 $8,050 になります。

複数層構成

パフォーマンスとコストを最適化するために、Index State Management (ISM) ポリシーを使用して、アクセスパターンの変化に応じてインデックスを層間で自動的に移動するマルチティアストレージ戦略を実装します。

• ホット層 – 最速のアクセスのために頻繁にアクセスされるインデックスを保存
• ウォーム層 – より高いレイテンシーで中程度にアクセスされるインデックスを格納
• Cold 層 – コスト効率の良い長期保存のためにアクセス頻度の低いインデックスをアーカイブ

データ分布については、合計 150 GB から開始し、月に 50 GB ずつ増加します。以下は、約 6 か月後にデータが 400 GB に達した時点での予測データ分布です。

• ホット層 – 約 100 GB（最も頻繁にクエリされるコンテンツ）を 1 台の r6gd.8xlarge に配置
• ウォーム層 – 約 100 GB（中程度にアクセスされるコンテンツ）を 2 台の ultrawarm1.medium.search に配置
• Cold 層 – 約 200 GB（アクセス頻度の低いコンテンツ）

複数層構成では、ベクトルデータドメインのコストは合計 $3,880 になります。データノードのコストが $2,330、UltraWarm ノードのコストが $350、Cold ストレージのコストが $5.00 です。

ホット層のインスタンスサイズが約 66% 削減され、コンピューティングコストが削減されます。複数層ドメインにより、年間で約 50% のコスト削減が実現します。

シナリオ 3: UltraWarm を使用した大規模なディスクベースのベクトル検索

768 次元のベクトル 10 億件が、それぞれ 1,000 万ベクトルの 100 インデックスに分散しているシステムを考えてみましょう。システムは主にコスト最適化のために 32x FAISS 量子化を使用したディスクベースのベクトル検索を使用しており、クエリの約 70% がデータの 30% を対象としているため、階層型ストレージの理想的な候補です。

UltraWarm サポートなしのドメイン構成

このアプローチでは、ディスクベースのベクトル検索を使用して大規模データを処理し、4 台の r6gd.4xlarge インスタンスでクラスターをデプロイします。この構成は、ディスクベースの検索によってメモリ使用量を最適化しながら、十分なストレージ容量を提供します。

この構成の月額コストは、データインスタンスコスト $4,470 を含めて月額 $6,500 になります。

コスト削減戦略: UltraWarm ドメイン構成

このアプローチでは、シナリオ 1 と同様に、観測されたクエリパターンに合わせてストレージ戦略を調整します。

アクセス頻度の高い 30% のデータをホットストレージに保持し、1 台の r6gd.4xlarge インスタンスを使用します。アクセス頻度の低い 70% のデータには、2 台の ultrawarm1.medium.search インスタンスを使用します。

両方のストレージ層でディスクベースのベクトル検索を使用してメモリ使用量を最適化します。このバランスの取れたアプローチにより、月額コストは $3,270 に削減されます。ホット層が $1,120、ウォーム層が $400 で、月額コストは全体で約 50% 削減されます。

UltraWarm と Cold ストレージの使用を開始する

UltraWarm 層と Cold 層で k-NN インデックスを活用するには、ドメインが OpenSearch Service 2.17 以降を実行していることを確認してください。k-NN インデックスをストレージ層間で移行する手順については、「Amazon OpenSearch Service の UltraWarm ストレージ」を参照してください。

マルチティアベクトル検索のベストプラクティスとして、以下を検討してください。

• クエリパターンを分析して、層間のデータ配置を最適化する
• Index State Management (ISM) を使用して、層間のデータライフサイクルを透過的に管理する
• k-NN stats を使用してキャッシュヒット率を監視し、必要に応じて階層化とノードサイジングを調整する

まとめ

OpenSearch Service の UltraWarm 層と Cold 層での k-NN ベクトル検索機能は、ベクトル検索ワークロードに対するコスト効率が高くスケーラブルなソリューションを提供する上で大きな前進です。この機能により、頻繁にアクセスされるデータをホットストレージに保持して最低レイテンシーを実現しながら、アクティビティの低いデータを UltraWarm に移動してコストを削減することで、パフォーマンスとコストのバランスを取ることができます。UltraWarm ストレージにはパフォーマンス上のトレードオフがあり、データは不変になりますが、これらの特性は、古いデータほどクエリや更新が少なくなるという実際のアクセスパターンとよく合致することが多いです。

現在のベクトル検索ワークロードを評価し、このマルチティアアプローチがユースケースにどのように役立つかを検討することをお勧めします。AI と機械学習が進化し続ける中、お客様の増大するニーズに応えるためにサービスの強化に取り組んでいきます。

OpenSearch Service のベクトル検索機能の拡張に向けた今後のアップデートにご期待ください。

著者について

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