次の方法で共有

Azure Cosmos DB Java v4 SDK の要求タイムアウト例外を診断してトラブルシューティングする

  • [アーティクル]

適用対象: NoSQL

HTTP 408 エラーは、タイムアウト制限が発生する前に SDK が要求を完了できなかった場合に発生します。

トラブルシューティングの手順

次の一覧には、要求タイムアウト例外の既知の原因と解決方法が含まれています。

エンド ツー エンドのタイムアウト ポリシー

以下に示すすべてのプリエンプティブなソリューションが実装されている場合でも、408 のネットワーク タイムアウト エラーが発生するシナリオがあります。 最終的な待機時間を短縮し、これらのシナリオの可用性を向上させる一般的なベスト プラクティスは、エンド ツー エンドのタイムアウト ポリシーを実装することです。 最終的な待機時間はフェイル ファストすると短縮され、要求ユニットとクライアント側のコンピューティング コストは、タイムアウト後に再試行を停止することで削減されます。 タイムアウト期間は CosmosItemRequestOptions で設定できます。 その後、Azure Cosmos DB に送信されるすべての要求にオプションを渡すことができます。

CosmosEndToEndOperationLatencyPolicyConfig endToEndOperationLatencyPolicyConfig = new CosmosEndToEndOperationLatencyPolicyConfigBuilder(Duration.ofSeconds(1)).build();
CosmosItemRequestOptions options = new CosmosItemRequestOptions();
options.setCosmosEndToEndOperationLatencyPolicyConfig(endToEndOperationLatencyPolicyConfig);
container.readItem("id", new PartitionKey("pk"), options, TestObject.class);

既存の問題

要求がより長い期間停止しているか、タイムアウトがより頻繁に発生していると表示されている場合は、Java v4 SDK を最新バージョンにアップグレードしてください。 注: バージョン 4.18.0 以上を使用することを強くお勧めします。 詳細については、Java v4 SDK リリース ノートに関する記事を参照してください。

高い CPU 使用率

高い CPU 使用率は最も一般的なケースです。 最適な待機時間を実現するには、CPU 使用率は 40% ほどである必要があります。 CPU 使用率の (平均ではなく) 最大値を監視するには、間隔として 10 秒を使用します。 CPU スパイクは、1 つのクエリに対して複数の接続を実行する可能性があるクロスパーティション クエリでは、より一般的です。

解答:

SDK を使用するクライアント アプリケーションをスケールアップまたはスケールアウトする必要があります。

接続の帯域幅調整

接続の帯域幅調整は、ホスト マシンの接続制限、または Azure SNAT (PAT) ポート不足のいずれかが原因で発生します。

ホスト マシンの接続制限

一部の Linux システム (Red Hat など) では、開くファイルの最大数に上限があります。 Linux のソケットはファイルとして実装されるため、この数は接続の合計数も制限します。 次のコマンドを実行します。

ulimit -a

解決方法:

開くことができる最大ファイル数 ("nofile" で指定) は、10,000 個以上にする必要があります。 詳細については、Azure Cosmos DB Java SDK v4 のパフォーマンスに関するヒントを参照してください。

ソケットまたはポートの可用性が低下している可能性がある

Azure で実行されている場合、Java SDK を使用しているクライアントで Azure SNAT (PAT) ポートの枯渇が発生する可能性があります。

解決策 1:

Azure VM で実行している場合は、SNAT ポートの枯渇に関するガイドを参照してください。

解決策 2:

Azure App Service で実行している場合は、接続エラーのトラブルシューティングのガイドに従って、App Service の診断を利用してください。

解決策 3:

Azure Functions で実行している場合は、必要なすべてのサービス (Azure Cosmos DB を含む) に対してシングルトンまたは静的クライアントを管理するための Azure Functions の推奨事項に従っていることを確認します。 関数アプリのホスティングの種類とサイズに基づくサービスの制限を確認します。

解決策 4:

HTTP プロキシを使用する場合は、SDK GatewayConnectionConfig で構成されている接続の数をサポートできることを確認します。 そうしないと、接続の問題が発生します。

複数のクライアント インスタンスの作成

複数のクライアント インスタンスを作成すると、接続の競合とタイムアウトの問題を招くおそれがあります。

解決策 1:

パフォーマンスに関するヒントに従って、アプリケーション全体で単一の CosmosClient インスタンスを使用します。

解決策 2:

シングルトン CosmosClient をアプリケーションに含めることができない場合は、CosmosClient のこの API connectionSharingAcrossClientsEnabled(true) を通じて、複数の Azure Cosmos DB クライアントにわたって接続の共有を使用することをお勧めします。 同じ JVM に複数の Azure Cosmos DB アカウントと対話する Azure Cosmos DB Client のインスタンスが複数あるときは、これを有効にすると、Azure Cosmos DB Client のインスタンス間で、実行できる場合に直接モードで接続の共有を実行できます。 このオプションを設定すると、最初にインスタンス化されたクライアントの接続構成 (ソケット タイムアウト構成、アイドル タイムアウト構成など) が、他のすべてのクライアント インスタンスに使用されることに注意してください。

ホット パーティション キー

Azure Cosmos DB は、プロビジョニングされたスループット全体を物理パーティション間で均等に分散します。 ホット パーティションが存在すると、ある物理パーティション上の 1 つ以上の論理パーティション キーによってその物理パーティションのすべての要求ユニット/秒 (RU/秒) が消費されます。 同時に、他の物理パーティション上の RU/秒は未使用のままになります。 症状としては、消費済み RU/秒の合計は、データベースまたはコンテナー上にプロビジョニングされている全体的な RU/秒よりも少なくなりますが、ホット論理パーティション キーに対する要求では、帯域幅調整 (429) が見られます。 正規化された RU 消費量メトリック を使用して、ワークロードでホット パーティションが発生しているかどうかを確認します。

解決方法:

要求のボリュームと記憶域を均等に分散する適切なパーティション キーを選択します。 パーティション キーの変更方法を参照してください。

同時実行の程度が高い

アプリケーションで高レベルの同時実行が行われています。これにより、チャネル上で競合が発生する可能性があります。

解決方法:

SDK を使用するクライアント アプリケーションをスケールアップまたはスケールアウトする必要があります。

大量の要求または応答

要求数や応答数が増大すると、同時実行の程度が比較的低い場合でも、チャネル上でヘッドオブライン ブロッキングが発生し、競合が悪化する可能性があります。

解決方法:

SDK を使用するクライアント アプリケーションをスケールアップまたはスケールアウトする必要があります。

エラー率が Azure Cosmos DB の SLA に収まっている

アプリケーションでは、一時的なエラーの処理と必要に応じた再試行を実行できる必要があります。 パスの作成時にサービスによって項目が作成されたか否かを知ることはできないため、408 例外は再試行されません。 作成のために同じ項目を再度送信すると、競合例外が発生します。 ユーザー アプリケーションのビジネス ロジックに、競合を処理するためのカスタム ロジックが含まれている場合があります。これにより、既存の項目のあいまいさが解消されたり、作成の再試行と競合したりすることがあります。

エラー率が Azure Cosmos DB の SLA に違反している

Azure サポートにお問い合わせください。

次のステップ