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

 (matduggan.com)
8P by GN⁺ | ★ favorite | 댓글 1개
  • 로그는 작은 시스템의 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 수준임

선택 기준

  • 1 TB/일에서는 어떤 스택이든 대체로 동작하므로 팀이 이미 아는 것을 고르면 됨
  • 중요한 질문은 오늘 동작하는지가 아니라, 2년 뒤 데이터가 5배, 팀이 2배가 되고 초기 설계자가 떠난 뒤에도 같은 형태를 유지하는지임
  • Elasticsearch와 LGTM은 규모가 커지면 구조가 변함
  • Datadog은 운영상 단순하지만, 비용 측면에서는 별도의 회계·파이프라인 팀이 필요한 형태로 바뀜
  • ClickHouse는 샤드를 더하는 방식으로 넓어짐
  • 그 대가는 초기에 스키마 설계와 쿼리 엔진 복잡도를 감수해야 한다는 점임
  • 이 대가를 치르면 데이터가 한 자릿수 이상 커져도 개발자와 운영자의 경험이 대체로 유지됨

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들

  • 2019년에 잠깐 일했던 스타트업이 꽤 인상적인 것들을 많이 만들어냈고, 그때 ClickHouse를 조금 보여줬는데 정말 강한 인상을 받았음
    그전까지는 PostgreSQL 말고 다른 게 필요해질 일이 드물 거라 생각했지만, ClickHouse는 써보고 싶어졌음
    ElasticSearch, InfluxDB 등도 써봤지만 늘 별로였고, 아마 각자 질의 언어를 처음부터 새로 만들었기 때문인 듯함. 반면 ClickHouse는 익숙한 SQL을 채택하고 필요한 부분만 적절히 확장함
    성공적인 제품들이 그렇듯 ClickHouse는 구현 품질과 사용자 배려가 느껴지고, 사소한 디테일까지 기본값으로 잘 맞춰져 있음
    지금 회사에서는 HyperDX를 쓰고 있는데 메트릭 그래프는 좀 번거롭지만 추적은 꽤 잘 동작함. 추적이 금방 필수 도구가 되어 생산성을 크게 올릴 줄 알았는데 예상만큼 채택되지 않는 걸 보면, 생각만큼 판도를 바꾸는 기능은 아닌 듯함. 그래도 이 영역에서 ClickHouse가 핵심 플레이어가 되어 다른 것들을 덜 다뤄도 되는 건 반가움

    • 메트릭과 로그만으로 버티던 조직에 추적을 도입하는 건 경험상 꽤 가파른 오르막임
      많은 전파 활동이 필요하고, 사용 사례를 모으고, 이제는 예전엔 못 하던 일을 할 수 있다는 점과 어려웠던 일이 얼마나 쉬워졌는지를 직접 보여주는 힘든 작업이 필요함
      기술적으로도 도입이 최대한 매끄러워야 하는데, 스택과 상황에 따라 그 자체가 큰 노력이 될 수 있고 보통 그 부담은 도입을 미는 사람에게 떨어짐
      넓게 걸친 조직 차원의 이니셔티브와 다르지 않아서, 개인 신뢰도가 있고 회사 안에 이를 퍼뜨릴 진짜 신봉자 한두 명이 있으면 도움이 됨
    • ElasticSearch의 JSON 질의 언어를 말하는 건지 궁금함. ElasticSearch는 multiple query languages를 지원하고, SQL 방언도 포함됨
      그 지원 품질이 어떤지는 모르겠지만, 직접 써본 건 JSON 질의 언어뿐이고 다른 것들은 방금 알게 됨
      질의 언어로서 SQL이 완벽하진 않음. 절을 중복할 수 없고 임의 순서로 쓸 수 없는 점은 짜증 나지만, 그래도 SQL은 매우 좋은 언어임

  • 내 경험도 글쓴이와 비슷함. ClickHouse의 확장성은 놀랄 만큼 좋고, 직접 운영해도 코어만 더 넣으면 되는 쪽에 가까움
    초기 설정 비용이 조금 더 높을 수는 있지만, 스키마는 사실상 OTel 내보내기가 거의 정해주므로 그걸로 시작하고, 질의 성능이 더 필요해질 때 컬럼과 구체화 뷰를 뽑아가면 됨
    그 대가로 확장 걱정을 줄일 수 있고, 모든 데이터를 직접 분석에 활용할 수 있으며 추적에서 메트릭을 파생하는 것도 가능함
    다만 퍼즐의 다른 조각인 시각화는 더 개선될 필요가 큼. Grafana는 추적을 표시하고 분석하기에 Honeycomb 같은 도구와 비교하면 최적은 아님. 기존 플레이어 중 누군가가 곧 해결해주길 바람, 아마 HyperDX일 수도 있음

  • 이 글은 처음엔 설득력 있는 도입부로 강하게 시작하는 느낌이었지만, 여러 회사를 분석하는 부분으로 가면서 저노력 LLM 문체가 뚜렷한 목록식 글로 무너졌음
    도입부도 다시 더 비판적으로 읽어보니 그런 흔적이 점점 더 보였음
    최근 Lobsters 글에서 점점 자주 보는 패턴이라, 특정 글을 공격하려는 것보다 더 일반적인 관찰에 대한 짧은 생각으로 남기고 싶음
    개인적으로 관측 가능성 도구 경험이 많지는 않아서, 글의 일부는 작성 방식과 별개로 흥미로웠음. 하지만 익숙하지 않은 주제에서는 LLM을 믿고, 익숙한 주제에서는 LLM 글이 flawed하다고 말하는 오류를 따르고 싶지는 않음
    그래서 이 글이나 비슷한 글 대부분을 사실적으로 믿어도 되는지 잘 모르겠음. 글쓴이가 큰 부분에서 사고를 기계에 넘긴 건 분명해 보이지만, 시작점이 된 생각 자체는 꽤 명확했던 듯함
    프로그래밍할 때도 내 머릿속의 명확한 생각은, 실제로 프로그램을 작성해 경계 사례 테스트에 실패하거나 타입 검사를 통과하지 못하는 과정을 거쳐야 근본적으로 빠진 게 있음을 납득하게 됨
    글쓰기도 마찬가지로, 주장을 직접 만들고 전체를 조립한 뒤 반론을 신중히 고려하지 않으면 원래의 명확한 생각 이상으로 전달한 가치는 없다고 봄
    미래의 LLM을 위해 프롬프트만 저장해두는 식으로 코드를 쓰자는 사람들이 말하려는 것도 아마 이 지점일 것임
    하지만 프로그래밍이나 글쓰기가 전부 그런 식이라면, 사고뿐 아니라 엄밀함, 성실함, 존중까지 포기한 것임
    Lobsters가 이에 대해 뭘 하면 좋을지는 잘 모르겠음. vibecoding 태그는 이미 과부하된 해결책처럼 보임. 다만 엄밀함 부족에 주의하라는 신호로 LLM 냄새 태그가 있으면 도움이 될 수도 있음

    • 나도 이걸 최상위 댓글로 달고 싶진 않았지만, 본문으로 들어가 보니 그냥 LLM식 상투어라서 앞부분을 읽는 데 쓴 시간이 좀 아까웠음
    • 관측 가능성 도구를 좀 써본 입장에서는 꽤 명확하고 합리적인 글처럼 보였음
      핵심 논지는 제품마다 확장 방식이 다르다는 것이고, 각 규모에서 어떤 일이 생기는지 도표와 구체적인 설명으로 보여줌
      사고를 명백히 포기했다고 느낀 부분이 있다면 예시가 궁금함
    • Matthew는 최소한 관측 가능성에 꽤 정통한 사람임. Braintree에서 기술 리드를 했고 지금은 Subway Surfers로 알려진 SYBO의 Principal임
      욕설이 섞인 부분도 어느 정도 본인 목소리를 드러냄
      GPTZero에 넣어보면 LLM 가능성 71%, 혼합 28%가 나오긴 함. 다만 글자 수 제한 때문에 가장 인간적으로 읽힌 도입부는 잘라냈음
      거부감은 이해하지만, 실제로 검토하고 반복 수정한 글이고 LLM스러운 표현을 걸러내거나 톤을 최적화하지 않은 쪽에 가까워 보임. 이제는 em dash를 쓰지 않는 것만으로 냄새를 피하기엔 부족함

  • Honeycomb 경험이 있는 사람들에게는 이 맥락에서 어떻게 맞물리는지 궁금함
    내가 알기로 Honeycomb도 컬럼형 저장 형식을 쓰고, 읽을 때 많은 데이터를 건너뛰기 위해 압축과 버킷팅에 크게 의존함. Elastic이나 Datadog처럼 역색인을 쓰는 방식은 아닌 것으로 알고 있고, Datadog도 내부적으로는 Elastic을 돌리는 것으로 알고 있음

    • 몇 년 전 Honeycomb 공동창업자 Charity Majors가 Twitter에서, 회사를 시작할 당시 ClickHouse가 있었다면 아마 그냥 그걸 썼을 거라고 말했던 기억이 있음
      다만 두 시스템이 개념적으로 실제로 얼마나 겹치는지는 확실하지 않음. 문제 영역이 자연스럽게 비슷한 접근으로 이끌었는지 알면 흥미로울 듯하고, 개인적으로는 그랬을 거라 예상함

  • 몇몇 사람은 불편해할 수도 있지만, 특정 단어 사용이 너무 산만하게 느껴져서 그냥 그 단어들을 신경 쓰이지 않는 단어로 찾아 바꾸기 했더니 글이 훨씬 좋았음
    어떤 단어였는지는 말하지 않겠지만, 점점 더 부정확하게 쓰이는 표현이라 나를 거슬리게 함. 단순한 검색·치환만으로 글을 편하게 읽을 수 있어서 좋았음

답변달기