기본 시각화 도구의 상호작용 한계와 커스텀 플러그인 도입
여기어때 기술블로그를 통해 공개된 내용에 따르면, 개발팀은 오픈텔레메트리 컬렉터(OpenTelemetry Collector)로 수집해 클릭하우스(ClickHouse)에 저장한 개별 스팬 데이터를 직관적인 산점도(Scatter plot) 형태로 표현하는 작업을 진행했습니다. 요청별 응답 지연 시간의 전수 분포를 확인하기 위해서는 단일 요청을 점 단위로 나타내야 했지만, 그라파나에 내장된 기본 패널들로는 운영 요구사항을 충족하기 어려웠다고 밝혔습니다.
기존 타임 시리즈(Time series) 패널은 통상 시간 버킷 기반 집계 쿼리를 선으로 잇는 방식이라 개별 데이터의 분포 특성을 접어버리는 한계가 있었습니다. 히트맵(Heatmap)이나 XY 차트(XY chart) 역시 상태 코드(정상, 지연, 4xx, 5xx)에 따른 색상 구분과 호출 카테고리(HTTP In, 메시지 컨슈머, 스케줄러)에 따른 도형 모양 구분을 동시에 독립적으로 적용하기 어려웠습니다. 특히 화면에서 마우스 드래그로 이상 징후 구간을 지정했을 때 단순 브라우저 줌인이 아니라 서버로 해당 영역의 원본 목록을 재질의하는 상호작용은 기본 패널로 구현할 수 없었습니다.
공식 규격을 준수한 패널 플러그인 아키텍처와 식별자 관리
개발팀은 요구사항을 해결하기 위해 그라파나 커스텀 패널 플러그인을 직접 제작했습니다. 플러그인의 최소 필수 구성 요소는 공식 가이드라인에 규정된 메타데이터 파일 `src/plugin.json`과 프론트엔드 진입점 파일 `src/module.ts`입니다. 메타데이터에는 플러그인 유형, 명칭, 의존 버전, 고유 식별자(ID)가 명시됩니다.
그라파나 공식 문서에 따르면 플러그인 폴더와 식별자는 `<organization>-<pluginName>-<pluginType>` 형태의 표준 명명 규칙을 따르도록 권장됩니다. 이 식별자는 대시보드 JSON 구조, 프로비저닝 설정, 디렉터리 경로 전반에 결합되기 때문에 개발 초기 단계에서 신중하게 확정하지 않으면 변경 시 광범위한 파일 수정이 수반됩니다. 진입점인 `module.ts`에서는 `@grafana/data` 패키지의 `PanelPlugin` 인스턴스를 `plugin`이라는 고정된 이름으로 내보내며 리액트 컴포넌트와 제어 옵션들을 바인딩합니다.
동적 런타임 제어를 위한 커스텀 패널 에디터 구축
그라파나 패널 빌더가 지원하는 정적 입력 컴포넌트만으로는 관측성 도구 간 유기적인 연계 환경을 구성하기 어렵습니다. 점 하나를 클릭했을 때 관련 분산 추적(트레이스)이나 로그로 이동하려면 대상 데이터소스(Tempo 또는 Loki)의 UID를 패널 설정에서 지정할 수 있어야 하지만, 등록된 데이터소스 목록은 그라파나 실행 인스턴스마다 다르기 때문입니다.
여기어때 팀은 `builder.addCustomEditor` 메서드와 `StandardEditorProps` 인터페이스를 채택해 정적 설정의 한계를 보완했습니다. `@grafana/runtime`의 `getDataSourceSrv().getList()` API를 호출하여 브라우저 실행 시점에 등록된 데이터소스를 조회하고, 그중 분산 추적 시스템에 해당하는 항목만 필터링해 드롭다운 옵션으로 노출하도록 설계했습니다. 이는 하드코딩된 대시보드 설정을 지양하고 실행 환경에 유연하게 대응하는 커스텀 UI 개발 표준 패턴으로 평가할 수 있습니다.
대규모 렌더링 병목 완화 기법과 성능 검증 범위의 제약
10만 점 규모의 대용량 산점도를 프론트엔드에 렌더링할 때 발생하는 성능 저하는 시각화 도구의 대표적인 장애물입니다. 브라우저의 DOM 노드 수직 상승과 메모리 점유 문제를 완화하기 위해 저자는 서버 격자 집계, 사전 집계 롤업 테이블, 변경 구간에 대한 증분 조회, 화면 픽셀 단위당 시간 갱신을 제어하는 적응형 리프레시(Adaptive Refresh) 기법을 구조적으로 배치했습니다.
다만 실무 도입 관점에서 주의할 점은 공개된 성능 수치와 동작 검증의 범위가 '로컬 개발 환경에서의 실측'으로 한정되어 있다는 사실입니다. 실제 대규모 트래픽이 유입되는 프로덕션 환경에서의 클릭하우스 쿼리 레이턴시(p95/p99), CPU 및 메모리 리소스 소비량, 클라이언트 브라우저의 렌더링 프레임(FPS) 저하 여부 등은 기재되지 않았습니다. 따라서 사내 인프라에 동일 아키텍처를 도입할 때는 상용 환경 지표를 별도로 계측하고 검증하는 절차가 필수적입니다.
엔터프라이즈 모니터링 적용 시 고려할 점과 확인 필요 사항
자체 제작한 APM 산점도 패널은 기존 관측 플랫폼(Datadog, Scouter 등)의 핵심 기능을 오픈소스 기반(OpenTelemetry, ClickHouse, Grafana)으로 내재화하려는 조직에 실질적인 레퍼런스를 제공합니다. 특히 드래그 선택 시 서버 재질의 방식을 택함으로써 클라이언트 렌더링 한계치를 초과해 유실될 수 있는 원본 요청을 정확히 확보할 수 있다는 점은 심층 분석에 유용합니다.
그러나 해당 플러그인의 소스 코드가 깃허브(GitHub) 공개 저장소나 그라파나 공식 마켓플레이스에 배포되었는지 여부는 확인되지 않았습니다. 현재로서는 기술블로그에 서술된 아키텍처와 코드 조각을 참고하여 각 조직이 자체적으로 플러그인을 구현해야 하는 상태입니다. 향후 공식 패키징 배포 여부 및 프로덕션 환경의 장기 부하 테스트 결과가 추가로 공개되는지 지켜볼 필요가 있습니다.
출처
여기어때 기술블로그의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
OpenTelemetry + ClickHouse 로 APM 스캐터 차트 만들기[2편] — Grafana 커스텀 패널 (새 창)
