Home
Blog
コールドデータへの支払いをやめる：milvus階層型ストレージのオンデマンド・ホット/コールド・データ・ローディングによる80%のコスト削減

コールドデータへの支払いをやめる：milvus階層型ストレージのオンデマンド・ホット/コールド・データ・ローディングによる80%のコスト削減

Engineering

December 15, 2025

Buqian Zheng

システムがほとんど触れていないデータのために、いまだに割高なインフラ料金を支払っているチームはどれくらいあるだろうか？正直に言うと、ほとんどのチームがそうだ。

ベクター検索をプロダクションで運用しているのであれば、おそらくこのような状況を目の当たりにしているはずだ。大量のメモリとSSDをプロビジョニングすることで、データセットのほんの一部しかアクティブになっていないにもかかわらず、すべてが「クエリ・レディ」の状態に保たれているのだ。そして、それはあなただけではない。同じようなケースはたくさん見てきました：

マルチテナントのSaaSプラットフォーム：マルチテナントのSaaSプラットフォーム：何百ものテナントが契約しているが、ある日アクティブなのは10～15%に過ぎない。残りのテナントは、リソースを占有したまま放置されている。
Eコマース・レコメンデーション・システム：100万ものSKUがあるにもかかわらず、上位8％の商品がレコメンデーションと検索トラフィックのほとんどを生み出している。
AI検索：ユーザーのクエリの90％が過去1週間の商品をヒットしているにもかかわらず、膨大な埋め込みアーカイブがある。

頻繁にクエリされるデータは全体の10％以下だが、ストレージとメモリの80％を消費している。この不均衡が存在することは誰もが知っていますが、最近まで、それを修正するクリーンなアーキテクチャの方法はありませんでした。

それが Milvus 2.6で変わります。

このリリース以前は、Milvusは（多くのベクターデータベースと同様に）フルロードモデルに依存していた。検索可能なデータが必要な場合、ローカルノードにロードする必要があった。検索可能なデータが必要な場合は、ローカルノードにロードされなければならなかった。そのデータが1分間に1000回ヒットするか、四半期に1回ヒットするかは問題ではなく、すべてホットな状態を維持しなければならなかった。この設計上の選択により、予測可能なパフォーマンスを確保することができましたが、クラスタのサイズを大きくし、コールドデータにはふさわしくないリソースにお金を払うことになりました。

階層型 ストレージが私たちの答えです。

Milvus 2.6では、真のオンデマンドローディングを備えた新しい階層型ストレージアーキテクチャを導入し、システムがホットデータとコールドデータを自動的に区別できるようにしました：

ホットセグメントはコンピュート近くにキャッシュされます。
コールドセグメントはリモートのオブジェクトストレージに安価に保存
クエリが実際にデータを必要とするときだけ、ローカルノードにデータを取り込む。

これにより、コスト構造が "どれだけのデータを持っているか "から "どれだけのデータを実際に使用しているか "にシフトする。そして、初期の本番環境では、この単純なシフトにより、ストレージとメモリーのコストを最大80％削減することができる。

この記事の続きでは、Tiered Storageがどのように機能するかを説明し、実際のパフォーマンス結果を共有し、この変更が最大の効果をもたらす場所を示す。

フルローディングがスケールダウンする理由

ソリューションに入る前に、なぜMilvus 2.5とそれ以前のリリースで使われていたフルロードモードが、ワークロードの規模が拡大するにつれて制限要因になったのかを詳しく見ておく価値がある。

Milvus 2.5およびそれ以前では、ユーザーがCollection.load() リクエストを発行すると、各QueryNodeはメタデータ、フィールドデータ、インデックスを含むコレクション全体をローカルにキャッシュしていた。これらのコンポーネントは、オブジェクトストレージからダウンロードされ、完全にメモリに格納されるか、ローカルディスクにメモリマップ（mmap）されます。このデータがすべてローカルで利用できるようになって初めて、コレクションはロードされ、クエリを処理する準備ができたとマークされます。

言い換えると、コレクションは、ホットまたはコールドの完全なデータセットがノード上に存在するまで、クエリ可能ではありません。

注意:未加工のベクトルデータを含むインデックスタイプの場合、Milvusはベクトルフィールドを個別にロードするのではなく、インデックスファイルのみをロードします。それでも、実際にどの程度のデータにアクセスするかに関わらず、クエリに対応するためにはインデックスを完全にロードする必要があります。

これがなぜ問題になるかを知るために、具体的な例を考えてみましょう：

具体的な例を考えてみましょう：

