Milvusアーキテクチャの概要
Milvusはオープンソースの クラウドネイティブなベクトルデータベースであり、膨大なベクトルデータセットの高性能な類似検索用に設計されています。Faiss、HNSW、DiskANN、SCANNを含む一般的なベクトル検索ライブラリの上に構築され、AIアプリケーションや非構造化データ検索シナリオを強化します。先に進む前に、埋め込み検索の基本原理についてよく理解してください。
アーキテクチャ図
以下の図は、Milvusのハイレベルなアーキテクチャを示しており、完全に分離されたストレージとコンピュートレイヤーを持つ、モジュール化されたスケーラブルでクラウドネイティブな設計を示しています。
アーキテクチャ図
アーキテクチャの原則
Milvusはデータプレーンとコントロールプレーンの分離という原則に従い、スケーラビリティとディザスタリカバリの点で相互に独立した4つの主要レイヤーで構成されています。ストレージとコンピュートレイヤーが完全に分離されたこの共有ストレージアーキテクチャは、コンピュートノードの水平スケーリングを可能にし、同時にWoodpeckerをゼロディスクWALレイヤーとして実装することで、弾力性の向上と運用オーバーヘッドの削減を実現しています。
ストリーム処理をStreaming Nodeに、バッチ処理をQuery NodeとData Nodeに分離することで、Milvusはリアルタイム処理要件を同時に満たしながら高いパフォーマンスを実現しています。
詳細レイヤアーキテクチャ
レイヤー1：アクセスレイヤー
ステートレスプロキシ群から構成されるアクセスレイヤーは、システムのフロントレイヤーであり、ユーザーへのエンドポイントである。クライアントのリクエストを検証し、返された結果を縮小する：
- プロキシはそれ自体ステートレスである。Nginx、Kubernetes Ingress、NodePort、LVSなどのロードバランシングコンポーネントを使用して、統一されたサービスアドレスを提供する。
- Milvusは超並列処理（MPP）アーキテクチャを採用しているため、プロキシは最終結果をクライアントに返す前に中間結果を集約し、後処理を行う。
レイヤ2：コーディネータ
CoordinatorはMilvusの頭脳として機能する。常にクラスタ全体で1つのCoordinatorがアクティブであり、クラスタトポロジの維持、すべてのタスクタイプのスケジューリング、クラスタレベルの一貫性の確保を担当します。
以下はCoordinatorが処理するタスクの一部です：
- DDL/DCL/TSO 管理：コレクション、パーティション、インデックスの作成または削除などのデータ定義言語（DDL）およびデータ制御言語（DCL）リクエストの処理、タイムスタンプオラクル（TSO）の管理、タイムティッカーの発行。
- ストリーミング・サービス管理：ライト・アヘッド・ログ（WAL）をストリーミング・ノードにバインドし、ストリーミング・サービスのサービス・ディスカバリーを提供する。
- クエリー管理：クエリ・ノードのトポロジーと負荷分散を管理し、クエリ・ルーティングをガイドするサービング・クエリ・ビューを提供・管理します。
- 履歴データ管理：コンパクションやインデックス構築などのオフラインタスクをデータノードに分散し、セグメントとデータビューのトポロジーを管理する。
レイヤー3：ワーカー・ノード
手足。ワーカーノードはコーディネーターの指示に従うダムエグゼキューターです。ワーカーノードはストレージと計算を分離しているためステートレスであり、Kubernetesにデプロイすることでシステムのスケールアウトやディザスタリカバリを容易にすることができる。ワーカーノードには3つのタイプがある：
ストリーミングノード
Streaming Nodeはシャードレベルの "ミニ頭脳 "として機能し、シャードレベルの一貫性保証と、基礎となるWAL Storageに基づく障害復旧を提供する。一方、Streaming Nodeはデータクエリの増大とクエリプランの生成も担当する。さらに、成長データを密封（履歴）データに変換する処理も行う。
クエリーノード
クエリーノードはオブジェクトストレージから履歴データをロードし、履歴データのクエリーを提供します。
データノード
データノードは、コンパクションやインデックス構築など、履歴データのオフライン処理を担当する。
レイヤー4：ストレージ
ストレージはシステムの骨格であり、データの永続性を担う。メタ・ストレージ、ログ・ブローカー、オブジェクト・ストレージで構成される。
メタ・ストレージ
メタ・ストレージは、コレクション・スキーマやメッセージ消費チェックポイントなどのメタデータのスナップショットを保存する。メタデータの保存には、極めて高い可用性、強力な一貫性、トランザクションサポートが要求されるため、Milvusはメタ・ストレージにetcdを選択した。Milvusはサービスの登録とヘルスチェックにもetcdを使用している。
オブジェクトストレージ
オブジェクトストレージには、ログのスナップショットファイル、スカラーデータおよびベクトルデータのインデックスファイル、クエリの中間結果が格納される。MilvusはオブジェクトストレージとしてMinIOを使用しており、AWS S3やAzure Blobといった世界で最も利用されているコスト効率の高いストレージサービスに容易に導入することができる。しかし、オブジェクトストレージはアクセスレイテンシーが高く、クエリー数に応じて課金される。パフォーマンスを向上させ、コストを下げるために、milvusはメモリまたはSSDベースのキャッシュプール上にコールド・ホット・データ分離を実装する予定である。
WALストレージ
WAL（Write-Ahead Log）ストレージは、分散システムにおけるデータの耐久性と一貫性の基盤である。変更がコミットされる前に、まずログに記録され、障害が発生した場合でも、中断したところから正確にリカバリできることを保証する。
一般的なWALの実装には、Kafka、Pulsar、Woodpeckerなどがある。従来のディスクベースのソリューションとは異なり、Woodpeckerはオブジェクトストレージに直接書き込むクラウドネイティブなゼロディスク設計を採用しています。このアプローチは、お客様のニーズに合わせて容易に拡張でき、ローカルディスクを管理するオーバーヘッドを取り除くことで運用を簡素化します。
WALレイヤーは、すべての書き込み操作を事前にログに記録することで、分散環境がどんなに複雑になっても、信頼性の高いシステム全体のリカバリーと一貫性のメカニズムを保証します。
データフローとAPIカテゴリ
MilvusのAPIはその機能によって分類され、アーキテクチャを通じて特定のパスに従います：
| APIカテゴリ | オペレーション | API例 | アーキテクチャフロー |
|---|---|---|---|
| DDL/DCL | スキーマとアクセス制御 | createCollection dropCollection, 、hasCollection createPartition | アクセス層 → コーディネータ |
| DML | データ操作 | insert delete upsert | アクセス層 → ストリーミングワーカーノード |
| DQL | データクエリー | search,query | アクセス層 → バッチワーカーノード（クエリノード） |
データフロー例：検索操作
- クライアントがSDK/RESTful API経由で検索リクエストを送信
- ロードバランサーがリクエストをアクセスレイヤーの利用可能なプロキシにルーティング
- Proxyはルーティングキャッシュを使ってターゲットノードを決定し、キャッシュが利用できない場合のみCoordinatorに連絡する。
- Proxyはリクエストを適切なStreaming Nodeに転送し、Streaming Nodeはローカルで成長データ検索を実行しながら、密封データ検索のためにQuery Nodeと連携する。
- クエリーノードは必要に応じてオブジェクトストレージから封印されたセグメントをロードし、セグメントレベルの検索を実行する。
- 検索結果はマルチレベルで削減される：クエリ・ノードは複数のセグメントにわたる結果を削減し、ストリーミング・ノードはクエリ・ノードからの結果を削減し、プロキシはクライアントに戻る前にすべてのストリーミング・ノードからの結果を削減します。
データフローの例：データ挿入
- クライアントがベクトルデータを含む挿入リクエストを送信
- アクセス・レイヤがリクエストを検証し、ストリーミング・ノードに転送する。
- ストリーミング・ノードが操作をWALストレージに記録し、耐久性を確保する
- データはリアルタイムで処理され、クエリに利用可能になる
- セグメントが容量に達すると、Streaming Nodeは密封されたセグメントへの変換をトリガーする
- データノードがコンパクションを行い、密封されたセグメント上にインデックスを構築し、結果をオブジェクトストレージに格納する。
- クエリノードは新しく構築されたインデックスを読み込み、対応する成長データを置き換える。
次のページ
- メインコンポーネントの詳細な実装を見る
- データ処理のワークフローと最適化戦略について学ぶ
- Milvusの一貫性モデルとトランザクション保証について理解する。