3- アカウント制限の超過 - Amazon DynamoDB
アカウント制限緩和策一般的な診断とモニタリング解決手順

3- アカウント制限の超過

オンデマンドテーブルには管理するプロビジョンドキャパシティレベルはありませんが、DynamoDB はアカウントレベルのスループット制限を適用して、実行の暴走を防ぎ、すべてのお客様に公平なリソース使用量を確保します。これらのテーブルごとのアカウント制限は、アカウントとリージョンの組み合わせごとに設定された調整可能な保護手段として機能します。読み取りまたは書き込みの消費量がこれらの制限を超えると、DynamoDB は AccountLimitExceeded スロットリング例外でスロットリングの理由タイプを返します。テーブルごとのデフォルトのアカウント制限は、テーブルにカスタム最大スループット設定が設定されていない場合に自動的に適用されます。オプションで、コスト管理と予測可能性を高めるために最大スループット設定を構成することも、アプリケーション要件がデフォルトの制限を超えた場合は Amazon DynamoDB のクォータ コンソールからクォータの引き上げをリクエストすることもできます。

アカウント制限緩和策

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

特定のスロットリングシナリオに進む前に、まずアクションが実際に必要かどうかを判断します。

  • パフォーマンスへの影響を評価する: スロットリングが適用されているにもかかわらず、アプリケーションが依然としてパフォーマンス要件を満たしているかどうかを確認します。多くのアプリケーションは、特に一括操作またはデータ移行中に、アカウントの制限またはその近くで正常に動作します。

  • スロットリングパターンを確認する: スロットリングが断続的で、アプリケーションが再試行を効果的に処理する場合、ワークロードには現在の制限で十分である可能性があります。

時折アカウント制限に達した場合でもアプリケーションが正常に動作する場合は、即時の変更を実装するのではなく、単に状況をモニタリングすることを選択できます。

スロットリングが許容できないパフォーマンスの問題や信頼性の懸念を引き起こしていると判断した場合は、以下の特定のスロットリングの理由を選択して、推奨される緩和オプションを見つけます。

TableReadAccountLimitExceeded

この問題が発生した場合:

テーブルの読み取り消費量が、リージョンのテーブルごとのアカウントレベルの読み取りスループットクォータを超えています。一般的な診断とモニタリング で CloudWatch メトリクスをモニタリングして、スロットリングイベントを分析できます。

解決方法

このスロットリングを解決するには、次の手順に従います。

  • クォータの引き上げのリクエスト:

    テーブルごとの読み取りスループット制限 (クォータコード L-CF0CBE56) の引き上げをリクエストします。リクエストの送信方法の詳細については、「テーブルあたりのクォータの引き上げのリクエスト」を参照してください。

TableWriteAccountLimitExceeded

この問題が発生した場合:

テーブルの書き込み消費量が、リージョンのアカウントレベルのテーブルあたりの書き込みスループットクォータを超えています。一般的な診断とモニタリング で CloudWatch メトリクスをモニタリングして、スロットリングイベントを分析できます。

解決方法

このスロットリングを解決するには、次の手順に従います。

  • クォータの引き上げのリクエスト: テーブルあたりの書き込みスループット制限 (クォータコード L-AB614373) の引き上げをリクエストします。リクエストの送信方法の詳細については、「テーブルあたりのクォータの引き上げのリクエスト」を参照してください。

IndexReadAccountLimitExceeded

この問題が発生した場合:

グローバルセカンダリインデックス (GSI) に向けられた読み取りオペレーションは、現在の AWS リージョンでアカウントのテーブルごとの読み取りクォータで許可されているよりも多くのスループットを消費します。テーブルごとのアカウントレベルの読み取りスループットクォータは、テーブルとそのすべての GSI の組み合わせにまとめて適用されます。一般的な診断とモニタリング で CloudWatch メトリクスをモニタリングして、スロットリングイベントを分析できます。

解決方法

アカウントのキャパシティ分布に基づいて適切な解決策を選択します。

IndexWriteAccountLimitExceeded

この問題が発生した場合:

基本テーブルへの書き込みオペレーションにより、GSI に対応する更新を生成し、AWS リージョンのアカウントレベルのテーブルあたりの書き込みスループットクォータを合計で超過します。GSI によってインデックス付けされた属性を含む基本テーブル項目へのすべての書き込みは、その GSI への対応する書き込みオペレーションをトリガーします。これらの結合書き込みオペレーションは、テーブルあたりの書き込みスループットクォータにカウントされます。CloudWatch メトリクスを 一般的な診断とモニタリング でモニタリングして、これらのスロットリングイベントのパターンとタイミングを分析し、過剰な GSI 書き込みアクティビティの原因となっているオペレーションを特定できます。

解決方法

アカウントのキャパシティ分布に基づいて適切な解決策を選択します。

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

