次の方法で共有

Azure Cosmos DB と .NET のパフォーマンスに関するヒント

適用対象: NoSQL

Azure Cosmos DB は、高速で柔軟性に優れた分散データベースです。待ち時間とスループット レベルが保証されており、シームレスにスケーリングできます。 Azure Cosmos DB でデータベースをスケーリングするために、アーキテクチャを大きく変更したり、複雑なコードを記述したりする必要はありません。 スケールアップとスケールダウンは、API 呼び出しを 1 回行うだけの簡単なものです。 詳細については、コンテナーのスループットのプロビジョニングまたはデータベースのスループットのプロビジョニングに関するページを参照してください。

Azure Cosmos DB にはネットワーク呼び出しによってアクセスするため、SQL .NET SDK を使うと、最高のパフォーマンスを実現するためにクライアント側の最適化を行うことができます。

データベースのパフォーマンスを向上させる場合は、次のセクションで示すオプションを検討してください。

ホスティングの推奨事項

サーバー側のガベージ コレクションを有効にする

ガベージコレクションの頻度を減らすことで役立つ場合もあります。 .NET では、gcServer を true に設定します。

クライアント ワークロードをスケールアウトする

高スループット レベルでテストしたり、1 秒あたりの要求ユニット数 (RU/秒) が 50,000 を超えるレートでテストしたりすると、クライアント アプリケーションがワークロードのボトルネックになる可能性があります。 この原因として、マシンの CPU またはネットワークの使用率に上限が設定されている可能性があります。 この状態に達しても、クライアント アプリケーションを複数のサーバーにスケールアウトすることで引き続き同じ Azure Cosmos DB アカウントで対応できます。

注意

CPU 使用率が高い場合、待機時間が長くなり、タイムアウト例外が要求される可能性があります。

メタデータ操作

ホット パス内や項目の操作前に、Create...IfNotExistsAsync や Read...Async を呼び出して、データベースやコンテナーが存在することを検証しないでください。 検証は、削除されていることが予想される場合に、必要に応じてアプリケーションの起動時にのみ行う必要があります (それ以外は不要です)。 これらのメタデータ操作では、追加のエンドツーエンドの待機時間が発生し、SLA はなく、データ操作のようにスケーリングしない独自の独立した制限があります。

ログとトレース

一部の環境では、.NET DefaultTraceListener が有効になっています。 DefaultTraceListener は、運用環境でのパフォーマンス上の問題を引き起こし、高い CPU 使用率や I/O のボトルネックが発生します。 調査して、運用環境では TraceListeners から DefaultTraceListener を削除することで、DefaultTraceListener がアプリケーションに対して無効になっているようにしてください。

最新の SDK バージョン (3.23.0 以上) では、これが検出されると自動的に削除されます。より古いバージョンを使用している場合は、以下によってこれを削除できます。

if (!Debugger.IsAttached)
{
    Type defaultTrace = Type.GetType("Microsoft.Azure.Cosmos.Core.Trace.DefaultTrace,Microsoft.Azure.Cosmos.Direct");
    TraceSource traceSource = (TraceSource)defaultTrace.GetProperty("TraceSource").GetValue(null);
    traceSource.Listeners.Remove("Default");
    // Add your own trace listeners
}

高可用性

Azure Cosmos DB での高可用性の構成に関する一般的なガイダンスについては、Azure Cosmos DB での高可用性に関する記事をご覧ください。

データベース プラットフォームでの適切な基本的なセットアップに加えて、.NET SDK 自体に実装できる特定の手法があり、停止シナリオに役立ちます。 2 つの重要な戦略は、しきい値ベースの可用性戦略とパーティション レベルのサーキット ブレーカーです。

しきい値ベースの可用性戦略

しきい値ベースの可用性戦略では、並列読み取り要求をセカンダリ リージョンに送信し ( ApplicationPreferredRegionsで定義されている) 最速の応答を受け入れることで、末尾の待機時間と可用性を向上させることができます。 このアプローチを使うと、アプリケーションのパフォーマンスに対するリージョンの障害や高遅延状態の影響を大幅に軽減できます。

