Azure Cosmos DB SQL SDK の接続モード

  • [アーティクル]

適用対象: NoSQL

クライアントが Azure Cosmos DB に接続する方法は、特に監視対象となるクライアント側の待機時間について、パフォーマンスに重要な影響を及ぼします。 Azure Cosmos DB では、ゲートウェイ モードと呼ばれる HTTPS を介したシンプルなオープン RESTful プログラミング モデルが提供されます。 さらに、直接モードと呼ばれる効率的な TCP プロトコルも提供されます。これは、通信モデルでは RESTful でもあり、初期認証とトラフィックの暗号化に TLS が使用されます。

使用可能な接続モード

使用可能な 2 つの接続モードは、次のとおりです。

  • ゲートウェイ モード

    ゲートウェイ モードは、すべての SDK プラットフォームでサポートされています。 ゲートウェイ モードでは標準の HTTPS ポートと単一の DNS エンドポイントが使用されるため、ファイアウォールの厳しい制限がある企業ネットワーク内でアプリケーションを実行する場合は、ゲートウェイ モードが最適な選択肢となります。 ただし、パフォーマンスのトレードオフとして、ゲートウェイ モードでは、Azure Cosmos DB に対してデータの読み取りまたは書き込みを行うたびに、追加のネットワーク ホップが必要になります。 ソケット接続の数に制限がある環境でアプリケーションを実行する場合、ゲートウェイ接続モードも推奨されます。

    Azure Functions (特に従量課金プラン) で SDK を使用する場合は、現在の接続数の制限に注意してください。

  • 直接モード

    直接モードでは、初期認証とトラフィックの暗号化に TLS を使用した TCP プロトコルによる接続がサポートされ、ネットワーク ホップが少ないためパフォーマンスが向上します。 アプリケーションからバックエンド レプリカに直接接続されます。 現在、直接モードは .NET と Java SDK プラットフォームでのみサポートされています。

Azure Cosmos DB の接続モード

基本的に、これらの接続モードでは、データ プレーン要求 (ドキュメントの読み取りと書き込み) がクライアント マシンから Azure Cosmos DB バックエンドのパーティションに到達するまでのルートを調整します。 直接モードは、最高のパフォーマンスを得るための推奨オプションです。クライアントは、Azure Cosmos DB バックエンドのパーティションへの TCP 接続を直接開き、中継なしで要求を "直接" 送信できます。 これに対して、ゲートウェイ モードでは、クライアントからの要求は Azure Cosmos DB フロントエンドのいわゆる "ゲートウェイ" サーバーにルーティングされ、そこから Azure Cosmos DB バックエンドの適切なパーティションに送信されます。

サービス ポート 範囲

直接モードを使用する場合は、Azure Cosmos DB で動的 TCP ポートが使用されるため、クライアントが 10000 から 20000 の範囲のポートにアクセスできるようにする必要があります。 これは、ゲートウェイ ポートに加えて、必要なものです。 プライベート エンドポイントで直接モードを使用する場合は、TCP ポートの全範囲である 0 から 65535 が Azure Cosmos DB によって使用される場合があります。 クライアントでこれらのポートが開いていない場合に TCP プロトコルを使用しようとすると、[503 サービスを利用できません] エラーが受信される可能性があります。

次の表は、さまざまな API で使用できる接続モードと、各 API で使用されるサービス ポートの概要を示しています。

接続モード サポートされるプロトコル サポートされる SDK API/サービス ポート
Gateway HTTPS すべての SDK SQL (443)、MongoDB (10255)、Table (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 上でローカルにキャッシュされます。そのため、以降の操作でこの情報を利用できます。 既に確立されている TCP 接続も、操作間で再利用されます。 SDK オプションを使用して特に構成されていない限り、接続は SDK インスタンスの有効期間中、完全に維持されます。

分散アーキテクチャと同様に、レプリカを保持しているマシンはアップグレードまたはメンテナンスを受ける可能性があります。 このサービスにより、レプリカ セットの整合性が維持されますが、レプリカの移動によって既存の TCP アドレスが変更されます。 このような場合、SDK はルーティング情報を更新し、新しいゲートウェイ要求を介して新しいアドレスに再接続する必要があります。 これらのイベントが、P99 SLA 全体に影響しないようにする必要があります。

接続の量

各物理パーティションには、4 つのレプリカから成るレプリカ セットがあります。可能な限り最高のパフォーマンスを実現するために、SDK は、書き込み操作と読み取り操作を混在させるワークロードに対してすべてのレプリカとの接続を開くことになります。 同時操作は、各レプリカが提供するスループットを利用するために、既存の接続間で負荷分散されます。

SDK が開く TCP 接続の数を決定する要因は 2 つあります。

  • 物理パーティションの数

    安定状態では、SDK には、物理パーティションごとにレプリカ当たり 1 つの接続があります。 コンテナー内の物理パーティションの数が多いほど、開いている接続の数が多くなります。 操作が別々のパーティションにルーティングされると、オンデマンドで接続が確立されます。 接続の平均数は、物理パーティションの数を 4 倍した数になります。

  • 同時要求の量

    確立された各接続は、構成可能な数の同時操作に対応できます。 同時操作の量がこのしきい値を超えると、対応するために新しい接続が開きます。物理パーティションの場合、開いている接続の数が安定状態の数を超える可能性があります。 この動作は、操作の量が急増する可能性があるワークロードに対して想定されます。 .NET SDK の場合、この構成は CosmosClientOptions.MaxRequestsPerTcpConnection によって設定され、Java SDK の場合は、DirectConnectionConfig.setMaxRequestsPerConnection を使用してカスタマイズできます。

既定では、将来の操作のパフォーマンスに役立つように接続は完全に維持されます (接続を開くと、計算オーバーヘッドが発生します)。 将来の操作に若干影響を与える可能性があることを理解して、しばらく使用されていない接続を閉じる必要がある場合があります。 .NET SDK の場合、この構成は CosmosClientOptions.IdleTcpConnectionTimeout によって設定され、Java SDK の場合は、DirectConnectionConfig.setIdleConnectionTimeout を使用してカスタマイズできます。 接続が頻繁に閉じられ、全体的なパフォーマンスに影響を与える可能性があるため、これらの構成を低い値に設定することはお勧めできません。

言語固有の実装の詳細

言語に関する実装の詳細については、次を参照してください。

次の手順

特定の SDK プラットフォーム パフォーマンスを最適化する場合: