ある企業が AWS 上で Amazon DynamoDB を使ったアプリケーションを運用しており、読み取りパフォーマンスが問題になっています。現在の DynamoDB テーブルは 1 億件のアイテムがあり、ホットパーティション（特定のパーティションキーへのアクセスが集中）が発生しています。同一パーティションキーへの読み取りが毎秒 1 万件に達し、DynamoDB の ProvisionedThroughputExceededException が多発しています。最もコスト効率よくこの問題を解決するには、どの方法が適切ですか？
- A. DynamoDB テーブルを Amazon Aurora PostgreSQL に移行し、リードレプリカで読み取り負荷を分散する
- B. Amazon DynamoDB Accelerator（DAX）クラスターを DynamoDB の前段に配置し、マイクロ秒レベルの読み取りキャッシュを提供する。ホットパーティションへの繰り返し読み取りは DAX キャッシュから応答し、DynamoDB への実際の読み取りを大幅に削減する
- C. DynamoDB のプロビジョニングキャパシティを大幅に増加し、ホットパーティションでも処理できるようにする
- D. テーブルのパーティションキーを変更して書き込みシャーディングを実装し、ランダムサフィックスでキーを分散させる
解答と解説を見る
正解: B
DynamoDB Accelerator（DAX）はインメモリキャッシュクラスターで、繰り返しの読み取りをマイクロ秒レベルでキャッシュから応答します。ホットパーティションへの毎秒 1 万件の読み取りが同一データの繰り返しであれば、DAX のキャッシュヒット率は非常に高くなり、DynamoDB への読み取りを大幅に削減できます。DAX は DynamoDB の API と完全互換で、アプリケーションのコード変更も最小限です。 C: プロビジョニングキャパシティの増加は問題を解決しますが、ホットパーティションの制限（1 パーティションあたりの上限: 1,000 RCU）により、キャパシティを増やしてもパーティションの上限に達する可能性があります。またコストも増加します。 D: パーティションキーのシャーディングは書き込み分散には有効ですが、読み取り時に複数のパーティションを結合する処理が必要になり、アプリケーションの大幅な変更が必要です。 A: DynamoDB から Aurora への移行はデータモデルの全面的な変更が必要で、ホットパーティションという具体的な問題に対して過剰な対応です。
📚 関連サービスの解説: Amazon DynamoDB