プロビジョンドモードのDynamoDBテーブルとGSIを使用している。書き込みでProvisionedThroughputExceededExceptionが発生するが、テーブル全体の1分平均の消費量は設定容量を下回る。
テーブル、GSI、パーティションのどの上限が原因かを確認してから対策を決めたい。例外の詳細とCloudWatchメトリクスを取得できる。
最初の調査として最も適切なのはどれか。
ThrottlingReasonsのreasonとresource ARNで対象と上限を特定し、対応するメトリクスと容量消費で裏付ける。
詳細解説
1分間の消費合計は60で割って秒当たりの率へ合わせる。合計と秒当たりの上限を直接比較すると単位が合わない。
テーブル全体の平均は、GSI固有の容量不足や特定パーティションへの負荷集中を否定する根拠にならない。
例外の詳細で対象・読み書き・上限の種類を特定し、そのリソースのメトリクスと同じ時間帯で照合できる。
同じ例外名でもパーティション上限などが原因になり得る。GSIの容量不足ならテーブル容量だけの変更では対象を取り違える。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
公式資料でThrottlingReasonsの形式、原因別メトリクス、GSIのディメンション、消費Sumの秒当たり換算を確認する。
参考にした公式資料
確認できる内容
IndexWriteProvisionedThroughputExceededとTableWriteKeyRangeThroughputExceededを区別し、1分平均だけでは原因を断定できない理由を説明できる。
理解のポイント
- ThrottlingReasons
- ConsumedCapacity
- ProvisionedThroughputExceededException
確認時の注意
- 確認環境: AWS公式SOA-C03試験ガイドとAWS公式ドキュメントの確認
- AWS公式SOA-C03試験ガイドと各サービスの公式ドキュメントを確認する。
基礎のおさらい
例外の対象と上限を読む
reasonはTable／Index、Read／Write、上限の種類を組み合わせる。IndexWriteProvisionedThroughputExceededならresource ARNのGSIの書き込み容量を調べる。TableWriteKeyRangeThroughputExceededならテーブル内のパーティション上限を調べ、必要に応じてContributor Insightsで負荷が集中するキーを確認する。
集計値で負荷分布を断定しない
ConsumedWriteCapacityUnitsの1分Sumを60で割ると秒当たりの平均消費になる。GSIはTableNameとGlobalSecondaryIndexNameを指定して別に確認する。平均は短い急増や一部への集中を隠すため、原因別スロットル指標のSumや例外の時刻と照合する。