DVAAWSのサービスを使用した開発
あるアプリケーションが多数のIoTセンサーから毎秒数千件の計測値をDynamoDBテーブルに書き込んでいます。テーブルはパーティションキーに計測日（yyyy-mm-dd）、ソートキーにタイムスタンプを使用しています。プロビジョンドWCUを十分に設定しているにもかかわらず、書き込みの一部がProvisionedThroughputExceededExceptionでスロットリングされます。スループットを最大化する最も適切な対策はどれですか。
Aパーティションキーに算出したランダムサフィックス（例: 日付#0〜N）を付与し、書き込みを複数の論理パーティションに分散させる
✓ 正解
特定日付に書き込みが集中するホットパーティションが原因で、単一パーティションは1,000WCU上限に縛られます。パーティションキーへ乱数サフィックスを付与する write sharding でキー空間を分散させればテーブル全体のスループットを引き出せ、唯一根本解決になります。
Bキャパシティモードをオンデマンドに変更し、トラフィックに応じて書き込みを自動的にスケールさせる
オンデマンドは課金・スケールモデルの変更にすぎず、単一物理パーティションの1,000WCU上限は同じです。書き込みが当日キーに集中する構造は変わらないため、ホットパーティションのスロットリングは解消しません。
CソートキーをタイムスタンプからランダムなUUIDに変更して、書き込みキーを一意になるようにする
ソートキーはパーティション内でのアイテム並びを決めるだけで、どの物理パーティションに書くかはパーティションキーで決まります。UUID化しても書き込みは同一日付パーティションに集中し続け、スロットリングは解消しません。
DテーブルにGSIを追加し、書き込みトラフィックをGSI側のパーティションへ分散させる
GSIは読み取りクエリのために射影される副次テーブルで、ベーステーブルへの書き込みはパーティションキーに従って行われます。GSI追加はむしろ書き込みコストを増やし、ホットパーティション自体は解消しません。
解説
書き込みが「当日」という単一のパーティションキー値に集中するホットパーティションが原因です。
DynamoDBの単一物理パーティションは最大1,000WCU/3,000RCUに制限されるため、テーブル全体のWCUを増やしても1パーティションに集中する限りスロットリングは解消しません。
パーティションキーに 日付#乱数（0〜N）のようなサフィックスを付ける write sharding を行うと、書き込みがN個の論理パーティションへ分散し、キー空間全体でスループットを引き出せます。
選択肢のオンデマンドは課金モデルの変更で、単一パーティションの上限は変わりません。
選択肢のソートキー変更はパーティション内の分散で、パーティション選択はパーティションキーのみで決まります。
選択肢のGSI追加はクエリ用であり、ベーステーブルへの書き込み集中は解消しません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDVAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →