OpenSearch_VectorDB

OpenSearch Tokyo meetup #1 2026-02-05

VectorDBとしてのOpenSearch
5,000万件超のベクトル検索をコストを抑えて運用する技術選定

https://www.meetup.com/opensearch-project-tokyo/events/312364230/?eventOrigin=home_next_event_you_are_attending

Transcript

1. VectorDBとしてのOpenSearch 5,000万件超のベクトル検索をコストを抑えて運用する技術選定 OpenSearch Tokyo meetup #1 @gumamon33
2. アジェンダ • 自己紹介 • 導入：今日のテーマ(等) • 前提：VectorDBの概要と関連用語の説明 • 課題：5,000万件とインフラコストの壁 • 技術: Disk-based vector searchとメモリ圧縮の仕組み • 解決：成立させた構成（例）と勘所 • まとめ
3. アジェンダ • 自己紹介 • 導入：今日のテーマ(等) • 前提：VectorDBの概要と関連用語の説明 • 課題：5,000万件とインフラコストの壁 • 技術: Disk-based vector searchとメモリ圧縮の仕組み • 解決：成立させた構成（例）と勘所 • まとめ
4. 自己紹介 • 稲熊修宏 (いなぐまのぶひろ) • 株式会社ラクス / SRE課 • 社内プラットフォームの守り人 • おチビ達のしもべ • X (@gumamon33)
5. Ⓒ RAKUS Co.,Ltd. 会社名 株式会社ラクス 設立 2000年11月1日 従業員数 連結：3,086名 単体：1,907名(2025年3月31日時点) 上場証券取引所 東京証券取引所　プライム市場 (コード：3923) クラウド事業 ・ IT人材事業 事業内容 代表取締役 中村崇則 グループ会社 5 株式会社ラクスライトクラウド 株式会社ラクスパートナーズ 株式会社ラクスみらい RAKUS Vietnam Co., Ltd.
6. Ⓒ RAKUS Co.,Ltd. 勤怠管理 サービス紹介 6 交通費・経費精算 電子請求書発行 販売管理業務 メールマーケティング 企業のさまざまな業務の効率化に貢献するクラウドサービス（SaaS）を複数展開 電子帳簿保存 請求書受領 問合せ管理
7. アジェンダ • 自己紹介 • 導入：今日のテーマ(等) • 前提：VectorDBの概要と関連用語の説明 • 課題：5,000万件とインフラコストの壁 • 技術: Disk-based vector searchとメモリ圧縮の仕組み • 解決：成立させた構成（例）と勘所 • まとめ
8. 導入：今日のテーマと持ち帰り 📢今日のテーマ • 大規模なVectorDBのインフラコストを如何に抑えるか 👜持ち帰り • インフラコスト(メモリ)を抑える実装例 • インフラコスト(メモリ)を抑える技術の理解
9. 導入：話すこと・話さないこと 󰢏話すこと • テーマに沿った課題や技術共有、実装例 󰢃話さないこと • 弊社における実際の採用事例 Note: 説明を分かりやすくするために「非機能要件」や「モデル名」が登場しますが、実際のプロジェクトの要件・実 装ではありません。「規模感」を捉える参考情報として頂けますと幸いです。
10. アジェンダ • 自己紹介 • 導入：今日のテーマ(等) • 前提：VectorDBの概要と関連用語の説明 • 課題：5,000万件とインフラコストの壁 • 技術: Disk-based vector searchとメモリ圧縮の仕組み • 解決：成立させた構成（例）と勘所 • まとめ
11. 前提：VectorDBの概要と関連用語の説明 VectorDBとは Note: • データを「意味」を表すベクトルで管理 • キーワード一致ではなく類似度検索ができる • RAG、検索AI、レコメンド などで使われる 文章・画像・音声などを数値ベクトルに変換して保存し、 「意味の近さ」で高速検索できるデータベース
12. 前提：VectorDBの概要と関連用語の説明 「請求書が見つからない」という質問 👉 意味が近い回答を複数見つけられる • 「請求書の再発行方法」 • 「請求書検索手順」 Note: • 回答の文章が登録されていることが前提 • 応答は「意味が近い順」の複数回答 (top k) • Vectorは「Embedding(埋め込み)Vector」とも呼ばれる VectorDBの活用例
13. 前提：VectorDBの概要と関連用語の説明 単語
 役割
 補足
 RAG
 (主に)生成AI向けの、外部データ検索機能
 一般知識以外の情報を補完
 Vector
 意味を表す数値
 [0.1, 0.2, -0.03, ..., 1.42] など
 Embedding
 文章をVectorに変換する
 text-embedding-3(OpenAI) など
 VectorDB
 Vectorを保存・検索するDB
 OpenSearch, Qdrant, Milvus など
 ANN
 高速に近いVectorを探す方法
 入力ベクトルに近い top kを返す
 FAISS
 ANNを実装した検索ライブラリ
 Meta製。多くのVectorDBの内部で使われる
 HNSW
 FAISS等で使われる検索アルゴリズム
 グラフ型近傍探索。大容量のメモリが必要

