리포트와 ML을 위한 대용량 이벤트 트래킹 파이프라인을 설계하세요 — 어떤 스택을 쓰나요?

Question

IT Interview Practice · Accepted Answer

하루 수억 건의 이벤트(초당 수천 건, 피크에는 더 높음) 규모에서 이기는 수는 수집(ingestion)과 서빙(serving)을 분리하는 것입니다: 쓰기를 내구성 있는 로그로 흡수하고, 스트림을 한 번 처리한 뒤, 정반대 작업에 맞춰 튜닝된 두 저장소 로 팬아웃합니다 — 부모용으로는 사전 집계(빠른 읽기), ML용으로는 원본 그대로의 full-fidelity 데이터.

우편실 — 컬렉터는 우편을 받고, Kafka는 컨베이어 벨트이며, 모든 물품은 두 선반에 복사됩니다: 부모가 힐끗 보는 , 그리고 ML 팀이 파고드는 .

**멘탈 모델:** 우편실 — 컬렉터는 우편을 받고, Kafka는 컨베이어 벨트이며, 모든 물품은 두 선반에 복사됩니다: 부모가 힐끗 보는 *요약 게시판*, 그리고 ML 팀이 파고드는 *전체 아카이브*.

## 쓰기 경로 (수집)

```text
Client ─(batch)─▶ Collector ─▶ Kafka ─▶ Stream proc ─┬─▶ OLAP rollup  (daily summaries)
 (learning app)    (HTTP)     (buffer,   (read once)  └─▶ S3 / Parquet (raw events)
                              replay)
```

- **컬렉터(Collector)** 는 HTTP로 **배치(batched)** 이벤트를 받습니다 — 클라이언트에서의 배칭은 수억 건의 작은 쓰기를 훨씬 적은 수의 요청으로 바꿉니다.
- **Kafka** 는 내구성 있는 버퍼입니다: 스파이크를 흡수하고, 프로듀서와 컨슈머를 분리하며, ML이 피처를 추가하거나 새 rollup을 도입할 때 히스토리를 **replay** 할 수 있게 합니다.
- **스트림 프로세서(Stream processor)** 는 Kafka를 한 번 읽고 두 sink에 모두 씁니다 — 원본은 레이크에 append하고, 리포트용 rollup은 upsert합니다.

```js
// 하나의 컨슈머가 Kafka를 한 번 읽고 두 sink에 모두 씀
for await (const batch of kafka.consume('events')) {
  await lake.appendParquet(batch);                      // 원본 -> S3/Parquet (ML)
  for (const e of batch)
    rollup.add({ childId: e.childId, day: dayOf(e.ts) },// 집계 -> OLAP (리포트)
               { lessons: 1, studiedMs: e.studiedMs ?? 0 });
  await rollup.flush();
}
```

## 읽기 경로 (서빙)

```text
Parent app ─▶ API ─▶ OLAP rollup                 (pre-aggregated: report = O(1), no scan)
ML / Data  ─▶ Spark / warehouse ─▶ S3 / Parquet  (raw, flexible, ad-hoc)
```

부모는 **사전 집계된 요약** 을 조회하므로, 리포트는 키 조회일 뿐 수십억 행에 대한 스캔이 아닙니다. ML은 **원본 레이크** 를 쿼리하여 피처 엔지니어링을 위해 모든 필드를 유지합니다.

## 스택 & 이유
- **Kafka** — 버퍼, 분리(decouple), replay.
- **ClickHouse / 일별 요약 테이블** — 부모 대시보드를 위한 읽기 최적화.
- **S3 + Parquet** — ML을 위한 저렴하고 컬럼 지향적이며 유연한 원본 저장소.
- **스키마 레지스트리(Schema registry)** — 이벤트 계약(contract)을 강제하여 프로듀서가 컨슈머를 조용히 깨뜨리지 못하게 함.

## 인터뷰 관점
면접관은 여러분이 **쓰기 최적화 수집과 읽기 최적화 서빙** 을 분리하는지, 부모 리포트마다 원본 이벤트를 스캔하지 않는지, ML을 위해 원본 데이터를 유지하는지 확인합니다. **약함:** "전부 Postgres에 넣고 쿼리한다." **강함:** 내구성 있는 버퍼 + 두 개의 서빙 경로 + replay + 스키마 계약, 그리고 스케일에 대한 감각.

## 트레이드오프
사전 집계는 즉각적인 읽기를 주지만 차원(dimensions)을 미리 고정합니다. 원본 레이크는 유연하지만 느립니다. **둘 다** 유지하세요 — 고전적인 write-once, read-many 분리입니다.

쓰기 경로 (수집)

읽기 경로 (서빙)

스택 & 이유

인터뷰 관점

트레이드오프

관련 질문