10분 안에 500만 표를 대규모로 어떻게 처리하시겠습니까?

Question

IT Interview Practice · Accepted Answer

각 표를 곧바로 데이터베이스 row에 write하지 마십시오 — **write를 버퍼링하고, 카운터를 shard하며, 최종적 집계(eventual tally)를 받아들이십시오**. 10분에 500만 표는 평균 초당 약 8,300표이며, 스파이크는 훨씬 높습니다(생방송 순간이 그 10배가 될 수 있음). 요령은 hot single-row 업데이트를 여러 독립적, 병렬적 증가로 바꾸는 것입니다.

```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
```

## 왜 write를 버퍼링하는가

**Kafka** 같은 큐는 수집(ingestion)과 집계(tallying)를 분리합니다. 클라이언트 write는 저렴한 append이며, 스파이크 동안 consumer가 뒤처져도 이벤트는 DB를 압도하는 대신 로그에서 대기합니다. Kafka는 또한 **리플레이(replay)**를 제공합니다 — consumer가 crash되면 마지막 커밋된 offset부터 표를 잃지 않고 재처리합니다.

## Sharded 카운터가 핫스팟을 제거한다

"Option A"에 대한 모든 표가 `UPDATE counter SET n=n+1 WHERE id='A'`를 수행하면 그 하나의 row가 lock 경합 병목이 됩니다 — 수천 개의 트랜잭션이 하나의 row에서 직렬화됩니다. 대신 각 옵션을 **N개의 shard row**(`A:0 … A:63`)로 나누십시오. 각 증가는 무작위 shard를 건드리므로 write가 N개의 row에 분산되어 병렬로 실행됩니다. 표시되는 총계는 `SUM(shards)`로, aggregator가 1~2초마다 계산합니다. Redis에서는 단지 N개의 `INCR` key이고, DynamoDB에서는 N개의 partition key입니다.

## 1인 1표 dedup

idempotency 키로 "사용자당 1표"를 강제하십시오: `SADD voted:{pollId} {userId}`(또는 조건부 put). 사용자가 이미 존재하면 증가 전에 이벤트를 폐기하십시오. 이를 클라이언트가 아니라 consumer에서 하십시오 — 클라이언트는 거짓말하고 재시도합니다.

## 면접 관점

면접관은 당신이 **단일 hot key 문제(single-hot-key problem)**를 인식하고 "DB replica를 더 추가한다"(replica는 read를 확장하지 이 write를 확장하지 않음)가 아니라 버퍼링 + 샤딩에 손을 뻗는지 파고듭니다. 좋은 답변: "큐와 캐시를 사용한다." 훌륭한 답변: 당신은 **최종적 일관성 트레이드오프(eventual-consistency trade-off)**를 짚습니다 — 실시간 숫자가 현실보다 1초 뒤처진다는 점 — 그리고 그것이 투표 수에는 괜찮지만 투표 종료 후 권위 있게 재계산하는 *최종 공인 결과*에는 안 된다고 주장합니다.

**흔한 함정:** "정확성"을 위해 표마다 데이터베이스 트랜잭션을 사용하는 것. 이 규모에서 바로 그것이 녹아내립니다.

## 트레이드오프 및 실패 모드

- **최종적 집계:** shard 합계는 지연됩니다. 실시간 카운터에는 허용되며, 종료 시 대조하십시오.
- **At-least-once 전달:** Kafka는 재전달할 수 있습니다 — dedup이 증가를 idempotent하게 만들며, 그렇지 않으면 이중 계산됩니다.
- **Hot shard 편향(skew):** shard가 너무 적으면 여전히 경합하고, 너무 많으면 합산이 비싸집니다. 32~128개 shard가 일반적입니다.
- **공정성/부정:** IP/기기별 rate-limit를 두십시오. 1인 1표 SET이 당신의 무결성 경계입니다. 이를 잃으면 crash가 아니라 부정 투표(ballot stuffing)가 되는데 — 어쩌면 더 나쁩니다.

왜 write를 버퍼링하는가

Sharded 카운터가 핫스팟을 제거한다

1인 1표 dedup

면접 관점

트레이드오프 및 실패 모드

관련 질문