Milvus
Zilliz
  • Home
  • Blog

  • Milvus 2.5.xからMilvus 2.6.xへの安全なアップグレード方法

Milvus 2.5.xからMilvus 2.6.xへの安全なアップグレード方法

  • Tutorials
December 25, 2025
Yiqing Lu

Milvus 2.6がリリースされてしばらく経つが、プロジェクトにとって確かな前進であることが証明された。このリリースは、洗練されたアーキテクチャ、より強力なリアルタイムパフォーマンス、より少ないリソース消費、本番環境におけるよりスマートなスケーリング動作をもたらします。これらの改善点の多くは、ユーザーからのフィードバックによって直接形作られたものであり、2.6.xを早期に導入したユーザーからは、重いワークロードや動的なワークロードの下で、検索が著しく高速になり、システムのパフォーマンスがより予測しやすくなったという報告がすでに寄せられています。

Milvus 2.5.xを運用し、2.6.xへの移行を検討しているチームにとって、本ガイドは出発点となるものです。アーキテクチャの違いを分解し、Milvus 2.6で導入された主要な機能に焦点を当て、運用の中断を最小限に抑えるよう設計された、実践的でステップバイステップのアップグレードパスを提供します。

リアルタイムパイプライン、マルチモーダル検索、ハイブリッド検索、大規模なベクトル操作などのワークロードをお持ちの場合、このブログは、2.6がお客様のニーズに合致しているかどうかを評価し、続行することを決定した場合、データの整合性とサービスの可用性を維持しながら、自信を持ってアップグレードするのに役立ちます。

Milvus 2.5からMilvus 2.6へのアーキテクチャの変更点

アップグレードワークフローそのものに入る前に、まずMilvus 2.6でMilvusアーキテクチャがどのように変更されるのかを理解しましょう。

Milvus 2.5のアーキテクチャ

Milvus 2.5 Architecture Milvus 2.5 アーキテクチャ

Milvus 2.5では、ストリーミングワークフローとバッチワークフローが複数のワーカーノードで絡み合っていました：

  • QueryNodeは履歴クエリとインクリメンタル（ストリーミング）クエリの両方を処理した。

  • DataNodeは、インジェスト・タイム・フラッシングと履歴データのバックグラウンド・コンパクションの両方を処理した。

このようにバッチとリアルタイムのロジックが混在していたため、バッチのワークロードを独立してスケールすることが困難だった。また、ストリーミングの状態が複数のコンポーネントに散らばっていたため、同期の遅延が発生し、障害復旧が複雑になり、運用が複雑になっていました。

Milvus 2.6アーキテクチャ

Milvus 2.6 Architecture Milvus 2.6のアーキテクチャ

Milvus 2.6では、メッセージキューの消費、増分セグメントの書き込み、増分クエリの提供、WALベースのリカバリの管理など、すべてのリアルタイムデータを処理する専用のStreamingNodeが導入されました。ストリーミングが分離されたことで、残りのコンポーネントはよりすっきりとした、よりフォーカスされた役割を担うようになりました：

  • QueryNode は履歴セグメントに対するバッチクエリのみを処理します。

  • DataNodeは、コンパクションやインデックス構築などの履歴データタスクのみを処理します。

StreamingNodeは、Milvus 2.5ではDataNode、QueryNode、そしてProxyに分かれていたストリーミング関連のタスクをすべて吸収し、役割を明確にし、クロスロールの状態共有を減らします。

Milvus 2.5.xとMilvus 2.6.xの比較：コンポーネントごとの比較

