2- プロビジョンドスループットの超過 - Amazon DynamoDB

2- プロビジョンドスループットの超過

プロビジョンドキャパシティのスロットリングは、アプリケーションの消費率が、テーブルまたはグローバルセカンダリインデックス用に設定された読み取りまたは書き込みキャパシティユニット (RCU/WCU) を超えた場合に発生します。DynamoDB はトラフィックの急増を処理するためのバーストキャパシティを提供しますが、プロビジョニングされた制限を超える持続的なリクエストはスロットリングを引き起こします。この場合、DynamoDB はスロットリング例外で ProvisionedThroughputExceeded スロットリングの理由タイプを返します。この理由は、問題が読み取り操作か書き込み操作か、基本テーブルまたはグローバルセカンダリインデックスに影響するかを識別します。

Auto Scaling が有効になっているかどうかにかかわらず、スロットリングが発生する可能性があります。Auto Scaling は消費量の増加に適応しますが、すぐには応答せず、設定した最大キャパシティ制限によって制約されます。つまり、突然のトラフィックの急増時や、消費が Auto Scaling の最大制限を超えた場合でも、スロットリングが発生する可能性があります。

プロビジョンドスループット超過の緩和策

このセクションでは、プロビジョンドキャパシティのスロットリングシナリオの解決ガイダンスを提供します。このガイドを使用する前に、アプリケーションの例外処理から特定のスロットリングの理由を特定し、影響を受けるリソースの Amazon リソースネーム (ARN) を決定していることを確認してください。スロットリングの理由の取得とスロットリングされたリソースの識別については、「DynamoDB スロットリング診断フレームワーク」を参照してください。

特定のスロットリングシナリオに進む前に、まずスロットリングが解決が必要な問題であるかどうかを検討します。

  • 時折のスロットリングは正常であり、適切に最適化された DynamoDB アプリケーションで予期されます。スロットリングとは、プロビジョニングした内容の 100% を消費していることを意味します。アプリケーションが再試行でスロットリングを適切に処理し、全体的なパフォーマンスが要件を満たしている場合、スロットリングは即時のアクションを必要としない場合があります。

  • ただし、スロットリングによってクライアント側の許容できないレイテンシーが発生している場合、ユーザーエクスペリエンスが低下している場合、または重要なオペレーションがタイムリーに完了しない場合は、以下の緩和オプションに進みます。

スロットリングの問題に対処する必要がある場合は、まずスロットリングの原因が以下であるかどうかを判断します。

  • 一時的なトラフィックのスパイク: プロビジョニングされたキャパシティを超えるが持続しないトラフィックの短期間の増加。これには、継続的な高トラフィックとは異なる戦略が必要です。

  • 継続的な高トラフィック: プロビジョニングされたキャパシティを一貫して超える持続的なワークロード。

トラフィックのスパイクについては、その他のリソース の「Handle traffic spikes with Amazon DynamoDB provisioned capacity」ブログの戦略を検討してください。

継続的な高トラフィックの場合は、以下のキャパシティ調整オプションを検討します。

TableReadProvisionedThroughputExceeded

この問題が発生した場合

アプリケーションの読み込み消費レートが、テーブルに設定されたプロビジョニングされた読み込みキャパシティユニット (RCU) を超えています。一般的な診断とモニタリング で CloudWatch メトリクスをモニタリングして、スロットリングイベントを分析できます。

解決方法

読み取りキャパシティスロットリングを解決するには、次の戦略を検討します。

TableWriteProvisionedThroughputExceeded

この問題が発生した場合

アプリケーションの書き込み消費量が、テーブルに設定されたプロビジョニングされた書き込みキャパシティユニット (WCU) を超えています。一般的な診断とモニタリング で CloudWatch メトリクスをモニタリングして、スロットリングイベントを分析できます。

解決方法

書き込みキャパシティスロットリングを解決するには、次の戦略を検討します。

IndexReadProvisionedThroughputExceeded

この問題が発生した場合

グローバルセカンダリインデックス (GSI) の読み取り消費量が GSI のプロビジョニングされた読み込みキャパシティユニット (RCU) を超えています。一般的な診断とモニタリング で CloudWatch メトリクスをモニタリングして、スロットリングイベントを分析できます。

解決方法

GSI 読み取りキャパシティスロットリングを解決するには、次の戦略を検討します。

IndexWriteProvisionedThroughputExceeded

この問題が発生した場合

基本テーブルの項目の更新により、GSI のプロビジョニングされた書き込みキャパシティを超える GSI への書き込みがトリガーされます。これにより、基本テーブルの書き込み時にバックプレッシャースロットリングが発生します。一般的な診断とモニタリング で CloudWatch メトリクスをモニタリングして、スロットリングイベントを分析できます。

解決方法

GSI 書き込みキャパシティスロットリングを解決するには、次の戦略を検討します。

一般的な診断とモニタリング

スループットエラーをトラブルシューティングする場合、いくつかの CloudWatch メトリクスが根本原因の特定に役立ちます。

重要な CloudWatch メトリクス

