하루 수백만 건의 트랜잭션에 대한 실시간 매출 분석: 어떻게 하시겠습니까?

Question

IT Interview Practice · Accepted Answer

**트랜잭션을 Kafka를 통해 스트림 프로세서로 흘려보내 OLAP 저장소에 사전 집계(pre-aggregate)하여, 대시보드가 원시 이벤트를 스캔하는 대신 아주 작은 사전 계산된 rollup을 읽게 하십시오.** 하루 수백만 건에서는 페이지 로드마다 원시 테이블에 `SUM()`을 절대 실행하지 않습니다 — write 시점에 한 번 집계합니다.

## 아키텍처

```text
Payment svc ──▶ Kafka topic ──▶ Flink/Kafka Streams ──┬─▶ OLAP (ClickHouse/Druid)  ◀── Dashboard
 (txn events)   (buffer,replay)   (windowed pre-agg)    │      (per-minute rollups)     (read)
                                                         └─▶ S3/Parquet (raw, replay/audit)
                                     state store ◀──────────┘  (exactly-once checkpoints)
```

## 동작 방식

- **Kafka**는 내구성 있는 로그입니다. 모든 결제가 이벤트(`amount`, `currency`, `ts`, `merchant`)를 발행합니다. 스파이크를 버퍼링하고, producer를 consumer로부터 분리하며, 집계를 다시 빌드하기 위해 히스토리를 **리플레이**할 수 있게 합니다.
- **스트림 프로세서(Flink / Kafka Streams)**는 **tumbling/sliding window**(분/시간 단위)를 유지하며 각 이벤트를 **state store**의 누적 합계에 접습니다(fold). 출력은 (분, dimension)별 사전 집계된 row입니다.
- **OLAP 저장소(ClickHouse, Druid, Pinot)**는 그 rollup을 columnar로 저장합니다. "최근 24시간 매출"을 쿼리하는 대시보드는 수백만 개가 아니라 약 1,440 row를 스캔합니다 — 1초 미만.
- ClickHouse의 **materialized view**는 moving part를 줄이고 싶다면 DB 내부에서 동일한 rollup을 수행할 수 있습니다(`AggregatingMergeTree`).

## 면접 관점

면접관은 당신이 **write 시 사전 집계 vs read 시 스캔**을 아는지, 그리고 **exactly-once**를 이해하는지 파고듭니다. 좋은 답변은 Kafka + OLAP를 짚고, 훌륭한 답변은 **늦은/중복 이벤트가 왜 총계를 오염시키는지**와 이를 고치는 법을 설명합니다: idempotent 키, exactly-once를 위한 Flink **checkpointing + transactional sink**, 그리고 늦게 도착해도 window를 닫는 **watermark**. 흔한 함정은 Postgres에서 `SELECT SUM()`을 제안하는 것 — 하루 수천 건에는 괜찮지만 수백만 건에서는 붕괴합니다.

## 트레이드오프 및 실패

- **Lambda vs Kappa.** Lambda는 스트림 계층(빠르지만 근사) 옆에 batch 계층(야간 Spark가 진실 공급원을 대조)을 둡니다 — 정확하지만 코드베이스가 둘입니다. **Kappa**는 스트림 계층만 사용하고 버그를 고치기 위해 **Kafka를 리플레이**합니다 — 더 단순하고, 코드베이스가 하나이며, 이제 흔한 기본값입니다.
- **Exactly-once는 공짜가 아니다.** transactional sink는 latency와 throughput 비용을 더합니다. 많은 팀이 대신 `txn_id`로 키잉된 **at-least-once + idempotent upsert**를 받아들입니다.
- **늦은 데이터.** 2시간 늦게 정산되는 결제는 window가 닫힌 뒤에 도착합니다. watermark + allowed-lateness가 window를 다시 열거나, 야간 batch job이 어제 숫자를 보정합니다.
- **다중 통화 / 환불**은 부호 있는(signed) 이벤트로 모델링해야 하며, 그렇지 않으면 "매출"이 어긋납니다.
- **하지 않아야 할 때:** 하루 수천 건은 이 중 아무것도 필요 없습니다 — cron이 갱신하는 Postgres rollup 테이블이 운영해야 할 Kafka+Flink 클러스터보다 낫습니다.

아키텍처

동작 방식

면접 관점

트레이드오프 및 실패

관련 질문