Milvus 2.5.xMilvus 2.6.x変更点
コーディネーターサービスRootCoord / QueryCoord / DataCoord (または MixCoord)ミックスコードメタデータ管理とタスクスケジューリングが単一のMixCoordに統合され、コーディネーションロジックが簡素化され、分散の複雑さが軽減されました。
アクセスレイヤープロキシプロキシ書き込みリクエストはStreaming Nodeを通してのみルーティングされ、データを取り込む。
ワーカーノード-ストリーミング・ノード増分データの取り込み - 増分データのクエリ - オブジェクトストレージへの増分データの永続化 - ストリームベースの書き込み - WALに基づく障害回復を含む、すべての増分（成長セグメント）ロジックを担当する専用のストリーミング処理ノード。
クエリーノードクエリーノード過去のデータに対するクエリのみを処理するバッチ処理ノード。
データノードデータノードコンパクションやインデックス構築を含む、履歴データのみを扱うバッチ処理ノード。
インデックス・ノード-インデックスノードはデータノードに統合され、役割定義と展開トポロジーが簡素化される。

つまり、Milvus 2.6では、ストリーミングとバッチのワークロードに明確な線引きがなされ、2.5で見られたようなコンポーネントをまたいだもつれがなくなり、よりスケーラブルで保守性の高いアーキテクチャが実現されています。

Milvus 2.6機能ハイライト

アップグレードのワークフローに入る前に、Milvus 2.6が何をもたらすかを簡単にご紹介します。本リリースでは、インフラコストの削減、検索パフォーマンスの向上、大規模でダイナミックなAIワークロードのスケーリングを容易にすることに重点を置いています。

コストと効率の改善

  • プライマリ・インデックスのRaBitQ 量子化- ベクトル・インデックスを元のサイズの1/32に圧縮する新しい1ビット量子化手法。SQ8リランキングと組み合わせることで、メモリ使用量を約28%削減し、QPSを4倍向上。

  • BM25最適化全文検索- スパースな用語重みベクトルによるネイティブBM25スコアリング。キーワード検索はElasticsearchと比較して3～4倍（データセットによっては最大7倍）高速に実行され、インデックスサイズは元のテキストデータの3分の1程度に抑えられます。

  • JSONシュレッディングによるJSONパスインデックス- ネストされたJSONの構造化フィルタリングが劇的に高速化し、より予測しやすくなりました。事前にインデックス化されたJSONパスにより、フィルターのレイテンシーが140 msから1.5 msに短縮され（P99：480 msから10 ms）、ハイブリッドベクター検索＋メタデータフィルタリングの応答性が大幅に向上しました。

  • 拡張されたデータ型サポート- Int8ベクトル型、ジオメトリフィールド（POINT / LINESTRING / POLYGON）、Array-of-Structsを追加。これらの拡張は、地理空間ワークロード、より豊富なメタデータモデリング、よりクリーンなスキーマをサポートします。

  • 部分更新の Upsert- 1 回の主キー呼び出しでエンティティの挿入や更新ができるようになりました。部分更新では、提供されたフィールドのみが変更されるため、書き込みの増幅が減少し、メタデータや埋め込みを頻繁に更新するパイプラインが簡素化されます。

検索と取得の強化

  • テキスト処理と多言語サポートの向上：新しいLinderaとICUトークナイザーにより、日本語、韓国語、多言語のテキスト処理が改善されました。Jieba はカスタム辞書をサポートします。run_analyzer はトークン化の動作のデバッグを支援し、多言語アナライザは一貫したクロスランゲージ検索を保証します。

  • 高精度テキストマッチング: フレーズマッチは、設定可能なスロープを持つ順序付きフレーズクエリを強制します。新しいNGRAMインデックスは、VARCHARフィールドとJSONパスの両方で部分文字列とLIKE クエリを高速化し、高速な部分テキストとファジーマッチングを可能にします。

  • 時間を考慮した再ランキングとメタデータを考慮した再ランキング： Decay Rankers(exponential, linear, Gaussian)はタイムスタンプを使ってスコアを調整し、Boost Rankersはメタデータドリブンのルールを適用して結果を昇格または降格させます。どちらも、基礎となるデータを変更することなく、検索動作を微調整するのに役立ちます。

  • 簡素化されたモデル統合と自動ベクトル化：OpenAI、Hugging Face、その他のエンベッディングプロバイダとの統合により、Milvusは挿入やクエリ操作の際にテキストを自動的にベクトル化します。一般的なユースケースにおいて、手作業による埋め込みパイプラインはもう必要ありません。

  • スカラーフィールドのオンラインスキーマ更新：ダウンタイムやリロードなしで既存のコレクションに新しいスカラーフィールドを追加し、メタデータ要件の増加に伴うスキーマの進化を簡素化します。

  • MinHashによる重複検出： MinHash+ LSHにより、高価な厳密比較を行うことなく、大規模なデータセット全体で効率的に重複を検出できます。