1億ベクトル
768次元（BERTエンベッディング）
float32精度（各次元4バイト）
HNSWインデックス

このセットアップでは、HNSWインデックスだけで、埋め込まれた生ベクトルを含めて、約430GBのメモリを消費する。ユーザーID、タイムスタンプ、カテゴリーラベルのような一般的なスカラーフィールドを追加すると、ローカルリソースの総使用量は500GBを簡単に超えます。

これは、データの80%がめったにクエリされないか、まったくクエリされない場合でも、システムはコレクションをオンラインに保つためだけに、500GB以上のローカルメモリまたはディスクをプロビジョニングし、保持しなければならないことを意味します。

ワークロードによっては、この動作は許容範囲内です：

ほぼすべてのデータが頻繁にアクセスされる場合、すべてを完全にロードすることで、可能な限り低いクエリ・レイテンシが得られますが、コストは最も高くなります。
データをホットサブセットとウォームサブセットに分割できる場合、ウォームデータをディスクにメモリマッピングすることで、メモリへの負荷を部分的に軽減することができます。

しかし、データの80%以上がロングテールに位置するようなワークロードでは、パフォーマンスと コストの両面で、フルローディングの欠点がすぐに表面化します。

パフォーマンスのボトルネック

実際には、フルローディングはクエリのパフォーマンス以上に影響し、日常的な運用ワークフローを遅くすることが多い：

ローリングアップグレードの長期化：大規模クラスタでは、ローリングアップグレードに数時間から丸一日かかることもある。
障害後の回復が遅い：QueryNodeが再起動すると、すべてのデータが再ロードされるまでトラフィックに対応できないため、復旧時間が大幅に長くなり、ノード障害の影響が増幅されます。
反復と実験の速度低下：フルロードは開発ワークフローを遅らせ、AIチームは新しいデータセットやインデックス構成をテストする際、データがロードされるまで何時間も待たなければならない。

コストの非効率性

フルローディングはインフラコストも押し上げる。例えば、メモリが最適化された主流のクラウドインスタンスでは、1TBのデータをローカルに保存する場合、およそ $**$ 70 $, 000peryear **、$ $70,000/年**、$ $*$ $, basedonconservativepricing（AWSr6i$ : $5.74 /GB/月; GCP n4-highmem：~5$ $. 68 /GB/月; AzureE -series :$ 5 $.68/GB/月;Azure E-series：$ ~ $5$ $. 68 /GB/月; AzureE -$ $シリーズ$ : $5.67/GB/月）。$

次に、より現実的なアクセスパターンを考えてみよう。そのデータの80%はコールドデータであり、代わりにオブジェクトストレージに保存することができる（おおよそ$0.023 / GB /月）：

ホットデータ200GB × $5.68
コールドデータ800GB × $0.023

年間コスト：（200×5.68+800×0.023）×12≒14,000ドル

これは、実際に重要な部分のパフォーマンスを犠牲にすることなく、総ストレージコストを80%削減することになる。

階層型ストレージとその仕組みとは？

このトレードオフをなくすために、Milvus 2.6では、ローカルストレージをデータセット全体のコンテナとしてではなく、キャッシュとして扱うことで、性能とコストのバランスをとるTiered Storageを導入した。

このモデルでは、QueryNodeは起動時に軽量のメタデータのみをロードします。フィールドデータとインデックスは、クエリが必要とするときにリモート・オブジェクト・ストレージからオンデマンドでフェッチされ、頻繁にアクセスされる場合はローカルにキャッシュされる。また、頻繁にアクセスされる場合はローカルにキャッシュされます。

その結果、ホットデータはコンピュート・レイヤーの近くに留まり、低レイテンシーのクエリーを実現し、コールドデータは必要な時までオブジェクト・ストレージに留まります。これにより、ロード時間が短縮され、リソース効率が向上し、QueryNodeはローカルメモリやディスク容量よりもはるかに大きなデータセットをクエリできるようになります。

実際には、Tiered Storageは以下のように機能する：

ホットデータをローカルに保つ：頻繁にアクセスされるデータのおよそ20%をローカルノードに常駐させ、最も重要な80%のクエリで低レイテンシを実現します。
コールドデータをオンデマンドでロードする：残りの80%のアクセス頻度の低いデータは、必要なときのみフェッチされ、ローカルメモリとディスクリソースの大半を解放します。
LRUベースで動的に適応：Milvusは、LRU（Least Recently Used：最近使用されたデータ消去）戦略を使用して、どのデータをホットまたはコールドとみなすかを継続的に調整します。非アクティブなデータは自動的に退去され、新しくアクセスされたデータのためのスペースを確保します。

