Milvus
Zilliz
  • Home
  • Blog

  • ベクターデータベースの高可用性：CDCでmilvusスタンバイクラスタを構築する方法

ベクターデータベースの高可用性：CDCでmilvusスタンバイクラスタを構築する方法

  • Tutorials
March 26, 2026
Cal Huang

すべてのプロダクション・データベースには、物事がうまくいかなくなったときのための計画が必要だ。リレーショナル・データベースには、WALシッピング、ビンログ・レプリケーション、自動フェイルオーバーが何十年も前から備わっている。しかし、ベクトル・データベースは、AIアプリケーションの中核インフラになりつつあるにもかかわらず、この面ではまだ追いついていない。ほとんどがノードレベルの冗長性を提供するのがせいぜいだ。クラスタ全体がダウンした場合、バックアップからリストアし、ベクターインデックスをゼロから再構築することになる。MLパイプラインを通じてエンベッディングを再生成するのは安くはないため、このプロセスには数時間かかり、数千の計算コストがかかる。

Milvusは異なるアプローチを取る。クラスタ内の高速フェイルオーバーのためのノードレベルレプリカ、クラスタレベルとクロスリージョンの保護のためのCDCベースのレプリケーション、そしてセーフティネットリカバリーのためのバックアップです。このレイヤーモデルは従来のデータベースでは標準的な手法であり、Milvusはこれをベクターワークロードに導入した最初の主要なベクターデータベースです。

本ガイドでは、ベクターデータベースで利用可能な高可用性戦略（"production-ready "が実際に何を意味するのか評価できるように）と、Milvus CDCのプライマリ-スタンバイレプリケーションをゼロからセットアップするための実践的なチュートリアルの2つを取り上げます。

これはシリーズの第1部です：

  • パート1（本記事）：新しいクラスタでのプライマリ/スタンバイ・レプリケーションの設定
  • パート2:Milvus Backupを使用して、すでにデータがある既存のクラスタにCDCを追加する
  • パート3: フェイルオーバーの管理 - プライマリ停止時のスタンバイの昇格

なぜベクターデータベースでは高可用性が重要なのか？

従来のSQLデータベースがダウンした場合、構造化されたレコードへのアクセスは失われますが、データ自体は通常、上流のソースから再インポートすることができます。ベクターデータベースがダウンした場合、復旧は根本的に難しくなります。

ベクトル・データベースは、MLモデルによって生成された高密度の数値表現であるエンベッディングを保存している。エンベッディングデータベースを再構築するということは、エンベッディングパイプラインを通してデータセット全体を再実行することを意味する。何億ものベクトルを持つデータセットでは、これには何日もかかり、GPU計算で何千ドルもかかる。

一方、ベクトル検索に依存するシステムは、しばしばクリティカルパスに入っている：

  • 顧客に対応するチャットボットや検索を支えるRAGパイプライン- ベクトル・データベースがダウンすると、検索は停止し、AIは一般的な回答や幻覚のような回答を返す。
  • 商品やコンテンツの提案をリアルタイムで提供するレコメンデーション・エンジン- ダウンタイムは収益を逃すことを意味する。
  • 類似性検索に依存する不正検知や異常監視システムは、疑わしいアクティビティにフラグを立てる。
  • 記憶とツールの検索にベクター・ストアを使用する自律エージェント・システム- エージェントは知識ベースがないと失敗したりループしたりする。

これらのユースケースのためにベクターデータベースを評価するのであれば、高可用性は後で確認するための機能ではありません。高可用性は、最初に確認すべき機能の一つです。

ベクターデータベースにおけるプロダクショングレードの高可用性とは？

すべての高可用性が同じではありません。単一のクラスタ内のノード障害にしか対応できないベクターデータベースは、プロダクションシステムが必要とするような「高可用性」ではありません。本当のHAは3つのレイヤーをカバーする必要がある：

