平均レイテンシーが正常なのに、Amazon DynamoDB の最大レイテンシーメトリクスが高くなるのはなぜですか?

解決方法

CloudWatch メトリクス SuccessfulRequestLatency を分析する際には、平均レイテンシーを確認することをお勧めします。最大レイテンシーは、DynamoDB テーブルの全体的なレイテンシーを示すものではなく、その期間に 1 つのリクエストにかかった最大時間が示されます。例えば、DynamoDB テーブルで一度に 100 個のリクエストがある場合、99 個のリクエストに 10 ミリ秒かかり、1 つのリクエストに 100 ミリ秒かかったとしても、最大レイテンシーメトリクスは 100 ミリ秒になります。

DynamoDB は、バックエンドフリートに数千のノードを持つ大規模な分散システムです。そのため、DynamoDB テーブルにはテーブルスペースに複数のパーティションがあり、各パーティションにはバックエンドフリートに複数のコピーがある可能性があります。DynamoDB への API 呼び出しを行うと、DynamoDB サービスエンドポイントは呼び出しを受信し、処理のためにバックエンドノードの 1 つにルーティングします。呼び出しが正常に処理されると、DyanamoDB は結果をクライアントにルーティングします。

ほとんどの場合、API 呼び出しは 1 回の試行で正常に処理され、クライアント側のレイテンシーは小さくなります。しかし、バックエンドノードで以下が発生している場合、最初の試行が失敗することがあります。

• ビジー時期
• フェイルオーバー
• パーティション分割
• 接続の問題

このような場合、最初の試行はサーバー側のタイムアウト (5000 ミリ秒) 以内に失敗します。その後、サーバーは別のノードで API 呼び出しを自動的に再試行します (多くの場合は複数回)。API 呼び出しが正常に処理されると、サーバーは結果をクライアントに返します。これが発生すると、その特定のリクエストのレイテンシーが上昇することがわかります。 そのため、最大レイテンシーメトリクスが大きいことは一般的に懸念の原因にはなりません。DynamoDB サービスが 1 つのノードから一貫して高いレイテンシーを観測する場合、サービスはそのコンポーネントをバックエンドフリートから自動的に削除します。前述のローカライズされた障害がサービス側で発生すると、特定の割合の API 呼び出しでレイテンシーのレベルが上昇することがあります。これは、関連する DynamoDB テーブルの CloudWatch メトリクスの最大 SuccessfulRequestLatency の高レベルに反映されます。このため、ローカライズされた障害によって最大レイテンシーが増加する可能性がありますが、この障害を制御するためのアクションを実行する必要はありません。

ただし、エクスポネンシャルバックオフ再試行で短時間で失敗することにより、アプリケーションが迅速に対応するように設定できます。これは、新しいリクエストが新しいノードにヒットし、結果がより速く得られることを意味します。詳細については、「レイテンシーの影響を受けやすい Amazon DynamoDB アプリケーションの AWS Java SDK HTTP リクエスト設定の調整」を参照してください。

---

関連情報

Amazon DynamoDB テーブルでの高レイテンシーをトラブルシューティングする方法を教えてください。

レイテンシーメトリクスのログ記録