アーキテクチャとスケーラビリティのアップグレード

  • ホット/コールドデータ管理のための階層型ストレージ：遅延ロードと部分ロードをサポートし、コレクションをローカルに完全にロードする必要性を排除。リソース使用量を最大50%削減し、大規模データセットのロード時間を短縮。

  • リアルタイム・ストリーミング・サービス：Kafka/Pulsarと統合された専用のストリーミング・ノードを追加し、継続的なインジェストを実現。即時のインデックス作成とクエリ可用性を可能にし、書き込みスループットを向上させ、リアルタイムで変化の速いワークロードの障害回復を高速化します。

  • 拡張性と安定性の強化：Milvusは、大規模なマルチテナント環境向けに100,000以上のコレクションをサポートするようになりました。Woodpecker（ゼロディスクWAL）、Storage v2（IOPS/メモリの削減）、Coordinator Mergeといったインフラストラクチャーのアップグレードにより、クラスタの安定性が向上し、高負荷時でも予測可能なスケーリングが可能になりました。

Milvus 2.6機能の完全なリストについては、Milvusリリースノートをご覧ください。

Milvus 2.5.xからMilvus 2.6.xへのアップグレード方法

Milvus 2.5クラスタからMilvus 2.6へのアップグレードは、アップグレード中も可能な限りシステムを利用可能な状態に保つため、以下の順序で行ってください。

1.ストリーミングノードを最初に起動する

Streaming Nodeを先に起動する。新しいDelegator(Query Nodeの中でストリーミングデータの処理を担当するコンポーネント)をMilvus 2.6 Streaming Nodeに移動する必要があります。

2.MixCoordのアップグレード

コーディネータコンポーネントをMixCoordにアップグレードする。このステップでは、MixCoordは分散システム内のクロスバージョン互換性を処理するために、Worker Nodeのバージョンを検出する必要があります。

3.クエリーノードのアップグレード

Query Nodeのアップグレードには通常時間がかかります。この段階では、Milvus 2.5データノードとインデックスノードはフラッシュやインデックス構築などの処理を継続することができ、クエリノードのアップグレード中にクエリサイドのプレッシャーを軽減することができます。

4.データノードのアップグレード

Milvus 2.5 データノードがオフラインになると、Flush 操作は利用できなくなり、すべてのノードが Milvus 2.6 に完全にアップグレードされるまで、Growing Segment のデータは蓄積され続ける可能性があります。

5.プロキシのアップグレード

ProxyをMilvus 2.6にアップグレードした後、すべてのクラスタコンポーネントが2.6にアップグレードされるまで、そのProxyに対する書き込み操作は利用できません。

6.インデックスノードの削除

他のすべてのコンポーネントがアップグレードされたら、スタンドアロンのIndex Nodeを安全に取り外すことができます。

注意事項

  • DataNodeのアップグレードが完了してからProxyのアップグレードが完了するまで、フラッシュ操作は利用できません。

  • 最初のProxyがアップグレードされてからすべてのProxyノードがアップグレードされるまでの間、一部の書き込み操作は利用できません。

  • Milvus2.5.xから2.6.6へ直接アップグレードする場合、DDLフレームワークの変更により、アップグレード中はDDL(Data Definition Language)オペレーションが利用できません。

