データ通信の最適化：ミルバス、NATSメッセージングを採用
データ処理という複雑なタペストリーにおいて、シームレスなコミュニケーションは業務を結びつける糸である。オープンソース・ベクターデータベースの先駆者であるMilvusは、その最新機能で変革の旅に乗り出した：NATSメッセージングの統合である。この包括的なブログポストでは、この統合の複雑さを解き明かし、そのコア機能、セットアッププロセス、移行のメリット、そして前身であるRocksMQとの比較について説明します。
Milvus におけるメッセージキューの役割を理解する
Milvusのクラウドネイティブアーキテクチャにおいて、メッセージキュー（ログブローカー）は極めて重要な役割を担っています。これは、永続的なデータストリーム、同期、イベント通知、システム復旧時のデータ整合性を保証するバックボーンです。従来、Milvusスタンドアロン・モードでは、特にPulsarやKafkaと比較した場合、RocksMQが最もわかりやすい選択肢でしたが、膨大なデータや複雑なシナリオでは、その限界が明らかになりました。
Milvus 2.3では、シングル・ノードMQ実装であるNATSを導入し、データ・ストリームの管理方法を再定義します。前世代とは異なり、NATSはMilvusユーザをパフォーマンスの制約から解放し、膨大なデータ量の処理においてシームレスな体験を提供します。
NATS とは？
NATSはGoで実装された分散システム接続技術です。システム間のRequest-ReplyやPublish-Subscribeのような様々な通信モードをサポートし、JetStreamを通してデータの永続性を提供し、組み込みのRAFTを通して分散機能を提供します。NATSの詳細についてはNATS公式サイトを参照してください。
Milvus2.3スタンドアロンモードでは、NATS、JetStream、PubSubがMilvusに堅牢なMQ機能を提供します。
NATS の有効化
Milvus2.3では新しいコントロールオプションとしてmq.typeが追加され、ユーザが使用するMQのタイプを指定できるようになった。NATSを有効にするには、mq.type=natsmqと設定する。Milvusインスタンスを起動した後、以下のようなログが表示されれば、メッセージキューとしてNATSを有効にすることができたことになる。
[INFO] [dependency/factory.go:83] ["try to init mq"] [standalone=true] [mqType=natsmq].
MilvusのNATS設定
NATSのカスタマイズオプションには、リスニングポート、JetStreamストレージディレクトリ、最大ペイロードサイズ、および初期化タイムアウトの指定が含まれます。これらの設定を微調整することで、最適なパフォーマンスと信頼性を確保することができます。
natsmq：
サーバーの設定：# natsmq のサーバ側の設定。
ポート：4222 # デフォルトは 4222, nats サーバの待ち受けポート。
storeDir: /var/lib/milvus/nats # デフォルトでは/var/lib/milvus/nats。
maxFileStore：17179869184 # (B) デフォルトでは16GB, 'ファイル'ストレージの最大サイズ.
maxPayload：8388608 # (B) デフォルトでは8MB, メッセージのペイロードの最大バイト数.
maxPending: デフォルト：67108864 # (B) 64MB(デフォルト), 接続時にバッファリングされるバイト数の最大値 クライアント接続時に適用される.
initializeTimeout：4000 # (ms) デフォルトでは4秒、natsmqの初期化が終了するのを待つ。
natsmqの初期化が終了するのを待つ：
trace: false # デフォルトはfalse、trueの場合プロトコルのトレースログメッセージを有効にする。
debug: false # デフォルトはfalse, もしtrueならデバッグログメッセージを有効にする.
logTime: true # デフォルトではtrue、falseに設定するとタイムスタンプなしでログを記録する。
logFile: /tmp/milvus/logs/nats.log # デフォルトでは/tmp/milvus/logs/nats.log, milvusバイナリの ...からの相対パスを使用する場合.
logSizeLimit: 536870912 # (B) 512MB(デフォルト), ログファイルが新しいものにロールオーバーされた後のバイト数.
保持：
maxAge: 4320 # (最小) デフォルトでは3日, Pチャンネルに記録されるメッセージの最大保存期間.
maxBytes：# (B)デフォルトではなし, 一つのPチャンネルが含むことができるバイト数.Pチャンネルがこのサイズを超えた場合, 最も古いメッセージを削除します.
maxMsgs：# デフォルトではなし, 一つのPチャンネルが含むことができるメッセージの数.Pチャンネルがこの制限を超えた場合、最も古いメッセージを削除します。
注意:
NATS サーバのリスニングには
server.portを指定する必要がある。ポートが競合するとMilvusは起動できません。ランダムにポートを選択するにはserver.port=-1を設定してください。storeDir`はJetStreamストレージのディレクトリを指定する。Milvusの読み書きスループットを向上させるため、高性能なソリッドステートドライブ(SSD)にディレクトリを保存することを推奨する。
maxFileStore`はJetStreamストレージサイズの上限を設定します。この上限を超えると、それ以上データを書き込むことができなくなります。
maxPayload` は個々のメッセージのサイズを制限する。書き込み拒否を避けるために、5MB 以上に保つ必要がある。
initializeTimeout`はNATSサーバーの起動タイムアウトを制御する。
monitor` NATS の独立ログを設定する。
retention` は NATS メッセージの保持メカニズムを制御する。
詳しくはNATS official documentationを参照してください。
RocksMQ から NATS への移行
RocksMQからNATSへの移行は、書き込み操作の停止、データのフラッシュ、設定の変更、Milvusのログによる移行の検証などのステップを含むシームレスなプロセスです。
移行を開始する前に、Milvusのすべての書き込み操作を停止します。
Milvus で
FlushALLオペレーションを実行し、その完了を待つ。このステップにより、保留中のデータがすべてフラッシュされ、システムがシャットダウンできる状態になる。mq.type=natsmq
を設定し、natsmq`セクションの関連オプションを調整することで、Milvus設定ファイルを修正する。Milvus 2.3 を起動する。
rocksmq.path`ディレクトリに保存されているオリジナルデータをバックアップし、クリーンアップする。(オプション)
NATS vs. RocksMQ: パフォーマンス対決
Pub/Sub パフォーマンステスト
テスト・プラットフォーム:** M1 Pro チップ / メモリ: 16GB
テストシナリオ：*** トピックへのランダムなデータパケットのサブスクライブおよびパブリッシュを、最後のパブリッシュ結果を受信するまで繰り返す。
結果
より小さなデータパケット（<64kb）では、RocksMQはメモリ、CPU、応答速度に関してNATSを上回る。
より大きなデータパケット（> 64kb）では、NATSがRocksMQを凌駕し、レスポンスタイムがはるかに速い。
| テスト・タイプ｜MQ｜op数｜opあたりのコスト｜メモリ・コスト｜CPU合計時間｜ストレージ・コスト | ------------------- | ------- | -------- | ---------------- | ----------- | -------------- | ------------ | | 5MB100 Pub/Sub | NATS | 50 | 1.650328186 s/op | 4.29 GB | 85.58 | 25G | 5MB100 Pub/Sub｜RocksMQ｜50｜2.47595131 s/op｜1.18 GB｜81.42｜19G | 1MB500 Pub/Sub｜NATS｜50｜2.248722593 s/op｜2.60 GB｜96.50｜25G | 1MB500 Pub/Sub｜RocksMQ｜50｜2.554614279 s/op｜614.9 MB｜80.19｜19G | NATS｜50｜2.133345262 s/op｜3.29 GB｜97.59｜31G | 64KB10000 Pub/Sub｜RocksMQ｜50｜3.253778195 s/op｜331.2 MB｜134.6｜24G | 1KB50000 Pub/Sub｜NATS｜50｜2.629391004 s/op｜635.1 MB｜179.67｜2.6G | RocksMQ｜50｜0.897638581 s/op｜232.3 MB｜60.42｜521M
表1: Pub/Subパフォーマンステスト結果
Milvus 統合テスト
データサイズ: 100M
**NATS は、1 億個のベクターデータセットを用いた広範なテストにおいて、ベクター検索とクエリのレイテンシが低いことを示しました。
| メトリクス｜RocksMQ (ms)｜NATS (ms) | --------------------------------------- | ------------ | --------- | | 平均ベクトル検索レイテンシー｜23.55｜20.17 | ベクトル検索リクエスト/秒（RPS）｜2.95｜3.07 | 平均クエリーレイテンシー｜7.2｜6.74 | クエリーリクエスト/秒（RPS）｜1.47｜1.54
表2：100mデータセットによるMilvus統合テスト結果
データセット<100M
結果: 100M以下のデータセットでは、NATSとRocksMQは同程度のパフォーマンスを示した。
結論NATSメッセージングによるMilvusの強化
MilvusにNATSが統合されたことで、データ処理は大きく前進した。リアルタイム分析、機械学習アプリケーション、またはデータ集約的なベンチャー企業であろうと、NATSは効率性、信頼性、スピードでプロジェクトを強化します。データ環境が進化する中、ミルバスにNATSのような堅牢なメッセージングシステムがあれば、シームレスで信頼性の高い、高性能なデータ通信が可能になります。
Zhen YeSoftware Engineer at Zilliz
読み続けて
Turbopuffer vs. Zilliz Cloud: A Performance and Cost Benchmark for Multi-Tenant Vector Search
Turbopuffer vs. Zilliz Cloud: A Performance and Cost Benchmark
What is the K-Nearest Neighbors (KNN) Algorithm in Machine Learning?
KNN is a supervised machine learning technique and algorithm for classification and regression. This post is the ultimate guide to KNN.
Knowledge Injection in LLMs: Fine-Tuning and RAG
Explore knowledge injection techniques like fine-tuning and RAG. Compare their effectiveness in improving accuracy, knowledge retention, and task performance.