Amazon DynamoDB でのスロットリングの問題のトラブルシューティング - Amazon DynamoDB

Amazon DynamoDB でのスロットリングの問題のトラブルシューティング

サービス指向アーキテクチャや分散システムでは、API 呼び出しが各種サービスコンポーネントによって処理される速度を制限することをスロットリングと呼びます。これにより、スパイクをスムーズにし、コンポーネントのスループットの不一致を制御し、予期しない運用上のイベントが発生した場合の回復が予測しやすくなります。DynamoDB はこれらのタイプのアーキテクチャ向けに設計されており、DynamoDB クライアントにはスロットリングされたリクエストに対する再試行が組み込まれています。ある程度のスロットリングはアプリケーションにとって必ずしも問題とはなりませんが、データワークフローのレイテンシーの影響を受けやすい部分を継続的にスロットリングすると、ユーザーエクスペリエンスに悪影響を及ぼし、システム全体の効率を低下させる可能性があります。

DynamoDB テーブルの読み込みまたは書き込みオペレーションがスロットリングされている場合 (またはオペレーションを実行したときに ProvisionedThroughputExceededException が発生している場合)、問題の解決に役立つ次の戦略の使用を検討してください。

プロビジョンドモードテーブルに十分な容量があることを確認する

DynamoDB は、分単位のメトリクスを CloudWatch に報告します。メトリクスは、1 分間の合計として計算され、平均化されます。ただし、DynamoDB のレート制限は 1 秒ごとに適用されます。例えば、テーブルに 60 の書き込みキャパシティーユニットをプロビジョニングした場合、1 分で 3600 の書き込みユニットを実行できますが、1 秒間に 60 を超える書き込みユニットを実行しようとすると、一部のリクエストがスロットリングされる可能性があります。

この問題を解決するには、テーブルにトラフィックを処理するのに十分な容量があることを確認し、エクスポネンシャルバックオフを使用してスロットリングされたリクエストを再試行してください。AWS SDK を使用している場合、このロジックはデフォルトで実装されています。このため、スロットリングが発生しても、コードにエラーが発生することなく、2 回目または 3 回目の再試行で正常に再試行される可能性があります。スロットリングの発生状況を把握するために、各 AWS-SDK フレーバーにはスロットリングを検出する方法があります。例えば、Python では、返された ResponseMetadata.RetryAttempts フィールドの数字を確認します。これがゼロより大きい場合は、スロットリングが発生したことを示します。これを検出した場合の最適な方法は、関連するパーティションキーをログに記録することです。これは、ホットキーパターンの可能性があり、CloudWatch だけでは診断が難しいからです。

また、プロビジョニングされたテーブルで自動スケーリングを使用して、ワークロードに基づいてプロビジョニングされたキャパシティを自動的に調整することも検討してください。また、スケーリングポリシーを更新して最小使用率を上げるか、または目標使用率を下げることを検討してください。この場合、最大設定が低すぎないようにしてください。

オンデマンドモードへの切り替えを検討する

Amazon DynamoDB自動スケーリングは Application Auto Scaling サービスを使用し、実際のトラフィックパターンに応じてプロビジョンドスループットキャパシティをユーザーに代わって動的に調節します。Application Auto Scaling は、消費されたキャパシティユニットの 2 つの連続したデータポイントが、1 分以内に設定された目標使用率値を超えた場合にのみスケールアップを開始します。Application Auto Scaling は、消費されたキャパシティが 2 分間連続して目標使用率を上回った場合にのみ、プロビジョンドキャパシティを自動的にスケーリングします。また、CloudWatch での消費されたキャパシティについて、15 個の連続するデータポイントが目標使用率を下回ると、スケールダウンイベントが開始されます。

Application Auto Scaling が開始されると、UpdateTable API 呼び出しが呼び出され、DynamoDB テーブルまたはインデックスのプロビジョンドキャパシティが更新されます。Application Auto Scaling では、DynamoDB テーブルのプロビジョニングされたキャパシティをスケールアップするために、目標使用率値が高い連続したデータポイントが必要です。この期間中、テーブルのプロビジョンドキャパシティを超えるリクエストはスロットリングされます。そのため、きわめて予測不能な (バースト性の高い) トラフィックパターンには オンデマンドモード の使用を検討してください。詳細については、「DynamoDB Auto Scaling によるスループットキャパシティの自動管理」を参照してください。

読み込みオペレーションと書き込みオペレーションをパーティションキーに均等に分散する

DynamoDB では、低カーディナリティのパーティションキーは、小数のパーティションのみをターゲットとする多くのリクエストが発生し、ホットパーティションになる可能性があります。パーティションの上限である 3000 RCU と 1000 WCU /秒を超えると、ホットパーティションによってスロットリングが発生する可能性があります。

テーブル内で最もアクセス数が多く、スロットリングされた項目を見つけるには、Amazon CloudWatch Contributor Insights を使用してください。Amazon CloudWatch Contributor Insights は、DynamoDB テーブルにおけるトラフィックの傾向を一目で把握できる診断ツールで、最も頻繁にアクセスされるパーティションを特定するのに役立ちます。このツールを使用すると、テーブルの項目のアクセスパターンについてグラフで継続的に監視できます。ホットパーティションは、テーブル全体のパフォーマンスを低下させる可能性があります。このようなパフォーマンスの低下を避けるには、高カーディナリティのキーを選択して、読み込みオペレーションと書き込みオペレーションをできるだけ均等に分散してください。詳細については、「パーティションキーを設計してワークロードを分散する」および「適切な DynamoDB パーティションキーの選択」を参照してください。

注記

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

テーブルレベルの読み込みまたは書き込みのスループットクォータを増加する

テーブルレベルの読み取りスループットとテーブルレベルの書き込みスループットクォータは、テーブルレベルで適用されます。これらのクォータは、プロビジョンドキャパシティモードとオンデマンドキャパシティモードの両方のテーブルに適用されます。デフォルトでは、テーブルに設定されるスループットクォータは 40,000 読み込みリクエストユニットと 40,000 書き込みリクエストユニットです。テーブルへのトラフィックがこのクォータを超えると、テーブルがスロットリングする可能性があります。この発生を防止する方法の詳細については、「Amazon DynamoDB をモニタリングして運用状況を把握する」を参照してください。

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