Milvus Operatorを使用したMilvus 2.6へのアップグレード方法

Milvus OperatorはオープンソースのKubernetesオペレータであり、対象のKubernetesクラスタ上にMilvusサービススタック全体をデプロイ、管理、アップグレードするためのスケーラブルで可用性の高い方法を提供します。オペレータが管理するMilvusサービススタックには以下が含まれます：

  • Milvusのコアコンポーネント

  • etcd、Pulsar、MinIOなどの必要な依存関係

Milvus Operatorは、標準のKubernetes Operatorパターンに従います。バージョン、トポロジー、構成など、Milvusクラスタの望ましい状態を記述するMilvusカスタムリソース（CR）を導入します。

コントローラはクラスタを継続的に監視し、CRで定義された望ましい状態と実際の状態を照合します。Milvusバージョンのアップグレードなどの変更が行われると、オペレータは制御された反復可能な方法でそれらを自動的に適用し、自動アップグレードと継続的なライフサイクル管理を可能にします。

Milvusカスタムリソース(CR)の例

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-milvus-mansion    
  namespace: dev       
spec:
  mode: cluster                  # cluster or standalone
  # Milvus Components
  components:
    image: milvusdb/milvus:v2.6.5
    imageUpdateMode: rollingUpgrade 
    proxy:                   
      replicas: 1          
    mixCoord:              
      replicas: 1           
    dataNode:               
      replicas: 1          
    queryNode:              
      replicas: 2           
      resources:
        requests:
          cpu: "2"
          memory: "8Gi"  
  # Dependencies, including etcd, storage and message stream
  dependencies:
    etcd:                   
      inCluster:
        values:
          replicaCount: 3    
    storage:                 
      type: MinIO
      inCluster:
        values:
          mode: distributed     
    msgStreamType: pulsar    
    pulsar:
      inCluster:
        values:
          bookkeeper:
            replicas: 3   
  # Milvus configs
  config:
    dataCoord:
      enableActiveStandby: true

Milvus OperatorによるMilvus 2.5から2.6へのローリングアップグレード

Milvus Operatorは、クラスタモードでMilvus 2.5から2.6へのローリングアップグレードをビルトインサポートしています。

1.アップグレードシナリオの検出

アップグレード中、Milvus Operatorはクラスタ仕様から対象のMilvusバージョンを決定します。これは次のいずれかによって行われます：

  • spec.components.image で定義されたイメージタグを検査する。

  • で指定された明示的なバージョンを読み取ります。spec.components.version

status.currentImage status.currentVersion現在のバージョンが2.5で、希望するバージョンが2.6の場合、オペレータはアップグレードを2.5→2.6のアップグレードシナリオとして識別します。

2.ローリングアップグレードの実行順序

2.5から2.6へのアップグレードが検出され、アップグレードモードがローリングアップグレード(spec.components.imageUpdateMode: rollingUpgrade)に設定されている場合、Milvus OperatorはMilvus 2.6アーキテクチャに沿った事前定義された順序で自動的にアップグレードを実行します：

ストリーミング・ノードの起動 → MixCoordのアップグレード → クエリ・ノードのアップグレード → データ・ノードのアップグレード → プロキシのアップグレード → インデックス・ノードの削除

3.コーディネータの自動統合

Milvus 2.6は複数のコーディネータコンポーネントを単一のMixCoordに置き換えます。Milvus Operatorは、このアーキテクチャの移行を自動的に処理します。

spec.components.mixCoord が設定されると、オペレータは MixCoord を起動し、準備が整うまで待ちます。MixCoordが完全に稼動すると、オペレータはレガシーコーディネータコンポーネント（RootCoord、QueryCoord、DataCoord）を潔くシャットダウンし、手動で操作することなく移行を完了します。

Milvus 2.5から2.6へのアップグレード手順

1.Milvus Operatorを最新バージョンにアップグレードする(本ガイドでは、執筆時の最新リリースであるバージョン1.3.3を使用する)

