面接問題：「ホットキー」と「高トラフィック」の違い（分散システム設計）

問題¶

Tech Lead in a meeting says: "Its a hot key, not high traffic." As a developer, do you understand the difference?

解答¶

ホットキー問題：特定の1つ（または少数）のキーにアクセスが集中する問題。全体のトラフィックは少なくても発生する。

高トラフィック問題：リクエスト数の絶対量が多い問題。キーの分散度は問わない。

解説¶

ホットキー（Hot Key）とは¶

分散キャッシュ（Redis など）や分散データベース（DynamoDB など）において、特定のキーへのアクセスが極端に集中する状態。

例: 有名人のツイートがバイラル化
  → tweet_id:12345 のキャッシュに毎秒100万リクエスト
  → 他の tweet は1秒に数回程度

全体のリクエスト数は「高トラフィック」でなくても、
1つのキャッシュノードがボトルネックになる

高トラフィック（High Traffic）とは¶

全体のリクエスト数が増大する状態。キーは分散しているため、水平スケールで対処しやすい。

例: セール開始で EC サイトにアクセス集中
  → 商品 A, B, C, D ... 数万種類に均等にアクセス
  → 各キャッシュノードに均等に負荷が分散

→ インスタンスを追加すれば解決できる

なぜ混同されるか¶

高トラフィック → スケールアウトで解決できる
ホットキー    → スケールアウトしても解決しない！

ホットキーは「1つのノードへの集中」が問題なので、
ノードを増やしても同じノードに負荷がかかり続ける

ホットキー問題の対策¶

1. Local Cache（アプリケーション層でキャッシュ）
   → 各アプリサーバーが hot key を短時間ローカルキャッシュ
   → Redis への問い合わせを大幅削減

2. Key Splitting（キー分割）
   → tweet:12345 → tweet:12345:shard1, tweet:12345:shard2
   → 読み取り時はランダムにシャードを選択

3. Read Replica（読み取りレプリカ）
   → DynamoDB Global Tables や Redis Cluster での分散
   → 書き込みはプライマリ、読み取りはレプリカに分散

4. Rate Limiting per Key
   → 1つのキーへのアクセス頻度を制限（バックプレッシャー）

DynamoDB でのホットキー問題例¶

# 問題のある設計: パーティションキーに固定値
{
    "PK": "STATUS#active",  # 全アクティブユーザーが同じパーティション
    "SK": "USER#12345"
}

# 改善: パーティションキーにシャード番号を追加
{
    "PK": f"STATUS#active#{random.randint(1, 10)}",  # 10シャードに分散
    "SK": "USER#12345"
}
# 読み取り時は 1〜10 全シャードを並列クエリして結合（Scatter-Gather）

面接でのポイント¶

TL の一言が「ホットキー」と「高トラフィック」を区別できているか試している
「スケールアウトで解決」と即答すると落とされる（ホットキーはスケールアウトで解決しない）
Local Cache / Key Splitting / Read Replica の対策を1つでも言えると評価される
DynamoDB や Redis Cluster での具体例を出せると実務経験として映る