レイヤー何から守るかどのように機能するか復旧時間データ損失
ノードレベル（マルチレプリカ）単一ノードのクラッシュ、ハードウェア障害、OOMキル、AZ障害同じデータセグメントを複数のノードにコピーし、他のノードが負荷を吸収インスタントゼロ
クラスタレベル（CDCレプリケーション）クラスタ全体がダウン - K8sのロールアウト不良、ネームスペースの削除、ストレージの破損すべての書き込みをライトアヘッドログ経由でスタンバイクラスタにストリーム；スタンバイは常に数秒遅れ分秒
セーフティネット（定期バックアップ）致命的なデータ破損、ランサムウェア、レプリケーションを通じて伝播する人的エラー定期的にスナップショットを取得し、別の場所に保存時間時間（最後のバックアップから）

これらのレイヤーは補完的なものであり、代替ではありません。本番環境では、これらを積み重ねる必要がある：

  1. まずマルチレプリカ- 最も一般的な障害（ノードのクラッシュ、AZの障害）に対応し、ダウンタイムとデータロスをゼロにします。
  2. 次にCDC- マルチレプリカでは対応できない障害（クラスタ全体の停止、致命的なヒューマンエラー）から保護します。スタンバイクラスタは別の障害領域にあります。
  3. 定期的なバックアップは常に- 最後のセーフティネットです。CDCであっても、破損したデータをキャッチする前にスタンバイにレプリケートしてしまえば、あなたを救うことはできません。

ベクターデータベースを評価する際には、この3つのレイヤーのうち、その製品が実際にどのレイヤーをサポートしているのか？今日、ほとんどのベクターデータベースは最初のものしか提供していない。Milvusはこの3つすべてをサポートしており、CDCはサードパーティのアドオンではなく、ビルトイン機能として提供されています。

Milvus CDCとは？

Milvus CDC (Change Data Capture)は組み込みのレプリケーション機能で、プライマリクラスタのWAL (Write-Ahead Log)を読み込み、各エントリを別のスタンバイクラスタにストリームします。スタンバイはエントリーをレプリケートし、通常数秒遅れで同じデータを取得します。

このパターンはデータベースの世界では確立されている。MySQLにはbinlogレプリケーションがある。PostgreSQLにはWALシッピングがある。MongoDBにはoplogベースのレプリケーションがある。これらは何十年もの間、リレーショナル・データベースやドキュメント・データベースを本番稼動させてきた実績のある技術だ。Milvusは、同じアプローチをベクターワークロードにもたらす。Milvusは、WALベースのレプリケーションをビルトイン機能として提供する最初のメジャーなベクターデータベースである。

CDCがディザスタリカバリに適している理由は3つある：

  • 低レイテンシー同期。CDCは、スケジュールされたバッチではなく、オペレーションが発生した時点でストリーミングを行う。通常、スタンバイはプライマリから数秒遅れている。
  • 順序付けられた再生。操作は、書き込まれたのと同じ順序でスタンバイに到着する。リコンシリエーションを行わなくても、データは一貫性を保ちます。
  • チェックポイント・リカバリ。CDCプロセスがクラッシュしたり、ネットワークがダウンした場合でも、中断したところから再開します。データがスキップされたり、複製されたりすることはありません。

CDCアーキテクチャの仕組み

CDCの展開には3つのコンポーネントがあります：

CDC architecture showing Source Cluster with Streaming Nodes and CDC Nodes consuming the WAL, replicating data to the Target Cluster's Proxy layer, which forwards DDL/DCL/DML operations to Streaming Nodes and appends to WAL ストリーミング・ノードとCDCノードがWALを消費し、データをターゲット・クラスタのプロキシ・レイヤにレプリケートします。プロキシ・レイヤはDDL/DCL/DMLオペレーションをストリーミング・ノードに転送し、WALに追加します。

コンポーネント役割
プライマリクラスタ本番Milvusインスタンス。すべてのリードとライトはここに送られます。すべての書き込みはWALに記録される。
CDCノードプライマリと並ぶバックグラウンドプロセス。WALエントリを読み込み、スタンバイに転送する。読み取り/書き込みパスから独立して実行されるため、クエリやインサートのパフォーマンスには影響しない。
スタンバイクラスタ転送されたWALエントリを再生する別のMilvusインスタンス。プライマリと同じデータを数秒遅れで保持します。リードクエリを提供できるが、ライトは受け付けない。