構成例:

これを構成するには、 CosmosClientBuilderを使用します。

CosmosClient client = new CosmosClientBuilder("connection string")
    .WithApplicationPreferredRegions(
        new List<string> { "East US", "East US 2", "West US" } )
    .WithAvailabilityStrategy(
        AvailabilityStrategy.CrossRegionHedgingStrategy(
        threshold: TimeSpan.FromMilliseconds(500),
        thresholdStep: TimeSpan.FromMilliseconds(100)
     ))
    .Build();

または、オプションを構成して CosmosClientに追加します。

CosmosClientOptions options = new CosmosClientOptions()
{
    AvailabilityStrategy
     = AvailabilityStrategy.CrossRegionHedgingStrategy(
        threshold: TimeSpan.FromMilliseconds(500),
        thresholdStep: TimeSpan.FromMilliseconds(100)
     )
      ApplicationPreferredRegions = new List<string>() { "East US", "East US 2", "West US"},
};

CosmosClient client = new CosmosClient(
    accountEndpoint: "account endpoint",
    authKeyOrResourceToken: "auth key or resource token",
    clientOptions: options);

しくみ:

  1. 初期要求: 時刻 T1 に、プライマリ リージョン (米国東部など) に対して読み取り要求が行われます。 SDK は、最大 500 ミリ秒 (threshold の値) まで応答を待ちます。

  2. 2 回目の要求: 500 ミリ秒以内にプライマリ リージョンから応答がない場合、次の優先リージョン (たとえば、米国東部 2) に並列要求が送信されます。

  3. 3 回目の要求: プライマリとセカンダリどちらのリージョンも 600 ミリ秒 (500 ミリ秒 + 100 ミリ秒、thresholdStep の値) 以内に応答しない場合、SDK は別の並列要求を 3 番目の優先リージョン (米国西部など) に送信します。

  4. 最速応答の採用: 最初に応答するのがどのリージョンであっても、その応答が受け入れられて、他の並列要求は無視されます。

注意

1 番目の優先リージョンから一時的なものではないエラー状態コード (ドキュメントが見つからない、認可エラー、競合など) が返された場合、操作自体がフェイル ファストするので、可用性戦略にはこのシナリオでのメリットはありません。

パーティション レベルのサーキット ブレーカー

パーティション レベルのサーキット ブレーカー (PPCB) は、異常な物理パーティションを追跡することで可用性と待機時間を向上させる .NET SDK の機能です。 有効にすると、より健全なリージョンに要求をルーティングし、リージョンまたはパーティション固有の問題による連鎖的なエラーを防ぐことができます。 この機能は、バックエンドによってトリガーされるフェールオーバーとは無関係であり、環境変数によって制御されます。

この機能は 既定では無効になっていますが、パーティション レベルのフェールオーバーが有効になっている場合は 自動的に 有効になります。

動作方法

  1. エラー検出:503 Service Unavailable、408 Request Timeout、キャンセル トークンなどの特定のエラーが検出されると、SDK はパーティションの連続するエラーをカウントします。
  2. フェールオーバーのトリガー: 構成された連続するエラーのしきい値に達すると、SDK は、 GlobalPartitionEndpointManagerCore.TryMarkEndpointUnavailableForPartitionKeyRangeを使用して、そのパーティション キー範囲の要求を次の優先リージョンにリダイレクトします。
  3. バックグラウンド回復: フェールオーバー中にバックグラウンド タスクが開始され、4 つのレプリカすべてに接続しようとして、失敗したパーティションの正常性が定期的に再評価されます。 正常になると、SDK によってオーバーライドが削除され、プライマリ リージョンに戻ります。

アカウントの種類別の動作

  • 単一リージョンの書き込み (単一マスター):読み取り要求のみが PPCB フェールオーバー ロジックに参加します。
  • マルチリージョン書き込み (マルチマスター):読み取り要求と書き込み要求の両方で PPCB フェールオーバー ロジックが使用されます。

構成オプション

PPCB を構成するには、次の環境変数を使用します。

