「とりあえず最大構成」で予算を溶かしていませんか？Milvus on K8sの適正リソース設計とTCO解剖

導入

「とりあえず余裕を持って、メモリは最大構成にしておきましょう。足りなくなって止まるよりマシですから」

RAG（検索拡張生成）システムのPoC（概念実証）から本番移行フェーズに進む際、インフラ設計のミーティングでこのような会話が交わされることがあります。システムの安定性を最優先したいという技術的な視点は理解できます。しかし、この「とりあえず」という判断が、半年後のクラウド請求書を見て経営陣を驚かせる原因になることも少なくありません。AIプロジェクトにおいて、ROI（投資対効果）の最大化は避けて通れない課題です。

生成AIブームに伴い、多くのプロジェクトでRAGの導入が進められています。その中核となるベクトルデータベースとして、オープンソースの「Milvus」を採用し、Kubernetes（K8s）上でセルフホスト運用を始めるケースも増えています。しかし、ステートレスなWebアプリケーションとは異なり、ベクトル検索エンジンは「計算リソースの塊」であり、「メモリの怪物」でもあります。

マネージドサービスが高いからとセルフホストを選んだはずが、運用人件費や過剰なリソース確保で、結果的にTCO（総所有コスト）が跳ね上がっているケースも散見されます。実際の現場では、適切なサイジングを行わなかった結果、実際の検索負荷に対して3倍以上のリソース費を毎月支払うことになった事例も報告されています。

この記事では、K8sエンジニアやSRE、そしてプロジェクトの予算責任者の方々に向けて、Milvusのアーキテクチャに基づいた「本当に必要なリソース」の算出方法と、AI推論基盤と共存させる際のコスト最適化戦略を解説します。単なるコストカットではなく、パフォーマンスを維持しながら無駄を削ぎ落とす「適正化」の道筋を、論理的かつ体系的に探っていきましょう。

1. なぜベクトルDBのコスト試算は複雑なのか？

一般的なRDBMS（MySQLやPostgreSQLなど）のサイジングであれば、データ容量とTPS（Transaction Per Second）からある程度のリソースを見積もることができます。しかし、ベクトルデータベース、特にMilvusのような分散型アーキテクチャを持つシステムのコスト試算は、一筋縄ではいきません。なぜなら、そこには従来のリレーショナルデータベースとは異なる、特殊なリソース消費特性があるからです。

「見えないコスト」になりがちなインデックス構築リソース

ベクトルDBにおける最大のコスト要因の一つでありながら、設計時に見落とされがちなのが「インデックス構築」にかかるリソースです。ベクトル検索では、データを挿入した後、高速に近似近傍探索（ANN）を行うために、インデックス構造を作成する必要があります。

2026年現在も、HNSW（Hierarchical Navigable Small World）はベクトル検索のデファクトスタンダードとして広く利用されていますが、このインデックス構築処理は極めてCPUインテンシブ（CPU負荷が高い）です。データ量が増えれば増えるほど、計算量は指数関数的に増加する場合があります。検索時のQPS（Query Per Second）にばかり気を取られ、この「書き込み後のバックグラウンド処理」に必要なリソースを見落としがちです。

K8s上で運用する場合、インデックス作成を担当する Index Node がリソース不足に陥ると、いつまでたってもデータが検索可能（Searchable）にならなかったり、最悪の場合、同一ノードに同居している他のPodのリソースを食いつぶしてクラスタ全体が不安定になったりする可能性があります。逆に、ピーク時のインデックス作成負荷に合わせてリソースを確保しすぎると、データの追加がないアイドルタイムにはそのCPUリソースが無駄になります。

検索レイテンシとコンピュートリソースの非線形な関係

通常のDB検索（B-Treeインデックスなど）は対数オーダーで効率よく検索できますが、高次元ベクトルの近似検索は、精度（Recall）と速度、そしてリソース消費が複雑なトレードオフの関係にあります。Milvusの最新バージョンではクエリ処理やスケジューリングの最適化が進んでいますが、この根本的な特性は変わりません。

例えば、検索精度を少し上げるために探索範囲パラメータ（IVFにおける nprobe や HNSWにおける ef）を広げると、CPU使用率が急激に跳ね上がることがあります。「リソースを2倍にすればレイテンシは半分になるだろう」という線形な予測は通用しません。この非線形な特性が、適切なPodのRequests/Limits設定を難しくしており、安全マージンを過剰に取りすぎる原因となっています。