流れ: 書き込みがプライマリにヒット → CDCノードがスタンバイにコピー → スタンバイが複製。スタンバイの書き込みパスには他には何も話しかけない。プライマリがダウンした場合、スタンバイはすでにほぼすべてのデータを持っており、昇格させることができる。

チュートリアルMilvus CDCスタンバイクラスタのセットアップ

この記事の残りは実践的なチュートリアルです。最終的には、2つのMilvusクラスタが稼働し、それらのクラスタ間でリアルタイムレプリケーションが行われるようになります。

前提条件

始める前に

  • Milvusv2.6.6以降。CDCはこのバージョンを必要とします。最新の2.6.xパッチを推奨します。
  • Milvus Operatorv1.3.4以降。本ガイドでは、Kubernetes上のクラスタ管理にOperatorを使用します。
  • kubectl 、helm が設定された稼働中のKubernetesクラスタ。
  • レプリケーション設定ステップに pymilvusを使用したPython。

現在のリリースには2つの制限があります：

制限事項詳細
単一のCDCレプリカクラスタあたり1つのCDCレプリカ。分散CDCは将来のリリースで計画されています。
BulkInsertなしCDCが有効な場合、BulkInsertはサポートされません。こちらも将来のリリースを予定しています。

ステップ1: Milvus Operatorのアップグレード

Milvus Operatorをv1.3.4以降にアップグレードします：

helm repo add zilliztech-milvus-operator https://zilliztech.github.io/milvus-operator/
# "zilliztech-milvus-operator" has been added to your repositories

helm repo update zilliztech-milvus-operator
# Hang tight while we grab the latest from your chart repositories…
# …Successfully got an update from the “zilliztech-milvus-operator” chart repository
# Update Complete. ⎈Happy Helming!⎈


helm -n milvus-operator upgrade milvus-operator zilliztech-milvus-operator/milvus-operator
# Release “milvus-operator” has been upgraded. Happy Helming!
# NAME: milvus-operator
# LAST DEPLOYED: Wed Dec  3 17:25:28 2025
# NAMESPACE: milvus-operator
# STATUS: deployed
# REVISION: 30
# TEST SUITE: None
# NOTES:
# Milvus Operator Is Starting, use kubectl get -n milvus-operator deploy/milvus-operator to check if its successfully installed
# Full Installation doc can be found in https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md
# Quick start with kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/main/config/samples/milvus_minimum.yaml
# More samples can be found in https://github.com/zilliztech/milvus-operator/tree/main/config/samples
# CRD Documentation can be found in https://github.com/zilliztech/milvus-operator/tree/main/docs/CRD
# Administration Documentation can be found in https://github.com/zilliztech/milvus-operator/tree/main/docs/administration

Operator podが動作していることを確認します：

kubectl get pods -n milvus-operator
# NAME                             READY   STATUS    RESTARTS   AGE
# milvus-operator-9fc99f88-h2hwz   1/1     Running   0          54s

ステップ2: プライマリクラスタのデプロイ

プライマリ(ソース)クラスタ用のYAMLファイルを作成します。components の下のcdc セクションは、クラスタと一緒にCDCノードをデプロイするようにOperatorに指示します：

# This is a sample to deploy a milvus cluster with cdc.
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: source-cluster
  namespace: milvus
  labels:
    app: milvus
spec:
  mode: cluster
  components:
    image: milvusdb/milvus:v2.6.6 # Use version 2.6.6 or above, as CDC is available from 2.6.6 onwards
    cdc:
      replicas: 1  # Currently, CDC only supports 1 replica
  dependencies:
    msgStreamType: woodpecker

msgStreamType: woodpecker 、KafkaやPulsarのような外部メッセージキューではなく、Milvusの組み込みWoodpecker WALを使用します。WoodpeckerはMilvus 2.6で導入されたクラウドネイティブなライトアヘッドログで、外部メッセージングインフラストラクチャの必要性を取り除きます。

