▲

OTel을 대체하고 Wide Events로 관찰 플랫폼을 확장하기

 (clickhouse.com)
1P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • LogHouse는 1년 만에 19PiB에서 100PB 이상의 로그 데이터를 처리하며 약 500조 행까지 확장됨
  • OpenTelemetry(OTel) 의 데이터 처리 한계와 비효율성 문제로 인해, 핵심 시스템에 맞는 맞춤형 파이프라인(SysEx) 으로 전환했음
  • 이 전환으로 이벤트 처리량이 20배 증가함에도 CPU 사용률이 10% 이하로 유지되는 효율을 실현했음
  • ClickHouse의 HyperDX 및 ClickStack 도입으로 UI와 데이터 통합, 스키마 유연성, 강력한 데이터 탐색 환경이 구축됨
  • Wide events 및 고카디널리티 모델 채택을 통해, 사전 집계 없는 모든 이벤트 저장과 분석이 가능해졌음

배경 및 변화

  • ClickHouse Cloud를 위한 내부 로깅 플랫폼 LogHouse는, 1년 만에 데이터 규모가 19PiB에서 100PB 이상, 37조 행에서 거의 500조 행까지 증가한 대형 시스템으로 성장함
  • 초기에는 모든 텔레메트리를 OpenTelemetry(OTel) 을 통해 수집했으나, 대량 데이터 환경에서는 성능, 리소스 한계, 데이터 변환 과정에서의 CPU 낭비 및 데이터 손실 문제가 두드러졌음

OTel의 한계와 맞춤 파이프라인 도입 이유

  • OTel의 파이프라인은, 로그가 JSON으로 변환되고, 이후 OTel 형식으로 다시 매핑되며 여러 번 변환과 마샬링이 반복되어 효율이 극도로 낮았음
  • 실제로 OTel 기반으로 초당 2,000만 행을 처리하려면 약 8,000개의 CPU 코어가 필요할 정도였음
  • 트래픽 급증 시 Collector가 과부하로 로그 드롭 현상이 발생하며, 수집되지 못한 데이터가 발생함

SysEx 도입과 구조

  • SysEx(System Tables Exporter) 는 ClickHouse의 system tables를 대상으로 데이터를 본래 타입 그대로, 변환 없이 직접 LogHouse로 옮김
  • 해시 링 구조를 통한 분산 스크래핑, 시간 지연 버퍼 및 슬라이딩 윈도우 방식으로 데이터 누락 방지, 내부 SLA 충족
  • Go 언어 및 ClickHouse 클라이언트 커스텀 기능을 이용해 데이터 마샬링 없이 byte-to-byte 전송이 가능함
  • 스키마가 가변적인 점을 위해, 스키마 해시와 동적 스키마 관리를 적용하고, Merge table engine으로 여러 스키마 버전을 하나의 논리적 뷰로 통합함
  • 스냅샷 기반 메모리 테이블 수집, 고도화된 진단 및 분석 작업 지원

성능 및 효율성 개선

  • SysEx의 도입으로 OTel Collector가 초당 200만 로그를 800개 CPU로 처리하는 반면, SysEx는 70개 CPU로 3,700만 로그를 처리할 수 있게 됨
  • 이러한 효율성 향상으로 리소스 사용량 극감, 이벤트 손실 방지, 실시간 지원 환경 구현

OTel의 지속적 역할

  • OTel은 표준, 벤더 중립 플랫폼 제공, 서비스 장애나 비정상 상태에서는 여전히 필수
  • SysEx로 처리하지 못하는 크래시·비정상 상황에서도 로그 캡처 가능
  • 현재는 트레이스 레벨 이하의 로그만 제거하고, info 레벨 이상만 수집해 리소스 최적화 중

UI 및 HyperDX, ClickStack 통합

  • 기존 커스텀 Grafana UI에서 HyperDX 기반의 ClickHouse-native UI로 점차 전환
  • HyperDX는 스키마 독립적, Lucene 쿼리 지원, SQL 지원 등 ClickHouse의 광범위한 데이터 유형과 완벽한 호환성 제공
  • 다양한 테이블 구조 및 맞춤 Exporter 출처의 데이터도 UI 변경 없이 통합 가능함
  • Grafana는 Prometheus 기반 메트릭 및 고정 대시보드를 담당하는 등, 두 솔루션이 상호 보완적으로 사용됨

