Amazon DynamoDB テーブルへの読み取りまたは書き込み操作がスロットルされ、アプリケーションでエラーが発生します。ただし、Amazon CloudWatch は、消費したキャパシティーユニットがプロビジョニングされたキャパシティーユニットを超えていないことを示しています。なぜこれが発生したのでしょうか?どうすれば修正できるでしょうか? 

パーティションは、ダウンストリームのアプリケーションが他のパーティションよりも頻繁にアクセスする場合 (つまり、「ホット」なパーティション)、またはワークロードが短期間に高使用率になる場合 (読み取りまたは書き込み アクティビティの「バースト」) にスロットルされます。

パーティションがホットになり、スロットリングが発生するのを避けるには、DynamoDB のベストプラクティスにあるベストプラクティス戦略に従ってテーブルおよびパーティション構造を最適化する必要があります。

以下のソリューションのひとつ、または複数を検討してください。

  • 読取りまたは書込みの操作で短期間のスパイクやバーストが発生することが予想されるテーブルの読取りまたは書込みのキャパシティーを増やす。後で追加キャパシティーを必要としないと判断した場合は、減らす。
    注意: どれだけ読み書きのキャパシティーを増やすかを決定する前に、Designing Partition Keys to Distribute Your Workload Evenly のベストプラクティスを検討します。
  • エラーの再試行とエクスポネンシャルパックオフを実装する。この手法では、アプリケーションの信頼性を向上させるために、連続するエラー応答に対して再試行の間隔を徐々に長くしていきます。AWS SDK を使用している場合、このロジックは組み込まれています。 そうでなければ、手動で実装することを検討します。
  • 読み取り操作と書き込み操作を可能な限りテーブル全体に均等に分配する。 「ホット」なパーティションがあると、テーブルの全体的なパフォーマンスを低下させる可能性があります。
  • DynamoDB Accelerator (DAX) または Amazon ElastiCache などのキャッシングのソリューションを実装する。 DAX は、アプリケーションに高速なメモリ内パフォーマンスを提供する DynamoDB 対応のキャッシングサービスです。ワークロードが主に静的データへの読み取りアクセスであるなら、データベースよりもうまく設計されたキャッシュからの方が、クエリ結果がより迅速に処理されることが多くなります。

適応型キャパシティーは、5 〜 30 分で有効になり、短期間のワークロードの不均衡の問題を緩和するのに役立ちます。ただし、各パーティションには引き続き、書き込みで 1,000 のキャパシティーユニット、読み込みで 3,000 のキャパシティーユニットというハードリミットがあるため、適応型キャパシティーではテーブルまたはパーティションの設計における大きな問題は解決できません。


このページは役に立ちましたか? はい | いいえ

AWS サポートナリッジセンターに戻る

サポートが必要ですか?AWS サポートセンターをご覧ください。

公開日: 2016 年 8 月 17 日

更新: 2018 年 05 月 29 日