設定を適用する：

kubectl create namespace milvus
# namespace/milvus created
kubectl apply -f milvus_source_cluster.yaml
# milvus.milvus.io/source-cluster created

すべてのポッドがRunningステータスになるのを待つ。CDCポッドが起動していることを確認します：

kubectl get pods -n milvus
# Look for source-cluster-milvus-cdc-xxx in Running state
# NAME                                                READY   STATUS    RESTARTS   AGE
# source-cluster-milvus-cdc-66d64747bd-sckxj          1/1     Running   0          2m42s
# source-cluster-milvus-datanode-85f9f56fd-qgbzq       1/1     Running   0          2m42s
# ...

ステップ3: スタンバイクラスタのデプロイ

スタンバイ(ターゲット)クラスタは同じMilvusバージョンを使用しますが、CDCコンポーネントは含まれません：

# This is a sample to deploy a milvus cluster with cdc.
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: target-cluster
  namespace: milvus
  labels:
    app: milvus
spec:
  mode: cluster
  components:
    image: milvusdb/milvus:v2.6.6 # Use version 2.6.6 or above, as CDC is available from 2.6.6 onwards
  dependencies:
    msgStreamType: woodpecker

適用します：

kubectl apply -f milvus_target_cluster.yaml
# milvus.milvus.io/target-cluster created

すべてのポッドが実行されていることを確認します：

kubectl get pods -n milvus
# NAME                                                   READY   STATUS    RESTARTS   AGE
# ...
# target-cluster-milvus-datanode-7ffc8cdb6b-xhzcd        1/1     Running   0          104m
# target-cluster-milvus-mixcoord-8649b87c98-btk7m        1/1     Running   0          104m
# ...

ステップ4: レプリケーション関係の構成

両方のクラスタが実行されている状態で、pymilvusを使用してPythonを使用してレプリケーション・トポロジを構成します。

クラスタ接続の詳細と物理チャネル（pchannel）名を定義します：

source_cluster_addr = "http://10.98.124.90:19530" # example address — replace with your actual Milvus server address
target_cluster_addr = "http://10.109.234.172:19530"
source_cluster_token = "root:Milvus"
target_cluster_token = "root:Milvus"
source_cluster_id = "source-cluster"
target_cluster_id = "target-cluster"
pchannel_num = 16

source_cluster_pchannels = []
target_cluster_pchannels = []
for i in range(pchannel_num):
source_cluster_pchannels.append(f"{source_cluster_id}-rootcoord-dml_{i}")
target_cluster_pchannels.append(f"{target_cluster_id}-rootcoord-dml_{i}")

レプリケーション構成を構築します：

config = {
    "clusters": [
        {
            "cluster_id": source_cluster_id,
            "connection_param": {
                "uri": source_cluster_addr,
                "token": source_cluster_token
            },
            "pchannels": source_cluster_pchannels
        },
        {
            "cluster_id": target_cluster_id,
            "connection_param": {
                "uri": target_cluster_addr,
                "token": target_cluster_token
            },
            "pchannels": target_cluster_pchannels
        }
    ],
    "cross_cluster_topology": [
        {
            "source_cluster_id": source_cluster_id,
            "target_cluster_id": target_cluster_id
        }
    ]
}

両方のクラスタに適用します：

from pymilvus import MilvusClient

source_client = MilvusClient(uri=source_cluster_addr, token=source_cluster_token)
source_client.update_replicate_configuration(**config)
source_client.close()


target_client = MilvusClient(uri=target_cluster_addr, token=target_cluster_token)
target_client.update_replicate_configuration(**config)
target_client.close()

これが成功すると、プライマリ上のインクリメンタルな変更がスタンバイに自動的にレプリケートされ始めます。

ステップ5: レプリケーションの動作確認

  1. プライマリに接続し、コレクションを作成し、いくつかのベクターを挿入し、ロードします。
  2. プライマリで検索を実行し、データがそこにあることを確認する。
  3. スタンバイに接続し、同じ検索を実行します。
  4. スタンバイが同じ結果を返せば、レプリケーションは機能しています。