この設計により、Milvusはもはやローカルメモリとディスクの固定容量に制約されることはない。代わりに、ローカルリソースは動的に管理されるキャッシュとして機能し、非アクティブなデータからスペースが継続的に回収され、アクティブなワークロードに再割り当てされる。

この動作は、3つのコア技術メカニズムによって実現されている：

1.遅延ロード

Milvusは初期化時に最小限のセグメントレベルのメタデータのみをロードし、起動後すぐにコレクションをクエリ可能にします。フィールドデータとインデックスファイルはリモートストレージに残り、クエリ実行中にオンデマンドでフェッチされるため、ローカルメモリとディスクの使用量を低く抑えることができます。

Milvus 2.5でのコレクションローディングの仕組み

Milvus 2.6以降での遅延ロードの仕組み

初期化時にロードされるメタデータは4つの主要なカテゴリーに分類されます：

セグメント統計(行数、セグメントサイズ、スキーマメタデータなどの基本情報)
タイムスタンプ(タイムトラベルクエリをサポートするために使用される)
レコードの挿入と削除(クエリ実行中にデータの一貫性を維持するために必要)
ブルームフィルタ(無関係なセグメントを素早く除外するための、高速なプレフィルタリングに使用される)

2.部分ロード

レイジーローディングがデータをロードするタイミングを制御するのに対し、パーシャルローディングはロードするデータの量を制御する。クエリまたは検索が開始されると、QueryNode は部分ロードを実行し、必要なデータチャンクまたはインデックスファイルのみをオブジェクトストレージからフェッチします。

ベクトル・インデックス：テナントを意識したロード

Milvus 2.6+で導入された最もインパクトのある機能の1つは、マルチテナントのワークロードのために特別に設計された、テナントを意識したベクトルインデックスのロードです。

クエリが単一のテナントのデータにアクセスする場合、Milvusはそのテナントに属するベクトルインデックスの部分のみをロードし、他のすべてのテナントのインデックスデータをスキップします。これにより、ローカルリソースをアクティブなテナントに集中させることができます。

この設計にはいくつかの利点があります：

非アクティブテナントのベクトルインデックスは、ローカルメモリやディスクを消費しません。
アクティブなテナントのインデックスデータは、低レイテンシアクセスのためにキャッシュされたままである。
テナントレベルのLRU退去ポリシーにより、テナント間での公平なキャッシュ使用が保証されます。

スカラーフィールド：カラムレベルのパーシャルローディング

パーシャルローディングはスカラーフィールドにも適用され、milvusはクエリによって明示的に参照されたカラムのみをロードすることができます。

id,vector,title,description,category,price,stock,tags のような50のスキーマフィールドを持つコレクションで、id,title,price の3つのフィールドのみを返す必要があるとします。

Milvus 2.5では、50のスカラーフィールドはクエリー要件に関係なくロードされます。
Milvus 2.6+では、要求された3つのフィールドのみがロードされます。残りの47フィールドはロードされずに残り、後でアクセスされた場合のみ遅延フェッチされます。

リソースの節約は非常に大きい。各スカラー・フィールドが20GBを占有する場合：

すべてのフィールドをロードするには1,000GBが必要（50×20GB）。
必要な3つのフィールドだけをロードする場合は60GB

これは、クエリの正しさや結果に影響を与えることなく、スカラーデータのロードを94%削減したことになります。

注：スカラー・フィールドとベクトル・インデックスのテナント対応パーシャル・ローディングは、今後のリリースで正式に導入される予定です。これが利用可能になれば、大規模なマルチテナント展開におけるロードレイテンシをさらに削減し、コールドクエリのパフォーマンスを向上させることができます。

3.LRUベースのキャッシュ消去

レイジーローディングとパーシャルローディングは、ローカルメモリとディスクに持ち込まれるデータ量を大幅に削減します。しかし、長時間稼動するシステムでは、新しいデータがアクセスされるにつれてキャッシュは増大します。ローカル容量に達すると、LRUベースのキャッシュ消去が有効になる。

LRU（Least Recently Used）消去は、最近アクセスされていないデータが最初に消去されるという単純なルールに従っている。これにより、頻繁に使用されるデータをキャッシュに常駐させながら、新しくアクセスされるデータのためにローカル領域を解放する。

性能評価：ティアード・ストレージとフルローディングの比較

