はじめに
生成AIやマルチモーダル検索の導入が進むにつれて、企業が扱うベクトルデータの規模は急速に大きくなっています。画像、動画、音声、センサー、ログ、ドキュメント、ユーザー行動などを embedding 化し、検索・分析・評価・モデル改善に使うケースは珍しくありません。
ただし、ここで難しくなるのは「大規模データを検索できるか」だけではありません。実際の現場では、同じベクトルデータを複数のチームが異なる頻度で使います。
- 本番アプリケーションは、低レイテンシで継続的に検索したい
- データ分析チームは、必要な時だけ大規模な探索をしたい
- モデル開発チームは、定期的に回帰テストや評価データ抽出をしたい
- バッチ処理では、短時間だけ高いスループットが必要になる
このようなワークロードをすべて同じ常時稼働クラスターで処理すると、使っていない時間の計算リソースにもコストが発生します。一方で、単純な Serverless 型の課金では、大規模データセットや高スループットの短時間処理で、クエリ・書き込み・ストレージの単価が想定以上に効いてくることがあります。
Zilliz Cloud の On-Demand は、この中間にある課題を解くための計算モデルです。
On-Demand が必要になる典型的な場面
元記事で紹介されている例は、自動運転領域の大規模データ分析です。あるチームは、10億件を超えるベクトルデータセットに対して、データ分析や corner case の探索を行いたいと考えていました。
このデータは本番検索やモデル訓練にも使われます。しかし、分析チームが本当に検索を実行する時間は、1か月のうち数時間程度です。つまり、データは大きく、検索時の計算負荷も高い一方で、アクセス頻度は低いという状態です。
このような場合、常時稼働の Dedicated Cluster を使うと、安定したオンラインサービスには向いているものの、実際には使っていない時間にもリソースを確保し続けることになります。元記事のケースでは、月に数時間の分析のために、月額約 7,000 ドル規模のコストが発生する例が示されています。
一方で Serverless は、軽量な導入や予測しづらいトラフィックには便利です。しかし、大規模な底データ、継続的な書き込み、周期的な高スループット検索がある場合、クエリ・ストレージ・書き込みの課金が積み上がり、Dedicated より高くなる場合があります。元記事では、同じワークロードで Serverless の月額が約 10,700 ドル規模になる例が紹介されています。
On-Demand は、このような「大規模データに対する短時間・断続的な計算」に向いた選択肢です。紹介されているケースでは、On-Demand を使うことで月額コストが 500 ドル未満まで下がる例が示されています。
これらの数値は、元記事で紹介されている特定ワークロードに基づく例です。すべての環境で同じ結果を保証するものではありません。
On-Demand は何を変えるのか
On-Demand の基本的な考え方はシンプルです。データとインデックスは保持しながら、計算リソースは必要な時だけ起動し、使い終わったら解放します。課金も、計算ノードが実際にオンラインだった時間に基づいて行われます。
これにより、次のような使い方がしやすくなります。
- 1か月に数回だけ、大規模な意味検索を実行する
- モデル更新のたびに、過去データから類似ケースを抽出する
- 画像・動画・ログから異常パターンや edge case を探す
- 本番検索とは別に、分析用の計算リソースを一時的に立ち上げる
- 複数チームが同じデータを使いながら、互いの処理を邪魔しない
重要なのは、On-Demand が Dedicated や Serverless を単純に置き換えるものではないことです。むしろ、アクセスパターンに合わせて計算モデルを選べるようにするものです。
Dedicated、Serverless、On-Demand の使い分け
Dedicated Cluster は、低レイテンシで安定した本番検索に向いています。ECの商品検索、レコメンド、チャットボットのRAG基盤、リアルタイムな類似検索など、継続的にユーザーリクエストを処理する主経路では、計算リソースを常時確保する意味があります。
Serverless は、初期検証、小規模アプリケーション、トラフィックが読みづらいサービスに向いています。インフラを意識せずに始めやすく、PoC や新規アプリケーションの立ち上げでは有効な選択肢です。
On-Demand は、大規模データを対象にした短時間の分析、周期的な回帰テスト、バッチ的な探索、データマイニングに向いています。データ量は大きいが、検索の発生頻度は低い。検索時だけ一時的に強い計算能力が必要になる。このようなケースで特に効果が出ます。
整理すると、次のようになります。
| 方式 | 向いている用途 | 注意点 |
|---|---|---|
| Dedicated | 継続的な本番検索、低レイテンシ、高QPS | 使っていない時間も計算リソースを確保する |
| Serverless | PoC、軽量アプリ、予測しづらいトラフィック | 大規模データや高頻度処理では単価が効く場合がある |
| On-Demand | 大規模データの短時間分析、回帰、探索、バッチ検索 | 常時低レイテンシが必要な主経路には向かない場合がある |
技術的なポイント：なぜ短時間起動が可能になるのか
On-Demand を成立させるには、単にクラスターを自動で起動・停止するだけでは不十分です。大規模ベクトルデータを毎回すべて読み込んでいては、起動に時間がかかり、分単位課金の意味が薄れてしまいます。
元記事では、主に次のような設計が紹介されています。
まず、データを細かい単位に分割し、クエリに必要な部分だけを読み込む設計です。スカラー条件では倒立インデックスや min/max などの統計情報を使い、ベクトル検索では IVF 系のインデックスにより、検索時に必要な bucket を絞り込みます。(*倒立インデックスは、通常の辞書や索引が「文書の中にどんな単語があるか」を調べるのに対し、「ある単語がどの文書に含まれているか」を逆引きできるようにした仕組みを指します。)
次に、S3 などのオブジェクトストレージ、ローカルディスク、メモリを組み合わせた階層キャッシュです。冷たいデータを毎回すべて読み込むのではなく、小さな粒度で必要なデータを移動・キャッシュ・破棄できるようにします。
さらに、計算ノードを session 単位で起動・解放するリソース管理です。分析用、回帰テスト用、バッチ探索用といった異なるワークロードを、それぞれ独立した計算 session として扱えます。
この設計により、同じ collection、同じ index、同じ metadata を共有しながら、チームや処理ごとに計算リソースを分離できます。
日本企業にとってなぜ重要か
日本企業のAI活用では、PoC から本番運用へ進む段階で「データは増えるが、すべての処理が常時オンラインではない」という課題が出やすくなります。
たとえば製造業では、検査画像、作業ログ、センサーデータ、保守履歴を embedding 化し、不良パターンや過去事例を探索するニーズがあります。ただし、そうした分析は常時発生するわけではなく、品質問題の調査、モデル更新、定期レビューのタイミングで集中的に行われます。
自動車・ロボティクス領域では、走行データや映像データから corner case を探す作業が重要です。大量のデータを対象に、特定のシーンや類似状況を短時間で探したい一方、その処理は毎秒発生するユーザー向け検索とは性質が異なります。
金融やセキュリティでは、過去の取引、アラート、文書、ログから類似パターンを探す分析があります。必要な時に大きな探索を行い、普段は計算リソースを持ち続けない設計は、コスト管理とガバナンスの両面で意味があります。
メディア、EC、コンテンツプラットフォームでも同じです。画像・動画・テキスト・メタデータを横断して検索する本番サービスとは別に、タグ改善、重複検出、類似コンテンツ整理、レコメンド改善のための分析ワークロードが存在します。
こうした企業にとって On-Demand が魅力的なのは、「AI検索の本番基盤」と「分析・改善のための一時的な計算」を同じデータ基盤上で扱いやすくする点です。データをコピーして別クラスターを作り、インデックスを再構築し、チームごとに運用する必要が減れば、コストだけでなく、データ管理の複雑さも下げられます。
On-Demand は Vector Lakebase の一部
Zilliz は、従来の Vector Database から Vector Lakebase へと製品の考え方を広げています。背景にあるのは、ベクトルデータがオンライン検索だけでなく、モデル訓練、評価、データ分析、バッチ処理、パイプライン処理にも使われるようになっていることです。
Vector Lakebase では、データと計算を分離し、同じデータに対して複数の計算形態を接続する考え方を取ります。オンライン検索には Dedicated、軽量なアプリケーションには Serverless、大規模な短時間分析には On-Demand、データパイプラインには Spark や Ray といった形で、ワークロードごとに適した計算を選べるようにします。
On-Demand は、その中で「大規模データを必要な時だけ検索・分析する」ための重要な部品です。
まとめ
On-Demand は、常時稼働の本番検索を否定するものではありません。また、Serverless の手軽さを置き換えるものでもありません。
むしろ、ベクトル検索の利用が広がり、同じ大規模データを複数チーム・複数ワークロードが使うようになった結果として必要になる、新しい計算モデルです。
特に次のような状況では、On-Demand を検討する価値があります。
- ベクトルデータは大規模だが、分析検索は断続的である
- 1回の分析や回帰テストでは高いスループットが必要になる
- 本番検索と分析処理を同じクラスターで混在させたくない
- データコピーやインデックス再構築を増やしたくない
- PoC 後の運用コストを現実的に抑えたい
AI検索やRAGは、作って終わりではありません。運用が進むほど、データ分析、評価、改善、回帰テストが必要になります。Zilliz Cloud On-Demand は、そのような継続的な改善サイクルを、大規模データ上でより扱いやすくするための選択肢です。