環境変数 説明 既定値
AZURE_COSMOS_CIRCUIT_BREAKER_ENABLED PPCB 機能を有効または無効にします。 false
AZURE_COSMOS_PPCB_CONSECUTIVE_FAILURE_COUNT_FOR_READS フェールオーバーをトリガーするための連続した読み取りエラー。 10
AZURE_COSMOS_PPCB_CONSECUTIVE_FAILURE_COUNT_FOR_WRITES フェールオーバーをトリガーするための連続する書き込みエラー。 5
AZURE_COSMOS_PPCB_ALLOWED_PARTITION_UNAVAILABILITY_DURATION_IN_SECONDS パーティションの正常性を再評価するまでの時間。 5 秒
AZURE_COSMOS_PPCB_STALE_PARTITION_UNAVAILABILITY_REFRESH_INTERVAL_IN_SECONDS パーティションの正常性をバックグラウンドで更新する間隔。 60 秒

注意

SDK には現在、読み取り用の信頼性の高いフェールバック トリガーがありません。 代わりに、バックグラウンド正常性チェッカーは、4 つのレプリカすべてが応答しているときに、元のリージョンの再有効化を徐々に試みます。

可用性の最適化の比較

  • しきい値ベースの可用性戦略:

    • 利点: セカンダリ リージョンに並列読み取り要求を送信することで末尾の待機時間を短縮し、ネットワーク タイムアウトになる要求を割り込むことで可用性を向上させます。
    • トレードオフ: 並列リージョン間要求が増えるので (しきい値を超えた期間だけですが)、サーキット ブレーカーと比べて余分な RU (要求ユニット) コストが発生します。
    • ユース ケース: 待ち時間の短縮が重要であり、ある程度の追加コスト (RU 料金とクライアントの CPU 負荷の両方) が許容される、読み取り量の多いワークロードに最適です。 また、非べき等書き込み再試行ポリシーにオプトインし、アカウントに複数リージョンの書き込みがある場合は、書き込み操作にもメリットがあります。

  • パーティション レベルのサーキット ブレーカー:

    • 利点: 異常なパーティションを回避し、要求をより正常なリージョンにルーティングするので、可用性と待ち時間が向上します。
    • トレードオフ: RU コストが増えることはありませんが、ネットワーク タイムアウトが発生する要求の初期可用性の損失が引き続き発生する可能性があります。
    • ユース ケース: 一貫したパフォーマンスが不可欠な、書き込み量の多いワークロードや混合ワークロードに最適です (特に、断続的に異常になる可能性があるパーティションを扱う場合)。

両方の戦略を併用して、読み取りと書き込みの可用性を高め、完了までの待ち時間を短縮できます。 パーティション レベルのサーキット ブレーカーを使うと、並列要求を実行する必要なしに、レプリカのパフォーマンスが低下する可能性があるシナリオなど、さまざまな一時的障害シナリオを処理できます。 さらに、RU コストが増えてもかまわない場合は、しきい値ベースの可用性戦略を追加すると、完了までの待ち時間がいっそう短くなり、可用性が失われなくなります。

これらの戦略を実装すると、開発者はアプリケーションの回復性を確保し、ハイ パフォーマンスを維持し、リージョンで停止や高遅延の状況が発生しても優れたユーザー エクスペリエンスを提供できます。

ネットワーク

接続ポリシー:直接接続モードを使用する

.NET V3 SDK の TCP プロトコルとの既定の接続モードは直接です。 CosmosClient で CosmosClientOptions インスタンスを作成するときに、接続モードを構成します。 さまざまな接続オプションについては、接続モードに関する記事を参照してください。

CosmosClient client = new CosmosClient(
  "<nosql-account-endpoint>",
  tokenCredential
  new CosmosClientOptions
  {
      ConnectionMode = ConnectionMode.Gateway // ConnectionMode.Direct is the default
  }
);

一時的なポートの不足

インスタンスで接続量が多いか、ポートの使用率が高い場合は、まず、クライアント インスタンスがシングルトンであることを確認します。 言い換えると、クライアント インスタンスは、アプリケーションの有効期間にわたって一意である必要があります。