# Option 1: Using Helm
helm upgrade --install milvus-operator \
  -n milvus-operator --create-namespace \
  https://github.com/zilliztech/milvus-operator/releases/download/v1.3.3/milvus-operator-1.3.3.tgz
 # Option 2: Using kubectl & raw manifests
 kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/v1.3.3/deploy/manifests/deployment.yaml

2.コーディネータコンポーネントをマージする

kubectl patch milvus my-release -n demo-operator --type=merge -p '
{
  "spec": {
    "components": {
      "mixCoord": {
        "replicas": 1
      }
    }
  }
}'

3.クラスタがMilvus 2.5.16以降を実行していることを確認します。

kubectl patch milvus my-release -n demo-operator --type=merge -p '
{
  "spec": {
    "components": {
      "image": "milvusdb/milvus:v2.5.22"
    }
  }
}'
# wait till updated
kubectl wait milvus my-release -n demo-operator --for=condition=milvusupdated --timeout=1h

4.Milvusをバージョン2.6にアップグレードする。

kubectl patch milvus my-release -n demo-operator --type=merge -p '
{
  "spec": {
    "components": {
      "image": "milvusdb/milvus:v2.6.5"
    }
  }
}'
# wait till updated
kubectl wait milvus my-release -n demo-operator --for=condition=milvusupdated --timeout=1h

Helmを使用したMilvus 2.6へのアップグレード方法

Helmを使用してMilvusをデプロイする場合、すべてのKubernetesDeployment リソースは実行順序を保証されることなく並行して更新されます。その結果、Helmはコンポーネント間のローリングアップグレードシーケンスを厳密に制御できません。そのため、本番環境ではMilvus Operatorの使用を強く推奨します。

Milvusは以下の手順でHelmを使用して2.5から2.6にアップグレードすることができます。

システム要件

  • Helmバージョン:≥ 3.14.0

  • Kubernetesバージョン:≥ 1.20.0

1.Milvus Helmチャートを最新バージョンにアップグレードする。本ガイドでは、執筆時点の最新であるチャートバージョン5.0.7を使用する。

helm repo add zilliztech https://zilliztech.github.io/milvus-helm
helm repo update

2.クラスタに複数のコーディネータコンポーネントがデプロイされている場合は、まずMilvusをバージョン2.5.16以降にアップグレードし、MixCoordを有効にします。

mixCoordinator
。
helm upgrade -i my-release zilliztech/milvus \
  --namespace=helm-demo \
  --set image.all.tag="v2.5.22" \
  --set mixCoordinator.enabled=true \
  --set rootCoordinator.enabled=false \
  --set indexCoordinator.enabled=false \
  --set queryCoordinator.enabled=false \
  --set dataCoordinator.enabled=false \
  --set streaming.enabled=false \
  --set indexNode.enabled=true \
  --reset-then-reuse-values \
  --version=5.0.7 \
  --wait --timeout 1h

3.Milvusをバージョン2.6にアップグレードする。

helm upgrade my-release zilliztech/milvus \
  --namespace=helm-demo \
  --set image.all.tag="v2.6.5" \
  --set streaming.enabled=true \
  --set indexNode.enabled=false \
  --reset-then-reuse-values \
  --version=5.0.7 \
  --wait --timeout 1h

Milvus 2.6のアップグレードと運用に関するFAQ

Q1: Milvus HelmとMilvus Operator、どちらを使用すればよいですか？

本番環境ではMilvus Operatorを強く推奨します。

詳細はオフィシャルガイド:https://github.com/zilliztech/milvus-operator?tab=readme-ov-file#milvus-operator-vs-helmをご参照ください。

Q2: メッセージキュー(MQ)はどのように選択すればよいですか?

推奨するMQは、導入形態や運用要件によって異なります：

1.スタンドアロンモード：スタンドアロンモード：コストを重視する場合はRocksMQをお勧めします。

