# スロットリングの診断
アプリケーションでスロットリングが発生すると、DynamoDB はこれらのイベントの診断に役立つ詳細な例外情報とターゲットを絞った CloudWatch メトリクスを提供します。
このセクションでは、DynamoDB アプリケーションのスロットリングイベントを理解するための体系的なアプローチを示します。スロットリング例外を解釈し、CloudWatch メトリクスと関連付けてより深いインサイトを得る方法、DynamoDB アプリケーションのスロットリングを減らす変更を理解する方法を示します。
## スロットリングの例外について
DynamoDB がリクエストを調整すると、詳細な診断情報を含む特定の例外が返されます。例えば、Java では、これらには `ProvisionedThroughputExceededException`、`RequestLimitExceeded`、または `ThrottlingException` が含まれます。
各例外には、スロットリングを識別して理解するのに役立つ 2 つのキーフィールドを含む個々の `ThrottlingReason` のコレクションである `ThrottlingReasons` が含まれます。
+ **理由** - `` 形式に従った連結フィールド
+ **リソース ARN** - 影響を受けるテーブルまたはインデックスの Amazon リソースネーム (ARN)
理由フィールドは、何が起こっているのかを正確に理解するのに役立つ一貫したパターンに従います。
+ **ResourceType** (スロットリングの対象): `Table` または `Index`
+ **OperationType** (オペレーションの種類): `Read` または `Write`
+ **LimitType** (スロットリングが発生した理由):
+ `KeyRangeThroughputExceeded`: これは、テーブルまたはインデックスをサポートする特定のパーティションが、パーティションごとの内部スループット制限を超える読み取りまたは書き込みキャパシティを消費した場合に発生します。
+ `ProvisionedThroughputExceeded`: これは、読み取りまたは書き込みの消費率がプロビジョニングされた量を超えた場合に、プロビジョニングされたテーブルまたはグローバルセカンダリインデックスで発生します。
+ `AccountLimitExceeded`: これは、オンデマンドテーブルまたはインデックスで、読み取りまたは書き込みの消費レートが、アカウントレベルで設定されたテーブルとそのインデックスの最大消費レートを超えた場合に発生します。このクォータの引き上げをリクエストできます。
+ `MaxOnDemandThroughputExceeded`: これは、オンデマンドテーブルまたはインデックスで、読み取りまたは書き込みの消費レートが、テーブルまたはインデックスに設定されたユーザー提供の最大消費レートを超えた場合に発生します。この値は、アカウント制限までの任意の値に自分で上げることも、ユーザーが指定した制限がないことを示すために -1 に設定することもできます。
リソース ARN は、スロットリングされているテーブルまたはインデックスを正確に識別します。
+ テーブルの場合: `arn:aws:dynamodb:[region]:[account-id]:table/[table-name]`
+ インデックスの場合: `arn:aws:dynamodb:[region]:[account-id]:table/[table-name]/index/[index-name]`
完全なスロットリングの理由の例:
+ `TableReadProvisionedThroughputExceeded`
+ `IndexWriteAccountLimitExceeded`
これにより、スロットリングされているリソース、スロットリングの原因となったオペレーションのタイプ、スロットリングが発生した理由を正確に特定できます。
### 例外の例
#### 例 1: GSI でプロビジョニングされたキャパシティを超過
```
{
"ThrottlingReasons": [
{
"reason": "IndexWriteProvisionedThroughputExceeded",
"resource": "arn:aws:dynamodb:us-west-2:123456789012:table/CustomerOrders/index/OrderDateIndex"
}
],
"awsErrorDetails": {
"errorCode": "ProvisionedThroughputExceeded",
"errorMessage": "The level of configured provisioned throughput for the index was exceeded",
"serviceName": "DynamoDB",
"sdkHttpResponse": {
"statusText": "Bad Request",
"statusCode": 400
}
}
}
```
この例では、アプリケーションは `ProvisionedThroughputExceededException` を受け取り、その理由は `IndexWriteProvisionedThroughputExceeded` です。`OrderDateIndex` への書き込みは、書き込み消費量が GSI で設定されたプロビジョンド書き込みキャパシティを超えたため、スロットリングされています。
#### 例 2: オンデマンドの最大スループットを超過
```
{
"ThrottlingReasons": [
{
"reason": "TableReadMaxOnDemandThroughputExceeded",
"resource": "arn:aws:dynamodb:us-east-1:123456789012:table/UserSessions"
}
],
"awsErrorDetails": {
"errorMessage": "Throughput exceeds the maximum OnDemandThroughput configured on table or index",
"errorCode": "ThrottlingException",
"serviceName": "DynamoDB",
"sdkHttpResponse": {
"statusText": "Bad Request",
"statusCode": 400
}
}
}
```
この例では、`UserSessions` テーブルからの読み取りは、テーブルで設定された最大オンデマンドスループット制限を超えているため、スロットリングされています。
## DynamoDB スロットリング診断フレームワーク
アプリケーションでスロットリングが発生した場合は、以下の手順に従って問題を診断して解決します。
### ステップ 1 - `ThrottlingReason` の詳細を分析する
1. **理由**フィールドをチェックして、スロットリングの具体的な理由を特定します。理由には、スロットリングされたリソースのタイプ (テーブルまたはインデックス)、スロットリングイベントの原因となったオペレーションのタイプ (読み取りまたは書き込み)、および超過した制限タイプ (パーティション、プロビジョニングされたスループット、アカウント制限) が詳しく記載されています。
1. **resourceArn** フィールドをチェックして、スロットリングされているリソース (テーブルまたは GSI) を特定します。
1. この組み合わせ情報を使用して、スロットリングの問題の完全なコンテキストを理解します。
例えば、スロットリングの理由 `ProvisionedThroughputExceededException` で次の例外 `TableWriteKeyRangeThroughputExceeded` が発生するシナリオを考えてみます。影響を受ける resourceARN は `arn:aws:dynamodb:us-west-2:123456789012:table/CustomerOrders` です。
この組み合わせにより、`CustomerOrders` テーブルへの書き込みオペレーションがスロットリングされていることが通知されます。スロットリングはパーティションレベルで発生しています (テーブルレベルではなく、`TableWriteProvisionedThroughputExceeded` と表示されます)。根本原因は、特定のパーティションキー値または範囲の最大スループットキャパシティを超えており、ホットパーティションの問題を示していることです。
例外要素間のこの関係を理解することで、適切な緩和策を実装できます。この場合、テーブルの全体的なプロビジョンドキャパシティを増やすのではなく、ホットパーティションに対処します。
### ステップ 2 - 関連する CloudWatch メトリクスを特定して分析する
1. **メトリクスを特定する:** DynamoDB の各スロットリングの理由は、スロットリングイベントを追跡および分析するためにモニタリングできる特定の CloudWatch メトリクスに直接対応します。スロットリングの理由から適切な CloudWatch メトリクス名を体系的に取得できます。
1. このリファレンステーブルを使用して、スロットリングの理由と対応する CloudWatch メトリクスを一致させます。
**完全なスロットリングの理由と CloudWatch メトリクスリファレンス**
[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/throttling-diagnosing-workflow.html)
例えば、`IndexWriteProvisionedThroughputExceeded` を受け取った場合は、少なくとも `ResourceArn` で識別された特定のインデックスの `WriteProvisionedThroughputThrottleEvents` CloudWatchメトリクスをモニタリングする必要があります。
1. CloudWatch でこれらのメトリクスをモニタリングして、スロットリングイベントの頻度とタイミングを理解し、読み取りスロットリングと書き込みスロットリングを区別し、スロットリングの増加時に時間パターンを特定し、キャパシティ使用率の傾向を追跡します。
DynamoDB は、各テーブルとグローバルセカンダリインデックスの詳細なメトリクスを発行します。メトリクス (`ReadThrottleEvents`、`WriteThrottleEvents`、および `ThrottledRequests`) は、テーブルとそのインデックス全体のすべてのスロットリングイベントを集計します。
### ステップ 3 - CloudWatch Contributor Insights を使用してスロットリングされたキーと高アクセス率を特定する (パーティション関連のスロットリング用)
ステップ 1 でパーティション関連の問題 (`KeyRangeThroughputExceeded` エラーなど) を特定した場合、CloudWatch Contributor Insights for DynamoDB は、トラフィックを駆動し、テーブルまたはインデックスでスロットリングイベントが発生している特定のキーを診断するのに役立ちます。
1. `ResourceARN` に基づいてスロットリングされたテーブルまたはインデックスに対して CloudWatch Contributor Insights を有効にします。
*スロットリングされたキー*モードを選択すると、最もスロットリングされたキーのみに集中できます。このモードは、スロットリングが発生したときにのみイベントを処理するため、継続的なモニタリングに最適です。または、*アクセスおよびスロットリングされたキー*モードは、最もアクセスされたキーのパターンを探すのに役立ちます。
1. レポートを分析して、問題のあるパターンを特定します。アクセス率またはスロットリング率が不釣り合いに高いキーを探し、スロットリングとトラフィックパターンを関連付けます。Contributor Insights グラフと DynamoDB CloudWatch メトリクスを組み合わせた統合ダッシュボードを作成できます。
CloudWatch Contributor Insights の有効化と使用に関する詳細については、「[CloudWatch Contributor Insights for DynamoDB を使用する](contributorinsights.md)」を参照してください。
### ステップ 4 - 適切なソリューションを決定する
スロットリングの特定の原因を診断したら、特定のコンテキストに基づいて推奨されるソリューションを実装します。適切なソリューションは、スロットリングシナリオ、テーブルのキャパシティモード、テーブルとキーの設計決定、アクセスパターンとクエリ効率、グローバルおよびセカンダリインデックスの設定、および全体的なシステムアーキテクチャと統合ポイントなど、複数の要因によって異なります。
特定のスロットリングシナリオに対処するための詳細な解決策については、「[DynamoDB スロットリング解決ガイド](troubleshooting-throttling-diagnostics.md)」セクションを参照してください。このリソースは、特定のスロットリングの理由とキャパシティモードの設定に合わせてカスタマイズされたターゲットを絞った修復戦略を提供します。
### ステップ 5 - 進捗状況をモニタリングする
1. スロットリングシナリオに対応する CloudWatch メトリクスを追跡します。
1. スロットリングイベントの減少を観察することで、緩和戦略が有効であることを確認します。