セルフマネージド Milvus を Zilliz Cloud に移行してレイテンシを 99% 超削減

もともとsimonhearne.comで公開され、許可を得て再投稿されています。

Milvusをベクトルデータベースとして使用し、StandaloneまたはDistributedでアプリケーションを構築したとします。アプリケーションが動作し、顧客が利用し、データ量が増えている段階に到達しました。やがて、ベクトルデータベースの管理により多くの時間を費やすようになり、Podの障害がサービスの揺らぎを引き起こし、サーバーのRAMが不足し始めたり、etcdが厄介なボトルネックになったりします。

この段階では、おそらく運用負荷を取り除くためにマネージドサービスを検討しているでしょう。幸いなことに、MilvusからZilliz Cloudへの移行は簡単で、さまざまなオプションが十分に文書化されています。

私の場合、シンプルなWikipedia RAGアプリケーションを構築していました。CohereのEmbed v3 multilingualモデルを使用した1,024次元の50M埋め込み（Wikipedia英語コーパス全体をカバー）です。当初は、Milvus Standaloneを使ってこれを自分のラップトップ上でホストしていましたが、コンテナが不安定で、再起動に約20分かかっていました。デモを見せたいときには理想的ではありません！

クエリ性能も、頻繁なページングのために低下していました（私のラップトップには十分なメモリがないため、mmapを有効にしていました）。以下は、アプリケーションの動作を示す短い動画です。

3秒のクエリ時間はあまり良いものではないため、新しいラップトップを購入する予算がない中で、Zilliz Cloud上のマネージドMilvusへの移行を計画しました。以下は、私が実施したステップバイステップのプロセスです。利用できる方法はいくつかありますが、簡単さを重視してバックアップ/リストアを選びました。

1. バックアップを作成する

Zillizはmilvus-backupユーティリティを提供しており、インストールはbrew install milvus-backupと同じくらい簡単です。

次に、設定ファイルを作成する必要があります（milvus-backupはデフォルトで現在の作業ディレクトリ内のbackup.yamlを探します）。これは、ローカルでDocker上に実行しているStandaloneからバックアップを作成するための最小限の例です（完全なyaml optionsはGitHubを参照してください）。

milvus:
  address: localhost
  port: 19530
  user: "root"
  password: "Milvus"
  tlsMode: 0
  etcd:
    endpoints: 127.0.0.1:2379
    rootPath: "by-dev"
minio:
  storageType: "local"
  rootPath: "/../milvus_wikipedia/volumes/milvus/data"
  backupStorageType: "local"
  backupRootPath: "/../milvus-backup-test/backup"

次に、簡単なチェックを実行します。

$ milvus-backup check

Milvus version: 2.6.2
Storage:
  milvus-storage-type: local
  milvus-bucket: a-bucket
  milvus-rootpath: /../milvus_wikipedia/volumes/milvus/data
  backup-storage-type: local
  backup-bucket: a-bucket
  backup-rootpath: /../milvus-backup-test/backup

Success!

そして最後に、バックアップを作成します（これには少し時間がかかります）。

$ milvus-backup create -n wiki_backup

2. Zilliz Cloudにターゲットインスタンスを作成する

まず、Zilliz Cloudアカウントを持っていることを確認し、ローカルデプロイメントの最小要件に一致するインスタンスを作成します。Tiered-Storage上の50M x 1,024-D埋め込みの場合、public calculatorでは2つのQuery CUが必要だと見積もられました。

そこでクラウドコンソールに移動し、「+ Cluster」をクリックして、以下の設定を使用しました。

作成中に、次のステップで必要になるAPIキーを取得/生成できます。

また、新しいインスタンスのクラスターIDをメモしておきます。

3. Zillizへの移行

先ほど生成/取得したクラウドキーを含めるように、backup.yamlを更新します。

cloud:
  address: https://api.cloud.zilliz.com
  apikey: <your-api-key>

最後に、バックアップ名とターゲットのクラスターIDを引数として渡し、移行コマンドを1つ実行するだけです。

$ milvus-backup migrate -n wiki_backup -c <your-cluster-id>

私の場合、約120GBのバックアップファイルをZilliz Cloud上のVolumeにアップロードするのに数時間かかり、その後Volumeからターゲットクラスターを作成するのに約1時間かかりました。移行ステータスは、Zilliz CloudコンソールのJobsで監視できます。

移行が完了したら、必ずコレクションをクラスターにロードしてください！

4. 検証

これで、アプリケーションを更新して新しいクラスターエンドポイントと認証情報を使用するだけです。

Milvus Standaloneと比較してパフォーマンスの向上が確認できます — 3,112msに対して25ms — これは99%以上のレイテンシ削減です！。これは、クラウドサービスで割り当てられるコンピューティングが増加したことに加え、Milvus OSSと比較して10倍高速なクエリを実現できるZilliz Cloudの独自インデックスエンジン — Cardinal — によるところもあります。

パフォーマンス向上は非常に大きいですが、それ以上に、コンテナの停止を心配する必要がなくなり、ラップトップ上で約20GBのRAMを解放できるようになりました！

5. その他の考慮事項

• アプリケーションが 24x7 で稼働していない場合、ベクトルデータベースも同様に稼働している必要はありません。使用されていないときは非アクティブなクラスターを一時停止して、コンピュートコストをゼロにできます。
• Tiered-Storage は低い（<10 QPS）要件に適したクラスタータイプですが、他のオプションもあり、それらの間でデータを移行できます。
• On-Demand — クエリが実行されているときにのみコンピュートを使用します。クエリの頻度によっては、より高いコールドスタートレイテンシを代償として、コストを 99% 削減できる可能性があります。
• Capacity-Optimized — Tiered-Storage と比較してデータ密度は低下しますが、10 倍高いスループットと 2〜5 倍高速なクエリを実現します。これにより、私の例のコンピュートコストは約 60% 増加します。
• Performance-Optimized — データ密度がさらに低下する代わりに、さらに高いスループット（レプリカあたり >1,000 QPS）とパフォーマンス（10〜100 倍高速）を提供します。
• Zilliz Cloud は、Google Cloud Storage、Amazon S3、Azure Blob Storage などから外部ボリュームをマウントすることをサポートしています。そのため、よりクリーンなアプローチは、バックアップをクラウドストレージに直接アップロードし、そこから復元することです。
• 何らかの理由でバックアップの作成/復元ができず、Milvus デプロイメントを公開アクセス可能にできる場合は、Zilliz Cloud の Migrate from Milvus Endpoint 機能を使用できます。
• クリック操作が好みの方法でない場合、Zilliz Cloud で行ったすべてのことは API および/または Terraform 経由で管理できます。