1천만 개의 시간 예약 작업(timed task)을 위한 스케줄러를 어떻게 설계하시겠습니까?

Question

IT Interview Practice · Accepted Answer

작업을 만료 시각을 key로 하는 **시간 버킷(time-bucketed) / 우선순위 큐**에 저장하고, *지금* 만료되는 작업만 poll하며, at-least-once 전달로 idempotent worker에게 넘기십시오. 매 tick마다 1천만 row를 절대 스캔하지 말고, 발화 시각(fire time)으로 인덱싱하여 각 poll이 만료된 것만 건드리도록 하십시오.

## 아키텍처

```text
API ─▶ Task store (DB/Redis ZSET, score = due_ts)  ── 10M tasks, sharded
             │
     Poller (leader per partition) ── ZPOPMIN due<=now ──▶ Ready queue (Kafka)
             │ leader election (etcd/ZK)                       │
             ▼                                                 ▼
     other pollers idle/standby                       Worker pool (idempotent)
                                                        └─ ack ✔ / retry ✖ ─▶ DLQ
```

## 구성 요소와 흐름

- **발화 시각으로 인덱싱된 작업 저장소**: Redis sorted set(`ZADD tasks score=due_ts`) 또는 `(run_at)`으로 인덱싱된 DB 테이블. `ZPOPMIN`/`ZRANGEBYSCORE now`는 이번 초에 만료되는 작업만 가져옵니다 — 테이블 스캔이 아니라 O(log n)입니다. task-id 기준 **샤딩/파티셔닝**은 1천만 작업을 여러 노드에 분산시켜 어떤 단일 저장소도 hot해지지 않게 합니다.
- **리더 선출(leader election)을 갖춘 Poller**: 각 partition은 etcd/ZooKeeper로 선출된 하나의 활성 poller를 가지며, 장애 시 standby가 이어받습니다. partition당 하나의 리더는 두 poller가 같은 작업을 dispatch하는 것을 막고, 파티셔닝은 throughput을 높게 유지합니다.
- **Ready 큐(Kafka)**: 만료된 작업이 enqueue되어 *스케줄링*과 *실행*을 분리합니다. worker는 poller와 독립적으로 확장됩니다.
- **Idempotent worker**는 실행하고 **ack**합니다. 전달이 at-least-once이므로 작업이 두 번 실행될 수 있습니다(poller가 dispatch 후 완료 표시 전에 crash) — 따라서 작업 자체가 `task_id` 기준으로 idempotent해야 하며, 그렇지 않으면 고객에게 이중 청구합니다. 실패는 backoff로 재시도한 뒤 DLQ로 들어갑니다.

## 면접 관점

면접관은 두 가지를 파고듭니다: **효율적인 시간 조회**와 **exactly-once vs at-least-once**. "좋은" 답변은 테이블을 도는 cron 루프이고, "훌륭한" 답변은 sorted-set 인덱스에 더해 분산 exactly-once가 비현실적이라는 솔직한 인정, 그래서 **at-least-once + idempotent worker**를 선택하는 것입니다. 전형적인 함정: 단일 스케줄러 노드에 의존하는 것 — SPOF이자 throughput 상한입니다. 또 다른 함정: 작업이 초 단위 정밀도를 요구하는데 너무 성기게(매 분) polling하거나, 너무 촘촘히 하여 저장소를 두드리는 것입니다.

## 트레이드오프와 실패

- **정밀도 vs 부하**: 1초 tick은 초 단위 정확도를 주지만 poll이 더 많습니다. 작업을 분 단위 → 초 단위 하위 큐로 버킷화하여 스캔 비용을 줄이십시오(Kafka와 Quartz가 쓰는 "timing wheel" / hashed-wheel 방식).
- **At-least-once vs exactly-once**: crash 경계를 넘어 진정한 exactly-once는 얻을 수 없습니다. idempotency 키가 이중 실행을 무해하게 만듭니다 — 올바른 트레이드오프입니다.
- **실패**: poller가 dispatch 도중 죽으면 리더 선출이 standby를 승격시키고 ack되지 않은 작업이 재전달됩니다 — 아무것도 잃지 않고 일부가 반복될 수 있습니다. 노드 간 **clock skew**(NTP)를 주시하십시오. 그렇지 않으면 작업이 일찍/늦게 발화합니다. 또한 영구히 실패하는 작업이 영원히 루프하지 않도록 재시도를 제한하고 — 검사용으로 DLQ로 보내십시오.

아키텍처

구성 요소와 흐름

면접 관점

트레이드오프와 실패

관련 질문