14. 前提：VectorDBの概要と関連用語の説明 各用語の関連性 【意味を数値にする】 【大量に保存・検索する】
15. アジェンダ • 自己紹介 • 導入：今日のテーマ(等) • 前提：VectorDBの概要と関連用語の説明 • 課題：5,000万件とインフラコストの壁 • 技術: Disk-based vector searchとメモリ圧縮の仕組み • 解決：成立させた構成（例）と勘所 • まとめ
16. 課題：5,000万件とインフラコストの壁 以下を満たす RAGシステムを構築してほしいと依頼を受けた 非機能要件 (抜粋): • レイテンシー: 10秒以内 (希望3秒) • ベクトル数: 5,000万超 (多い) • 検索精度: 非公開 (割と高い) • 予算: 非公開 (制約が強い) 👉 予算が通らないことには作れない。インフラコストを見積もる ことにした。
17. 課題：5,000万件とインフラコストの壁 インフラコストを見積もる過程で、 VectorDBは莫大なメモリを必要とする ことに気づいてしまった HNSWに必要なメモリ容量の計算式 • 1.1 * (4 * dimension + 8 * m) * num_vectors` (byte) 5,000万件で計算してみた • メモリが300GB・・・？🤔 (単一サーバ) • メモリが600GB・・・!?🤮 (可用性を考慮)
18. 課題：5,000万件とインフラコストの壁 なぜ大容量のメモリが必要なのか？ 　 Note: 今回のユースケースにおいて、特にメモリを消費したのは `2. ベクトル(全部)`の方でした。 ただし、HNSWのグラフ構造もそれなりにメモリを消費します ANNのアルゴリズムにHNSWを選定 (高精度&低レイテンシ) HNSWはメモリ上に以下を全て乗せる構造 • 1. HNSWのグラフ構造 (ベクトル同士の繋がり) • 2. ベクトル(全部)
19. 課題：5,000万件とインフラコストの壁 ベクトルの構造を実際に見てみる （例) text-embedding-3-small: 1536 次元 • ベクトル構造 = [ 0.01, 0.02, -0.10 .... n(1536)] • 1ベクトルあたり 6KB (float32 x 1536) • 5,000万ベクトルで 307GB
20. 課題：5,000万件とインフラコストの壁 Q. という感じなんですが、払えますか？
21. 課題：5,000万件とインフラコストの壁 A. 払えません！
23. アジェンダ • 自己紹介 • 導入：今日のテーマ(等) • 前提：VectorDBの概要と関連用語の説明 • 課題：5,000万件とインフラコストの壁 • 技術: Disk-based vector searchとメモリ圧縮の仕組み • 解決：成立させた構成（例）と勘所 • まとめ
24. 技術: Disk-based vector searchとメモリ圧縮の仕組み という訳にも行かないので、色々と調査検討を重ねた結果、 以下の機能が打開策となった。 Note: ディスクベースのベクトル検索では、バイナリ量子化を使用してベクトルを圧縮し、メモリ要件を削減します。こ のメモリ最適化により、検索レイテンシはわずかに増加しますが、高い再現率を維持しながら、大幅なメモリ 節約を実現します。 Disk-based vector search
25. 技術: Disk-based vector searchとメモリ圧縮の仕組み つまり・・・？ 🤔
26. 課題：5,000万件とインフラコストの壁 Disk-based Vector Search では、メモリ上に保持するベクトルを 生 ベクトル（float32）ではなくバイナリ量子化ベクトル に変換する。こ れにより、 • Before: 1536 次元 × float32 （約 6KB / vector） • After: 1536 次元 × 1bit （約 0.18KB / vector） と メモリ使用量を大幅に削減 できる。 生ベクトルはディスク上に保持し、 検索時に必要なものだけを参照 することで 精度とメモリ効率を両立する。
27. 技術: Disk-based vector searchとメモリ圧縮の仕組み Before 生ベクトル (float32) After バイナリ量子化 (1bit)
28. 技術: Disk-based vector searchとメモリ圧縮の仕組み Before 生ベクトル (float32) After バイナリ量子化 (1bit) x 5,000万 = 307.0GB x 5,000万 = 9.6GB
29. 技術: Disk-based vector searchとメモリ圧縮の仕組み 🎉 圧倒的削減効果・・・！！
30. 技術: Disk-based vector searchとメモリ圧縮の仕組み Q. 検索精度は落ちないのか A. ほぼ落ちない (と言われており、検証した範囲では大きな劣化は見られなかった)
31. 技術: Disk-based vector searchとメモリ圧縮の仕組み Q. 検索精度は落ちないのか A. ほぼ落ちない (と言われており、検証した範囲では大きな劣化は見られなかった) Note: バイナリ量子化で検索するのは、あくまで top k の"候補"。 OpenSearchはこの候補に(HNSWのグラフ上関係のあるベクトル )をメモリロードし、 再度検索を実施する (最初にざっくりあたりをつけ、その後詳細を調査するイメージ )
32. 技術: Disk-based vector searchとメモリ圧縮の仕組み Q. 必要なメモリ容量が1/32になるのか A. 完全にそうはならない(再掲)
33. 技術: Disk-based vector searchとメモリ圧縮の仕組み Q. 必要なメモリ容量が1/32になるのか A. 完全にそうはならない(再掲) Note: バイナリ量子化で節約できるのは、メモリに乗るベクトルの圧縮によるもの。 HNSWのグラフは引き続きメモリに乗るし、再検索 (リランキング)でロードする生ベクトル (一部)の メモリ使用量もオーバーヘッドとなる。
34. 技術: Disk-based vector searchとメモリ圧縮の仕組み Disk-based vector search の導入方法 Indexの作成時に指定するのみ！
35. 技術: Disk-based vector searchとメモリ圧縮の仕組み Disk-based vector search の導入方法 Indexの作成時に指定するのみ！ Note: Embeddingモデルに合わせて設定する項目 があるので注意 • dimension (ベクトル次元数) • space_type (距離計算方式) • 等
36. 技術: Disk-based vector searchとメモリ圧縮の仕組み Disk-based vector search の導入方法 Indexの作成時に指定するのみ！ Note: 量子化の圧縮レベルはオプションとして選択可能 • "32x" (32bit > 1bit) ※Default • "16x" (32bit > 2bit) • "8x" (32bit > 4bit) ※ “4x” も存在するがエンジンが luceneになる
37. アジェンダ • 自己紹介 • 導入：今日のテーマ(等) • 前提：VectorDBの概要と関連用語の説明 • 課題：5,000万件とインフラコストの壁 • 技術: Disk-based vector searchとメモリ圧縮の仕組み • 解決：成立させた構成（例）と勘所 • まとめ
38. 解決：成立させた構成（例）と勘所 今回のインフラには Amazon OpenSearch Serviceを採用した。 Note: Amazon OpenSearch Service は、OpenSearch OSS をマネージドで提供する AWSサービス。 クラスタ構築・スケール・パッチ適用・バックアップ・監 視などの運用作業を AWSが肩代わり する。 こちらは指定したリソースでクラスタが常時稼働する タイプだが、インフラ管理やキャパシティ設計を不要 にしたAmazon OpenSearch Serverless という提 供形態もある。
39. 解決：成立させた構成（例）と勘所 採用理由 • 無停止でクラスタ構成の変更が可能 ◦ ベクトル量子化でメモリ削減したとはいえ、 利用拡大に比例してメモリは増える ◦ メモリ追加時にサービス停止をしたくなかった • DISKのIOPSが調整可能だった ◦ 生ベクトルをDISK>MEMORYにロードするタイミングがある ◦ IOPSを上げ(有償)、レイテンシーを削減 したい意図があった
40. アジェンダ • 自己紹介 • 導入：今日のテーマ(等) • 前提：VectorDBの概要と関連用語の説明 • 課題：5,000万件とインフラコストの壁 • 技術: Disk-based vector searchとメモリ圧縮の仕組み • 解決：成立させた構成（例）と勘所 • まとめ
41. まとめ 「大規模な VectorDBのインフラコストを如何に抑えるか」 をお話した • 🎉 OpenSearchはVectorDBとしても活躍可能 • 💰 Disk-Based vector search によりメモリの大幅節約が可能 ◦ メモリに乗るベクトルを量子化することでメモリの節約可能 ◦ メモリに乗るグラフ構造に対する削減効果は無いことに注意
42. 参考資料： • OpenSearch Documentation: Disk-based vector search (Introduced 2.17) • Amazon Web Service ブログ: OpenSearchにおける 10 億規模のユースケースに適した k-NN アルゴリズムの 選定
43. 󰢛ご清聴いただきありがとうございました！