ClickHouse가 Observability 전쟁에서 앞서가는 이유

2 hours ago 2

로그는 작은 시스템의 grep 경험과 달리, 서비스와 소비자가 늘면 대용량·비정형·예측 불가 쿼리가 겹쳐 Observability에서 가장 다루기 어려운 데이터가 됨
ClickHouse는 클릭스트림 분석용 DB로 출발했지만, 고볼륨·추가 중심·시간 순서·집계 읽기라는 로그의 사용 패턴과 잘 맞음
컬럼 지향 저장 방식은 필요한 컬럼만 읽게 해주며, 실제 Observability 데이터에서 10–14x 압축률을 보여 Elasticsearch의 2–3x와 대비됨
1 TB/일 규모에서는 여러 스택이 모두 가능하지만, 5 TB/일과 10 TB/일로 커질수록 Elasticsearch·LGTM·Datadog은 구조나 비용이 크게 바뀌고 ClickHouse는 주로 샤드 추가로 확장됨
ClickHouse는 초기 스키마 설계와 쿼리 엔진 복잡도를 요구하지만, 데이터가 한두 자릿수로 늘어도 운영 모델이 크게 흔들리지 않음

로그가 Observability에서 어려운 이유

개발자는 작은 시스템에서 grep, jq, tail -f로 로그를 빠르게 다뤘던 경험 때문에 로그 검색에 높은 기대치를 가짐
그 방식은 시스템이 작고, 로그 양이 적고, 쿼리하는 사람이 로그 라인을 직접 작성했을 때 잘 통함
규모가 커지면 스키마 드리프트, 카디널리티 폭발, 팀 간 소비자, 대시보드 요구가 동시에 생김
로그를 쓰는 사람은 개발자만이 아님
- 고객지원팀은 특정 사용자의 실패한 결제 같은 사건을 찾아야 함
- 데이터팀은 백엔드 엔지니어가 바꿀 수 있는 로그 라인 위에 비즈니스 대시보드를 만들 수 있음
- 온콜 담당자는 새 쿼리 언어나 인덱스 패턴을 배우지 않고 검색창이 바로 동작하길 기대함
기술적으로는 데이터 양이 크고 형태가 불규칙하며, 어떤 쿼리가 들어올지 예측하기 어려움
개발자는 즉시성, 임의 연산, 느슨한 스키마를 원하고, 비기술 사용자는 안정적인 대시보드와 관대한 UI를 원함

ClickHouse가 로그에 맞는 구조

ClickHouse는 Yandex에서 클릭스트림 데이터의 대규모 분석 쿼리를 처리하기 위해 만들어짐
Observability 전용으로 설계된 것은 아니지만, 클릭스트림과 Observability 데이터는 닮은 점이 많음
- 대량 데이터
- 추가 중심 쓰기
- 시간 순서 중심
- 집계 읽기 위주
- 가끔 특정 레코드를 찾아야 하는 사용 패턴
운영 방식도 여러 선택지가 있음
- Helm chart로 직접 실행 가능함
- Grafana의 ClickHouse 플러그인, 자체 웹 UI, 직접 만든 프런트엔드를 사용할 수 있음
- OpenTelemetry Collector의 ClickHouse exporter로 OTLP 데이터를 직접 넣고 초기 스키마 관리를 맡길 수 있음
수십억 행을 스캔하고 매우 큰 데이터량을 수집하도록 설계됨
쿼리 언어는 새 전용 언어가 아니라 SQL임

컬럼 지향 저장과 압축이 만드는 차이

