Amazon DynamoDB のプロビジョンドテーブルがスロットルされるのはなぜですか?

所要時間1分

Amazon DynamoDB のプロビジョンドテーブルで読み取りまたは書き込み操作がスロットルされます。または、DynamoDB のプロビジョンドテーブルで読み取りまたは書き込み操作を実行すると、次のエラーが表示されます。「ProvisionedThroughputExceededException.」

簡単な説明

DynamoDB のプロビジョンドテーブルでスロットリングに直面する可能性のある一般的なシナリオは次のとおりです。

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

解決策

注: スロットリングイベント中に監視する必要がある WriteThrottleEvents や ReadThrottleEvents など、DynamoDB メトリクスの詳細については、「DynamoDB のメトリクスとディメンション」を参照してください。

ユースケースに基づいて、次のタスクを実行します。

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

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

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

注: 1 秒あたりの消費キャパシティがプロビジョンドキャパシティを超過しても、DynamoDB はテーブルのスロットリングを開始しません。バーストキャパシティ機能を使用すると、DynamoDB は後で発生するスループットのバーストに備えて未使用キャパシティの一部を予約し、使用量の急増に対処します。詳細については、「プロビジョンドキャパシティモード」と「Amazon DynamoDB はスパイクな負荷を短い間隔でどのように処理しますか?」を参照してください

DynamoDB の AWS Application Auto Scaling を有効にしたが、DynamoDB テーブルがスロットルされている

AWS Application Auto Scaling は、DynamoDB テーブルのトラフィックが突然急増した場合に適切に対処できるソリューションではありません。Application Auto Scaling は、消費キャパシティーユニットの 2 つの連続したデータポイントが設定された使用率値を 1 分以内に超えると、スケールアップを開始します。Application Auto Scaling は、消費キャパシティがターゲット使用率を上回る状態が 2 分間継続した場合にのみ、プロビジョンドキャパシティを自動的にスケールします。

消費キャパシティについて CloudWatch の 15 個連続したデータポイントでターゲット使用率を下回ると、スケールダウンイベントが開始されます。Application Auto Scaling が開始されると、UpdateTable API コールが呼び出されます。API コールで DynamoDB テーブルまたはインデックスのプロビジョンドキャパシティを更新するのに数分かかる可能性があります。Application Auto Scaling では、DynamoDB テーブルのプロビジョンドキャパシティをスケールアップするために、ターゲット使用率の値がより高くなっているデータポイントが連続している必要があります。この間、テーブルのプロビジョンドキャパシティを超えるリクエストはすべてスロットルされます。Application Auto Scaling を使用して DynamoDB の急増するワークロードを処理することはベストプラクティスではありません。代わりに、オンデマンドモードに切り替えてください。詳細については、「DynamoDB Auto Scaling によるスループットキャパシティの自動管理」を参照してください。

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

DynamoDB で、カーディナリティが高くないパーティションキーでは、少数のパーティションだけを対象とするリクエストが多数発生する可能性があります。このようなイベントは、ホットパーティションが発生する原因となります。ホットパーティションでは、1 秒あたり 3000 RCU および 1000 WCU (または両方の組み合わせ) というパーティション制限を超えると、スロットリングが発生する可能性があります。

テーブルで最もアクセス数が多く、スロットルされている項目を見つけるには、Amazon CloudWatch Contributor Insights を使用してください。Amazon CloudWatch Contributor Insights は、DynamoDB テーブルのトラフィック傾向の概要を提示する診断ツールです。このツールを使用すると、最も頻繁にアクセスされるパーティションキーを特定し、テーブルの項目アクセスパターンのグラフを継続的にモニタリングできます。

ホットパーティションは、テーブルの全体的なパフォーマンスを低下させる可能性があります。このようなパフォーマンス低下を回避するには、テーブル全体にわたり読み取り操作と書き込み操作を可能な限り均等に分散してください。詳細については、「パーティションキーを設計してワークロードを分散する」と「Choosing the right DynamoDB partition key」を参照してください。

また、ホットキーに書き込みシャーディングを実装してカーディナリティを高め、ホットキーが複数のパーティションにまたがることを可能にすることもできます。詳細については、「書き込みシャーディングを使用してワークロードを均等に分散する」を参照してください。エクスポネンシャルバックオフを使用して、スロットルされたリクエストを再試行してください。AWS SDK を使用する場合、このロジックはデフォルトで実装されます。詳細については、「エラーの再試行とエクスポネンシャルバックオフ」を参照してください。

高トラフィックが予想される場合は、プロビジョンドキャパシティを高い値に増やすことがベストプラクティスです。プロビジョンドキャパシティが増えると、バックエンドのパーティションの数も増えます。

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

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

テーブルレベルの読み取りスループットとテーブルレベルの書き込みスループットのクォータは、AWS リージョンのアカウントレベルで適用されます。これらのクォータは、プロビジョンドキャパシティモードとオンデマンドキャパシティーモードの両方のテーブルに適用されます。デフォルトでは、テーブルに設定されるスループットクォータは、40,000 読み取りリクエストユニットと 40,000 書き込みリクエストユニットです。テーブルへのトラフィックがこのクォータを超えると、テーブルがスロットルされる可能性があります。

この問題を解決するには、Service Quotas コンソールを使用して、アカウントのテーブルレベルの読み取りまたは書き込みスループットのクォータを増やします。