Milvusクイックスタートでは、コレクションの作成、挿入、検索について説明しています。

本番環境でのCDCの実行

CDCのセットアップは簡単です。CDCの信頼性を長期間維持するには、いくつかの運用領域に注意を払う必要があります。

レプリケーションの遅延の監視

スタンバイは常にプライマリより若干遅れている。これは非同期レプリケーション特有のものだ。通常の負荷であれば、遅延は数秒である。しかし、書き込みが急増したり、ネットワークが混雑したり、スタンバイのリソースが圧迫されたりすると、ラグが大きくなることがあります。

ラグを指標として追跡し、アラートを出す。ラグが回復せずに大きくなるのは、通常、CDCノードが書き込みスループットに追いついていないことを意味します。まずクラスタ間のネットワーク帯域幅を確認し、スタンバイがより多くのリソースを必要とするかどうかを検討します。

スタンバイをリード・スケーリングに使用する

スタンバイは、災害が発生するまでアイドル状態で待機しているだけのコールドバックアップではありません。レプリケーションがアクティブな間は検索やクエリのリクエストを受け付け、書き込みだけがブロックされる。これにより、実用的な用途が広がる：

  • バッチ類似検索や分析ワークロードをスタンバイにルーティングする。
  • ピーク時の読み取りトラフィックを分割し、プライマリへの負担を軽減する。
  • 本番の書き込みレイテンシに影響を与えることなく、高価なクエリ（大規模なトップK、大規模なコレクションをフィルタリングした検索）を実行できます。

これにより、DRインフラストラクチャがパフォーマンス資産に変わります。スタンバイは、何も故障していないときでも稼げます。

スタンバイの適切なサイズ

スタンバイはプライマリからの書き込みをすべて複製するため、同様の計算リソースとメモリ・リソースが必要になります。読み込みもスタンバイにルーティングするのであれば、その追加負荷も考慮してください。ストレージの要件も同じです。

必要になる前にフェイルオーバーをテストする

フェイルオーバー・プロセスが機能しないことを知るために、実際の障害を待つ必要はありません。定期的にドリルを実行する：

  1. プライマリへの書き込みを停止する
  2. スタンバイが追いつくのを待つ（ラグ → 0）
  3. スタンバイをプロモートする
  4. クエリが期待通りの結果を返すことを確認する
  5. 逆プロセス

各ステップにかかる時間を測定し、文書化する。目標は、フェイルオーバーをタイミングがわかっている日常的な手順にすることです。このシリーズのパート3では、フェイルオーバー・プロセスについて詳しく説明する。

CDCを自分で管理したくない？Zilliz Cloudにお任せください

MilvusのCDCレプリケーションのセットアップと運用は強力ですが、運用にはオーバーヘッドが伴います。2つのクラスタを管理し、レプリケーションの健全性を監視し、フェイルオーバーのランブックを処理し、リージョン間でインフラを維持する必要があります。運用の負担なしにプロダクショングレードのHAを求めるチームには、Zilliz Cloud（マネージドMilvus）がすぐに提供してくれる。

グローバルクラスタはZilliz Cloudの主要機能である。北米、ヨーロッパ、アジアパシフィックなど、複数の地域にまたがるMilvusデプロイメントを単一の論理クラスタとして運用することができる。ボンネットの下では、この記事で説明したのと同じCDC/WALレプリケーション・テクノロジーを使用しているが、完全に管理されている：

機能セルフマネージドCDC（この記事）Zillizクラウド・グローバル・クラスター
レプリケーション構成と監視自動化された非同期CDCパイプライン
フェイルオーバー手動ランブック自動化 - コード変更なし、接続文字列更新なし
セルフヒーリング障害が発生したクラスタを再プロビジョニング自動: 古い状態を検出してリセットし、新しいセカンダリとして再構築する
クロスリージョン両方のクラスタをデプロイして管理ローカル・リード・アクセスによるマルチ・リージョンを内蔵
RPO秒（監視状況による）秒（計画外）/ゼロ（計画的な切り替え）
RTO分（ランブックによる）分（自動化）

