상용 APM 의존 벗는 산점도 파이프라인: OpenTelemetry와 ClickHouse 설계

집계 지표 사각지대와 산점도 도입 배경

여기어때 기술블로그를 통해 숙박플랫폼개선TF팀의 박준희 엔지니어는 OpenTelemetry와 ClickHouse를 결합한 APM 산점도(스캐터 차트) 수집 및 저장 계층 설계 과정을 공개했습니다. 개발팀은 기존 관측 환경에서 활용하던 평균 응답시간, P95, P99 백분위 같은 집계 지표가 개별 요청의 극단적 이상치를 가리는 구조적 한계를 안고 있다고 지적했습니다.

일반적인 백분위 지표는 다수의 성공 사례에 가려진 소수의 10초 이상 지연 구간을 온전히 포착하지 못합니다. 상용 APM 도구가 제공하는 스캐터 차트는 모든 요청을 점으로 펼쳐 분포 형태를 유지하지만, 라이선스 종속성과 비용 문제를 수반합니다. 이에 개발팀은 내부에서 이미 수집 중인 OpenTelemetry 트레이스 원본을 ClickHouse에 효율적으로 적재해 독립적인 분석 체계를 구성하기로 결정했습니다.

SpanKind 기반 데이터 분류와 좌표계 정의

스캐터 차트 설계의 핵심 과제는 차트에 찍히는 '점(Point)' 하나를 어떤 단위로 정의할 것인가였습니다. 전체 트랜잭션을 점 하나로 묶으면 화면 구성은 단순해지지만 내부 DB 병목인지 외부 API 지연인지 원인 구분이 불가능해집니다. 반대로 모든 스팬을 그대로 표시하면 화면에 점이 과도하게 쏠려 가독성이 저하됩니다.

개발팀은 스팬 단위를 점으로 삼되, OpenTelemetry 공식 명세에 명시된 SpanKind 구분을 기반으로 UI 제어 계층을 분리하는 방식을 택했습니다. 서버 수신(SERVER), 메시징 소비(CONSUMER), 스케줄러(INTERNAL)는 시스템 진입점으로 정의해 기본 노출하고, 클라이언트 호출(CLIENT)과 메시징 발행(PRODUCER)은 하위 호출로 묶어 필요에 따라 필터링할 수 있도록 설계했습니다.

동시에 X축 좌표를 트레이스 시작 시점이 아닌 종료 시각(시작 시각 + duration)으로 결정했습니다. 요청이 완료되기 전에는 소요 시간을 확정할 수 없기 때문입니다. 다만 저장소 엔진은 통상 시작 시각 기준으로 정렬되므로, 이러한 좌표 매핑 방식은 조회 시 인덱스 스캔 불일치 문제를 유발할 수 있어 정교한 쿼리 튜닝이 요구됩니다.

ClickHouse 컬럼 지향 스토리지와 압축 코덱 활용

시계열 대용량 트레이스 저장소로 선정된 ClickHouse는 대규모 데이터 분석에 특화된 컬럼형 DBMS입니다. 스캐터 차트 렌더링에는 종료 시각, 지연 시간, 상태 코드, URI 등 6개 안팎의 속성만 요구되며, 에러 메시지나 부가 메타데이터와 같이 디스크 점유율이 큰 컬럼은 화면 호출 시 스캔 대상에서 완전히 제외되어 I/O 비용을 크게 줄일 수 있습니다.

또한 컬럼별 물리적 특성에 맞춘 압축 코덱 조합이 적용되었습니다. 단조 증가하는 성격을 지닌 타임스탬프 필드에는 값의 차분만을 기록하는 Delta 코덱과 ZSTD 코덱을 결합했습니다. 자주 조회되는 지연 시간 필드에는 압축 해제 속도가 빠른 LZ4 코덱이 권장되었습니다. 단일 노드 로컬 실측 결과, ZSTD 코덱 적용 시 system.parts 메타데이터 기준으로 원본 크기 대비 약 10분의 1 수준(90% 감소)으로 용량이 절감되는 양상이 확인되었습니다.

희소 인덱스와 MergeTree 파트 관리의 실무 제약

ClickHouse의 핵심 테이블 엔진인 MergeTree는 8,192개 행을 단일 '그랜뉼(Granule)'로 묶고 인덱스 마크를 생성하는 희소 인덱스(Sparse Index) 방식을 취합니다. 모든 행을 인덱싱하는 전통적인 B-Tree 구조와 달리 인덱스 자체의 물리적 크기가 극히 작아, 수십억 건의 트레이스가 유입되어도 주요 인덱스를 메모리(RAM)에 상주시킬 수 있습니다.

그러나 스토리지 엔진의 동작 구조에 따른 실무적 운영 제약도 명확합니다. MergeTree는 삽입 시 불변(Immutable) 상태의 새 파트(Part)를 디스크에 기록하고 백그라운드에서 병합합니다. 만약 OpenTelemetry Collector가 짧은 간격으로 잦은 쓰기를 수행하면 파트 수가 급증하여 'Too many parts' 에러가 발생하고 조회 성능이 급격히 저하됩니다. 따라서 수집기 계층에서 충분한 버퍼를 두고 대규모 배치 단위로 데이터를 플러시하도록 파이프라인을 엄격히 제어해야 합니다.

검증 범위와 향후 해결 과제

이번 아키텍처 검증은 로컬 단일 노드 및 3-Keeper / 2-Shard x 2-Replica 클러스터 환경에서 합성 트래픽을 주입해 수행된 기술 검증 단계입니다. 실제 대규모 라이브 서비스 트래픽이 집중되는 프로덕션 환경에 즉각 도입된 것은 아니므로, 네트워크 대역폭 비용과 멀티 샤드 환경 내 Collector의 메모리 부하 변동폭은 추후 실측을 통한 확인이 필요합니다.

아울러 비단조적으로 튀는 지연 시간(duration) 컬럼에 Delta 코덱을 적용하는 것은 차분 압축 효율을 보장하기 어려워 현장 데이터 기반의 정밀 검증이 권장됩니다. 대규모 점 데이터를 웹 브라우저에서 직접 렌더링할 때 마주하는 메모리 과부하를 해소하기 위해 서버 측 버킷 집계나 롤업을 구현하는 시각화 영역의 세부 대응은 후속 검증 과제로 남아 있습니다.