Wide Events 및 고카디널리티 모델 수용

  • Wide events는 각 행에 쿼리 ID, Pod 이름, 버전 정보 등 다양한 컨텍스트를 포함시켜, 집계 없이 모든 데이터를 저장하는 획기적 방식임
  • 이런 방식은 Prometheus 등과 달리, 사전 집계, 레이블 제한, 카디널리티 폭발 걱정 없이 심층 분석과 유연한 쿼리가 가능함
  • 데이터 분석 시점에 필요한 집계를 진행함으로써, 대량 데이터 환경에서도 성능과 비용을 모두 잡음

데이터 시각화 및 쿼리 유연성

  • ClickHouse는 Plotly, Jupyter notebook 등과의 연동이 뛰어나 여러 시각화 도구를 자유롭게 활용할 수 있음
  • Lucene 기반 HyperDX의 빠른 탐색 외에도, 복잡한관계·조건 쿼리(SQ L, JOIN 등)를 통한 고도의 원인 분석이 ClickHouse에서 바로 가능함

다양한 Wide Event 기반 데이터 소스 증대

  • kubenetmon: Kubernetes 네트워크 감시 오픈소스, L3/L4 트래픽, 연결, 비용 분석
  • Kubernetes Event Exporter: ClickHouse 싱크 추가 포크 활용, 대규모 클러스터 상태 변화 추적, 전체 오브젝트 스냅샷 실험 중
  • Control Plane Data, RUM(Real User Monitoring) , Istio Access Log 등 다양한 레이어의 데이터로 해석 범위 및 상관분석 능력 대폭 강화

운영상 고려점 및 향후 방향

  • SysEx가 쿼리 중 로그, 메트릭에 노출될 수 있으나 메모리 제한, 오류 시 영향 최소화 구조로 설계
  • Zero-impact scraping: 완전 디커플링 구조(예: S3 기반 plain rewritable disk 활용)로, 클러스터에 미치는 영향조차 근본적으로 제거하는 방식 연구 중
  • OTel은 서비스 초기·비정상 상태에서의 로그 확보 등으로 여전히 중요한 요소이나, 향후 zero-impact 방식이 안정화되면 의존도 더욱 낮아질 전망

ClickHouse JSON 타입의 진화와 활용

  • JSON 타입이 정식 GA 출시되어, 필드별 동적 컬럼 생성, 여러 타입 지원, 스키마 폭발에도 유연하게 대처 가능
  • 대량의 컬럼을 가진 JSON 질의 시 최적화가 완벽하지 않아 형태별 병행 저장, Map 타입의 실용성 재확인 등 접근방식 고도화 중
  • HyperDX와의 연계로 Map, JSON 필드 자동 추출·분석 가능, 향후 JSON의 폭넓은 활용 계획

결론 및 문화적 변화

  • LogHouse는 이제 성능 분석부터 실시간 디버깅까지 ClickHouse Cloud 운영의 핵심 관찰 플랫폼으로 자리 잡음
  • 비용 절감이 출발점이었지만, SysEx와 같은 맞춤 도구, OTel과의 조화, HyperDX 기반의 유연한 UI 확대 등으로 기술적·문화적 전환을 경험 중
  • 대규모, 고정확도의 Wide Event 기반 데이터 모델이 엔지니어링, 지원, 데이터 분석 모든 영역에 새로운 가치와 효율성을 제공함
  • 앞으로도 100PB, 500조 행의 스케일에서 얻은 경험을 바탕으로, 관찰성의 미래를 계속 선도할 계획임
