OTel을 대체하고 Wide Events로 옵저버빌리티 플랫폼 확장하기

 (clickhouse.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • ClickHouse의 내부 LogHouse는 1년 만에 19PiB·약 40조 행에서 100PB 이상 비압축 로그와 거의 500조 행을 저장하는 규모로 커짐
  • 기존 OpenTelemetry 중심 수집 경로는 JSON, OTel 포맷, ClickHouse Native 포맷을 오가며 CPU 비용과 로그 드롭 위험을 키웠음
  • ClickHouse는 SysEx(System Tables Exporter)로 시스템 테이블을 LogHouse에 바이트 단위 복사해 37M logs/s를 70 CPU 코어로 처리함
  • OTel은 stdout·stderr 기반 장애 로그와 벤더 중립 표준 포맷에 계속 유용하지만, 핵심 ClickHouse 텔레메트리는 SysEx와 wide events 중심으로 이동함
  • HyperDX 도입 이후 ClickHouse 네이티브 UI, Lucene 문법 검색, SQL 분석, 스키마 비의존 탐색을 결합해 Grafana 기반 커스텀 UI의 일부 역할을 대체하고 있음

LogHouse가 100PB와 500조 행 규모로 커짐

  • LogHouse는 ClickHouse Cloud 모니터링을 위해 만든 내부 로깅 플랫폼이며, 이전에는 커지는 Datadog 비용을 대체하는 역할도 했음
  • 1년 전에는 19PiB 비압축 데이터와 37조 행을 처리했고, 현재는 100PB 이상 비압축 데이터와 거의 500조 행을 저장함
  • 현재 저장 데이터의 주요 구성은 다음과 같음
    • SysEx: 93.6PB, 431조 행
    • OTel: 14.5PB, 16.7조 행
  • 이전에는 모든 텔레메트리가 OpenTelemetry를 통과했지만, 지금은 대부분의 데이터가 ClickHouse가 만든 목적 특화 exporter인 SysEx에서 들어옴

OpenTelemetry 파이프라인의 한계

  • OpenTelemetry는 Kubernetes 환경의 모든 Pod 로그를 ClickHouse로 보내는 초기 표준 파이프라인으로 적합했음
  • ClickHouse의 stdout 텍스트 로그만으로는 운영 분석에 충분하지 않았고, 실제 분석에는 system 테이블의 구조화 로그, 메트릭, 실행 세부 정보, 디스크 I/O, 백그라운드 작업 상태가 필요했음
  • 기존 OTel 로그 경로는 여러 변환 단계를 거쳤음
    • 고객 ClickHouse 인스턴스가 로그를 JSON으로 stdout에 기록함
    • kubelet이 /var/log/…에 로그를 저장함
    • OTel collector가 디스크에서 로그를 읽고 JSON을 파싱해 메모리 표현으로 변환함
    • collector가 이를 OTel 로그 포맷으로 다시 변환함
    • ClickHouse Go client가 ClickHouse Native 포맷으로 재변환해 LogHouse에 삽입함
  • 실제 OTel 파이프라인에는 edge collector, OTLP 전송, gateway collector, 추가 처리까지 포함되어 각 단계가 오버헤드·지연·복잡성을 늘림
  • 규모가 커지면서 두 문제가 두드러짐
    • ClickHouse Native 타입이 JSON과 OTel 포맷을 거치며 CPU를 낭비하고 데이터 충실도가 낮아짐
    • Kubernetes 노드의 OTel agent가 CPU·메모리 제한에 걸려 트래픽 급증 시 로그 라인을 드롭함
  • OTel 기반으로 20M rows/s를 손실 없이 처리하려면 agent와 collector 전체에 약 8,000 CPU 코어가 필요할 것으로 추정됨

SysEx: ClickHouse-to-ClickHouse 전송에 특화한 수집기

  • ClickHouse는 System Tables Exporter(SysEx) 를 만들어 고객 Pod의 ClickHouse 시스템 테이블에서 LogHouse 테이블로 데이터를 직접 전송함
  • SysEx는 소스와 목적지 사이에서 바이트 단위 복사를 수행해 ClickHouse Native 타입을 보존하고 중간 변환을 제거함
  • 이 구조 덕분에 엔지니어가 live instance 디버깅에 쓰던 쿼리를 LogHouse의 전체 플릿 과거 데이터 쿼리로 쉽게 바꿀 수 있음
    • 테이블 스키마가 동일하고, Pod 이름·ClickHouse 버전 같은 enrichment 컬럼만 추가됨
  • 아키텍처는 SysEx scraper 풀과 hash ring으로 구성됨
    • hash ring이 고객 Pod를 특정 scraper replica에 배정해 부하를 분산함
    • scraper는 소스 Pod의 system table에 SELECT를 실행하고 데이터를 LogHouse로 스트리밍함
    • scraper는 역직렬화 없이 소스와 목적지 사이의 바이트 전달을 조율함
  • 시스템 테이블의 버퍼 flush 누락을 피하기 위해 SysEx는 슬라이딩 시간 창을 쓰며, 일반적으로 실시간보다 5분 늦게 쿼리함
  • Go ClickHouse client의 기본 동작은 데이터를 Go native type으로 변환하므로, ClickHouse는 내부 marshalling을 우회하는 기능을 clickhouse-go에 기여함
  • SysEx는 pull 기반 모델이라 OTel처럼 무거운 버퍼링이 필요 없고, LogHouse가 일시적으로 사용할 수 없거나 소스 텔레메트리가 급증해도 과거 window를 다시 scrape해 백필할 수 있음

동적 스키마와 상태 스냅샷

  • SysEx는 소스와 타깃 스키마가 일치해야 하지만, ClickHouse system table 스키마는 새 메트릭과 컬럼 추가로 자주 바뀜
  • 이를 처리하기 위해 SysEx는 system table을 만나면 스키마를 검사하고 hash한 뒤 LogHouse에 같은 스키마 테이블이 있는지 확인함
    • 있으면 기존 테이블에 삽입함
    • 없으면 text_log_6 같은 새 스키마 버전을 생성함
  • 쿼리 시점에는 ClickHouse의 Merge table engine을 사용해 여러 스키마 반복을 하나의 논리 뷰로 묶음
  • Merge table engine은 호환 컬럼만 선택하거나 요청 컬럼이 있는 테이블로 쿼리를 제한해 스키마 변화에도 수동 관리 없이 조회할 수 있게 함
  • ClickHouse는 system.processes 같은 인메모리 system table도 주기적으로 스냅샷으로 캡처해 LogHouse에 저장함
  • 이 스냅샷은 특정 시점의 클러스터 상태, 테이블 스키마, 클러스터 설정을 과거 기준으로 분석하는 데 쓰임

전체 플릿 분석과 효율 수치

  • SysEx 덕분에 고객이 개별 ClickHouse 인스턴스 모니터링에 쓰는 Advanced Dashboard queries를 전체 고객 인스턴스 플릿에 동시에 실행할 수 있음
  • 릴리스 분석에서는 배포 전후에 진단 쿼리를 실행해 쿼리 성능 패턴, 리소스 사용 추세, 오류율 변화를 플릿 규모에서 실시간으로 확인함
  • 지원 대시보드는 Advanced Dashboard 쿼리와 함께 네트워크 로그, Kubernetes 이벤트, data plane·control plane 이벤트를 같은 인터페이스에서 상관분석함
  • LogHouse 기준 효율 비교는 다음과 같음
    • OTel Collectors: 800 CPU 코어 이상으로 2M logs/s 전송
    • LogHouse Scrapers(SysEx): 70 CPU 코어로 37M logs/s 전송
  • SysEx는 가장 중요한 데이터 소스에서 이벤트 볼륨을 20배 늘리면서 CPU footprint를 기존의 10% 미만으로 줄였고, edge에서 이벤트를 드롭하지 않게 됨

OpenTelemetry가 여전히 필요한 영역

  • OpenTelemetry는 표준화된 벤더 중립 포맷과 신규 사용자 온보딩 경험을 제공하므로 ClickStack의 기본 선택지로 남아 있음
  • SysEx는 ClickHouse 내부와 강하게 결합되어 있고 live system table을 쿼리하는 pull 기반 구조라, 서비스가 crash loop 중이거나 down 상태이면 데이터를 scrape할 수 없음
  • OpenTelemetry는 stdout과 stderr에 emit된 로그를 passive하게 캡처하므로 서비스가 완전히 healthy 상태가 아니어도 장애 중 로그를 수집할 수 있음
  • ClickHouse는 모든 ClickHouse 서비스에서 OpenTelemetry를 계속 실행하되 수집 범위를 바꿈
    • 이전에는 trace-level 로그까지 모두 ingest함
    • 현재는 info-level 이상만 수집함
  • 이 변경 이후 OTel collector와 gateway는 훨씬 적은 리소스로 동작하며, 앞서 언급한 2M log lines/s 규모의 더 작은 파이프라인으로 유지됨

HyperDX와 ClickHouse 네이티브 탐색 경험

  • LogHouse의 첫 UI는 Grafana 위에 구축한 커스텀 옵저버빌리티 경험이었지만, SysEx와 wide-column 텔레메트리가 늘면서 ClickHouse에 더 깊게 통합된 UI가 필요해짐
  • HyperDX는 ClickHouse 네이티브 UI로 로그·트레이스 탐색, 상관분석, 대규모 분석을 지원함
  • Lucene 문법으로 쿼리할 수 있어 데이터 탐색이 단순해지고, 복잡한 이벤트 분석에는 SQL을 계속 사용할 수 있음
  • HyperDX v2.0의 스키마 비의존 접근은 단일 고정 로그 테이블 구조를 요구하지 않음
    • OpenTelemetry 파이프라인의 표준화되지만 변화하는 데이터 포맷을 처리함
    • SysEx와 다른 custom exporter의 specialized wide-column table도 사전 스키마 지식이나 복잡한 grok pattern 없이 처리함
  • Grafana도 여전히 LogHouse에서 역할이 있음
    • 내부 Grafana 기반 앱은 namespace를 지정하게 해 서비스별 데이터 위치를 알고 적절한 ClickHouse 인스턴스로 쿼리를 라우팅함
    • Prometheus 메트릭 기반의 기존 대시보드와 알림은 여전히 Grafana에 남아 있음
    • kube_state_metrics 같은 고수준 메트릭은 deep investigation에는 적합하지 않아도 alerting에는 적합함

Wide events와 고카디널리티 옵저버빌리티

  • SysEx 도입은 stdout 로그 중심 수집에서 system table 기반 wide events와 고카디널리티 데이터 중심 모델로 전환하게 함
  • ClickHouse는 이를 Observability 2.0 대신 LogHouse와 ClickStack의 결합으로 부름
  • 이 모델은 전통적인 세 기둥 모델 대신 중앙 warehouse에 여러 소스의 고카디널리티 텔레메트리를 저장함
  • 각 row는 query identifier, Pod 이름, version metadata, network detail 같은 풍부한 context를 포함하며, metric store 제한에 맞추기 위해 dimension을 사전 집계하거나 버리지 않음
  • ingest 시점에 요약하지 않고 원본 그대로 저장한 뒤 집계는 query time으로 미룸
  • Prometheus와의 차이는 모든 data point를 저장한다는 점임
    • insertDuration 같은 필드를 사전 집계하지 않고 각 값을 관련 dimension과 함께 보존함
    • Prometheus에서 모든 label 조합의 timeseries를 저장하면 카디널리티 폭증이 생김
    • histogram 사전 집계는 리소스 사용을 제어하지만, 특정 spike가 어떤 instance, table, time window의 insert인지 묻기 어렵게 함
  • Elasticsearch도 wide events와 유연한 document 구조를 장려했지만, ClickHouse의 columnar design은 고카디널리티·고볼륨 이벤트 데이터를 대규모로 효율 저장하고 쿼리할 수 있게 함

데이터 과학 도구와 SQL 분석

  • wide event 하나에서 여러 특성을 시각화할 수 있고, 차트의 특정 지점에서 raw log로 되돌아갈 수 있음
  • ClickHouse는 데이터 시각화 통합과 언어 클라이언트를 제공하므로 Plotly, Jupyter notebook, Hex, Bokeh, Evidence 같은 SQL 기반 도구를 사용할 수 있음
  • HyperDX의 Lucene 문법 검색은 빠른 조회와 필터링에 적합하지만, 복잡한 질문에는 SQL이 필요함
  • ClickHouse SQL은 join, 시간 기반 연산, 변환을 표현할 수 있음
    • 예시는 Kubernetes event stream에서 같은 container의 Killing 이벤트와 Created 이벤트를 ASOF JOIN으로 맞춰 종료 후 재시작까지 걸린 시간을 계산함
    • 예시 쿼리는 17.78M rows와 581.49MB를 처리했고 0.099초가 걸렸으며 peak memory는 272.88MiB였음
  • 필요한 메트릭을 미리 component로 만들어 배포하지 않고, wide events warehouse에서 query time에 도출할 수 있음

LogHouse에 추가된 데이터 소스

  • LogHouse는 엔지니어링·지원 팀 요청에 따라 더 많은 wide event 기반 데이터 sink를 추가함
  • kubenetmon: Kubernetes 네트워킹 모니터링용 오픈소스 도구이며 Linux conntrack을 사용해 L3/L4 connection data와 byte·packet count를 캡처함
  • Kubernetes Event Exporter: 인기 exporter를 fork하고 ClickHouse native sink를 추가해 Kubernetes API 이벤트를 대규모로 분석함
    • fork: ClickHouse/kubernetes-event-exporter
    • 앞으로 이벤트뿐 아니라 전체 Kubernetes object model을 LogHouse에 ingest하고, 모든 변경 시점의 snapshot을 저장하는 계획을 진행 중임
  • Control Plane Data: LogHouse에 아직 온보딩되지 않았던 Control Plane 부서의 운영 데이터를 수집함
  • Real User Monitoring(RUM): 진행 중인 프로젝트로, 사용자 브라우저의 frontend performance metric을 public gateway를 통해 OTel 파이프라인으로 보냄
  • Istio Access Log: Istio service mesh의 HTTP-level traffic data를 ingest해 request·response pattern, latency, routing decision을 캡처함
    • system.query_log, kubenetmon network flow와 결합해 SQL query, HTTP request, packet flow를 교차 분석함

다음 단계: zero-impact scraping과 JSON

  • SysEx scrape query는 strict memory limit로 제한되어 있지만, 고객이 로그와 메트릭에서 이를 볼 때 우려가 생길 수 있음
  • ClickHouse는 live system에 쿼리를 실행하지 않는 zero-impact scraping을 탐색 중임
    • ClickHouse가 service log를 이미 쓰는 S3의 plain rewritable disk를 활용하는 방향이 유망함
    • SysEx worker pool이 disk 기반 log table을 직접 mount하면 실행 중인 ClickHouse instance 쿼리를 우회할 수 있음
  • 이 접근이 성공하면 native format, high fidelity, 최소 변환이라는 현재 장점을 유지하면서 운영 영향에 대한 인식까지 줄일 수 있음
  • ClickHouse의 JSON 타입은 25.3에서 GA에 도달했고, 새 필드 등장 시 적절한 타입의 컬럼을 동적으로 만들며 여러 타입 필드와 schema explosion도 처리함
  • LogHouse는 JSON이 대규모 옵저버빌리티 접근 패턴에 얼마나 맞는지 평가 중임
    • JSON blob 전체에서 문자열을 찾으면 수천 개 컬럼을 스캔할 수 있음
    • 구조화 데이터와 함께 raw string JSON을 저장하는 우회책이 있음
    • 대부분의 log·resource attribute는 작고 안정적이어서 Map type도 여전히 적합함
    • HyperDX는 map access를 JSONExtract 함수로 자동 변환함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이건 결국 ClickHouse 로그 수집에만 관련 있는 얘기지, 다른 로그에는 별로 해당되지 않음
    ClickHouse는 정말 좋아하지만, 범용적인 얘기로 보긴 어려움

  • 주목할 만한 대목은 이 부분임
    서비스가 크래시 루프에 빠졌거나 내려가 있으면 SysEx는 필요한 시스템 테이블을 사용할 수 없어 데이터를 스크레이프하지 못함
    반면 OpenTelemetry는 수동적으로 동작해 서비스가 실패 상태여도 stdout과 stderr로 나온 로그를 캡처함
    그래서 장애 중에도 로그를 모으고, 서비스가 완전히 정상 상태가 된 적이 없어도 근본 원인 분석이 가능함

    • 내가 해본 OpenTelemetry 작업은 전부 능동적 방식이었음
      그래서 이게 특별히 주목할 만하다기보다, 틀렸거나 불완전한 정보에 가까움

  • ClickHouse 수준의 규모에서 일해본 적은 없음
    이 정도 양의 로그 데이터를 검색할 수 있나? ElasticSearch는 소규모 로그 데이터에는 질의 기능이 있다고 봄
    과거 로그 데이터라면 JSON 파일로 저장하는 대신 왜 ClickHouse를 써야 하나?

    • 이 규모에서 일하는 입장에서 보면, 검색은 가능함
      다만 예상하듯 처리 비용이 엄청날 수 있음. 색인·정렬·클러스터링 전략이 잘못 잡히면 “이 문자열을 포함한 레코드 찾기” 같은 단순 질의 하나도 1~10달러 수준으로 비용이 나갈 수 있음
      페타바이트 단위 데이터를 다루는 규모에서는 최고의 최적화가 결국 “가능한 한 적은 데이터를, 가능한 한 적은 횟수로 건드리기”와 “가능한 한 적게 이동시키기”였음
      직렬화·역직렬화가 들어가거나 디스크·네트워크 입출력이 발생할 때마다 성능 비용과 실제 지출이 크게 늘어남
      그래서 OpenTelemetry Collector는 입출력과 직렬화 단계가 하나 더 생기므로 효율성과 충돌할 수 있음. 반대로 페타바이트 규모라면 그 한 단계를 없애서 절약되는 돈만으로 직렬화·역직렬화 로직만 쓰는 엔지니어 한 명의 비용을 충당할 수도 있음
    • 과거 로그 데이터를 JSON 파일로 저장하지 않고 ClickHouse를 쓰는 이유는 여러 가지가 있음
      ClickHouse나 VictoriaLogs 같은 로그 최적화 데이터베이스는 각 로그 필드의 값을 묶어 개별 압축하는 열 지향 저장 방식을 쓰기 때문에, 압축된 JSON 로그 파일보다도 저장 공간이 더 작아질 수 있음
      또 JSON 파일에 grep을 돌리는 것보다 일반적인 질의를 훨씬 빠르게 수행함. 필요 없는 데이터를 읽지 않기 때문에 성능 향상이 1000배 이상일 수도 있음. 참고: https://chronicles.mad-scientist.club/tales/grepping-logs-re...
      마지막으로 100페타바이트짜리 JSON 파일을 어떻게 grep할 것인가? 로그 최적화 데이터베이스는 저장 노드와 공간을 추가해 수평 확장할 수 있어서 이런 양의 로그도 질의 가능함
    • 핵심은 규모와 비용임
      회사에서도 로그 규모 문제를 겪고 있는데, 단순히 “JSON을 Splunk에 밀어 넣기” 방식으로 가면 연간 600만 달러가 넘게 들고, 승인받을 수 있는 예산은 그중 5~10% 정도뿐임
      글에서도 JSON 로그를 처리하는 데 CPU 8000개가 필요했지만 이후에는 CPU 90개만 필요했다고 나옴
    • 몇 년 전 ClickHouse는 전문 검색이 그리 좋지 않았고, 그게 나에게는 가장 큰 단점이었음
      더 빠르고 ElasticSearch 규모도 감당할 수는 있지만, 사용 사례에 따라 전문 검색이나 사전 구축 색인 없는 그룹화를 할 때는 ElasticSearch 질의가 훨씬 빠를 수 있음

  • 관측 가능성 극대주의는 일종의 컬트고, 그것도 아주 돈 많은 컬트임

    • 알 수 없는 미지의 문제를 조사하려면, 사실 대안이 많지 않음
    • 자기들이 문제를 만들어주고, 적은 월 사용료로 해결해주는 구조가 웃김

  • 와이드 이벤트가 정말 이렇게 많은 공간을 차지해야 하나?
    관측 가능성은 상당 부분 표본 추출 문제에 가깝고, 목표는 최소 저장 공간으로 특정 시점의 환경 상태를 최대한 잘 재구성하는 것임
    표본 수를 줄이거나 압축 능력을 개선해서 달성할 수 있음
    후자에 대해서는 이미 압축에서 대부분의 효율을 짜냈다고 믿기 어려움. 저 중복 데이터에는 엄청난 양의 저랭크 구조가 있을 것임
    물론 이런 회사들이 이미 역색인과 여러 트리 구조를 쓴다는 건 알지만, 저랭크 텐서 분해 같은 더 연구적인 접근을 효율적으로 수행할 방법을 찾으면 기존 방법을 압도할 수 있지 않을까 싶음
    다만 이 업계에 있는 건 아니라 뭔가 놓치고 있을 수도 있음

    • 100PB는 전체 보존 기간인 180일 동안의 원시 비압축 데이터 총량임
      비용 효율을 가능하게 하는 건 압축이고, 이 데이터셋에서는 약 15배 압축이 나와서 저장 시점에는 약 6.5PB만 보관함

  • 상관관계에 대한 정보가 많지 않음
    상태가 있는 사용 사례에서 관측 가능성을 위한 최신 도구와 기법은 뭘까?
    SFU 기반 화상회의 앱을 예로 들면, 사용자 기기가 세션에 참여하기 위해 여러 API 호출을 거침. 이제 어떤 사용자가 다른 참가자의 영상을 볼 수 없다고 보고했다고 해보자
    물론 첫 번째 사용자 기준으로 로그와 추적을 필터링하고, 다시 두 번째 사용자 기준으로 필터링해서 시그널링 교환과 프론트엔드·백엔드 오류를 수동으로 볼 수는 있음
    더 나은 접근이 있을까?

  • ClickHouse를 쓰다가 Postgres로 돌아오면 항상 충격을 받음
    20GB 덤프를 가져오는데 몇 분 동안 대체 뭘 하는 건가 싶음. 몇 초면 끝나야 하는 거 아닌가?

    • ClickHouse를 쓸 때마다 너무 괴롭고, 특히 Postgres가 있다는 걸 알고 있으면 더 그럼
      ClickHouse가 쓸모없다거나 Postgres가 ClickHouse가 하는 모든 걸 할 수 있다는 뜻은 아님
      다만 ClickHouse에서 작업하는 게 정말 싫고, 이상한 실수 유발 지점이 많음
      아주 구체적이고 제한적인 방식으로 쓰는 게 아니라면 거의 모든 면에서 Postgres보다 나쁘게 느껴짐

  • 와이드 이벤트를 안 쓴다고 욕하고 판단하는 사람들이 빼먹는 게 바로 이 부분임
    전통적인 메트릭 + 추적 + 표본 기반 로깅에 비해 저장 비용이 크게 늘어남
    이 방식에는 이점도 있지만 비용도 있고, 그 비용 부분은 늘 빠져 있음

    • 제대로 구현된 와이드 이벤트는 보통 모든 걸 제멋대로 로깅하는 방식보다 저장 비용을 줄임
      외부 요청 하나가 정확히 와이드 이벤트 하나로 이어지고, 그 요청을 나중에 디버깅하거나 분석하는 데 필요한 모든 정보를 담는 게 기대되는 형태임
      참고: https://jeremymorrell.dev/blog/a-practitioners-guide-to-wide...
    • ClickHouse는 와이드 이벤트를 꽤 잘 압축하므로, 고카디널리티 원격측정이 주는 이점과 비교하면 그렇게 극적인 비용 증가는 아님
      참고: https://clickhouse.com/blog/optimize-clickhouse-codecs-compr...

  • 로그를 얼마나 오래 보관하는지, 즉 보존 기간은 못 봤음
    몇 달이 지나면 원시 데이터가 아니라 요약·집계 데이터만 필요할 수도 있음

    • 우리는 180일 동안 보관함

  • 이 업계는 대체로 반쯤 완성됐거나 진행 중인 표준으로 가득 차 있어서 생태계가 쪼개짐
    GraphQL, OpenAPI, MCP 등 뭐든 완벽한 건 없고 그건 괜찮음
    문제는 명세를 만든 사람들이 그냥 시행착오 방식으로 따라가고 있다는 점인데, 이건 좀 말이 안 됨

답변달기