로그는 데이터 형태상 append-only에 가까움
- 로그 라인은 업데이트하지 않음
- 개별 삭제는 거의 없고, 보존 기간이 끝나면 대량 삭제함
- 대체로 시간 순서대로 도착하지만 완전히 정렬되지는 않음
읽기 패턴은 장애나 분석 시점에 폭발적으로 바뀜
- 며칠 동안 아무도 보지 않다가 장애 중에는 수십억 개를 몇 초 안에 훑고 싶어 함
- 좁은 시간 범위에서 여러 필드를 보거나, 넓은 시간 범위에서 몇 개 필터로 집계하는 일이 많음
- 트랜잭션 DB처럼 특정 ID의 한 행을 찾는 패턴은 드묾
Elasticsearch, Postgres, MySQL 같은 행 지향 DB는 한 로그 라인의 모든 필드를 함께 저장함
- 40개 필드 중 3개만 필요해도 디스크에서는 40개를 읽게 됨
ClickHouse는 각 컬럼을 따로 저장함
- timestamp, service, status_code만 쓰는 쿼리는 해당 컬럼만 읽음
- 수십 개 속성이 있어도 특정 쿼리가 3~4개 컬럼만 쓰는 Observability 데이터에서는 읽기량 차이가 커짐
컬럼 데이터는 같은 컬럼 안의 값이 서로 비슷해 압축이 잘 됨
- service_name 컬럼은 수십억 행에서도 고유 문자열이 수백 개일 수 있음
- 실제 Observability 데이터에서 10–14x 압축률을 흔히 볼 수 있음
- Elasticsearch의 2–3x와 뚜렷하게 대비됨

1 TB/일에서는 대부분의 스택이 가능함

1 TB/일 규모에서는 현대 Observability 스택이 대체로 쓸 만하며, 차이는 있지만 아직 고통스럽지 않은 수준임
Elasticsearch
- 비교적 기본적인 Elasticsearch 클러스터와 Logstash 버퍼로 운영 가능함
- 전체 텍스트 검색은 Elasticsearch의 강점이며, 이 규모에서는 잘 동작함
- 혼합 데이터에서는 mapping explosion 위험이 있어 dynamic mapping을 끄거나 템플릿을 신중히 잡아야 함
- ILM 정책인 hot → warm → delete는 이 규모에서도 필수임
- 비용은 대략 월 $6–9K 수준임
LGTM
- Alloy가 수집을 단일 데몬으로 통합함
- Loki는 개발자가 유용한 레이블을 붙이도록 교육해야 잘 동작함
- Mimir와 Tempo는 기대한 역할을 대체로 수행함
- 비용은 대략 월 $3.5–5K 수준임
Datadog
- 1 TB/일에서는 에이전트를 설치하고 대시보드를 보면 되는 수준으로 사용성이 좋음
- metered pipeline, indexed-vs-ingested logs 구분, custom metrics cardinality 비용 문제가 보이지만 이 규모에서는 관리 가능함
- 비용은 대략 월 $45–75K이며, 협상 가격 차이가 커 숫자는 크게 봐야 함
- Datadog의 가격 논리는 전담 엔지니어 1명을 절약한다는 식임
ClickHouse
- 1 TB/일에서는 ClickHouse가 다른 선택지보다 덜 복잡하지 않음
- 초기에 스키마 설계가 필요하고, ORDER BY 키가 매우 중요함
- ZSTD와 적절한 코덱으로 10–14x 압축을 얻을 수 있음
- Altinity Operator가 keeper coordination을 처리하고, 전체는 약 7개 pod로 실행됨
- 네이티브 PromQL은 없으며, 메트릭 워크플로는 Grafana 플러그인이나 chproxy와 adapter를 거침
- 비용은 대략 월 $1.5–2.5K 수준임

5 TB/일에서 구조 차이가 벌어짐