クライアントが TCP プロトコル上で実行されている場合は、有効期間が長い接続を使用して待ち時間が最適化されます。 これは、非アクティブ状態が 2 分間続くと接続を終了する HTTPS プロトコルとは対照的です。

アクセス頻度が低く、ゲートウェイ モード アクセスと比べて接続数が多い場合は、次のことが可能です。

  • CosmosClientOptions.PortReuseMode プロパティを PrivatePortPool に構成します (フレームワーク バージョン 4.6.1 以降および .NET Core バージョン 2.0 以降で有効)。 このプロパティにより、SDK はさまざまな Azure Cosmos DB の宛先エンドポイントに対して一時的なポートの小さなプールを使用できます。
  • CosmosClientOptions.IdleTcpConnectionTimeout プロパティを 10 分以上に構成します。 推奨値は 20 分～ 24 時間です。

パフォーマンスを確保するために同じ Azure リージョン内にクライアントを併置する

可能であれば、Azure Cosmos DB を呼び出すアプリケーションを Azure Cosmos DB データベースと同じリージョンに配置します。 大ざっぱな比較ですが、Azure Cosmos DB の呼び出しは、同じリージョン内であれば 1 から 2 ミリ秒 (ms) 以内で終了するのに対し、米国西部と米国東部との間では待ち時間が 50 ミリ秒を超えます。 要求がクライアントから Azure データセンターの境界まで流れるときに使用されるルートに応じて、この待機時間が要求ごとに異なる可能性があります。

最短の待ち時間は、プロビジョニングされた Azure Cosmos DB エンドポイントと同じ Azure リージョン内に呼び出し元アプリケーションを配置することによって実現できます。 利用可能なリージョンの一覧については、「Azure リージョン」をご覧ください。

クライアントを同じリージョンに併置する

スレッドまたはタスクの数を増やす

Azure Cosmos DB の呼び出しはネットワーク経由で行われるため、クライアント アプリケーションで要求間の待ち時間を最短にするために、要求のコンカレンシーの次数を変えることが必要な場合があります。 たとえば、.NET の タスク並列ライブラリを使用する場合、Azure Cosmos DB に対する読み取りタスクまたは書き込みタスクを 100 件単位で作成してください。

高速ネットワークを有効にして待機時間と CPU ジッターを削減する

パフォーマンスを最大限に高めるために、手順に従って Windows (クリックして手順を参照) または Linux (クリックして手順を参照) Azure VM で高速ネットワークを有効にすることをお勧めします。

高速ネットワークを使用しない場合、Azure VM と他の Azure リソース間を通過する IO は、VM とそのネットワーク カードの間にあるホストと仮想スイッチを介して不必要にルーティングされる可能性があります。 データパスにインラインでホストと仮想スイッチがあると、通信チャネルで待機時間とジッターが増加するだけでなく、VM から CPU サイクルが奪われます。 高速ネットワークを使用すると、VM は中継なしで NIC と直接やり取りします。ホストと仮想スイッチによって処理されていたネットワーク ポリシーの詳細は、NIC のハードウェアで処理されるようになり、ホストと仮想スイッチはバイパスされます。 通常、高速ネットワークを有効にすると、待機時間の短縮とスループットの向上だけでなく、より "一貫した" 待機時間と CPU 使用率の削減が期待できます。

制限事項: 高速ネットワークは、VM の OS でサポートされている必要があり、VM が停止され、割り当てが解除されている場合にのみ有効にすることができます。 Azure Resource Manager を使用して VM をデプロイすることはできません。 App Service では高速ネットワークが有効になっていません。

詳細については、Windows および Linux の手順を参照してください。

SDK の使用

最新の SDK をインストールする

Azure Cosmos DB SDK は、最適なパフォーマンスを提供するために頻繁に改善されています。 最新の SDK を確認し、改善点をレビューするには、Azure Cosmos DB SDK を参照してください。

ストリーム API を使用する

.NET SDK V3 には、シリアル化せずにデータを受信して返すことができるストリーム API シリーズが含まれています。

