10分間で500万票を大規模に処理するにはどうしますか？

Question

IT Interview Practice · Accepted Answer

各票をデータベースの行に直接書き込んではいけません。**書き込みをバッファリングし、カウンターをシャーディングし、結果整合な集計を受け入れます**。10分で500万票は平均で約8,300票/秒、スパイクははるかに高くなります（ライブTVの瞬間はその10倍になりえます）。コツは、ホットな単一行の更新を多数の独立した並列インクリメントに変えることです。

```text
Client ─▶ Edge/API ─▶ Kafka (vote events) ─▶ Consumers ─┬─▶ Dedup store (SET one-vote)
                        (durable buffer)                 └─▶ Sharded counters (INCR N shards)
                                                                     │
Redis/Aggregator ◀── periodic sum of shards ──────────────────────┘
      │
      └─▶ Read replica / CDN cache ─▶ Live tally to clients
```

## なぜ書き込みをバッファリングするのか

**Kafka**のようなキューは、取り込みと集計を分離します。クライアントの書き込みは安価なappendです。スパイク中にconsumerが遅れても、イベントはDBを圧倒する代わりにログで待機します。Kafkaは**リプレイ**も提供します。consumerがクラッシュしても、最後にコミットしたオフセットから票を失うことなく再処理できます。

## シャード化されたカウンターがホットスポットを潰す

「Option A」への各票が `UPDATE counter SET n=n+1 WHERE id='A'` を実行すると、その単一行がロック競合のボトルネックになります。数千のトランザクションが1行に直列化します。代わりに、各オプションを**Nシャード行**（`A:0 … A:63`）に分割します。各インクリメントはランダムなシャードに当たるので、書き込みがN行に分散して並列に実行されます。表示される合計は `SUM(shards)` で、1〜2秒ごとにアグリゲーターが計算します。Redisでは単にN個の `INCR` キー、DynamoDBではNパーティションキーです。

## 一票のdedup

冪等キーで「ユーザーごとに一票」を強制します：`SADD voted:{pollId} {userId}`（または条件付きput）。ユーザーが既に存在すれば、インクリメント前にイベントを破棄します。これはクライアントではなくconsumerで行います。クライアントは嘘をつき、リトライします。

## 面接での観点

面接官は、あなたが**単一ホットキー問題**を認識し、「DBレプリカを増やす」（レプリカは読み取りをスケールするが、この書き込みはスケールしない）ではなく、バッファリング + シャーディングに手を伸ばすかを探っています。良い回答：「キューとキャッシュを使う」。優れた回答：**結果整合のトレードオフ**を挙げること、つまりライブの数字は現実より1秒遅れると認め、それは票数には問題ないが、投票締切後に権威的に再計算する*最終確定結果*には*不可*だと論じることです。

**よくある罠：** 「正確さ」のために票ごとにDBトランザクションを使うこと。この規模ではそれこそが溶けるものです。

## トレードオフと障害モード

- **結果整合な集計：** シャード合計は遅れます。ライブカウンターには許容範囲で、締切時に照合します。
- **At-least-once配信：** Kafkaは再配信しうるので、dedupがインクリメントを冪等にします。さもないと二重カウントします。
- **ホットシャードの偏り：** シャードが少なすぎると依然競合し、多すぎると合計が高コストになります。32〜128シャードが典型的です。
- **公平性 / 不正：** IP/デバイスごとにrate-limitします。一票のSETが整合性の境界です。それを失うのはクラッシュではなく票の水増しであり、おそらくより悪いです。

なぜ書き込みをバッファリングするのか

シャード化されたカウンターがホットスポットを潰す

一票のdedup

面接での観点

トレードオフと障害モード

関連する質問