複数リージョン環境での Azure Cosmos DB SDK の可用性の診断とトラブルシューティング

  • [アーティクル]

適用対象: NoSQL

この記事では、特定のリージョンに対する接続の問題が発生した場合、またはリージョンのフェールオーバーが発生した場合の最新バージョンの Azure Cosmos DB SDK の動作について説明します。

すべての Azure Cosmos DB SDK には、リージョンの優先設定をカスタマイズするオプションがあります。 次のプロパティは、さまざまな SDK で使用されます。

リージョンの基本設定を指定する構成で SDK が初期化されると、まず使用可能なリージョンを含むアカウント情報がグローバル エンドポイントから取得されます。 その後、構成されたリージョンの基本設定とアカウントの利用可能なリージョンの交差部分が適用され、リージョンの優先順位の順序を使用して結果に優先順位が付けられます。

リージョンの基本設定構成に、アカウントで使用可能なリージョンではないリージョンが含まれている場合、値は無視されます。 これらの無効なリージョンが後でアカウントに追加された場合、基本設定構成でそれらの方が上位の場合は、それらが SDK によって使用されます。

アカウントの種類 読み取り 書き込み
単一の書き込みリージョン 順位が最も高い優先リージョン プライマリ リージョン
複数の書き込みリージョン 順位が最も高い優先リージョン 順位が最も高い優先リージョン

優先リージョンを設定しない場合、SDK クライアントは既定でプライマリ リージョンになります。

アカウントの種類 読み取り 書き込み
単一の書き込みリージョン プライマリ リージョン プライマリ リージョン
複数の書き込みリージョン プライマリ リージョン プライマリ リージョン

Note

プライマリ リージョンとは、Azure Cosmos DB アカウントのリージョン一覧にある最初のリージョンを指します。 リージョンの優先設定として指定された値が既存のどの Azure リージョンとも一致しない場合、それらは無視されます。 それらが既存のリージョンと一致していても、アカウントがそれにレプリケートされていない場合、クライアントは、一致する次の優先リージョンまたはプライマリ リージョンに接続します。

警告

このドキュメントで説明されているフェールオーバーと可用性ロジックは、クライアント構成で無効にできますが、これは、ユーザー アプリケーションで可用性エラー自体が処理される場合を除き、推奨されません。 これは、次のようにして実現できます。

通常の状況下では、SDK クライアントは優先リージョン (リージョンの優先設定が設定されている場合) またはプライマリ リージョン (優先設定が設定されていない場合) に接続され、以下のいずれかのシナリオが発生しない限り、操作はそのリージョンに限定されます。

これらの場合、Azure Cosmos DB SDK を使用するクライアントではログが公開され、操作の診断情報の一部として再試行情報が含まれます。

  • .NET V2 SDK の応答の RequestDiagnosticsString プロパティ。
  • .NET V3 SDK の応答と例外の Diagnostics プロパティ。
  • Java V4 SDK の応答と例外の getDiagnostics() メソッド。

優先順位において次のリージョンを決定する際、SDK クライアントではアカウント リージョンの一覧が使用され、優先リージョン (存在する場合) が優先されます。

これらのイベント中の SLA 保証に関する包括的な詳細については、「可用性に関する SLA」を参照してください。

アカウントからのリージョンの削除

Azure Cosmos DB アカウントからリージョンを削除すると、アカウントをアクティブに使用している SDK クライアントでは、バックエンドの応答コードを介してリージョンの削除が検出されます。 次に、クライアントによってリージョンのエンドポイントは使用不可とマークされます。 クライアントによって現在の操作が再試行され、以降のすべての操作は優先順に次のリージョンに永続的にルーティングされます。 優先設定一覧にエントリが 1 つしかなかった (または空だった) が、アカウントに他の使用可能なリージョンがある場合は、アカウント一覧内の次のリージョンにルーティングされます。

アカウントへのリージョンの追加

Azure Cosmos DB SDK クライアントでは、5 分ごとにアカウント構成が読み取られ、認識しているリージョンが更新されます。

リージョンを削除して後でアカウントに追加し直した場合、SDK 構成のリージョンの優先順位において、追加したリージョンの方が現在接続されているリージョンより高いと、SDK はそのリージョンを永続的に使用するように切り替わります。 追加されたリージョンが検出された後、それ以降のすべての要求はそのリージョンに送信されます。

できれば Azure Cosmos DB アカウントにないリージョンに接続するようにクライアントを構成した場合、優先リージョンは無視されます。 後でそのリージョンを追加すると、クライアントはそれを検出し、そのリージョンに永続的に切り替わります。

単一書き込みリージョン アカウントで書き込みリージョンをフェールオーバーする

現在の書き込みリージョンのフェールオーバーを開始すると、次の書き込み要求は既知のバックエンド応答で失敗します。 この応答が検出されると、クライアントは、アカウントに対してクエリを実行して新しい書き込みリージョンを学習し、続いて現在の操作を再試行し、以降のすべての書き込み操作を永続的に新しいリージョンにルーティングします。

リージョンの停止

アカウントが単一書き込みリージョンであり、書き込み操作中にリージョンの停止が発生した場合、動作は手動フェールオーバーと同様です。 読み取り要求または複数書き込みリージョン アカウントの場合、動作はリージョンの削除と同様です。

セッションの整合性の保証

セッションの整合性を使用する場合、クライアントでは、自身の書き込みを読み取ることができるように保証する必要があります。 読み取りリージョンの優先設定が書き込みリージョンとは異なる単一書き込みリージョン アカウントでは、ユーザーが書き込みを発行してローカル リージョンから読み取りを行うときに、そのローカル リージョンではデータのレプリケーションをまだ受け取っていません (光の速度の制約)。 このような場合、SDK が読み取り操作の特定の失敗をサービスから受け取り、セッションの整合性を確保するために、SDK によってプライマリ リージョンに対する読み取りが再試行されます。 複数の書き込みリージョンを持つアカウントの場合、同じセッション セマンティクスが適用されますが、使用可能な書き込みリージョンが複数あるため、優先リージョンの一覧またはアカウントのリージョンの順序を使用して再試行が発行されます。

TCP プロトコルでの一時的な接続の問題

Azure Cosmos DB SDK クライアントが TCP プロトコルを使用するように構成されているシナリオでは、特定の要求に対して、ネットワークの状態が特定のエンドポイントとの通信に一時的に影響を与える場合があります。 このような一時的なネットワーク状態は、TCP タイムアウトおよびサービス利用不可 (HTTP 503) エラーとして表面化する可能性があります。 クライアントは、可能な場合、数秒間同じエンドポイントに対して要求をローカルで再試行します。

ユーザーが複数のリージョンで優先リージョン リストを構成し、クライアントがローカルの再試行をすべて使い果たした場合は、優先設定一覧の次のリージョンでその 1 つの操作を再試行できます。 書き込み操作は Azure Cosmos DB アカウントで複数の書き込みリージョンが有効になっている場合にのみ他のリージョンで再試行できますが、読み取り操作は使用可能な任意のリージョンで再試行できます。

次の手順