SDK からの応答を直接使用せずに他のアプリケーション層にリレーする中間層アプリケーションでは、ストリーム API を利用するメリットがあります。 ストリーム処理の例については、項目管理のサンプルを参照してください。

アプリケーションの有効期間中はシングルトン Azure Cosmos DB クライアントを使用する

各 CosmosClient インスタンスはスレッドセーフであり、直接モードで動作しているときには効率的な接続管理とアドレスのキャッシュが実行されます。 効率的な接続管理と SDK クライアントのパフォーマンス向上を実現するために、アプリケーションの有効期間中、アプリケーションが対話する各アカウントについて、AppDomain ごとの単一のインスタンスを使用することをお勧めします。

複数のアカウントを処理するマルチテナント アプリケーションについては、関連するベスト プラクティスを参照してください。

Azure Functions で作業する場合、インスタンスは既存のガイドラインにも従って、1 つのインスタンスを維持する必要があります。

ブロックキング呼び出しを避ける

Azure Cosmos DB SDK では、多くの要求を同時に処理できるように設計する必要があります。 非同期 API では、ブロッキング呼び出しが実行されるのを待たないことによって、小さなスレッド プールでも数千の要求を同時に処理できます。 各スレッドで、時間のかかる同期的なタスクの処理が完了するのを待たずに、別の要求を処理します。

Azure Cosmos DB SDK を使用するアプリでよくあるパフォーマンスの問題は、ブロッキング呼び出しが非同期の可能性があることです。 多くの同期的なブロッキング呼び出しを行うと、スレッド プールの枯渇や応答時間の増加が起こります。

してはいけないこと:

  • Task.Wait や Task.Result を呼び出して非同期処理を妨げる。
  • Task.Run を使用して同期 API を非同期にする。
  • 共通のコードのパスでロックを取得する。 Azure Cosmos DB .NET SDK では、コードを並列実行するよう設計すると、パフォーマンスが最もよくなります。
  • Task.Run を呼び出して直ちに await を使用する。 既に ASP.NET Core で通常のスレッド プールのスレッドを使用してアプリのコードを実行しているため、Task.Run を呼び出しても、スレッド プールに対する無駄なスケジューリングを行うだけです。 Task.Run では、スケジュールされたコードによってスレッドがブロックされることも防げません。
  • Container.GetItemLinqQueryable<T>() に ToList() を使用し、ブロッキング呼び出しでクエリを同期的に drain しない。 ToFeedIterator() を使用して、クエリを非同期でドレインしてください。

すべきこと:

  • Azure Cosmos DB .NET API を非同期で呼び出します。
  • コール スタック全体を非同期にして、async/await の組み合わせを有効活用する。

PerfView などのプロファイラーを使用すれば、スレッド プールに頻繁に追加されるスレッドを把握できます。 Microsoft-Windows-DotNETRuntime/ThreadPoolWorkerThread/Start イベントは、スレッド プールにスレッドを追加したことを示します。

書き込み操作に対するコンテンツ応答を無効にする

高負荷の作成ペイロードがあるワークロードでは、EnableContentResponseOnWrite 要求オプションを false に設定します。 サービスは、作成または更新されたリソースを SDK に返さなくなります。 通常、アプリケーションには作成済みのオブジェクトがあるため、サービスから返される必要はありません。 ヘッダー値には、まだ要求の料金と同様にアクセスできます。 応答コンテンツを無効にすると、SDK がメモリを割り当てたり応答の本文をシリアル化したりする必要がなくなるため、パフォーマンスを向上させることができます。 また、ネットワーク帯域幅の使用量も削減され、パフォーマンスがさらに向上します。

ItemRequestOptions requestOptions = new ItemRequestOptions() { EnableContentResponseOnWrite = false };
ItemResponse<Book> itemResponse = await this.container.CreateItemAsync<Book>(book, new PartitionKey(book.pk), requestOptions);
// Resource will be null
itemResponse.Resource

待ち時間ではなくスループットを最適化するために一括処理を有効にする

ワークロードが大量のスループットを必要とし、待ち時間はそれほど重要ではないシナリオでは、一括処理を有効にします。 一括処理機能を有効にする方法と、その機能を使用する必要があるシナリオの詳細については、一括処理の概要に関するページを参照してください。

ゲートウェイ モードを使用するときにホストあたりの System.Net MaxConnections を増やす

ゲートウェイ モードを使用すると、Azure Cosmos DB の要求は HTTPS/REST を介して行われます。 それらは、ホスト名または IP アドレスごとの既定の接続数の上限に従います。 場合によっては、Azure Cosmos DB に対する複数の同時接続をクライアント ライブラリで使用できるよう、MaxConnections を高い値 (100 ～ 1,000) に増やす必要があります。 .NET SDK 1.8.0 以降では、ServicePointManager.DefaultConnectionLimit の既定値は 50 です。 値を変更するには、Documents.Client.ConnectionPolicy.MaxConnectionLimit を高い値に設定します。

スレッドまたはタスクの数を増やす

この記事の「ネットワーク」セクションの「スレッドまたはタスクの数を増やす」を参照してください。

クエリ操作

クエリ操作については、クエリ パフォーマンスのヒントに関するページを参照してください。

インデックス作成ポリシー

インデックス作成から未使用のパスを除外して書き込みを高速化する

Azure Cosmos DB のインデックス作成ポリシーでは、インデックス作成パス (IndexingPolicy.IncludedPaths および IndexingPolicy.ExcludedPaths) を使用して、インデックス作成に含めたり除外したりするドキュメント パスも指定できます。

必要なパスだけでインデックスを作成すると、クエリのパターンが事前にわかっている場合に、書き込みパフォーマンスの向上、書き込み操作に対する RU 料金の削減、およびインデックス ストレージの削減が可能になります。 これは、インデックス作成コストは、インデックスが作成される一意のパスの数に直接関係するためです。 たとえば、次のコードは、ワイルドカード "*" を使用して、ドキュメントのセクション全体 (サブツリー) をインデックス作成から除外する方法を示しています。