Tiered Storageの実環境への影響を評価するため、実運用ワークロードを忠実に反映したテスト環境を構築した。ロード時間、リソース使用量、クエリ性能、有効容量、コスト効率の5つの側面から、Tiered Storageを使用した場合と使用しない場合のMilvusを比較した。

実験セットアップ

データセット

768次元の1億ベクトル（BERTエンベッディング）
ベクトルインデックスサイズ：約430GB
ID、タイムスタンプ、カテゴリを含む10個のスカラーフィールド

ハードウェア構成

4 vCPU、32 GBメモリ、1 TB NVMe SSDを搭載したQueryNode 1台
10 Gbpsネットワーク
リモートストレージバックエンドとしてMinIOオブジェクトストレージクラスター

アクセスパターン

クエリは現実的なホット-コールドアクセス分布に従う：

クエリの80%は直近30日間のデータを対象（全データの20%程度）
15%は30～90日前のデータ（全データの約30%）。
5%は90日以上前のデータを対象（全データの50%以上）

主な結果

1.33倍速いロード時間

ステージ	Milvus 2.5	Milvus 2.6+ (階層型ストレージ)	スピードアップ
データダウンロード	22分	28秒	47×
インデックスロード	3分	17秒	10.5×
合計	25分	45秒	33×

Milvus 2.5では、コレクションのロードに25分かかっていた。Milvus 2.6+のTiered Storageでは、同じワークロードがわずか45秒で完了し、ロード効率が一段と向上しました。

2.ローカルリソース使用量の80%削減

ステージ	Milvus 2.5	Milvus 2.6+ (ティアード・ストレージ)	削減量
負荷後	430 GB	12 GB	-97%
1時間後	430 GB	68 GB	-84%
24時間後	430 GB	85 GB	-80%
定常状態	430 GB	85-95 GB	~80%

Milvus 2.5では、ワークロードやランタイムに関係なく、ローカルリソースの使用量は430GBで一定です。一方、Milvus 2.6+では、ロード直後はわずか12 GBから始まります。

クエリが実行されるにつれ、頻繁にアクセスされるデータはローカルにキャッシュされ、リソース使用量は徐々に増加する。約24時間後、システムは85-95GBで安定し、ホットデータの作業セットを反映する。長期的には、クエリの可用性を犠牲にすることなく、ローカルメモリとディスクの使用量を約80%削減することができます。

3.ホットデータのパフォーマンスへの影響はほぼゼロ

クエリータイプ	Milvus 2.5 P99レイテンシ	Milvus 2.6+ P99レイテンシ	変更
ホットデータクエリ	15 ms	16 ms	+6.7%
ウォームデータクエリー	15 ms	28 ms	+86%
コールドデータクエリ（最初のアクセス）	15 ms	120 ms	+700%
コールドデータ・クエリー（キャッシュ）	15 ms	18 ms	+20%

全クエリの約80%を占めるホットデータでは、P99のレイテンシはわずか6.7%しか増加せず、本番環境での影響はほとんど感じられません。

コールドデータクエリでは、オブジェクトストレージからのオンデマンドロードにより、最初のアクセス時の待ち時間が長くなります。しかし、一旦キャッシュされると、レイテンシは20%増加するだけである。コールドデータのアクセス頻度が低いことを考慮すると、このトレードオフは、ほとんどの実世界のワークロードで一般的に許容可能です。

4.4.3倍の実効容量

Milvus 2.5 は、同じハードウェア予算（各 64 GB のメモリを搭載した 8 台のサーバ（合計 512 GB））のもとで、最大 512 GB のデータ（約 1 億 3,600 万のベクターに相当）をロードすることができます。

Milvus 2.6+でTiered Storageを有効にした場合、同じハードウェアで2.2 TBのデータ、すなわち約5億9,000万のベクターをサポートすることができます。これは実効容量が4.3倍増加したことを意味し、ローカルメモリを拡張することなく、大幅に大きなデータセットに対応することができる。

5.80.1%のコスト削減

AWS環境における2TBのベクトルデータセットを例に、データの20%がホットデータ（400GB）であると仮定した場合のコスト比較は以下のようになる：

項目	Milvus 2.5	Milvus 2.6+ (階層型ストレージ)	節約額
月額コスト	$11,802	$2,343	$9,459
年間コスト	$141,624	$28,116	$113,508
節約率	-	-	80.1%

ベンチマーク概要

すべてのテストにおいて、Tiered Storageは一貫した測定可能な改善を実現しました：