アカウント制限がスロットリングイベントを超えたトラブルシューティングを行う場合、いくつかの CloudWatch メトリクスは、テーブル単位またはアカウント全体の制限に達しているかどうかを特定し、キャパシティ分散パターンを理解するのに役立ちます。

重要な CloudWatch メトリクス

これらの主要なメトリクスをモニタリングして、アカウント制限スロットリングを診断します。

  • アカウント制限スロットリングイベント: ReadAccountLimitThrottleEvents と WriteAccountLimitThrottleEvents は、アカウントレベルの制限によりリクエストがスロットリングされたタイミングを追跡します。ReadThrottleEvents および WriteThrottleEvents は、読み取りまたは書き込みリクエストがプロビジョニングされたキャパシティを超えたタイミングを追跡します。

  • リソースごとのキャパシティ消費量: 各テーブルと GSI の ConsumedReadCapacityUnits と ConsumedWriteCapacityUnits は、個々のリソースの使用状況を表示します。

  • アカウント全体の消費: CloudWatch メトリクス数式を使用して、すべてのテーブルと GSI の消費キャパシティを合計して、アカウントの合計使用量をモニタリングします。

解決手順

テーブルあたりのクォータの引き上げのリクエスト

アプリケーションが現在のテーブルごとのスループット制限を超えて動作する必要がある場合は、次の手順を使用してクォータ引き上げリクエストを送信する必要があります。AWS アカウント内の各 DynamoDB テーブル (および関連付けられたすべての GSI) は、特定のリージョン内のこれらのスループットクォータの対象となります。これらのクォータは、個々のテーブルとその GSI がまとめて消費できる最大読み取りまたは書き込みキャパシティを表し、アカウント内のすべてのテーブルに集約されるのではなく、各テーブルに個別に適用されます。

オプションで、オンデマンドスループットの最大設定を構成することで、テーブルごとまたは GSI ごとにより低い制限を設定することもできます。

  1. 引き上げる必要がある特定のクォータを特定します。

    • テーブルあたりの読み取りスループット制限 (クォータコード L-CF0CBE56): テーブルあたりのデフォルト 40,000 RCU

    • テーブルあたりの書き込みスループット制限 (クォータコード L-AB614373): テーブルあたりのデフォルト 40,000 WCU

  2. 引き上げをリクエストする際は、AWS Service Quotas コンソールを使用します。

    • Service Quotas で DynamoDB サービスに移動する

    • クォータコードを使用して適切なクォータを検索する

    • 予測されるピーク使用量に基づいて引き上げをリクエストする

  3. 以下を含め、引き上げの根拠を記載します。

    • 現在の使用パターンとピークトラフィック要件

    • キャパシティの増加に関するビジネス上の根拠

    • キャパシティの増加が必要な場合のタイムライン

注記

通常、クォータの増加の処理には 24～48 時間かかります。それに応じてリクエストを計画し、承認を待っている間に一時的な緩和戦略を検討します。

GSI 射影と設計の最適化

グローバルセカンダリインデックス (GSI) の射影と設計を最適化して、キャパシティの消費量を減らし、パフォーマンスを向上させます。

選択的射影戦略

クエリがいくつかの属性にのみアクセスする必要がある場合、それらの属性のみを射影すると、基本テーブル項目が変更されたときに GSI に書き込まれるデータの量が減少します。射影タイプの詳細については、「グローバルセカンダリインデックスの射影」を参照してください。

  1. クエリパターンを分析する: アプリケーションのクエリパターンを確認して、GSI を介して実際にアクセスされる属性を特定します。

  2. 選択的射影を使用する: 書き込み量を減らすためにクエリで実際に必要な属性のみを射影します。

  3. KEYS_ONLY の検討: クエリでキー属性のみが必要な場合は、KEYS_ONLY 射影を使用して書き込み量を最小限に抑えます。

  4. 読み取りと書き込みのトレードオフのバランス: 属性の数を減らすと、書き込みキャパシティの消費量は減りますが、追加の基本テーブルの読み取りが必要になる場合があります。

スパース GSI 実装

スパース GSI には、基本テーブルのすべての項目ではなく、インデックス付き属性を持つ項目のみが含まれます。これにより、データの特定のサブセットを頻繁にクエリする場合に、パーティション密度が低下し、パフォーマンスが向上します。

  1. 特定の属性値を持つ項目のみを含む GSI を設計します。

  2. インデックスを作成する必要がある項目にのみ GSI パーティションキー属性を設定して、条件付きインデックスを作成します。

  3. スパース GSI の複合キー (status#timestamp など) を使用して、インデックス化された項目のサブセット内にトラフィックをさらに分散します。

これらの戦略の実装の詳細については、「DynamoDB でセカンダリインデックスを使用するためのベストプラクティス」を参照してください。