var containerProperties = new ContainerProperties(id: "excludedPathCollection", partitionKeyPath: "/pk" );
containerProperties.IndexingPolicy.IncludedPaths.Add(new IncludedPath { Path = "/*" });
containerProperties.IndexingPolicy.ExcludedPaths.Add(new ExcludedPath { Path = "/nonIndexedContent/*");
Container container = await this.cosmosDatabase.CreateContainerAsync(containerProperties);

詳細については、Azure Cosmos DB インデックス作成ポリシーに関するページをご覧ください。

スループット

RU/秒の使用量を測定して最適化する

Azure Cosmos DB には、データベース操作の豊富なセットが用意されています。 これらの操作には、ユーザー定義関数 (UDF)、ストアド プロシージャ、トリガーを含むリレーショナル クエリと階層クエリが含まれます。これらはすべて、データベース コレクション内のドキュメントで動作します。

これらの操作のそれぞれに関連付けられたコストは、操作を完了するために必要な CPU、IO、およびメモリに応じて異なります。 ハードウェア リソースの検討や管理をする代わりに、要求ユニットをさまざまなデータベース操作の実行やアプリケーション要求の処理に必要なリソースの 1 つのメジャーとして考えることができます。

コンテナーごとに設定された要求ユニットの数に基づいて、スループットをプロビジョニングします。 要求単位の消費は 1 秒あたりのレートとして評価されます。 コンテナーのプロビジョニング済み要求ユニット レートを超過したアプリケーションは、レートがそのコンテナーにプロビジョニングされているレベルを下回るまで制限されます。 アプリケーションでより高いスループットが必要になった場合は、追加の要求ユニットをプロビジョニングしてスループットを増やすことができます。

クエリの複雑さは、操作で消費される要求ユニット数に影響します。 述語の数、述語の特性、UDF ファイルの数、ソース データ セットのサイズのすべてがクエリ操作のコストに影響します。

操作 (作成、更新、または削除) のオーバーヘッドを測定するには、x-ms-request-charge ヘッダー (あるいは、.NET SDK の RequestCharge または ResourceResponse<T> の同等の FeedResponse<T> プロパティ) を調べて、これらの操作で使用される要求ユニット数を測定します。

// Measure the performance (Request Units) of writes
ItemResponse<Book> response = await container.CreateItemAsync<Book>(myBook, new PartitionKey(myBook.PkValue));
Console.WriteLine("Insert of item consumed {0} request units", response.RequestCharge);
// Measure the performance (Request Units) of queries
FeedIterator<Book> queryable = container.GetItemQueryIterator<ToDoActivity>(queryString);
while (queryable.HasMoreResults)
    {
        FeedResponse<Book> queryResponse = await queryable.ExecuteNextAsync<Book>();
        Console.WriteLine("Query batch consumed {0} request units", queryResponse.RequestCharge);
    }

このヘッダーで返されるリクエスト チャージは、プロビジョニングされたスループット (2,000 RU/秒) の一部です。 たとえば、上記のクエリが 1 KB のドキュメントを 1000 個返した場合、この操作のコストは 1000 になります。 そのため、後続の要求をレート制限する前に、サーバーは 1 秒以内にこのような要求を 2 つだけ受け付けます。 詳細については、要求ユニットに関する記事および要求ユニット計算ツールのページを参照してください。

レート制限と大きすぎる要求レートに対処する

クライアントがアカウントの予約済みスループットを超えようとしても、サーバーでパフォーマンスの低下が発生することはなく、予約済みのレベルを超えてスループット容量が使用されることもありません。 サーバーは、RequestRateTooLarge (HTTP 状態コード 429) を使用して要求をプリエンプティブに終了します。 それからは、要求を再試行する前にユーザーが待機する必要がある時間 (ミリ秒単位) を示す、x-ms-retry-after-ms ヘッダーが返されます。

    HTTP Status 429,
    Status Line: RequestRateTooLarge
    x-ms-retry-after-ms :100

SDK はすべてこの応答を暗黙的にキャッチし、サーバーが指定した retry-after ヘッダーを優先して要求を再試行します。 アカウントに複数のクライアントが同時アクセスしている状況でなければ、次回の再試行は成功します。

累積的に動作する複数のクライアントがあり、要求レートを常に超えている場合は、現在クライアントによって内部的に 9 に設定される既定の再試行回数では、十分ではない可能性があります。 アプリケーションに対して、クライアントはステータスコード429のCosmosExceptionをスローします。

RetryOptions インスタンスで CosmosClientOptions を設定することにより、既定の再試行回数を変更できます。 既定では、要求レートを超えて要求が続行されている場合に、30 秒の累積待ち時間を過ぎると、状態コードが 429 の CosmosException が返されます。 このエラーは、現在の値が既定値の 9 かユーザー定義の値かにかかわらず、現在の再試行回数が最大再試行回数より少ない場合でも返されます。

自動再試行動作は、ほとんどのアプリケーションで回復性と使いやすさを向上させるのに役立ちます。 ただし、パフォーマンス ベンチマークを実行しているときは (特に待機時間を測定するとき)、最適な動作ではない可能性があります。 実験でサーバーが負荷制限に達してクライアント SDK が通知なしに再試行すると、クライアントが観測する待機時間が急増します。 パフォーマンスの実験中に待ち時間が急増するのを回避するには、各操作で返される使用量を測定し、予約済みの要求レートを下回った状態で要求が行われていることを確認します。

詳細については、要求ユニットに関する記事を参照してください。

スループットを向上させるためにサイズの小さいドキュメントに合わせて設計する

特定の操作の要求の使用量 (要求処理コスト) は、ドキュメントのサイズに直接関係します。 サイズの大きいドキュメントの操作は、サイズの小さいドキュメントの操作よりもコストがかかります。

次のステップ

少数のクライアント コンピューターでの高パフォーマンス シナリオで Azure Cosmos DB の評価に使用されるサンプル アプリケーションについては、「Azure Cosmos DB のパフォーマンスとスケールのテスト」を参照してください。

スケーリングと高パフォーマンスのためのアプリケーションの設計について詳しくは、「Azure Cosmos DB でのパーティション分割とスケーリング」をご覧ください。