AI推論（Embedding）とDB検索のリソース競合リスク

RAGシステム全体で見ると、コスト要因はDBだけではありません。ユーザーの質問をベクトル化する「Embeddingモデル」や、回答を生成する「LLM」の推論コストも考慮する必要があります。特に2026年のトレンドであるGraphRAG（ナレッジグラフとの組み合わせ）やマルチモーダルRAG（画像や音声の処理）の導入が進むにつれ、前処理にかかる計算負荷は以前よりも格段に高まっています。

セルフホストの場合、同じK8sクラスタ内にEmbedding用の推論サーバーとMilvusを同居させることが多いでしょう。ここで問題になるのが、リソースの競合です。高度化した推論処理もベクトル検索も、CPUやメモリ帯域を激しく消費します。適切な分離設計（Affinity/Anti-Affinity設定やTaints/Tolerations）を行わないと、互いに足を引っ張り合い、結果として高価なノードを追加し続けるという悪循環に陥ります。

TCOを考える際は、DB単体ではなく、複雑化する推論基盤を含めたシステム全体での最適化が不可欠です。

2. Milvus on K8sのアーキテクチャとリソース消費の解剖

コストを制御するには、まず「どこで何が消費されているか」を正確に把握する必要があります。Milvus（特にv2.x系）はマイクロサービスアーキテクチャを採用しており、各コンポーネントが異なるリソース特性を持っています。これを理解せずに一律な設定を行うのは、コスト最適化において致命的です。

Milvusのマイクロサービス構成（Proxy, Coordinator, Node）

Milvusのアーキテクチャは、大きく分けて以下の3層構造になっています。公式ドキュメント（milvus.io）のアーキテクチャ図を頭に浮かべながら読み進めてください。

1. Access Layer (Proxy): クライアントからのリクエストを受け付ける玄関口です。ここは主にネットワークI/Oと軽いCPU処理（リクエストの検証やルーティング）が中心で、ステートレスです。水平スケーリングは容易で、コストインパクトはシステム全体の中では比較的低めです。
2. Coordinator Service: システム全体のメタデータやノード管理を行う司令塔です（Root Coord, Data Coord, Query Coordなど）。システムの安定性にとって重要ですが、処理負荷自体はそれほど高くありません。リソースを過度に削減するべきではありませんが、大量のリソースを必要とするわけでもありません。
3. Worker Node: 実際に重労働を行う作業員です（Data Node, Query Node, Index Node）。ここがコストの主戦場です。リソース消費の大半はこの層で発生します。

読み取り（Query Node）と書き込み（Data Node）の負荷特性

特にコスト管理上の注意が必要なのが Query Node です。Milvusは検索高速化のために、ベクトルデータとインデックスをメモリ上にロードします。つまり、データ量に比例してメモリコストが直撃します。

• Query Node: メモリバウンドかつCPUバウンドです。データセットをロードするために大量のメモリを消費し、検索クエリが来るとCPUをフル回転させます。例えば、768次元のベクトルデータが1億件ある場合、生データだけで約300GBになります。インデックスのオーバーヘッドを含めると、数百GB〜TB単位のメモリが必要になることも珍しくありません。
• Data Node: ストリーミングデータの永続化を担当します。I/Oバウンドですが、データのデシリアライズなどでCPUもそれなりに使います。
• Index Node: 前述の通り、CPUバウンドの極みです。ただし、常時稼働している必要がない場合もあり、ここをどう制御するかがコスト削減の鍵になります。

依存コンポーネント（Etcd, MinIO, Pulsar/Kafka）のオーバーヘッド

MilvusをK8sにデプロイすると、Milvus本体以外にも以下のサードパーティコンポーネント（依存関係）が付随します。

• Etcd: メタデータ管理。高速なディスクI/Oと低レイテンシが必要。
• MinIO (S3互換ストレージ): データの永続化層。ディスク容量コストがかかります。
• Pulsar / Kafka: メッセージキュー。ログの流し込みに使用されます。

これらは「隠れた固定費」です。特にPulsarやKafkaは、それ自体がJVM上で動作する重量級のミドルウェアであり、小規模なデータセット（数万〜数十万ベクトル程度）でMilvusを使う場合、「本体よりメッセージキューの方がリソースを消費している」という本末転倒な事態も起こり得ます。小規模運用なら、メッセージキューを軽量な構成（PulsarのStandaloneモードなど）にするか、そもそもMilvus Standalone版を検討することも有効なアプローチです。

