← AWSサービスの内部原理 コース
11. ホットパーティション問題 — バーストとアダプティブキャパシティ
「1つのキーにアクセスが集中すると何が起きるか」を、パーティション=サーバーという前提から図で追っていきましょう。
①パーティション=サーバーには上限がある
テーブルの総キャパシティ見かけ上はひとつの数字
各パーティションに分配
パーティションA= 1台のサーバー
パーティションB= 1台のサーバー
パーティションC= 1台のサーバー
- ・各パーティションの上限: 最大3,000RCU/1,000WCU(1秒あたり)
- ・読み書きはパーティションごとに独立管理
- ・1台が上限超過 → そのパーティションだけスロットリング
テーブルの総キャパシティは各パーティションへの分配結果にすぎず、1台の上限を超えるとそこだけスロットリングされます。
②ホットパーティション問題 — 1台だけが燃える
人気商品IDへ殺到同じキーばかり読まれる
キーをハッシュ
hash(人気ID)同じキー → 常に同じ値
常に同じ1台へ
A余裕あり
B 上限到達!スロットリング発生
テーブル全体では余裕があるのにC余裕あり
- ・第一の防波堤は均等分散: 値の種類が多いパーティションキーを選ぶ(公式ベストプラクティス)
ハッシュはキーの種類を均等にばらまくのは得意でも、特定キーへのアクセス集中までは面倒を見てくれません。
③バーストキャパシティ — 時間軸の平準化
平時: 未使用キャパシティ設定より少なく使っている
DynamoDBが取っておく
バースト用の貯金直近最大5分間(300秒)ぶん
スパイク到来時
設定した毎秒能力を超えて一気に消費
平時に節約した分を非常時に前借りする仕組み。OSがプロセスの未使用CPU時間を貯めて後で使わせる「資源の貸し借り」と同じ発想です。
④アダプティブキャパシティ — 空間軸の平準化
Bだけに150WCU/秒割り当て100WCUを超過
DynamoDBが自動・瞬時に引き上げ
A 100WCU余力あり
B 150WCUを支えるスロットリングなし
C・D 100WCU余力あり
- ・引き上げ範囲: テーブル総キャパシティと1パーティション上限(3,000RCU/1,000WCU)の枠内
- ・全テーブルで自動有効・追加料金なし
- ・オンデマンド/プロビジョンドの両モードに適用
ホットになったパーティションのスループットを自動的かつ瞬時に引き上げ、余っているパーティションの余力を熱い場所へ回します。
⑤最後の逃げ道 — 熱い項目に専用の1台
頻繁アクセス項目が同居同じパーティション内で競合
再配置して引き離す
熱い項目X別パーティションへ
熱い項目Y別パーティションへ
1項目だけに高頻度アクセスが続くと
その1項目専用のパーティション上限いっぱいの最大3,000RCU/1,000WCUを届けられる
偏りが続くと項目を再配置して引き離し、極端な場合はたった1項目に1パーティションを丸ごと割り当てます。
⑥全体を1本の因果でつなぐ
パーティション=サーバー物理上限がある
だから
偏りはスロットリングを生む
第一の対策
均等分散(ハッシュ+キー設計)
それでも残る偏りを吸収
バースト時間軸の平準化
アダプティブ空間軸の平準化
挙動を丸暗記しなくても、「上限」と「サーバー」という基礎からこの流れを再導出できます。