하루 1억 개의 로그 이벤트를 어떻게 저장하시겠습니까?

Question

IT Interview Practice · Accepted Answer

**append-only 파이프라인: agent → Kafka → 계층형 저장소(hot은 ClickHouse/ELK, cold는 object storage)**를 구축하고, 최근 데이터는 인덱싱하고 나머지는 저렴하게 아카이브하는 보존 정책(retention policy)을 두십시오. 하루 1억 이벤트는 평균 초당 약 1,200개(스파이크는 훨씬 높음)이며 하루 수십~수백 GB입니다 — OLTP 의미론이 아니라 저렴한 write와 제한된 쿼리 비용에 최적화합니다.

```text
App/agents ─▶ Kafka ─▶ Consumers ─┬─▶ ClickHouse / ELK   (hot: last 7–30d, indexed, fast search)
 (Fluent Bit)  (buffer,            │
                replay)            └─▶ S3/Parquet         (cold: 90d–years, cheap, scan-on-demand)
                                          │
                                   Lifecycle/tiering ─▶ Glacier (archive) ─▶ delete at retention
```

## Append 파이프라인

로그는 write-once이며 절대 업데이트되지 않으므로 — 수집 경로는 **append**입니다. **Fluent Bit / Vector** 같은 agent가 라인을 **Kafka**로 실어 나르고, Kafka는 버스트를 버퍼링하며 producer를 저장소로부터 분리합니다. ClickHouse가 유지보수로 다운되어도 이벤트는 Kafka에 쌓였다가 리플레이됩니다 — 로그를 잃지 않습니다. per-row insert는 columnar store의 throughput을 파괴하므로 write를 batch(insert당 수천 row)하십시오.

## Hot 저장소: 검색을 위한 인덱싱

최근 로그는 빠른 검색이 필요합니다("최근 1시간, 서비스 X의 오류"). **ClickHouse**(columnar, 10배 압축, 초당 수십억 row 스캔) 또는 **ELK 스택**(Elasticsearch 역인덱스)이 이를 제공합니다. 쿼리가 몇 개 partition으로 pruning되도록 day/service로 파티셔닝하십시오. 이 계층은 GB당 비싸므로 작게 유지하십시오 — 최근 7~30일만.

## Cold 저장소: object storage + 계층화

오래된 로그는 **S3에 Parquet로** 이동합니다 — 저렴하고, 내구성 있으며, Athena/Trino로 필요 시 쿼리 가능합니다. **lifecycle 정책**이 보존 한도(예: 1년)에서 S3 → Glacier → 삭제로 전환합니다. 이 *계층화(tiering)*가 핵심 비용 레버입니다: hot 저장소는 아카이브의 50배 가격일 수 있습니다.

## 면접 관점

면접관은 **인덱스 대 비용 트레이드오프**를 파고듭니다: 전부 인덱싱하면 검색은 훌륭하지만 예산을 날립니다. 아무것도 인덱싱하지 않으면 저렴하지만 쿼리할 수 없습니다. 좋은 답변: "ELK를 쓴다." 훌륭한 답변: 계층화합니다 — 최근 hot 슬라이스는 인덱싱하고 나머지는 cold로 아카이브 — 그리고 수집을 downstream 장애에 강하게 만드는 버퍼로 Kafka를 짚습니다.

**흔한 함정:** 모든 로그를 영원히 Elasticsearch에 넣는 것. 가장 비싼 선택지이며, 계획하지 않은 cardinality/보존에서 클러스터가 무너집니다.

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

- **보존 vs 비용:** 긴 보존 = 선형적 저장소 증가. 공격적으로 계층화하십시오.
- **Kafka 백프레셔:** consumer가 뒤처지면 디스크가 찹니다 — 보존 크기를 정하고 lag를 모니터링하십시오.
- **Cardinality 폭발:** 높은 cardinality 필드(user_id)는 ES 인덱스를 부풀립니다. 샘플링하거나 드롭하십시오.
- **cold 데이터의 쿼리 비용:** Athena 스캔은 TB당 과금됩니다 — 스캔이 제한되도록 Parquet를 date/service로 파티셔닝하십시오.
- **At-least-once 중복:** 정확한 카운트가 중요하면 event id로 dedup하십시오.

Append 파이프라인

Hot 저장소: 검색을 위한 인덱싱

Cold 저장소: object storage + 계층화

면접 관점

트레이드오프 및 실패 모드

관련 질문