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

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

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

パーセンタイルメトリクス (p99、p90 など) は、レイテンシー分布をよりよく理解するのに役立ちます。例:

  • p50 (中央値) は、ワークロードの一般的なレイテンシーを示します。

  • p90 は、リクエストの 90% がこの値よりも高速であることを示しています。

  • p99 は、リクエストの 1% に影響する最悪の場合のレイテンシーを特定するのに役立ちます。

p50 値が正常で p99 値が高い場合は、リクエストのごく一部に影響する散発的な問題を示している可能性があり、p50 値が一貫して高い場合は、パフォーマンスの低下を示している可能性があります。

注記

カスタムパーセンタイル値 (p99.9 など) を分析するには、CloudWatch メトリクス統計フィールドに目的のパーセンタイル (p99.9 など) を手動で入力できます。これにより、ドロップダウンに表示されるデフォルトのパーセンタイルを超えるレイテンシー分布を評価できます。

レイテンシーメトリクスのバリエーションは、特にパーセンタイルが高い場合、DynamoDB テーブルに保存されているデータの高可用性と耐久性を維持する DynamoDB 主導のバックグラウンドオペレーションや、一時的なインフラストラクチャの問題の結果として発生する可能性があります。

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

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

注記

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

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

  • 接続の再利用: DynamoDB リクエストは、デフォルトで HTTPS に設定されている認証済みセッションを介して行われます。接続を開始するには複数のラウンドトリップが必要で、最初のリクエストのレイテンシーが接続を再利用する後のリクエストよりも長くなります。すでに初期化されている接続でリクエストを行うと、DynamoDB は整合性のある低いレイテンシーを実現できます。新しい接続を確立する際のレイテンシーオーバーヘッドを避けるために、他のリクエストが行われていない場合は 30 秒ごとに GetItem リクエストを送信することで、「キープアライブ」メカニズムを実装できます。

  • 結果整合性のある読み込みを使用する:アプリケーションで強い整合性のある読み取りが必要ない場合は、デフォルトの結果整合性のある読み込みを使用することを検討してください。結果整合性のある読み込みはコストが低く、複数のアベイラビリティーゾーンから取得できるため、リクエスタに近接するアベイラビリティーゾーンを選択でき、レイテンシーが短縮されます。詳細については、「DynamoDB の読み取り整合性」を参照してください。

  • リクエストヘッジを実装する: p99 レイテンシー要件が非常に低い場合は、リクエストヘッジを実装することを検討してください。リクエストヘッジでは、最初のリクエストが十分な速さでレスポンスを受信しない場合は、2 番目の同等のリクエストを送信して競合させます。最初のレスポンスが優先されます。こうすることで、追加リクエストによりテールレイテンシーを向上させることができます。2 番目のリクエストを送信するまでの待機時間を決定できます。読み取りでは、ヘッジがより簡単になります。書き込みの場合は、タイムスタンプベースの順序付けを使用して、ヘッジされたリクエストが最初のリクエストのタイミングで取り扱われるようにし、誤った順序での処理を防ぎます。このアプローチについては、「Timestamp writes for write hedging in Amazon DynamoDB」を参照してください。

  • リクエストのタイムアウトと再試行動作の調整: クライアントから DynamoDB へのパスは多くのコンポーネントを通過しますが、それぞれが冗長性を念頭に置いて設計されています。以下の要素を検討します。

    • ネットワークの耐障害性

    • TCP パケットタイムアウト

    • DynamoDB の分散アーキテクチャ

    デフォルトの SDK 動作は、ほとんどのアプリケーションに最適化されています。ただし、フェイルファスト戦略を実装し、タイムアウト設定を調整することはできます。通常よりも大幅に時間がかかるリクエストは、最終的に成功する可能性が低くなります。フェイルファストして再試行することで、別のパスですぐに成功する可能性があります。これはリクエストヘッジに似ていますが、続行せずに最初のリクエストを終了します。

    低すぎるタイムアウト値の設定を避けます。タイムアウトが低すぎると、クライアントが誘発する可用性の問題が発生する可能性があります。例えば、50 ミリ秒のソケットタイムアウトは、シングルフロートラフィックの Amazon EC2 インスタンス帯域幅制限に近づく場合など、ネットワークレイテンシーの急増中に接続エラーを引き起こす可能性があります。タイムアウトを短くすることの利点をアプリケーションの可用性に対する潜在的なリスクと慎重に比較検討し、短いタイムアウトよりもヘッジを優先します。

    このトピックに関する役立つ説明は、「レイテンシーを考慮した Amazon DynamoDB アプリケーションのための AWS Java SDK HTTP リクエスト設定のチューニング」に記載されています。

  • クライアントと DynamoDB エンドポイント間の距離を縮める:ユーザーが世界中に分散している場合は、グローバルテーブル - マルチアクティブ、マルチリージョンレプリケーション を使用することを検討してください。グローバルテーブルを使用すれば、そのテーブルを利用できるように指定した AWS リージョンにテーブルをレプリケートできます。データのコピーをエンドユーザーの近くに配置して、読み込みと書き込みのオペレーション中のネットワークレイテンシーを短縮できます。DynamoDB グローバルテーブルを効果的に使用する方法の詳細については、「AWS 規範ガイダンス」の「Amazon DynamoDB グローバルテーブルの使用」を参照してください。

  • キャッシュを使用する: トラフィックの読み取り量が多い場合は、以下のいずれかのキャッシュサービスの使用を検討してください。

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

    • Amazon ElastiCache: フルマネージドのインメモリキャッシュサービス。DynamoDB と統合して、キャッシュアサイドパターンを使用して読み取りパフォーマンスを向上させることができます。詳細については、「AWS 規範ガイダンス」の「リードスルーキャッシュを使用した Amazon DynamoDB と Amazon ElastiCache の統合」を参照してください。