クライアントが Azure Cosmos DB に接続する方法には、特にクライアント側の待機時間が観察される場合に、パフォーマンスに重要な影響があります。 Azure Cosmos DB には、 ゲートウェイ モードと呼ばれる HTTPS 経由の単純でオープンな RESTful プログラミング モデルが用意されています。 さらに、効率的な TCP プロトコルを提供します。これは通信モデルでも RESTful であり、 ダイレクト モードと呼ばれる初期認証とトラフィックの暗号化に TLS を使用します。
使用可能な接続モード
次の 2 つの接続モードを使用できます。
ゲートウェイ モード
ゲートウェイ モードは、すべての SDK プラットフォームでサポートされています。 ファイアウォールの制限が厳しい企業ネットワーク内でアプリケーションを実行する場合、ゲートウェイ モードは標準の HTTPS ポートと 1 つの DNS エンドポイントを使用するため、最適な選択肢です。 ただし、パフォーマンスのトレードオフとして、ゲートウェイ モードでは、データが Azure Cosmos DB から読み取られたり、Azure Cosmos DB に書き込まれたりするたびに、追加のネットワーク ホップが必要になります。 また、ソケット接続の数が限られている環境でアプリケーションを実行する場合は、ゲートウェイ接続モードもお勧めします。
Azure Functions (特に 従量課金プラン) で SDK を使用する場合は、接続に関する現在の 制限に注意してください。
ダイレクト モード
ダイレクト モードでは、初期認証とトラフィックの暗号化に TLS を使用した TCP プロトコル経由の接続がサポートされ、ネットワーク ホップが少なくなるため、パフォーマンスが向上します。 アプリケーションはバックエンド レプリカに直接接続します。 ダイレクト モードは現在、.NET および Java SDK プラットフォームでのみサポートされています。
これらの接続モードは、基本的に、データ プレーン要求 (ドキュメントの読み取りと書き込み) がクライアント コンピューターから Azure Cosmos DB バックエンドのパーティションに送信するルートを条件とします。 ダイレクト モードは、最適なパフォーマンスを得るための推奨オプションです。これにより、クライアントは Azure Cosmos DB バックエンドのパーティションへの TCP 接続を直接開き、仲介者なしで 直接要求を送信できます。 一方、ゲートウェイ モードでは、クライアントによって行われた要求は、Azure Cosmos DB フロントエンドのいわゆる ゲートウェイ サーバーにルーティングされ、Azure Cosmos DB バックエンド内の適切なパーティションへの要求がファンアウトされます。
サービス ポートの範囲
ダイレクト モードを使用する場合、Azure Cosmos DB では動的 TCP ポートが使用されるため、クライアントが 10000 ~ 20000 の範囲のポートにアクセスできることを確認する必要があります。 これはゲートウェイ ポートに加えて行われます。 プライベート エンドポイントでダイレクト モードを使用する場合、Azure Cosmos DB では、0 から 65535 までの TCP ポートの全範囲を使用できます。 これらのポートがクライアントで開かれていない場合、TCP プロトコルを使用しようとすると、"503 サービス利用不可" エラーが発生する可能性があります。
次の表は、さまざまな API で使用できる接続モードと、各 API で使用されるサービス ポートの概要を示しています。
| 接続モード | サポートされるプロトコル | サポートされる SDK | API/サービス ポート |
|---|---|---|---|
| Gateway | HTTPS | すべての SDK | SQL (443)、MongoDB (10255)、表 (443)、Cassandra (10350)、Graph (443) |
| 直接 | TCP (TLS 経由で暗号化) | .NET SDK Java SDK | パブリック/サービス エンドポイントを使用する場合: 10000 から 20000 の範囲のポート プライベート エンドポイントを使用する場合: 0 から 65535 の範囲のポート |
直接モード接続アーキテクチャ
概要で詳しく説明したように、ダイレクト モード クライアントは TCP プロトコルを使用してバックエンド ノードに直接接続します。 各バックエンド ノードは、物理パーティションに属するレプリカ セット内のレプリカを表します。
経路選択
直接モードの Azure Cosmos DB SDK が操作を実行するときは、接続先のバックエンド レプリカを解決する必要があります。 最初の手順は、操作を実行する必要がある物理パーティションを把握することです。そのため、SDK はゲートウェイ ノードから パーティション キー定義 を含むコンテナー情報を取得します。 レプリカの TCP アドレスを含むルーティング情報も必要です。 ルーティング情報はゲートウェイ ノードからも入手でき、両方とも コントロール プレーン メタデータと見なされます。 SDK がルーティング情報を取得したら、ターゲット物理パーティションに属するレプリカへの TCP 接続を開き、操作を実行できます。
各レプリカ セットには、1 つのプライマリ レプリカと 3 つのセカンダリが含まれています。 書き込み操作は常にプライマリ レプリカ ノードにルーティングされますが、読み取り操作はプライマリ ノードまたはセカンダリ ノードから処理できます。
コンテナーとルーティングの情報は頻繁に変更されないため、SDK にローカルにキャッシュされるため、後続の操作でこの情報を利用できます。 既に確立されている TCP 接続も、複数の操作で再利用されます。 SDK オプションを使用して特に構成しない限り、接続は SDK インスタンスの有効期間中に永続的に維持されます。
分散アーキテクチャと同様に、レプリカを保持しているマシンはアップグレードまたはメンテナンスを受ける可能性があります。 このサービスにより、レプリカ セットの一貫性が維持されますが、レプリカの移動によって既存の TCP アドレスが変更されます。 このような場合、SDK はルーティング情報を更新し、新しいゲートウェイ要求を介して新しいアドレスに再接続する必要があります。 これらのイベントは、P99 SLA 全体に影響を与えるべきではありません。
接続のボリューム
各物理パーティションには 4 つのレプリカのレプリカ セットがあり、可能な限り最高のパフォーマンスを実現するために、SDK は書き込み操作と読み取り操作を混在させるワークロードのすべてのレプリカへの接続を開きます。 同時実行操作は、各レプリカが提供するスループットを利用するために、既存の接続間で負荷分散されます。
SDK が開く TCP 接続の数を決定する要因は 2 つあります。
物理パーティションの数
安定した状態では、SDK には物理パーティションごとにレプリカごとに 1 つの接続があります。 コンテナー内の物理パーティションの数が多いほど、開いている接続の数が多くなります。 操作が異なるパーティションにルーティングされると、必要に応じて接続が確立されます。 接続の平均数は、物理パーティションの数に 4 を掛けたものになります。
同時リクエストの数
確立された各接続は、構成可能な数の同時操作に対応できます。 同時実行操作の量がこのしきい値を超えると、新しい接続が開いてサービスが提供されます。物理パーティションの場合、開いている接続の数が安定状態の数を超える可能性があります。 この動作は、運用ボリュームが急増する可能性があるワークロードに対して想定されます。 .NET SDK の場合、この構成は MaxRequestsPerTcpConnection によって設定され、Java SDK の場合は DirectConnectionConfig クラスを使用してカスタマイズできます。
既定では、接続は永続的に維持され、将来の操作のパフォーマンスが向上します (接続を開くと計算オーバーヘッドが発生します)。 使用されていない接続をしばらく放置してから閉じることで、今後の操作に若干影響を与える可能性があるというシナリオが考えられます。 .NET SDK の場合、この構成は IdleTcpConnectionTimeout によって設定され、Java SDK の場合は DirectConnectionConfig クラスを使用してカスタマイズできます。 接続が頻繁に閉じられ、全体的なパフォーマンスに影響を与える可能性があるため、これらの構成を低い値に設定することはお勧めしません。
言語固有の実装の詳細
言語に関する実装の詳細については、次を参照してください。
次のステップ
特定の SDK プラットフォームのパフォーマンス最適化の場合:
Azure Cosmos DB への移行のための容量計画を実行しようとしていますか? 容量計画のために、既存のデータベース クラスターに関する情報を使用できます。
- 既存のデータベース クラスター内の仮想コアとサーバーの数がわかっている場合は、 仮想コアまたは仮想 CPU を使用した要求ユニットの見積もりについてお読みください。
- 現在のデータベース ワークロードの標準的な要求レートがわかっている場合は、Azure Cosmos DB Capacity Planner を使用した要求ユニットの見積もりに関するページを参照してください。