Amazon DynamoDB テーブルがスロットルされるのはなぜですか?

簡単な説明

直面する可能性のある一般的なスロットリングの問題の一部を次に示します：

• DynamoDB テーブルには十分なプロビジョンドキャパシティーがありますが、ほとんどのリクエストはスロットルされています。
• DynamoDB の AWS Application Auto Scaling を有効にしましたが、DynamoDB テーブルがスロットルされています。
• DynamoDB テーブルはオンデマンドのキャパシティーモードですが、テーブルはスロットルされています。
• テーブルにはホットパーティションがあります。
• テーブルのトラフィックがアカウントのスループットクォータを超えています。

解決方法

スロットリングイベント中にモニタリングする必要がある DynamoDB メトリクスの詳細については、「DynamoDB メトリクスとディメンション」を参照してください。これらのメトリクスは、スロットルされたリクエストを作成するオペレーションを特定し、スロットルの原因を特定するのに役立ちます。ユースケースに基づいて、次のトラブルシューティングオプションを 1 つ以上お使いください。

DynamoDB テーブルには十分なプロビジョンドキャパシティーがありますが、ほとんどのリクエストはスロットルされています

DynamoDB は分レベルのメトリクスを Amazon CloudWatch にレポートします。メトリクスは、1 分間の合計として計算され、次に平均化されます。ただし、DynamoDB のレート制限は 1 秒単位で適用されます。例えば、DynamoDB テーブルに 60 の書き込みキャパシティーユニットをプロビジョニングした場合、1 分で 3600 回の書き込みを実行できます。ただし、1 秒で 3600 個のリクエストをすべて実行し、残りの時間はリクエストがないと、スロットリングが発生する可能性があります。1 分あたりの読み取りキャパシティーユニットまたは書き込みキャパシティーユニットの合計数は、テーブルのプロビジョニングされたスループットより少ない場合があります。ただし、すべてのワークロードが数秒以内に収まると、リクエストがスロットルされる可能性があります。

この問題を解決するには、テーブルにトラフィックを処理するのに十分な容量があることを確認し、エクスポネンシャルバックオフを使用してスロットルされたリクエストを再試行します。AWS SDK を使用している場合、このロジックはデフォルトで実装されます。詳細については、AWS でのエラー再試行とエクスポネンシャルバックオフをご参照ください。

**注:**DynamoDB は、1 秒あたりに消費された容量がプロビジョニングされた容量を超えると、必ずしもテーブルのスロットリングを開始しません。バーストキャパシティー機能では、DynamoDB は、使用量の急増を処理するために、後のスループットのバーストのために未使用の容量の一部を予約します。

AWS Application Auto Scaling を有効にしましたが、テーブルはまだスロットルされています

AWS Application Auto Scaling は、DynamoDB テーブルでのトラフィックの突然のスパイクに対処するための適切なソリューションではありません。Application Auto Scalingは、消費されたキャパシティーユニットの 2 つの連続するデータポイントが、1 分以内に設定されたターゲット使用率値を超えた場合にのみスケールアップを開始します。Application Auto Scaling は、消費されたキャパシティーがターゲットの使用率よりも高い状態が 2 分間継続した場合にのみ、プロビジョンドキャパシティーを自動的にスケーリングします。また、CloudWatch で消費されたキャパシティーの 15 個の連続するデータポイントが目標使用率を下回ると、スケールダウンイベントが開始されます。Application Auto Scaling が開始されると、UpdateTable API コールが呼び出されます。この呼び出しは、DynamoDB テーブルまたはインデックスのプロビジョンドキャパシティーを更新するのに数分かかる場合があります。Application Auto Scaling では、DynamoDB テーブルのプロビジョンドキャパシティーをスケールアップするために、より高いターゲット使用率の値を持つ連続したデータポイントが必要です。この期間中、テーブルのプロビジョンドキャパシティーを超えるリクエストはスロットルされます。したがって、Application Auto Scaling を使用して DynamoDB でスパイクのあるワークロードを処理することはベストプラクティスではなく、そのユースケースではオンデマンドモードに切り替えることを検討してください。詳細については、「DynamoDB Auto Scaling によるスループットキャパシティーの自動管理」を参照してください。

テーブルがオンデマンドキャパシティーモードを使用しているが、テーブルはまだスロットルされている

テーブルがオンデマンドキャパシティーモードを使用している場合、次の条件が当てはまる限り、テーブルはスロットルしません。

• アクセスパターンは、ホットパーティションに関連する問題を回避するために、パーティション間で均等に分散されます。
• このテーブルは、以前のピークトラフィックの 2 倍を超えません。

オンデマンドテーブルの場合、DynamoDB はトラフィック量が増加するにつれて自動的に容量を割り当てて、ワークロードにスロットリングが発生しないようにします。ただし、30 分以内にトラフィック量が前のピークの 2 倍を超えると、スロットリングが発生する可能性があります。詳細については、「ピークトラフィックとスケーリングのプロパティ」を参照してください。

テーブルにホットパーティションがある

DynamoDB では、高いカーディナリティを持たないパーティションキーは、少数のパーティションのみをターゲットとする多くのリクエストが発生し、ホットパーティションになる可能性があります。ホットパーティションは、1 秒あたり 3000 RCU または 1000 WCU（または両方の組み合わせ）のパーティション制限を超えると、スロットリングを引き起こす可能性があります。

テーブル内で最もアクセスされ、スロットルされた項目を見つけるには、Amazon CloudWatch Contributor Insights を使用します。Amazon CloudWatch Contributor Insights は、お使いの DynamoDB テーブルのトラフィックトレンドの概要を示し、最も頻繁にアクセスされるパーティションキーを特定するのに役立つ新しい診断用ツールです。このツールを使用すると、テーブルのアイテムアクセスパターンのグラフを継続的にモニタリングできます。ホットパーティションは、テーブルの全体的なパフォーマンスを低下させる可能性があります。このパフォーマンスの低下を回避するには、読み取り操作と書き込み操作をテーブル全体にできるだけ均等に分散します。詳細については、「ワークロードを均等に分散するためのパーティションキーの設計」および「適切な DynamoDB パーティションキーの選択」を参照してください。

注: CloudWatch Contributor Insights ツールを DynamoDB で使用すると、追加料金が発生します。詳細については、「DynamoDB 請求に関する CloudWatch Contributor Insights」を参照してください。

テーブルのトラフィックがアカウントのスループットクォータを超えています

テーブル レベルの読み取りスループットとテーブル レベルの書き込みスループットのクォータは、任意のリージョンのアカウント レベルで適用されます。これらのクォータは、プロビジョニングされたキャパシティモードとオンデマンドキャパシティモードの両方のテーブルに適用されます。デフォルトでは、テーブルに設定されているスループットクォータは 40,000 読み込みリクエストユニットと 40,000 書き込みリクエストユニットです。テーブルへのトラフィックがこのクォータを超えると、テーブルが調整される可能性があります。この問題を解決するには、Service Quotas コンソールを使用して、アカウントのテーブル レベルの読み取りまたは書き込みスループット クォータを増やします。

---

関連情報

書き込みシャーディングを使用してワークロードを均等に分散する