▲
GN⁺ 3일전  [-]
Hacker News 의견
  • 솔직히 이건 대단한 자랑거리가 아니라고 생각함. 100PB나 되는 로그를 저장하고 있다는 건, 아직 뭘 진짜로 남겨야 하는지 못 찾았다는 증거. 대부분의 핵심 정보는 메트릭과 구조화된 이벤트로 충분히 파악 가능. 나머지는? 아무도 안 읽는 디테일한 트레이스 로그, 정말 장애 터졌을 때나 봄. 더 잘할 수 있는 방법은? 한 번도 알람에 활용되지 않은 로그, 혹은 3개월 동안 검색에도 안 걸린 로그는 자동으로 삭제하는 식의 ‘관심도 기반 저장 정책’ 도입. 이런 식으로 가지 않는 한, 이건 그냥 아주 고급 디지털 쓰레기 더미에 압축만 좀 한 수준
    • 나는 반대로 모든 데이터를 모으고, 필요 없을 때 필터링하는 쪽을 선호함. 디버그 로그는 평소엔 필요 없지만, 필요할 때는 진짜 없어서는 안 되는 존재. 어떤 이벤트가 재현도 안 될 만큼 희귀한 경우엔, 그때서야 데이터를 다시 모을 수 없음. 이미 전부 저장돼 있으면 찾기만 하면 되니까 훨씬 낫다고 생각
    • 여러 회사에서 Datadog을 쓰면서, 갱신 비용이 터무니없게 나오면 메트릭과 제한된 이벤트만 남기고 로그는 줄이자는 압박을 많이 받았던 경험 있음. 문제는, 어떤 일이 터질지 미리 알았으면 진작에 고쳤을 거라는 점. 뭔가 이상하면 도대체 무슨 일이 있었나 찾을 때는 디테일 로그가 매우 필요함. 그런데, 반복적으로 일어나는 상황이 아니면 어떤 로그가 중요한지 알 방법이 없다는 게 현실
    • ‘관심도 기반 저장 정책’ 정말 멋진 아이디어임. 로그 패턴별로 쿼리/알람 접근 횟수만 카운트해도 TTL(저장 기간) 정책 세울 수 있음. 실제로 우리 팀도 이 방식 도입해서 저장 비용 70% 줄이면서, 중요한 데이터는 다 남김
    • 로그 전송 비용도 공짜가 아님. 특히, 크래쉬 원인 파악을 위해 최대한 빨리 디스크에 로그를 쓰는 언어일수록 더 비용이 커짐. 정보가 너무 많으면 진짜 중요한 상관관계 찾기도 힘들고, 해결된 버그의 로그는 가치가 금방 떨어짐. 난 통계 데이터를 선호함. 통계 데이터는 집계 방식이 효율적이고, 특히 GIL 기반 언어에선 OTEL 사용 시 오버헤드가 과도한 경우도 있음
    • 데이터가 이미 저장돼 있다면, 이후 필터링이나 정리는 할 수 있는 문제라고 봄. 데이터를 다 저장해두고 필요할 때 쓰는 게, 필요할 때 없어서 고생하는 것보단 낫다고 생각함. 물론, 이런 대용량 인프라를 운영할 수 있는 리소스가 있다는 전제하에 가능한 얘기
  • 이건 사실 Clickhouse 로그에만 해당되는 내용. 다른 종류 로그에는 별로 연관 없음. 물론 Clickhouse 자체는 아주 마음에 드는 솔루션이긴 하지만
    • 파티에서 엄청 재밌는 타입일 것 같음
  • 주의할 점 하나 언급할게. 서비스가 크래시 루프에 빠지거나 장애로 다운됐을 땐, SysEx로는 필요한 시스템 테이블에 접근 불가라 로그를 수집할 수 없음. 하지만 OpenTelemetry(OTel)는 수동적인 방식이라 서비스가 완전히 정상화되지 않았더라도 stdout, stderr로 나오는 로그를 챙길 수 있음. 이런 식으로 장애 상태에서도 로그를 모아서 근본 원인까지 분석 가능
    • 내가 해온 OTel 프로젝트들은 모두 능동적인 방식이었음. 그래서 저 내용은 딱히 새로운 정보라기보단, 잘못됐거나 불완전한 설명인 것 같음
  • '와이드 이벤트(wide event)'가 진짜 이렇게나 많은 저장 공간을 잡아먹어야 하는지 의문. 관찰(Observability)이란 건 본질적으로 샘플링 문제임. 최소한의 저장 공간으로, 특정 시점의 상태를 최대한 잘 복원할 수 있으면 됨. 샘플 개수를 줄이거나 압축 효율을 끌어올리면 됨. 그런데, 압축 기술이 아직 한계까지 간 것도 아니라고 봄. 중복 투성이 데이터엔 반드시 엄청난 저차원(low rank) 구조가 있을 거라 생각. 물론 이미 인버티드 인덱스나 각종 트리도 쓰고 있지만, 더 실험적인 저차원 텐서 분해 같은 연구적인 방법에도 희망이 있다고 느낌. 나도 업계 사람은 아니라 뭔가 빠뜨린 게 있을 수도 있음
  • ClickHouse 정도 스케일은 경험 못 해봤음. 이런 볼륨의 로그는 정말 검색 가능? ElasticSearch는 소규모엔 쿼리가 잘 되는 걸로 알고 있음. 역사적 로그용으로 json 파일 저장하는 방식 대신 ClickHouse를 써야 하는 이유는 뭘까?
    • 이 스케일에서 일하고 있음. 결론부터 말하자면, 가능은 함. 하지만 처리 비용이 상상을 초월할 수 있음. 인덱싱, 정렬, 클러스터링 전략이 엉망이면, "이 문자열이 들어간 레코드" 한 번 검색하는 데 $1~$10도 나옴. 내 경험상 대용량 데이터에선 무조건 "최대한 적은 데이터만, 최대한 적게 만지기"와 "최대한 덜 옮기기" 원칙이 중요. 직렬화/역직렬화 또는 디스크, 네트워크 IO가 한 번만 들어가도 비용이 폭증. 이러면 OTel의 경우, 데이터 수집기(collector) 한 번 더 거치는 게 효율성에 정면 위배될 수 있음. 하지만 페타바이트 스케일에선 이런 작은 최적화를 통해 아낀 돈이, 복잡한 직렬화 코드를 짜는 엔지니어 연봉을 뽑고도 남음
    • 왜 ClickHouse를 json 파일보다 히스토리 로그 용도로 쓰냐고? 이유는 여러 가지. (1) ClickHouse 같은 로그용 DB는 컬럼 단위 압축으로 각 필드별로 따로 압축해서 일반 json 파일(압축된 것 포함)보다 훨씬 작은 저장 공간. (2) 로그 DB는 쿼리 속도가 훨씬 빠름. 1000배 이상 빠른 것도 가능. 이유는 필요 없는 데이터는 아예 안 읽으니까. 관련 링크. (3) 100PB의 json 파일을 grep으로 검색하는 건 현실적으로 불가능. 로그 DB는 저장 노드, 저장 공간만 늘리면 수평 확장으로 가능한 구조
    • 규모와 비용의 문제임. 우리 회사도 로그 볼륨 문제에 부딪침. json을 Splunk로 그냥 넣으면 연간 600만 불 넘게 듦. 그런데 승인된 예산은 5~10%밖에 안 됨. 본문에서 json 로그 처리에 8,000개 CPU가 필요하다고 했는데, 최적화 후엔 90개 CPU만으로 해결된다고 함
    • 2~3년 전엔 ClickHouse가 전문(full text) 검색 성능이 아쉬웠음. 빠르고 ElasticSearch급 대용량 처리도 되긴 하는데, 사용 용도에 따라선 미리 인덱싱 안 하면 ES가 묶음, 그룹핑, FTS엔 훨씬 빠른 편이라고 느낌
  • 관측팔 극단주의는 진짜 신흥 종교 느낌. 그리고 돈도 엄청 많음
    • 알려지지 않은 이상현상까지 파고들려면, 딱히 뾰족한 대안이 없는 상황
    • 재밌는 건, 이런 문제로 고생하라고 만들더니 결국 "월정액만 내면 다 해결" 전략으로 파는 아이러니 상황
  • 본문에서 로그 보존 기간(리텐션)이 얼마인지 얘기가 없었음. 특정 기간 지나면 요약/집계 데이터만 남기고 원본 데이터는 굳이 보유 필요성에 의문
  • Clickhouse 쓰다가 Postgres로 돌아오면 항상 문화 충격 느낌. 20GB 덤프 임포트하는 데 몇 분씩 걸린다는 게 납득이 안 됨. 이거 몇 초면 하지 않아야 하는 상황 아닌가
    • Clickhouse 사용할 때마다 너무 힘듦. 물론 Clickhouse가 필요한 쓰임새가 있고, Postgres가 다 대체할 수 있는 건 아니지만, 왠지 Clickhouse는 ‘위험요소’가 많고, 특별히 제한된 목적 아니면 거의 모든 면에서 Postgres가 더 낫다고 느낌
  • 넓은(wide) 이벤트를 쓰라는 압박을 받는 사람들은 로그용 데이터 비용 폭증 이야기를 안 함. 기존 방식(메트릭+트레이스+샘플 기반 로그)이랑 비교하면 확실히 돈 많이 듦. 분명 이득도 있지만, 비용 문제는 항상 빠짐
    • 제대로 설계된 wide event 구조는 오히려 전통적 로그보다 저장 비용을 줄일 수 있음. 한 번의 외부 요청이 하나의 wide event로 남으니까, 이후 디버깅이나 분석에도 필요한 정보가 다 담김. 관련 글 참고 A practitioner's guide to wide events
  • Clickhouse나 Dynamo와 같은 시스템의 핵심 트릭이 궁금함. 본질적으로 거대한 해시테이블 같은 구조인지?
    • Clickhouse 등 대용량 DB에 공통된 트릭 두 가지가 있음. 첫째, 디스크에 데이터를 똑똑하게 배치해서 대부분의 데이터를 무시하고 필요한 덩어리만 읽어내는 방식(컬럼 지향 저장 및 LSM 트리류 등). 그리고 저장 데이터를 모두 압축해서 디스크 IO까지 최소화. 둘째, 모든 자원(CPU, RAM, 디스크, 네트워크)을 최대한 활용하게 하는 극한의 튜닝. 예를 들어 Clickhouse는 CPU 코어 하나당 초당 10억 개 이상의 로우를 처리할 수 있고, 코어 수에 맞게 선형적으로 확장됨
답변달기