ロード時間が33倍高速化：コレクションのロード時間が25分から45秒に短縮。
ローカルリソースの使用量を80%削減：定常状態では、メモリとローカルディスクの使用量が約80%減少。
ホットデータのパフォーマンスへの影響はほぼゼロ：ホットデータに対するP99レイテンシーの増加は10%未満で、低レイテンシーのクエリーパフォーマンスを維持します。
コールドデータの待ち時間を制御：コールドデータの初回アクセス時のレイテンシは大きくなりますが、アクセス頻度が低いため許容範囲です。
4.3倍の実効容量：メモリを追加することなく、同じハードウェアで4～5倍のデータを処理できる。
80%以上のコスト削減：年間インフラコストを80％以上削減。

milvusで階層型ストレージを使用する場合

ベンチマークの結果と実際の生産事例に基づいて、Tiered Storageの使用事例を3つのカテゴリーに分類し、ワークロードに適しているかどうかを判断できるようにしています。

最適な使用例

1.マルチテナント型ベクトル検索プラットフォーム

特徴ベクトル検索が中核ワークロードである。
アクセスパターン：ベクトル検索クエリの80%以上を生成するテナントは20%未満。
期待される効果70-80％のコスト削減、3-5倍の容量拡張。

2.Eコマース・レコメンデーション・システム（ベクトル検索ワークロード）

特徴トップ商品とロングテール商品の間に強い人気の偏りがある。
アクセスパターン：上位10％の商品がベクトル検索トラフィックの～80％を占める。
期待されるメリットピーク時の追加キャパシティの必要なし、60-70%のコスト削減。

3.ホット・コールドが明確な大規模データセット（ベクトル優位）

特徴TBスケール以上のデータセットで、アクセスが最近のデータに偏っている。
アクセスパターン：古典的な80/20分布：20%のデータが80%のクエリに対応している。
期待されるメリット75～85％のコスト削減

最適なユースケース

1.コスト重視のワークロード

特徴予算が厳しく、性能のトレードオフをある程度許容できる。
アクセスパターン：ベクタークエリーが比較的集中している。
期待される効果50～70％のコスト削減。コールドデータでは、最初のアクセスで500ミリ秒程度の待ち時間が発生する可能性があり、SLA要件と照らし合わせて評価する必要がある。

2.履歴データの保持とアーカイブ検索

特徴クエリー頻度が非常に低い、大量の履歴ベクトル。
アクセスパターン：クエリの約90％が最近のデータを対象としている。
期待されるメリット完全な履歴データセットの保持、予測可能でコントロール可能なインフラコストの維持

適合しないユースケース

1.一様にホットなデータ・ワークロード

特徴：すべてのデータが同じような頻度でアクセスされ、ホットとコールドの明確な区別がない。
適合しない理由キャッシュの利点は限定的。意味のある利得を得ずにシステムを複雑化させる。

2.超低レイテンシワークロード

特徴：金融取引やリアルタイム入札など、レイテンシに非常に敏感なシステム
不向きな理由わずかなレイテンシ変動も許容できない。フルローディングの方が予測可能なパフォーマンスが得られる。

クイック・スタートMilvus 2.6+で階層型ストレージを試す

# Download Milvus 2.6.1+
$ wget https://github.com/milvus-io/milvus/releases/latest
# Configure Tiered Storage
$ vi milvus.yaml
queryNode.segcore.tieredStorage:
  warmup:
    scalarField: disable
    scalarIndex: disable
    vectorField: disable
    vectorIndex: disable
  evictionEnabled: true
# Launch Milvus
$ docker-compose up -d

結論

Milvus 2.6のTiered Storageは、ベクターデータの格納方法と実際のアクセス方法のミスマッチに対処します。ほとんどのプロダクションシステムでは、頻繁にクエリされるデータはごく一部であるにもかかわらず、従来のローディングモデルはすべてのデータを等しくホットなデータとして扱っている。Milvusは、オンデマンドローディングに移行し、ローカルメモリとディスクをキャッシュとして管理することで、リソースの消費をワーストケースの仮定ではなく、実際のクエリの挙動に合わせます。

このアプローチにより、ホットクエリの性能をほぼ維持したまま、ローカルリソースを比例的に増加させることなく、システムをより大きなデータセットに拡張することができます。コールドデータは必要なときにアクセス可能であり続け、予測可能で制限されたレイテンシを実現し、トレードオフを明確かつ制御可能にしている。ベクトル検索が、コスト重視、マルチテナント、長時間稼働の本番環境に深く入り込むにつれて、Tiered Storageは、スケールに応じて効率的に運用するための実用的な基盤を提供します。

Tiered Storageの詳細については、以下のドキュメントをご覧ください：