DEAデータストアの管理
ある EC サイトが Amazon DynamoDB を使用してユーザーのセッションデータを管理しています。パーティションキーは userId、ソートキーは timestamp です。人気セールイベント時に特定ユーザーセグメントへのアクセスが集中し、ProvisionedThroughputExceededException（プロビジョニング済みスループットの超過エラー）が頻発しています。DynamoDB Auto Scaling は既に有効ですが改善しません。根本的な解決策として最も適切なものはどれですか？
Aキャパシティモードをプロビジョニング済みからオンデマンドに切り替える
オンデマンドモードはキャパシティの自動調整を行いますが、DynamoDB の物理パーティション単位のスループット上限（約 3,000 RCU / 1,000 WCU）は依然として存在するため、ホットパーティション問題の根本解決にはなりません。
Bパーティションキーを userId#{0〜9 のランダム数値} の形式に変更し、書き込みシャーディングを実装する
✓ 正解
ホットパーティション問題の根本原因は、特定のパーティションキー値にアクセスが集中することです。書き込みシャーディング（Write Sharding）を実装してパーティションキーにランダムなサフィックスを付加すると、同一ユーザーのデータを複数の物理パーティションに分散でき、パーティション単位のスループット制約を回避できます。
Ctimestamp に Global Secondary Index（GSI）を追加してクエリを分散させる
Global Secondary Index（GSI）追加は、クエリのアクセスパターンを変えるものであり、書き込み側のホットパーティション負荷分散には効果がありません。
DDynamoDB Streams を有効にして AWS Lambda でリアルタイム処理にオフロードする
DynamoDB Streamsは変更データキャプチャ（CDC）用途の機能であり、パーティションへの負荷集中とは無関係です。
解説
ホットパーティション問題の根本原因は、特定のパーティションキー値にアクセスが集中することです。書き込みシャーディング（Write Sharding）を実装してパーティションキーにランダムなサフィックスを付加すると、同一ユーザーのデータを複数の物理パーティションに分散でき、パーティション単位のスループット制約を回避できます。
選択肢Aのオンデマンドモードはキャパシティの自動調整を行いますが、DynamoDB の物理パーティション単位のスループット上限（約 3,000 RCU / 1,000 WCU）は依然として存在するため、ホットパーティション問題の根本解決にはなりません。
選択肢Cの Global Secondary Index（GSI）追加は、クエリのアクセスパターンを変えるものであり、書き込み側のホットパーティション負荷分散には効果がありません。
選択肢DのDynamoDB Streamsは変更データキャプチャ（CDC）用途の機能であり、パーティションへの負荷集中とは無関係です。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDEAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →