IT 技書の森

ホットパーティション

特定のパーティションにアクセスが集中し、スループットが低下する DynamoDB の性能問題

DynamoDBパフォーマンス

ホットパーティションとは

ホットパーティション (Hot Partition) は、DynamoDB で特定のパーティションにリクエストが集中し、そのパーティションのスループット上限に達してスロットリングが発生する性能問題である。テーブル全体のキャパシティに余裕があっても、1 つのパーティションが飽和すれば ProvisionedThroughputExceededException が返る。

DynamoDB はパーティションキーのハッシュ値でデータを物理パーティションに分散する。パーティションキーの設計が偏っていると、特定のパーティションにアクセスが集中する。

なぜ発生するか

DynamoDB の各パーティションには、1 秒あたり最大 3,000 RCU (読み取り) / 1,000 WCU (書き込み) の上限がある。テーブルに 10,000 WCU をプロビジョニングしても、10 パーティションに均等分散されれば各パーティションは 1,000 WCU だ。1 つのパーティションキーに書き込みが集中すると、その 1,000 WCU を超えた時点でスロットリングが発生する。

テーブル全体: 10,000 WCU (10 パーティション)
パーティション A: 8,000 WCU のリクエスト → スロットリング発生
パーティション B〜J: 各 200 WCU → 余裕あり

ホットパーティションを引き起こすキー設計

日付をパーティションキーにする

PK: "2026-04-01"  ← 今日のデータに全アクセスが集中
PK: "2026-03-31"  ← 昨日のデータはほぼアクセスなし

IoT データやログの蓄積で日付をパーティションキーにすると、常に「今日」のパーティションがホットになる。

ステータスをパーティションキーにする

PK: "ACTIVE"    ← アクティブユーザーが大多数
PK: "INACTIVE"  ← 少数
PK: "SUSPENDED" ← ごく少数

カーディナリティ (値の種類数) が低いキーは、特定の値にデータが偏る。

人気商品の ID

EC サイトで商品 ID をパーティションキーにすると、セール中の人気商品にアクセスが集中する。通常時は問題なくても、タイムセール開始時にスパイクが発生する。

対策

Write Sharding (書き込みシャーディング)

パーティションキーにランダムなサフィックスを付与し、書き込みを複数パーティションに分散する。

// ❌ 日付だけ → ホットパーティション
const pk = '2026-04-01';

// ✅ ランダムサフィックスで分散
const shardCount = 10;
const shard = Math.floor(Math.random() * shardCount);
const pk = `2026-04-01#${shard}`;  // "2026-04-01#0" 〜 "2026-04-01#9"

読み取り時は全シャードに対して並列クエリし、結果をマージする。書き込みの分散と引き換えに、読み取りの複雑さが増すトレードオフがある。

複合キーの設計

パーティションキーにカーディナリティの高い属性を組み合わせる。

// ❌ ステータスだけ
PK: "ACTIVE"

// ✅ ユーザー ID + ステータス
PK: "USER#usr-123"
SK: "STATUS#ACTIVE"

GSI (Global Secondary Index) でステータス別の検索が必要な場合は、GSI のパーティションキーにステータスを使いつつ、Sparse Index (該当するアイテムだけがインデックスに含まれる) で分散を図る。

DynamoDB のアダプティブキャパシティ

DynamoDB はアダプティブキャパシティ機能により、ホットパーティションに自動的に追加のキャパシティを割り当てる。ただし、これは緩和策であり根本解決ではない。パーティションあたりの物理的な上限 (3,000 RCU / 1,000 WCU) は変わらない。

検出方法

CloudWatch メトリクス

ConsumedReadCapacityUnits と ConsumedWriteCapacityUnits をパーティションキー別に確認する。CloudWatch Contributor Insights を有効にすると、最もアクセスの多いパーティションキーが可視化される。

# Contributor Insights の有効化
aws dynamodb update-contributor-insights \
  --table-name MyTable \
  --contributor-insights-action ENABLE

スロットリングの監視

ThrottledRequests メトリクスが 0 でない場合、ホットパーティションが発生している可能性がある。テーブル全体のキャパシティ使用率が低いのにスロットリングが発生していれば、ほぼ確実にホットパーティションだ。

オンデマンドモードでも発生する

オンデマンドキャパシティモードでもホットパーティションは発生する。オンデマンドはテーブル全体のスループットを自動スケールするが、パーティションあたりの上限は変わらない。キー設計の問題はキャパシティモードでは解決できない。

ホットパーティションの対策

対策 説明 例
高カーディナリティキー ユニークな値をキーに userId, orderId
ランダムサフィックス キーにランダム値を追加 date#${random}
Write Sharding 書き込みを複数キーに分散 counter#1, counter#2
GSI 別のアクセスパターン GSI で日付検索

ホットパーティションの背景や設計思想は関連書籍に詳しい。

関連用語