2.クラスタ・モード

  • Pulsarはマルチ・テナントをサポートし、大規模なクラスタがインフラを共有することを可能にし、強力な水平スケーラビリティを提供します。

  • Kafkaはより成熟したエコシステムを持っており、ほとんどの主要クラウド・プラットフォームでマネージドSaaSを利用することができます。

3.Woodpecker (Milvus 2.6で導入)：Woodpeckerは外部メッセージキューの必要性をなくし、コストと運用の複雑さを軽減する。

  • 現在、軽量で運用が容易な組み込み型のWoodpeckerモードのみがサポートされています。

  • Milvus 2.6のスタンドアロン環境ではWoodpeckerを推奨します。

  • 本番クラスタ環境では、Woodpeckerクラスタモードが利用可能になり次第、そちらを使用することをお勧めします。

Q3: アップグレード中にメッセージキューを切り替えることはできますか？

アップグレード中にメッセージキューを切り替えることは現在サポートされていません。今後のリリースでは、Pulsar、Kafka、Woodpecker、RocksMQ間の切り替えをサポートする管理APIを導入する予定です。

Q4: Milvus 2.6用にレート制限設定を更新する必要はありますか？

既存のレート制限設定は有効で、新しいStreaming Nodeにも適用されます。変更は必要ありません。

Q5: コーディネーターのマージ後、モニタリングロールやコンフィグレーションは変更されますか？

  • 監視ロールは変更されません(RootCoord,QueryCoord,DataCoord)。

  • 既存の設定オプションは以前と同様に機能します。

  • 新しい設定オプションmixCoord.enableActiveStandby が導入され、明示的に設定されていない場合はrootcoord.enableActiveStandby にフォールバックします。

  • 軽いリアルタイム・インジェストや、時折のライト＆クエリ作業負荷の場合は、CPUコア2個、メモリ8GBといった小規模な構成で十分です。

  • ヘビーなリアルタイムインジェストや継続的なライト＆クエリワークロードの場合は、Query Nodeと同等のリソースを割り当てることをお勧めします。

Q7: Docker Composeを使用したスタンドアロンデプロイのアップグレード方法を教えてください。

Docker Composeベースのスタンドアロンデプロイの場合、docker-compose.yaml のMilvusイメージタグを更新するだけです。

詳細は公式ガイドhttps://milvus.io/docs/upgrade_milvus_standalone-docker.mdをご参照ください。

結論

Milvus 2.6では、アーキテクチャと運用の両面で大きな改善がなされました。StreamingNode の導入によるストリーミング処理とバッチ処理の分離、コーディネー ターの MixCoord への統合、ワーカーの役割の簡素化により、Milvus 2.6 は、大規模なベクターワークロードに対 して、より安定でスケーラブル、かつ運用しやすい基盤を提供します。

このようなアーキテクチャの変更により、特に Milvus 2.5 からのアップグレードは、より順番を重視するようになりました。アップグレードが成功するかどうかは、コンポーネントの依存関係と一時的な可用性の制約を尊重できるかどうかにかかっています。Milvus Operatorは、アップグレードの順序を自動化し、運用リスクを低減するため、本番環境では推奨されるアプローチです。

Milvus 2.6は、強化された検索機能、より豊富なデータタイプ、階層化されたストレージ、改善されたメッセージキューオプションにより、リアルタイムインジェスト、高いクエリパフォーマンス、スケールでの効率的な運用を必要とする最新のAIアプリケーションをサポートするのに十分なポジションにあります。

Milvusの最新機能に関するご質問やディープダイブをご希望ですか？私たちの Discordチャンネルに参加するか、 GitHubに課題を提出してください。また、 Milvusオフィスアワーを通して、20分間の1対1のセッションを予約し、洞察、ガイダンス、質問への回答を得ることもできます。

Milvus 2.6に関するその他のリソース

    Try Managed Milvus for Free

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

    Get Started

    Like the article? Spread the word

    続けて読む