5 TB/일에서는 대부분의 스택에서 증가 곡선이 가팔라지고, ClickHouse와의 격차가 더 잘 보임
Elasticsearch
- Kafka가 사실상 필수가 됨
- 직접 Elasticsearch에 쓰면 트래픽 스파이크 중 bulk reject와 backpressure로 클러스터가 내려갈 수 있음
- 50GB target shard 기준 replica까지 포함해 하루 약 200개 shard가 생기며, cluster state 크기 자체가 문제가 됨
- searchable snapshot과 frozen tier 때문에 Elastic 상용 라이선스가 거의 필요함
- 비용은 라이선스 전 월 $40–55K 수준임
LGTM stack
- 65개 이상 pod와 세 개의 별도 시스템을 운영하는 마이크로서비스 모드가 됨
- 각 시스템마다 compaction pipeline, hash ring, memcached tier가 있음
- gossip/memberlist ring이 실제 운영 관심사가 됨
- ingester rollout에는 -ingester.autoforget-unhealthy 조정이 필요하고, 잘못하면 데이터 손실이나 중복이 생김
- 비용은 대략 월 $22–32K 수준임
Datadog
- 서버를 직접 운영하지 않으므로 운영 복잡도는 낮음
- 대신 Datadog 비용을 줄이는 전담 파이프라인 팀이 필요해짐
- exclusion filter, sampling rule, cardinality cap, tag allow-list 같은 장치가 생김
- 비용은 파이프라인 팀의 공격성에 따라 대략 월 $180–350K 수준임
- SaaS 제공자의 청구 문서를 보며 비용을 줄여야 하는 관계가 됨
ClickHouse
- 가장 큰 변화는 샤드 추가임
- operator, query engine, query language, mental model은 그대로 유지됨
- 샤드 추가 후 재분산은 수동이며, 대부분의 팀은 사전 프로비저닝이나 Distributed table의 weighting으로 우회함
- dashboard rollup용 materialized view는 있으면 좋은 수준에서 필수에 가까워짐
- 비용은 대략 월 $7–11K 수준임

10 TB/일에서 운영 모델이 갈라짐

10 TB/일은 많은 솔루션이 운영 부하를 감당하기 어려워지는 규모임
Elasticsearch
- logs, metrics, APM용으로 별도 Elasticsearch 클러스터 3개를 운영하고 Cross-Cluster Search로 묶게 됨
- hot-tier NVMe 비용이 청구액을 지배함
- 이 규모에서 팀들이 대안을 진지하게 평가하기 시작하며, 최근 ClickHouse 마이그레이션도 여기서 많이 나옴
- 비용은 상용 라이선스 외에 대략 월 $95–140K 수준임
- 이 규모의 Elasticsearch 운영에는 진짜 전문가가 필요함
LGTM
- 약 180개 이상 pod, zone-aware 구성, split-and-merge compaction, tenant별 limit, noisy neighbor 방지를 위한 shuffle sharding이 필요함
- 전담 Observability platform 팀 3~5명이 거의 필요함
- 비용은 대략 월 $55–85K 수준임
Datadog
- 직접 운영할 서버가 없다는 의미에서는 여전히 쉽지만, 월 청구액은 6~7자리 숫자가 될 수 있음
- 조직은 청구액을 줄이기 위한 전처리 파이프라인 팀을 만들 가능성이 큼
- 이 규모의 많은 회사는 Datadog을 APM과 고가치 메트릭에 쓰고, logs는 자체 호스팅으로 가져가는 하이브리드 구성을 사용함
- 자체 호스팅 대상은 점점 ClickHouse가 됨
- Datadog의 단순함, 파이프라인 복잡도, 두 번째 자체 호스팅 스택이 동시에 존재하는 구조가 됨
- 비용은 매우 다양하며 월 $1M 이상이 될 수 있음
ClickHouse
- 1 TB/일 구성과 기본 그림은 같고, 차이는 샤드가 더 많다는 점임
- rollup용 materialized view는 선택이 아니라 필수가 됨
- 2년 전에 만든 스키마 설계 실수가 이 규모에서 아프게 드러날 수 있음
- 샤드 추가 후 재분산은 여전히 수동임
- 대부분의 팀은 사전 프로비저닝을 하거나 clickhouse-copier, dual-write migration을 사용함
- 매우 bursty한 ingest에는 Kafka가 버퍼로 유용해지지만 필수는 아님
- 비용은 대략 월 $18–28K 수준임