3. 【ケーススタディ】規模別TCO試算シミュレーション

では、具体的にどの程度のリソースとコストがかかるのでしょうか。3つの運用シナリオを想定し、K8s上でのリソース構成と概算コストをシミュレーションしてみましょう。

※以下のコスト試算は、2026年1月時点のAWS東京リージョンにおけるオンデマンドインスタンス価格を参考にした概算値です。ストレージ料金やデータ転送量は含まず、コンピュートリソースに焦点を当てています。為替レートやリージョンにより実際の価格は変動するため、最新情報は必ず公式サイトをご確認ください。

ケースA：社内ドキュメント検索（データ量小・アクセス頻度低）

• 要件: 社内Wikiやマニュアル（約10万ベクトル / 768次元）。同時アクセス数は少ない。
• 構成戦略: ミニマム構成。高可用性（HA）は必須ではない。

この規模であれば、完全な分散構成（Milvus Cluster）はオーバースペックです。Milvus Standalone モードをK8sのDeploymentとして動かすのが論理的な選択です。

• リソース構成例:
  • Milvus Standalone Pod: 1 replica (4 vCPU, 16 GB Mem)
  • ※Etcd, MinIOは同一Pod内またはサイドカーとして軽量運用
• 参考インスタンス: 汎用インスタンス（例: m6i.xlarge / m7i.xlarge 相当）× 1台
• 月額インフラコスト目安: 約30,000円〜

ポイント: ここで無理にCluster構成を組むと、EtcdやPulsarのPodだけでリソースを浪費し、コストが3倍以上に膨れ上がります。「将来増えるかもしれない」という不確実な予測で最初からClusterにするのは避けましょう。MilvusはStandaloneからClusterへのデータ移行も可能です。

ケースB：ECサイトの商品検索（データ量中・アクセス頻度高）

• 要件: 商品データ（約500万〜1000万ベクトル）。ユーザーからの検索で頻繁にアクセスが発生。HA（高可用性）必須。
• 構成戦略: コンポーネント分離とQuery Nodeのスケールアウト。

ここでは Query Node のメモリ設計が重要になります。1000万ベクトル（768次元）の場合、生データだけで約30GB。HNSWインデックスを使用する場合、検索性能を維持するために最低でも64GB〜128GB程度のメモリプールを用意するのが安全です。

• リソース構成例:
  • Query Node: 2 replicas (各 4 vCPU, 32 GB Mem) → メモリ最適化インスタンス（例: r6i.xlarge 相当）
  • Data/Index Node: 2 replicas (各 4 vCPU, 16 GB Mem) → 汎用インスタンス（例: m6i.xlarge 相当）
  • Proxy: 2 replicas (各 2 vCPU, 4 GB Mem) → コンピュート最適化インスタンス（例: c6i.large 相当）
  • Dependencies (Kafka, Etcd, MinIO): 専用ノードプール（3台程度でHA構成）
• 月額インフラコスト目安: 約250,000円〜300,000円

ポイント: Query Nodeには「メモリ最適化インスタンス（AWSのr系、GCPのm系など）」を割り当てることで、コスト効率が良くなります。CPU最適化インスタンスを使用してしまうと、必要なメモリ量を確保するために無駄にCPU数が付随し、ライセンス費やコンピュート費が無駄になります。

ケースC：大規模RAG基盤（データ量大・リアルタイム更新）

• 要件: 全社ナレッジベース（1億ベクトル以上）。常に新しいニュースや文書が追加され、即座に検索可能にする必要がある。
• 構成戦略: Index Nodeの独立とオートスケーリング。

頻繁な更新がある場合、インデックス作成負荷が高まります。検索性能（Query Node）に影響を与えないよう、Index Node を物理的に別のノードプールに隔離することが重要です。

• リソース構成例:
  • Query Node: 10+ replicas (メモリ合計 500GB〜1TB) → 大規模メモリインスタンス（例: r6i.2xlarge × 10台など）
  • Index Node: 計算負荷に応じてオートスケール
  • Dependencies: 高性能なストレージとKafkaクラスタ
• 月額インフラコスト目安: 1,000,000円〜

