【要約】【DynamoDB】ホットパーティションを起こしたい [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
検証者は、DynamoDBの設計において特定のパーティションにアクセスが集中する「ホットパーティション」の挙動を、実環境に近い形で検証しようとした。しかし、検証を進める中で以下の技術的課題に直面した。
- ・パーティションキーのカーディナリティが低い設計によるスロットリングの発生。
- ・テーブル全体の容量不足と、特定パーティションの容量不足（ホットパーティション）の混同。
- ・物理パーティションの分割条件が、単なるキーの種類数ではない点。
// Approach
検証者は、意図的に負荷を偏らせることでスロットリングを誘発するため、以下の検証プロセスを採用した。
- ・Bad設計（PK: warehouseId）とGood設計（PK: itemId）の比較。
- ・WCU（書き込みキャパシティユニット）を段階的に変更し、物理パーティションの分割を狙う。
- ・Lambdaを用いた並列負荷生成による、高RPS（リクエスト/秒）の実現。
- ・CloudWatchメトリクスを用いた、スロットリング原因の特定。
// Result
検証の結果、負荷生成側の性能不足により目標のRPSに達せず、ホットパーティションの発生を確認できなかった。しかし、検証の過程で以下の重要な知見が得られた。
- ・物理パーティション数は、WCU/RCU/ストレージ量に基づき決定される。
- ・
WriteKeyRangeThroughputThrottleEventsを見ることで、ホットパーティション特有のスロットリングを識別できる。 - ・バーストおよびアダプティブキャパシティの挙動に関する理解。
Senior Engineer Insight
> DynamoDB設計において、カーディナリティの確保は必須である。しかし、スロットリング発生時に「容量不足」か「偏り」かを即座に判断できなければ、誤ったチューニングを招く。CloudWatchのメトリクスを使い分け、物理パーティションの挙動を理解した上で設計・運用すべきだ。また、負荷試験を行う際は、試験基盤自体のスループット限界にも注意を払う必要がある。