メインコンテンツまでスキップ

グローバルクラスターへの接続

この機能は、Business Critical(SaaS)および BYOC デプロイメントでのみ利用できます。

この機能は、サポートされているすべての AWS リージョンで利用できます。また、リクエストに応じて Google Cloud の us-central1 および us-east4 リージョンでも利用できます。この機能は Microsoft Azure では利用できません。

グローバルクラスターが実行されたら、エンドポイントと認証トークンを使用して接続します。このページでは、2 種類のエンドポイント、それぞれの使用場面、およびスイッチオーバーとフェイルオーバー時のルーティングの動作について説明します。

エンドポイントタイプの選択​

グローバルクラスターには、次の 2 つの接続方法があります。

  • グローバルエンドポイント経由

  • グローバルクラスター内のプライマリクラスターまたはセカンダリクラスターの パブリックエンドポイントまたはプライベートエンドポイント経由

次の表は、2 つの接続エンドポイントを比較したものです。

グローバルエンドポイントプライマリクラスターまたはセカンダリクラスターのエンドポイント
書き込みルーティングプライマリクラスターに自動的にルーティングされますプライマリのパブリックエンドポイントのみが書き込みを受け付けます
読み取りルーティングプライマリクラスターにルーティングされます
(レイテンシーに基づいて利用可能な最も近いクラスターへインテリジェントにルーティングする機能は近日中にサポートされる予定です。)
読み取りは、接続先の特定のクラスターに送信されます
スイッチオーバー / フェイルオーバー自動的に再ルーティングされます — コードの変更は不要です新しいプライマリを指すように接続を更新する必要があります
Private Linkサポートされません(パブリックインターネットが必要です)サポートされています。
最適な用途自動フェイルオーバーとレイテンシーベースのルーティングを必要とする本番アプリケーション特定のクラスターへの直接アクセス(例:環境の複製、テスト、デバッグ)
Notes

本番ワークロードには、グローバルエンドポイントの使用を推奨します。これにより、スイッチオーバーまたはフェイルオーバー時に、アプリケーションコードでエンドポイントの変更に対応する必要がなくなります。

エンドポイントとトークンの取得​

1

グローバルクラスターまたはターゲットクラスターに移動します。

  • グローバルエンドポイント の場合:グローバルクラスター ページに移動します。

  • パブリックエンドポイント の場合:特定のプライマリクラスターまたはセカンダリクラスターの クラスター詳細 ページに移動します。

2

Connect カードで、Global Endpoint または Public Endpoint をコピーします。

OPCTbMaYIoUXHKxDf0ycdMNBnze

3

認証トークンを準備します。これは API キー または クラスター資格情報(username:password)のいずれかです。

グローバルエンドポイントを使用した接続​

グローバルエンドポイントは、常にグローバルクラスター内の現在のプライマリクラスターにリクエストをルーティングする単一の URL です。

スイッチオーバーまたはフェイルオーバーが発生すると、Zilliz Cloud はグローバルエンドポイントを自動的に更新して新しいプライマリクラスターを指すようにします。これにより、アプリケーションはクラスター URI を手動で変更することなく、同じエンドポイントを引き続き使用できます。

Zilliz Cloud は、SDK と RESTful API の両方を通じてグローバルエンドポイントへの接続をサポートしています。本番アプリケーションには、SDK クライアントの使用を推奨します。

SDK 接続が RESTful API 接続よりも推奨されるのはなぜですか?

SDK クライアントは、エンドポイント一覧、プライマリとセカンダリのロール、クラスターの健全性など、グローバルクラスターのトポロジーを取得できます。この情報により、SDK クライアントはプライマリクラスターが変更されたときに、より迅速に対応できます。SDK クライアントは将来、read/write 分割もサポートする予定です。これは、書き込みリクエストをプライマリクラスターにルーティングし、対象となる読み取りリクエストをグローバルクラスターのトポロジーに基づいてルーティングするものです。

ただし、RESTful API 接続はグローバルクラスターのトポロジー情報を保持しません。そのため、スイッチオーバーまたはフェイルオーバー後に、RESTful API 接続が新しいプライマリクラスターへ切り替わるまでに時間がかかる場合があります。同じ理由で、RESTful API 接続は read/write 分割をサポートできません。

次の表は、SDK 接続と RESTful API 接続を比較したものです。

項目SDK 接続RESTful API 接続
最適な用途ロール変更時の迅速な復旧と将来の read/write 分割を必要とする本番アプリケーション。軽量なスクリプト、シンプルな REST 統合、単発の管理操作。
トポロジーの認識エンドポイント一覧、プライマリとセカンダリのロール、クラスターの健全性など、グローバルクラスターのトポロジーを取得します。グローバルクラスターのトポロジー情報を保持しません。
プライマリ変更時の対応スイッチオーバーまたはフェイルオーバー後にプライマリクラスターが変更されたとき、通常は数秒以内と、より迅速に対応できます。クライアントがトポロジー情報を保持しないため、新しいプライマリへの切り替えに通常は数分と、より長い時間がかかる場合があります。
read/write 分割 近日中にサポートされる予定です。 サポートされていません

SDK バージョンの確認​

開始する前に、SDK を インストール 済みであること、および SDK が最小バージョン要件を満たしていることを確認してください。

SDK最小バージョン
Python2.6.9
Java2.6.14

接続ガイド​

python
from pymilvus import MilvusClient

# Use the global endpoint for automatic routing
client = MilvusClient(
uri="YOUR_GLOBAL_ENDPOINT", # Global endpoint from the console
token="YOUR_CLUSTER_TOKEN" # API key or username:password
)

パブリックエンドポイントを使用した接続​

グローバルクラスター内の各クラスターには、独自のパブリックエンドポイントがあります。特定のクラスターを直接対象とする必要がある場合に使用します。

python
from pymilvus import MilvusClient

# Connect directly to a specific cluster
client = MilvusClient(
uri="YOUR_CLUSTER_PUBLIC_ENDPOINT", # Public endpoint of a specific cluster
token="YOUR_CLUSTER_TOKEN" # API key or username:password
)
Notes

パブリックエンドポイントを使用する場合、書き込み操作を受け付けるのはプライマリクラスターのパブリックエンドポイントのみです。セカンダリクラスターのパブリックエンドポイントへの書き込みは失敗します。

ルーティングの動作​

通常運用時​

リクエストタイプグローバルエンドポイントパブリックエンドポイント
書き込み(insert、upsert、delete)プライマリクラスターにルーティングされますプライマリクラスターのエンドポイントでのみ受け付けられます
読み取り(search、query)プライマリクラスターにルーティングされます
(レイテンシーに基づいて利用可能な最も近いクラスターへインテリジェントにルーティングする機能は近日中にサポートされる予定です。)
接続先の特定のクラスターによって処理されます

スイッチオーバー / フェイルオーバー中および後​

シナリオグローバルエンドポイントパブリックエンドポイント
スイッチオーバー進行中書き込みは一時的に中断され、その後、新しいプライマリで再開されます。読み取りは継続されます。エンドポイントに変更はありません。旧プライマリはセカンダリになります。
フェイルオーバー進行中新しいプライマリが昇格するまで書き込みは利用できません。読み取りはセカンダリで継続されます。旧プライマリのエンドポイントに到達できなくなります。
完了後新しいプライマリに自動的にルーティングされます。コードの変更は不要です。書き込みには新しいプライマリのパブリックエンドポイントを使用するようにコードを更新します。

SDK の自動再接続​

グローバルエンドポイントを使用する場合、Zilliz Cloud SDK がスイッチオーバーとフェイルオーバー時のエンドポイントの再ルーティングを処理します。アプリケーションは、ルーティング変更自体に対する再試行ロジックを実装する必要はありません。ただし、切り替えの瞬間に実行中だった書き込みは一時的なエラーを受け取る可能性があります — そのような場合は、アプリケーションの標準的な再試行ロジックが処理します。