MilvusのKubernetes上でのオートスケーリングとEC2およびS3バックアップ永続ストレージ
急速に増加するベクトルデータ（検索、レコメンデーション、RAGのための埋め込み）を持つAIプラットフォームは、クエリ負荷とデータ量に基づいてMilvusベクトルデータベースを自動的にスケーリングさせる必要がありました。それは、podが再起動したり、nodeが置き換えられたりしても失われない、耐久性があり費用対効果の高いストレージを備えたものでした。
プロジェクトを相談する
課題
本番環境でMilvusを大規模に実行するには、いくつかのインフラストラクチャに関する課題がありました。
- 固定キャパシティ — 静的なMilvusデプロイメントでは、ピーク時の10倍のクエリ負荷スパイクを処理できませんでした
- データ損失リスク — エフェメラルストレージ上でのPodの再起動により、大規模なコレクションでインデックスの再構築に数時間かかることがありました
- コスト非効率性 — ピーク負荷に備えて過剰にプロビジョニングすると、時間の70%はアイドル状態のコンピューティングに料金を支払うことになります
- ストレージコスト — インスタンスに紐付けられたブロックストレージボリュームは、数テラバイト規模のベクトルデータセットには高価でした
- インデックスの再構築 — ノードの交換後に数百万のベクトルの再インデックスに数時間のダウンタイムが必要でした
- Multi-AZの耐久性 — シングルAZストレージでは、アベイラビリティゾーンの障害に耐えることができませんでした
私たちのソリューション
クエリノード用のHorizontal Pod Autoscaling、コンピューティング用のCluster Autoscaler、そして永続ストレージバックエンドとしてAmazon S3を使用して、Kubernetes (EKS)上にMilvusをデプロイしました。これにより、データ損失のリスクを排除し、ストレージコストを約80%削減しました。
アーキテクチャ
- オーケストレーション: Amazon EKS (Elastic Kubernetes Service)
- コンピューティング: Cluster Autoscalerによって管理されるEC2インスタンス（混合インスタンスタイプ）
- ベクトルDB: 分散モードでHelmチャートを介してデプロイされたMilvus
- オブジェクトストレージ: セグメントファイル、インデックスファイル、およびバイナリログの永続化のためのAmazon S3
- メタデータ: Milvusの調整とメタデータのためのetcdクラスター
- メッセージキュー: Milvusログパイプラインのためのメッセージストリーミング
- モニタリング: MilvusのメトリクスとオートスケーリングシグナルのためのPrometheus + Grafana
Kubernetes上のMilvus分散アーキテクチャ
コンポーネントのデプロイ
Milvusは、専用のノードタイプを持つ分散モードで実行され、それぞれが独立したスケーリングを持つKubernetesワークロードとしてデプロイされます。
- プロキシノード — クライアント接続とリクエストルーティングを処理します
- クエリノード — ベクトル検索を実行し、セグメントをメモリにロードします
- データノード — 書き込みパスを処理し、セグメントをS3にフラッシュします
- インデックスノード — ベクトルインデックスを構築し、S3に書き込みます
- コーディネーター — クラスターの調整とタイムスタンプの割り当て
- etcd — メタデータストレージとサービスディスカバリ
- メッセージキュー — ログストリーミングとライトアヘッドログ
Horizontal Pod Autoscaling (HPA)
クエリノードのオートスケーリング
クエリノードは主要なスケーリングターゲットであり、ベクトルセグメントをメモリにロードして検索を実行します。スケーリングは、CPU使用率、メモリ使用率、クエリキュー深度、P99クエリレイテンシーを含む複数のメトリクスによって駆動されます。HPAは、適切な最小/最大レプリカ数、スパイクを処理するための高速スケールアップ、およびフラッピングを避けるための段階的スケールダウンで構成されています。
インデックスノードのオートスケーリング
インデックスノードは、保留中のインデックス構築ジョブに基づいてスケーリングします。ビルドキューに保留中のアイテムがある場合にスケールアップし、アイドル時にスケールダウンします。
EC2 Cluster Autoscaler
インスタンス戦略
- ノードグループ: コスト最適化のために異なるインスタンスタイプを持つ複数のノードグループ
- クエリワークロード: インメモリベクトルセグメントのためのメモリ最適化インスタンス
- インデックスワークロード: CPU集約型インデックス構築のためのコンピューティング最適化インスタンス
- Spot Instances: インデックスノードと非クリティカルなデータノードは、大幅なコスト削減のためにSpot Instancesで実行されます
- On-Demand: 安定性のために、クエリノードとコーディネーターはオンデマンドインスタンス上で実行されます
スケーリング挙動
HPAがスケジュールできない新しいPodを作成すると、Cluster Autoscalerは適切なノードグループに新しいEC2インスタンスをプロビジョニングします。その後、新しいクエリノードはS3から割り当てられたセグメントをメモリにロードし、クエリの処理を開始します。この全体のスケールアッププロセスは数分で完了します。
S3バックアップ永続ストレージ
ブロックストレージではなくS3を使用する理由
S3は、Milvusにとってブロックストレージよりも大幅な利点を提供します。
- 大規模データセットの場合、約80%低いストレージコスト
- 組み込みのMulti-AZレプリケーションによる11-ninesの耐久性
- 手動でのボリュームサイズ変更なしに無制限のスケーリング
- Podから独立 — Podやノードのライフサイクルに関係なく、データは常に利用可能です
- AZロックインなし — どのAvailability Zoneからでもデータにアクセスできます
S3とのデータフロー
- 書き込みパス: データノードはメモリに挿入をバッファし、その後、確定済みセグメントをS3にフラッシュします
- インデックス構築: インデックスノードはS3からセグメントを読み込み、インデックスを構築し、インデックスファイルをS3に書き戻します
- クエリパス: クエリノードはS3からセグメントとインデックスをダウンロードし、メモリにロードしてクエリを処理します
- リカバリ: Podの再起動時、クエリノードはS3から割り当てられたセグメントを再ダウンロードします（データ損失なし）
S3のパフォーマンス最適化
- セグメントサイズのチューニングにより、S3リクエストコストとデータの鮮度のバランスを取ります
- NVMeインスタンスストレージ上のローカルSSDキャッシングにより、ホットセグメントに対するS3の繰り返し読み込みを回避します
- 並列ダウンロードにより、高速なクエリノードの起動が可能になります
- ライフサイクルポリシーにより、古いデータをより安価なストレージ層にアーカイブします
モニタリングと可観測性
デプロイメントには、PrometheusとGrafanaを介した包括的なモニタリングが含まれています。
- クエリパフォーマンス — レイテンシー分布、QPS、キャッシュヒット率
- クラスター概要 — ノード数、Podステータス、リソース使用率
- ストレージ健全性 — S3使用量、セグメント数、フラッシュレート
- オートスケーリングイベント — HPAイベント、ノードスケーリング、Podスケジューリングレイテンシー
- アラート — 高レイテンシー、OOMリスク、フラッシュ失敗、キャパシティ制限に対する自動アラート
主要機能
- クエリノードHPA — CPU、メモリ、レイテンシー、キュー深度に基づく自動スケーリング
- EC2 Cluster Autoscaler — 混合インスタンスタイプによる動的なノードプロビジョニング
- S3永続性 — 11-ninesの耐久性、ブロックストレージより約80%安価、AZ障害に耐えます
- Spot Instances — 大幅なコンピューティングコスト削減のため、インデックスノードとデータノードはスポットインスタンスで稼働します
- ローカルSSDキャッシュ — NVMeキャッシングにより、ホットセグメントに対するS3の繰り返し読み込みを排除します
- ゼロダウンタイムリカバリ — Podの再起動はS3からセグメントを再ロードし、データ損失が発生しません
- Multi-AZ — 完全なAZ障害耐性のためのS3ストレージ + Multi-AZノードグループ
- 可観測性 — Milvus固有のメトリクスとオートスケーリングの可視性を提供するPrometheus + Grafana
成果
技術スタック
caseStudyDetail.more ケーススタディ
その他の技術実装事例をご覧ください
AIを活用したOCRによる請求書処理とQuickBooks連携
毎月数百件の仕入先請求書を処理する中規模企業が、AI/OCRを使用して請求書データを自動抽出し、それを記帳と支払追跡のためにQuickBooksに直接同期させることで、手動データ入力を排除する必要がありました。
SCTE-35マーカー解析とマルチプラットフォームプレイヤー統合によるクライアントサイド広告挿入 (CSAI)
あるビデオストリーミングプラットフォームは、ウェブ、モバイル、コネクテッドTVアプリ全体でクライアントサイド広告挿入 (CSAI) を実装する必要がありました。これにより、サーバーサイド挿入では提供できない、完全な広告インタラクションサポート（クリック可能なオーバーレイ、コンパニオンバナー、スキップボタン）を備えた、パーソナライズされたデバイスレベルの広告体験が可能になります。
よくある質問
MicrocosmWorks は、Milvus の組み込みメモリ使用量エクスポーターからのカスタムメトリクスを使用して水平ポッドオートスケーリングを設定し、いずれかのクエリノードがメモリ使用率 75% を超えた場合にスケールアウトイベントをトリガーします。コレクションセグメントは Milvus のセグメントマネージャーを使用して新しいノードに自動的に再配布され、これにより単一のノードがボトルネックになるのを防ぎます。
MicrocosmWorksは、MinIOをオブジェクトストレージ層として使用するS3ベースのストレージを選択しました。これは、ストレージをコンピューティングから切り離し、新しいEBSボリュームをプロビジョニングすることなく、クエリノードが独立してスケーリングできるようにするためです。このアーキテクチャにより、gp3 EBSボリュームと比較してストレージコストを約60%削減できる一方で、S3からのセグメントロード時間を100ミリ秒未満に維持できます。
MicrocosmWorksは、各Milvusコンポーネント（クエリノード、インデックスノード、データノードを含む）ごとにレプリカセットでデプロイメントを構成し、ローリングアップデート中の最小限の可用性を確保するためにpod disruption budgetsを設定しました。すべての永続データはS3に存在するため、障害が発生したノードの代替は、データ移行なしで、すぐにすべてのセグメントにアクセスできます。
MicrocosmWorks は、Milvus のクエリワークロードに対して、r6i.2xlarge インスタンスが最適なコストパフォーマンスを提供することを発見しました。これらのインスタンスは、競争力のある spot price で 64GB のメモリを提供し、インメモリセグメントキャッシュに利用できます。GPU アクセラレーションによるインデックス構築では、NVIDIA A10G GPU を搭載した g5.xlarge インスタンスを使用することで、CPU のみでの構築と比較してインデックス構築時間を 8 倍短縮しました。
MicrocosmWorksは、Kubernetesインフラプロジェクトを$30～$50/時間の料金で提供しています。Helm chartのカスタマイズ、HPAの設定、S3との統合、モニタリング設定を含むMilvus autoscalingデプロイメントには、通常150～250時間が必要です。クラスターの最適化やアップグレードに対する継続的なマネージドサポートも、同じ時間単価でご利用いただけます。