ポイント: この規模になると、運用の人的コスト（障害対応、バージョンアップ検証、パフォーマンスチューニング）が大きくなります。インフラ費だけでなく、専任SREチームの人件費を含めたTCOで評価すると、フルマネージドサービス（Zilliz Cloudなど）の方がコスト効率が良い場合もあります。

インフラコスト vs 人的運用コストの損益分岐点

セルフホストの最大の注意点は「人件費」です。K8s上のステートフルセットの運用は、ステートレスなアプリに比べて難易度が格段に高くなります。

特に考慮すべきは、クラウドプロバイダーによるKubernetesのバージョン更新サイクルです。
例えば、GCPのGKEでは2026年1月時点でバージョン1.28系などが廃止されており、定期的なアップグレード対応（1.31系、1.32系などへの移行）が必須となります。これに伴う検証工数は無視できません。

• K8sバージョン追随: 短いライフサイクルに合わせたクラスタ更新と動作検証
• データのバックアップ/リストア: 手順の確立と定期的な復旧訓練
• Milvusのバージョンアップ: 破壊的変更への対応と移行テスト
• 依存ミドルウェア: EtcdやPulsar/Kafkaのトラブルシューティング

これらにエンジニアの工数がかかる場合、インフラ費が多少安くてもROIの観点からは割に合いません。プロジェクト計画には、必ず「運用維持工数」の項目を追加し、リスクを可視化することが重要です。

4. 推論リソースとの共存と最適化戦略

RAGシステムでは、Milvusの隣でEmbedding（ベクトル化）やLLMの推論が常に稼働しています。データベース単体ではなく、K8sクラスタ全体でのリソース最適化を考えることが、TCO削減の鍵となります。

Embeddingモデル用GPUとMilvus用CPUのバランス

近年のMilvusは、NVIDIA RAFTベースのGPUインデックス（CAGRAなど）をサポートしており、検索の超高速化が可能になっています。しかし、多くのユースケースにおいて、Milvusは依然としてCPUと大容量メモリで機能するデータベースです。HNSWなどのグラフベースアルゴリズムはメモリ依存度が高く、CPUでの計算が中心となります。

一方で、Embedding生成やLLMの推論はGPUが得意な領域です。ここでよくあるアンチパターンが、「全てのノードにGPUインスタンスを使用して、そこにMilvusのPodも相乗りさせる」という構成です。

これは以下の理由から避けるべきです：

1. リソースのミスマッチ: MilvusがCPUインデックスを使用している場合、高価なGPUリソースが活用されません。
2. メモリ競合: GPUを使用する場合でも、検索用と推論用でVRAM（ビデオメモリ）を取り合い、OOM（Out Of Memory）のリスクが高まります。

GPUリソースは推論専用に温存し、Milvusはメモリ最適化されたCPUノードに配置するのが、コスト対効果の面で最も合理的です。

K8sでのNode Pool分離によるワークロード管理

コスト効率を最大化するには、K8sの Node Pool 機能と Taints/Tolerations を活用して、ワークロードを物理的に分離します。最新のMilvus（v2.6系など）ではクエリ処理やリソーススケジューリングが最適化され、CPU効率が向上していますが、物理的な分離は依然としてベストプラクティスです。

1. CPU/Memory Pool (Spot Instance活用):
   • 用途: Milvus Query Node, Proxy
   • インスタンス: メモリ最適化タイプ（r6iなど）。ステートレスなProxyにはSpotインスタンスを活用してコストダウンを図るのも有効です（ただしQuery Nodeはデータを保持するため、ステートフルな扱いとし、オンデマンドが推奨されます）。
2. GPU Pool:
   • 用途: Embedding Model, LLM Inference
   • インスタンス: GPUタイプ（g5.xlargeなど）。ここには Taints を設定し、推論以外のPodが誤ってスケジュールされないようにロックします。
3. Storage/Base Pool:
   • 用途: Etcd, MinIO, Pulsar/Kafka
   • インスタンス: I/O性能が安定した汎用タイプ。ここの安定性がクラスタ全体の命綱となります。

このように「適材適所」でPodをスケジューリングすることで、高価なリソースの無駄遣いを防ぎます。

オートスケーリング（HPA/VPA）の設定と注意点

Milvusの Proxy コンポーネントはステートレスであり、CPU負荷に応じてHPA（Horizontal Pod Autoscaler）で容易にスケールできます。