グローバル・クラスタ以外にも、ビジネス・クリティカル・プランにはDR機能が追加されています：

  • ポイント・イン・タイム・リカバリ(PITR)-保持ウィンドウ内の任意の時点にコレクションをロールバックします。スタンバイにレプリケートされた不慮の削除やデータ破損からの復旧に便利です。
  • クロスリージョンバックアップ- デスティネーションリージョンへの自動化された継続的なバックアップレプリケーション。新しいクラスタへのリストアは数分で完了します。
  • 99.99%のアップタイムSLA- 複数のレプリカによるマルチAZデプロイメントに支えられています。

本番環境でベクトル検索を運用しており、DRが必須要件である場合、Milvusのセルフマネージド・アプローチとともにZilliz Cloudを評価する価値がある。詳細はZillizチームまでお問い合わせください。

次の記事

本記事では、ベクターデータベースのHA環境について説明し、プライマリとスタンバイのペアをゼロから構築する方法を説明した。次回は

  • パート2: 既存のMilvusクラスタにCDCを追加し、レプリケーションを有効にする前にMilvus Backupを使用してスタンバイをシードする。
  • パート 3: フェイルオーバーの管理 - スタンバイの昇格、トラフィックのリダイレクト、元のプライマリのリカバリ

ご期待ください。

本番環境でMilvusを運用し、ディザスタリカバリについてお考えでしたら、ぜひお手伝いさせてください：

  • MilvusのSlackコミュニティに参加して、質問したり、HAアーキテクチャを共有したり、Milvusを大規模に運用している他のチームから学んだりしましょう。
  • CDCの設定、フェイルオーバーの計画、マルチリージョンの展開など、DRのセットアップについて説明する20分間のMilvusオフィスアワー（無料）をご予約ください。
  • インフラストラクチャのセットアップをスキップして、すぐに本番環境での高可用性を実現したい場合は、Milvusが管理するZilliz Cloudのグローバルクラスタ機能をご利用ください。

ベクター・データベースの高可用性をセットアップし始めると、いくつかの疑問が出てきます：

Q: CDCはプライマリクラスターの速度を落としますか？

CDC NodeはWALログを非同期で読み込みます。CDCノードは、プライマリ上のリソースのためにクエリやインサートと競合することはありません。CDCを有効にしてもパフォーマンスに違いはありません。

Q: CDCを有効にする前に存在したデータをレプリケートできますか？

いいえ - CDCは有効化された時点からの変更のみをキャプチャします。既存のデータをスタンバイに取り込むには、まずMilvus Backupを使用してスタンバイをシードし、次にCDCを有効にして継続的なレプリケーションを行います。このシリーズのパート2では、このワークフローについて説明します。

Q: すでにマルチレプリカを有効にしている場合でもCDCは必要ですか?

CDCとマルチレプリカは異なる障害モードから保護します。Multi-replicaは1つのクラスタ内のノード間で同じセグメントのコピーを保持します。ノードの障害には最適ですが、クラスタ全体がなくなってしまった場合（デプロイの失敗、AZの停止、ネームスペースの削除）には役に立ちません。CDCは、ほぼリアルタイムのデータを持つ別の障害領域に別のクラスタを保持する。開発環境以上のものには、両方が必要です。

Q: Milvus CDCは他のベクターデータベースのレプリケーションと比較してどうですか？

現在、ほとんどのベクターデータベースはノードレベルの冗長性（マルチレプリカに相当）は提供していますが、クラスタレベルのレプリケーションは提供していません。PostgreSQLやMySQLのようなリレーショナルデータベースが何十年も使ってきたのと同じパターンです。クロスクラスタやクロスリージョンのフェイルオーバーが要件である場合、これは評価すべき重要な差別化要因となる。

    Try Managed Milvus for Free

    Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.

    Get Started

    Like the article? Spread the word

    続けて読む