MilvusのKubernetes上でのオートスケーリングとEC2およびS3バックアップ永続ストレージ

クエリノード用の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とのデータフロー

1. 書き込みパス: データノードはメモリに挿入をバッファし、その後、確定済みセグメントをS3にフラッシュします
2. インデックス構築: インデックスノードはS3からセグメントを読み込み、インデックスを構築し、インデックスファイルをS3に書き戻します
3. クエリパス: クエリノードはS3からセグメントとインデックスをダウンロードし、メモリにロードしてクエリを処理します
4. リカバリ: Podの再起動時、クエリノードはS3から割り当てられたセグメントを再ダウンロードします（データ損失なし）

S3のパフォーマンス最適化

• セグメントサイズのチューニングにより、S3リクエストコストとデータの鮮度のバランスを取ります
• NVMeインスタンスストレージ上のローカルSSDキャッシングにより、ホットセグメントに対するS3の繰り返し読み込みを回避します
• 並列ダウンロードにより、高速なクエリノードの起動が可能になります
• ライフサイクルポリシーにより、古いデータをより安価なストレージ層にアーカイブします

モニタリングと可観測性

デプロイメントには、PrometheusとGrafanaを介した包括的なモニタリングが含まれています。

• クエリパフォーマンス — レイテンシー分布、QPS、キャッシュヒット率
• クラスター概要 — ノード数、Podステータス、リソース使用率
• ストレージ健全性 — S3使用量、セグメント数、フラッシュレート
• オートスケーリングイベント — HPAイベント、ノードスケーリング、Podスケジューリングレイテンシー
• アラート — 高レイテンシー、OOMリスク、フラッシュ失敗、キャパシティ制限に対する自動アラート

主要機能

1. クエリノードHPA — CPU、メモリ、レイテンシー、キュー深度に基づく自動スケーリング
2. EC2 Cluster Autoscaler — 混合インスタンスタイプによる動的なノードプロビジョニング
3. S3永続性 — 11-ninesの耐久性、ブロックストレージより約80%安価、AZ障害に耐えます
4. Spot Instances — 大幅なコンピューティングコスト削減のため、インデックスノードとデータノードはスポットインスタンスで稼働します
5. ローカルSSDキャッシュ — NVMeキャッシングにより、ホットセグメントに対するS3の繰り返し読み込みを排除します
6. ゼロダウンタイムリカバリ — Podの再起動はS3からセグメントを再ロードし、データ損失が発生しません
7. Multi-AZ — 完全なAZ障害耐性のためのS3ストレージ + Multi-AZノードグループ
8. 可観測性 — Milvus固有のメトリクスとオートスケーリングの可視性を提供するPrometheus + Grafana