Amazon DynamoDB でのレイテンシーの問題のトラブルシューティング - Amazon DynamoDB

Amazon DynamoDB でのレイテンシーの問題のトラブルシューティング

ワークロードのレイテンシーが高いと思われる場合は、CloudWatch SuccessfulRequestLatency メトリクスを分析し、平均レイテンシーをチェックして、それが DynamoDB に関連しているかどうかを確認できます。報告された SuccessfulRequestLatency にある程度のばらつきがあるのは正常であり、時折 (特に Maximum 統計) 急上昇が起きても心配する必要はありません。ただし、Average 統計が急激に増加し続けている場合は、AWS Service Health Dashboard と Personal Health Dashboard で詳細を確認する必要があります。考えられる原因としては、テーブル内の項目のサイズ (1 KB の項目と 400 KB の項目ではレーテンシーが異なります) やクエリのサイズ (10 項目と 100 項目) などがあります。

必要に応じて、AWS Support でサポートケースを作成することを検討し、作成したランブックに従って、アプリケーションで使用可能なフォールバックオプション (マルチリージョンアーキテクチャの場合はリージョンの退避など) を引き続き評価してください。リクエストが遅い場合は、サポートケースを開くときに AWS Supportに提示できるようにリクエスト ID を記録しておく必要があります。

SuccessfulRequestLatency メトリックスは DynamoDB サービス内部のレイテンシーのみを測定し、クライアント側のアクティビティとネットワークトリップ時間は含まれません。クライアントから DynamoDB サービスへの呼び出しの全体的なレイテンシーについて詳しく知るには、AWS SDK でレイテンシーメトリックスロギングを有効にできます。

注記

ほとんどのシングルトンオペレーション (プライマリキーの値を完全に指定することで 1 つの項目に適用されるオペレーション) では、DynamoDB は 1 桁のミリ秒単位の Average SuccessfulRequestLatency を返します。この値には、DynamoDB エンドポイントにアクセスする呼び出し側コードのトランスポートオーバーヘッドは含まれていません。複数項目のデータオペレーションの場合、レーテンシーは結果セットのサイズ、返されるデータ構造の複雑さ、適用される条件式やフィルター式などの要因によって異なります。同じパラメータで同じデータセットに対して複数項目のオペレーションを繰り返す場合、DynamoDB は一貫した高い Average SuccessfulRequestLatency を提供します。

レイテンシーを減らすには、次の戦略を 1 つ以上検討してください。

  • リクエストのタイムアウトと再試行動作の調整:クライアントから DynamoDB へのパスは多くのコンポーネントを通過しますが、それぞれが冗長性を念頭に置いて設計されています。ネットワークの回復力の範囲、TCP パケットタイムアウト、DynamoDB 自体の分散アーキテクチャについて考えてみてください。デフォルトの SDK の動作は、ほとんどのアプリケーションに対して適切なバランスを取るように設計されています。最善のレイテンシーを最優先する場合は、SDK のデフォルトのリクエストタイムアウトと再試行設定を調整し、クライアントで測定されたリクエストの成功までの一般的なレイテンシーに合わせることを検討してください。通常よりも大幅に時間がかかるリクエストは、最終的に成功する可能性が低くなります。フェイルファストしてから新しいリクエストを行うと、別のパスを使用してすぐに成功する可能性があります。これらの設定を積極的に使用し過ぎると、マイナス面がある場合があることにも注意してください。このトピックに関する役立つ説明は、「レイテンシーを考慮した Amazon DynamoDB アプリケーションのための AWS Java SDK HTTP リクエスト設定のチューニング」に記載されています。

  • クライアントと DynamoDB エンドポイント間の距離を縮める:ユーザーが世界中に分散している場合は、グローバルテーブル – DynamoDB の複数リージョンレプリケーション を使用することを検討してください。グローバルテーブルを使用では、そのテーブルを利用できるようにする AWS リージョンを指定できます。ローカルのグローバルテーブルレプリカからデータを読み込むと、ユーザーのレーテンシーを大幅に減らすことができます。また、DynamoDB ゲートウェイエンドポイントを使用して、クライアントトラフィックを VPC 内に留ることも検討してください。

  • キャッシュを使用する:トラフィックの読み取り量が多い場合は、DynamoDB Accelerator (DAX) とインメモリアクセラレーション などのキャッシュサービスの使用を検討してください。DAX は、フルマネージド型で可用性の高い、DynamoDB 用のインメモリキャッシュです。1 秒あたりのリクエスト数が数百万におよぶ場合であっても、最大 10 倍のパフォーマンスの (ミリセカンドからマイクロセカンドの範囲への) 向上を実現します。

  • 接続の再利用:DynamoDB リクエストは、デフォルトで HTTPS に設定されている認証済みセッションを介して行われます。接続の開始には時間がかかるため、最初のリクエストのレーテンシーは通常よりも長くなります。すでに初期化されている接続でリクエストを行うと、DynamoDB は整合性のある低いレイテンシーを実現できます。このため、新しい接続を確立するまでのレーテンシーを避けるために、他にリクエストが行われない場合は 30 秒ごとに「キープアライブ」GetItem リクエストを行うことをお勧めします。

  • 結果整合性のある読み込みを使用する:アプリケーションで強い整合性のある読み取りが必要ない場合は、デフォルトの結果整合性のある読み込みを使用することを検討してください。結果整合性のある読み込みを行うと、コストが低くなり、レイテンシーが一時的に増加する可能性も低くなります。詳細については、「DynamoDB の読み取り整合性」を参照してください。