しかし、Query Node のオートスケーリングには慎重な設計が必要です。Query Nodeが増減すると、ロードされたデータセグメントの再配置（リバランス）が発生します。これにはネットワーク帯域とCPUを消費するため、頻繁にスケールイン/アウトを繰り返すと、リバランス処理自体がボトルネックとなり、検索性能が一時的に低下するリスクがあります。

最新バージョンではリソース管理の安定性が向上していますが、Query Nodeのスケーリングは、日中のピークに合わせてスケジュールベース（CronJob等）で行うか、かなり保守的な閾値設定にすることをお勧めします。動的なオートスケールに頼るよりも、事前のキャパシティプランニングがシステムの安定稼働には重要です。

5. 「過剰スペック」を防ぐためのモニタリングとチューニング

運用開始後こそ、コスト削減の機会です。PrometheusとGrafanaを使って、以下の指標を監視し、定期的にリソースサイズを見直しましょう。

監視すべき主要メトリクス

• Query Node Memory Usage: 最も重要です。メモリ使用率が常に60%以下なら、明らかに割り当てすぎです。80%〜85%程度を目指してリクエスト値を下げましょう。ただし、OOM Kill（Out Of Memoryによる強制終了）を防ぐため、Limit値には余裕を持たせます。
• Search Latency (P99): 平均値ではなく、99パーセンタイルを確認します。ここがSLA（サービスレベル合意）の許容範囲内であれば、CPUリソースを削れる余地があります。
• Index Node CPU Usage: インデックス作成時以外はCPUに余裕があることが多いです。KEDA（Kubernetes Event-driven Autoscaling）などを使って、ジョブがない時は0にスケールする構成も検討できます。

インデックスタイプ（IVF, HNSW）によるコストへの影響

デフォルトで HNSW を選んでいませんか？ HNSWは高速で高精度ですが、メモリ消費量が大きいです。もしデータ量が膨大でメモリコストが圧迫されているなら、IVF_FLAT や IVF_SQ8（量子化）への切り替えを検討してください。

IVF_SQ8 はベクトルデータを圧縮するため、メモリ使用量を1/3〜1/4に削減できる場合があります。検索精度はわずかに落ちますが、リランキング処理（Rerank）を組み合わせることでカバーできるケースが多いです。これでメモリコストを大きく削減できます。「なんとなくHNSW」を見直すだけで、月額コストを最適化できることもあります。

Query Nodeの分離とレプリカ数調整

「読み取り専用レプリカ」の考え方を適用します。Milvusでは Resource Group 機能を使って、特定のコレクションや処理を特定のQuery Node群に割り当てることができます。

重要な検索機能（ユーザー向け）にはリソースを厚く割り当て、社内向けの分析用検索には低スペックなノードを割り当てる。こうした「SLAに応じたリソース配分」が、無駄なコストを削減します。

6. 結論：セルフホストを選択すべきタイミングとは

ここまで、K8s上でのMilvus運用の複雑さとコスト最適化手法について解説しました。「意外と大変そうだ」と感じた方もいるかもしれません。その直感は正しいと言えます。セルフホストは、自由度と引き換えに運用責任を伴います。

セルフホストを選択すべきなのは、以下の条件が揃った時です。

1. データ量が極めて大きい: TBクラスのデータがあり、クラウドの従量課金よりも、固定リソースで運用したほうが安くなる場合。
2. データ主権・セキュリティ要件: データを自社のVPC（あるいはオンプレミス）から一切出したくないという厳しいコンプライアンス要件がある場合。
3. K8s運用体制が成熟している: ステートフルなアプリの運用トラブルを自己解決できるSREチームが存在する場合。

マネージドサービスと比較した際のコストメリットが出るライン

ベクトル数が500万〜1000万未満であれば、マネージドサービスを利用したほうがTCOは安くなる傾向にあります。インフラ費だけでなく、バージョンアップや障害対応にかかるエンジニアの時間を「コスト」として計上すれば、マネージドの手数料は決して高くないと判断できます。

しかし、それを超える規模や、特殊なカスタマイズが必要な場合、今回紹介したようなリソース設計を自社でコントロールできるセルフホスト環境は、有効な選択肢になります。

「とりあえず最大構成」から脱却し、ビジネスの成長に合わせて拡張できる検索基盤を設計してください。それが、AIプロジェクトを成功に導き、ROIを最大化するための重要なステップとなります。

プロジェクトのフェーズに最適な選択を行い、実用的なAI導入を実現するための参考になれば幸いです。