これらの主要なメトリクスをモニタリングして、プロビジョンドキャパシティのスロットリングを診断します。

解決手順

テーブルスループットキャパシティの増加

Auto Scaling が有効になっておらず、すぐにキャパシティを増やす必要がある場合は、この手順を使用します。

  1. DynamoDB コンソール、AWS CLI、または SDK を使用して、テーブルのプロビジョンドキャパシティを更新します。

    • 読み込みキャパシティの場合: DynamoDB がリクエストを調整する前に 1 秒あたりに消費される強力な整合性のある読み込みの最大数を指定する ReadCapacityUnits パラメータを増やします。

    • 書き込みキャパシティの場合: DynamoDB がリクエストを調整する前に 1 秒あたりに消費される書き込みの最大数を指定する WriteCapacityUnits パラメータを増やします。

  2. 新しいキャパシティ設定がテーブルごとのスループットクォータを超えていないこと、およびアカウントの総消費量がリージョンのアカウントごとのスループットクォータを下回っていることを確認します。これらの制限に近づいている場合は、代わりにオンデマンドキャパシティモードに切り替えることを検討します。

テーブルまたは GSI の読み取りまたは書き込みキャパシティを調整するようにテーブル Auto Scaling を設定する

トラフィックパターンに基づいて読み取りまたは書き込みキャパシティを自動的に調整するように DynamoDB Auto Scaling を設定します。Auto Scaling は、テーブルと GSI の両方で個別に設定でき、読み取りキャパシティユニットと書き込みキャパシティユニットを個別に制御できます。

  1. テーブルまたは GSI の読み取りキャパシティ、書き込みキャパシティ、またはその両方に対して Auto Scaling を有効にします。

  2. トラフィックのスパイクのヘッドルームでターゲット使用率を設定します。

    注記

    ターゲット使用率が低いほど、コストとスケーリング頻度が増加します。ターゲットが 40% 未満の場合、オーバープロビジョニングが発生する可能性があります。使用パターンとコストをモニタリングして、パフォーマンスと効率のバランスを取ります。

  3. キャパシティの境界を設定します。

    • 最小 RCU/WCU: トラフィックが少ない期間に十分なキャパシティを維持します。

    • 最大 RCU/WCU: ピークトラフィックの需要に対応し、暴走スケーリングイベントから保護します。

DynamoDB Auto Scaling の設定と管理に関するガイダンスについては、「DynamoDB Auto Scaling によるスループットキャパシティの自動管理」を参照してください。

注記

Auto Scaling は通常、トラフィックの変化に対応するために数分かかります。突然トラフィックが急増した場合、テーブルのバーストキャパシティは Auto Scaling が調整している間にすぐに保護されます。適切なヘッドルームを使用してターゲット使用率を設定し、スケーリングオペレーションの時間を確保し、予期しない需要に備えてバーストキャパシティを維持します。

テーブルまたはインデックスの読み取りまたは書き込み Auto Scaling 設定の最適化

Auto Scaling が有効になっていてもスロットリングがまだ発生する場合は、この手順を使用します。Auto Scaling は、テーブルとグローバルセカンダリインデックス (GSI) の両方で個別に調整でき、読み取りキャパシティユニットと書き込みキャパシティユニットを個別に制御できます。

  • ターゲット使用率の調整: スロットリングが発生する前にスケーリングをトリガーするために、テーブルまたは GSI のターゲット使用率を下げることを検討します。これらの調整を行った後は、トラフィックを必ずモニタリングしてください。キャパシティの消費とコストへの影響の詳細については「テーブルまたは GSI の読み取りまたは書き込みキャパシティを調整するようにテーブル Auto Scaling を設定する」を参照してください。

  • キャパシティの境界を確認する: 最小キャパシティ設定と最大キャパシティ設定が実際のワークロードパターンと一致していることを確認します。

オンデマンドキャパシティモードに切り替える

キャパシティモードの切り替えに関する一般的な情報については「DynamoDB でキャパシティモードを切り替える際の考慮事項」を参照してください。モードを切り替える際の特定の制約については、Service Quotas を参照してください。

GSI スループットキャパシティの増加

GSI で Auto Scaling が有効になっていない場合、またはすぐにキャパシティを増やす必要がある場合は、この手順を使用します。

  1. DynamoDB コンソール、AWS CLI、または SDK を使用して GSI プロビジョンドキャパシティを更新します。

    • 読み取りキャパシティの場合: DynamoDB がリクエストを調整する前に GSI が 1 秒あたりに消費できる読み取りの最大数を指定する、特定の GSI の ReadCapacityUnits パラメータを増やします。GSI は結果整合性のある読み込みのみをサポートすることに注意してください。

    • 書き込みキャパシティの場合: DynamoDB がリクエストを調整する前に GSI が 1 秒あたりに消費できる書き込みの最大数を指定する、特定の GSI の WriteCapacityUnits パラメータを増やします。

  2. GSI のプロビジョンドスループットキャパシティが、アカウントごとおよびテーブルごとのスループットクォータ内に留まっていることを確認します。

その他のリソース