심한 경합 하에서 hot key나 hot row를 어떻게 처리하시겠습니까?

Question

IT Interview Practice · Accepted Answer

**모든 트래픽을 하나의 key로 몰아넣는 것을 멈추십시오: hot key를 N개의 서브 key(sharded counter)로 나누고, 중복 read를 병합(coalesce)하며, 로컬 캐시에서 제공하고, write를 batch하여 한 row가 매 요청마다 업데이트되지 않게 하십시오.** 바이럴 게시물의 단일 "좋아요" 카운터는 초당 5만 write를 받을 수 있습니다 — 모든 트랜잭션이 같은 lock을 두고 다투면서 한 row가 직렬화 병목이 됩니다.

## 하나의 경합 row 대신 팬아웃

```text
                 50k inc/sec on post:123
                          │
             hash(request) % N   (split the key)
        ┌────────┬────────┬────────┬────────┐
        ▼        ▼        ▼        ▼        ▼
   likes:123:0  :123:1  :123:2  :123:3  :123:4   ← sharded counters
        └────────┴───┬────┴────────┴────────┘
                     ▼
             SUM on read = total     (read fans in)
```

## 기법

- **Sharded counter / key 분할.** 무작위로 선택한 `likes:123:{0..N}`에 write하고, 진짜 카운트는 `SUM`입니다. 이는 하나의 hot row를 N개의 더 시원한 row로 바꿔 lock 경합을 약 N배 줄입니다. read는 작은 fan-in 비용을 치릅니다.
- **요청 병합(single-flight).** 1만 개의 요청이 동시에 같은 key를 원하면 **하나**만 DB를 치게 하고 나머지는 그 진행 중인 결과를 기다리게 하십시오. cache-miss stampede가 row를 짓밟는 것을 막습니다.
- **로컬(in-process) 캐시.** hot 값을 각 앱 노드에 짧은 TTL(예: 1초)로 캐시하십시오. read-hot key의 경우 이는 초당 수천 read를 하나의 갱신으로 접습니다 — 약간의 staleness를 감수합니다.
- **Write 배칭.** 증가를 메모리에 버퍼링하고 500번의 단일 업데이트 대신 초당 한 번 `+= 500`을 flush하십시오. 초당 500이 아니라 초당 한 번의 row 업데이트가 경합을 완전히 제거합니다.

## 면접 관점

면접관은 당신이 **경합이 어디에 있는지** 진단하고 read-hot vs write-hot에 맞게 해결책을 고르는지 보고 싶어 합니다. Read-hot → 캐시 + 병합; write-hot → sharded counter + 배칭. 좋은 답변은 기법을 나열하고, 훌륭한 답변은 샤딩이 **read 비용과 write 확장성을 맞바꾼다**는 점과 배칭/캐싱이 **신선도와 throughput을 맞바꾼다**는 점을 짚습니다.

**트레이드오프 & 함정:** sharded counter는 정확한 실시간 총계를 더 어렵게 만들고(shard를 합산) "0 미만으로 감소" 로직을 복잡하게 합니다. 로컬 캐시는 노드 간에 drift합니다 — 좋아요 수에는 괜찮지만 은행 잔고에는 틀립니다. 배칭은 노드가 flush 전에 crash하면 버퍼된 write를 잃을 위험이 있으므로, 금전이 아니라 idempotent/근사 카운터에 적합합니다. 데이터의 일관성 요구가 허용하는 완화책을 고르십시오.

하나의 경합 row 대신 팬아웃

기법

면접 관점

관련 질문