애플리케이션 모니터링에서의 카디널리티(Cardinality) 문제와 메트릭 최적화

증상 진단: 메트릭 폭증과 시스템 과부하

클라우드 네이티브 환경에서 애플리케이션 모니터링 시스템이 갑자기 응답 속도가 현저히 저하되거나, 대시보드 로딩이 실패하며, 저장소(Storage) 비용이 예측 불가능하게 급증하는 현상을 경험하고 계십니까? 이는 전형적인 카디널리티 문제의 초기 증상입니다. 가령, 메트릭 수집 에이전트(예: Prometheus)의 메모리 사용량이 지속적으로 증가하고, 쿼리 성능이 급격히 나빠지며, 시계열 데이터베이스(TSDB)의 디스크 I/O가 포화 상태에 이르는 현상이 동반됩니다, 이러한 증상은 서비스의 확장성과 안정성을 직접 위협하는 심각한 문제로, 즉각적인 진단과 조치가 필요합니다.

원인 분석: 카디널리티 폭발의 근본 메커니즘

카디널리티 문제는 단일 메트릭(Metric)이 생성하는 고유한 시계열(Time Series)의 수가 과도하게 많아져 발생하는 시스템 장애입니다. 핵심 원인은 메트릭의 라벨(Labels 또는 Tags) 조합이 기하급수적으로 증가하는 데 있습니다. 예를 들어, HTTP 요청 지연 시간을 측정하는 http_request_duration_seconds 메트릭에 method, status_code, path, instance, pod_name 라벨이 붙는다고 가정합니다. 만약 path 라벨이 사용자 ID나 세션 ID와 같은 고유값을 포함하게 되면, 각기 다른 사용자 요청마다 완전히 새로운 시계열이 생성됩니다. 컨테이너 기반 동적 환경에서는 pod_name이 지속적으로 변경되며, 이는 카디널리티 증가에 결정적인 역할을 합니다. 그래서 제한된 시스템 리소스 내에서 관리 불가능한 수준의 시계열이 폭증하며, 메트릭 시스템 자체의 신뢰성을 붕괴시킵니다.

해결 방법 1: 메트릭 라벨링 전략 재설계 및 필터링

가장 근본적이고 효과적인 해결책은 메트릭 생성 시점에서의 라벨링 전략을 재검토하는 것입니다. 이는 문제의 원인을 사전에 차단하는 선제적 조치입니다.

첫째, 고카디널리티 라벨의 사용을 최소화해야 합니다. 사용자 ID, 이메일 주소, 세션 ID, 요청 ID와 같이 값의 종류가 무한정 늘어날 수 있는 데이터는 절대 메트릭 라벨로 사용해서는 안 됩니다. 이러한 데이터는 로그(Log) 시스템으로 전송하여 분석하는 것이 올바른 관례입니다.

둘째, path 라벨의 정규화(Normalization)가 필수입니다. /users/12345/profile과 /users/67890/profile을 모두 /users/:id/profile과 같은 패턴으로 그룹화해야 합니다. 대부분의 모니터링 에이전트는 이 기능을 지원합니다.

1. Prometheus의 경우, scrape 설정에서 metric_relabel_configs를 사용하여 라벨 값을 교체 또는 삭제할 수 있습니다.
2. 애플리케이션 계층(예: Micrometer, OpenTelemetry)에서 메트릭을 등록할 때, 라벨 값에 대한 전처리 로직을 구현하는 것이 더 효율적입니다.

셋째, 불필요한 라벨을 과감히 제거하십시오. 모든 라벨이 쿼리에 필요한 것은 아닙니다. ‘무엇을’ 알람(Alert)할지, ‘어떻게’ 대시보드를 그릴지 명확히 정의한 후, 그에 필요한 최소한의 라벨만 유지해야 합니다.

실전 예시: Prometheus relabel 설정

다음은 Prometheus가 타겟을 스크랩(Scrape)할 때, __meta_kubernetes_pod_name과 같이 카디널리티가 매우 높은 라벨을 메트릭 라벨로 포함하지 않도록 방지하는 설정의 일부입니다.

scrape_configs:
- job_name: 'kubernetes-pods'
kubernetes_sd_configs: [...]
relabel_configs:
# pod 이름 라벨을 생성하지 않음 (중요)
- action: labeldrop
regex: pod_name
metric_relabel_configs:
# 특정 패턴의 high-cardinality path 라벨 값을 정규화
- source_labels: [__path__]
regex: '/users/([^/]+)/profile'
replacement: '/users/:id/profile'
target_label: path

해결 방법 2: 메트릭 에이전트의 집계(Aggregation) 및 샘플링(Sampling) 활용

애플리케이션 코드 수정이 어렵거나, 이미 생성된 고카디널리티 메트릭을 실시간으로 처리해야 하는 경우, 에이전트 수준에서의 집계와 샘플링이 효과적인 완화책이 됩니다.

StatsD나 Telegraf와 같은 에이전트는 기본적으로 집계 기능을 제공합니다, 예를 들어, 모든 http 요청 지연 시간 데이터를 수신한 후, 10초 간격으로 평균(avg), 최댓값(max), 백분위수(percentile) 등을 계산하여 하나의 집계된 메트릭으로 출력합니다. 이렇게 하면 원본 데이터의 카디널리티는 에이전트 메모리 내에서만 존재하며, 최종 저장소로 전송되는 메트릭의 수는 극적으로 감소합니다.

샘플링 기법은 대개 분산 추적(Tracing) 시스템에서 주로 다루어지나 방대한 양의 시계열 메트릭 처리 공정에도 유연하게 대입할 수 있습니다. 높은 정밀도가 강제되지 않는 비즈니스 지표 항목의 경우 https://zazona.com의 기술 운영 가이드라인에 명시된 데이터 추출 기준을 참조하여 수집률을 1% 이하로 조정함으로써 전체적인 인프라 연산 부하를 대폭 절감하게 됩니다. 이러한 수집 최적화 정책은 개별 서비스 환경과 모니터링의 본질적 목적을 면밀히 분석한 기초 위에서 시행됩니다.

• 장점: 애플리케이션 변경 없이 비교적 빠르게 시스템 부하를 감소시킬 수 있음
• 단점: 원본 데이터의 세부 정보가 손실될 수 있으며, 집계 알고리즘에 따라 특정 이상치(Outlier) 탐지가 어려워질 수 있음

해결 방법 3: 모니터링 아키텍처의 다중화 및 계층화

근본적인 해결책과 실시간 완화책을 적용한 후에도, 대규모 시스템에서는 모니터링 아키텍처 자체를 재설계해야 지속 가능한 운영이 가능합니다. 핵심은 ‘올바른 도구로 올바른 데이터를 처리’하는 계층화된 아키텍처를 구축하는 것입니다.

첫 번째 계층은 실시간 알람과 핵심 성능 지표(KPI)용 경량 메트릭 시스템입니다. Prometheus와 VictoriaMetrics는 여전히 이 역할에 최적화되어 있습니다. 이 계층에는 반드시 카디널리티가 낮고, 서비스 상태 판단에 필수적인 메트릭(예: 총 요청 수, 에러율, 평균 지연 시간)만을 유지해야 합니다.

두 번째 계층은 임시 분석과 디버깅을 위한 분산 추적(Distributed Tracing) 및 구조화된 로그 시스템으로 구성됩니다. 시스템의 가시성을 확보하기 위한 클라우드 관측성 고도화 트렌드를 다룬 최근 보도들을 분석해 보면, 마이크로서비스 아키텍처(MSA)의 복잡도가 증가함에 따라 개별 요청의 흐름을 추적하는 기술이 장애 복구 시간(MTTR) 단축의 핵심 변수로 부각되고 있음을 확인할 수 있습니다. 이에 따라 Jaeger, Zipkin 또는 Elasticsearch, Loki와 같은 솔루션을 활용해 고카디널리티 데이터(개별 요청 상세 정보)를 이 계층으로 명확히 분리하여 저장 및 조회함으로써, 메트릭 시스템의 데이터 처리 부담을 완전히 해소하고 모니터링의 정밀도를 높일 수 있습니다.

세 번째 계층은 장기적인 트렌드 분석과 비용 산정을 위한 데이터 웨어하우스입니다. 메트릭과 로그 데이터를 주기적으로 Amazon S3, Google BigQuery 등에 저장하고, Presto 또는 Trino를 통해 배치 쿼리를 실행합니다. 이 아키텍처는 각 시스템이 가장 잘하는 일에 집중하도록 하여, 전체 모니터링 스택의 효율성과 확장성을 보장합니다.

주의사항 및 전문가 팁

카디널리티 문제 해결 과정에서 시스템의 가시성(Observability)을 손상시키지 않도록 균형을 유지하는 것이 가장 중요합니다. 과도한 라벨 삭제는 문제 해결의 근본 원인을 파악할 수 없게 만드는 역효과를 낳을 수 있습니다.

프로 팁: 카디널리티 문제는 사후 대응보다 사전 예방이 훨씬 효율적이고 비용이 적게 듭니다. 새로운 메트릭이나 라벨을 추가하기 전에 반드시 ‘이 라벨의 가능한 값의 종류는 얼마나 될까?’와 ‘이 데이터로 어떤 알람을 만들거나, 어떤 대시보드 패널을 그릴 것인가?’를 자문하십시오. 또한, 모니터링 시스템 자체에 대한 메트릭(예: Prometheus의 prometheus_tsdb_head_series)을 상시 모니터링하여, 시계열 수의 증가 추세를 사전에 파악하고 조치할 수 있도록 해야 합니다. 정기적인 메트릭 감사(Audit)를 통해 사용되지 않는 메트릭이나 비효율적인 라벨을 식별 및 정리하는 작업도 시스템 장기 건강에 필수적입니다.

마지막으로, 모든 설정 변경은 스테이징(Staging) 환경에서 충분히 테스트한 후 프로덕션에 적용해야 합니다. 구체적으로 metric_relabel_configs나 집계 규칙 변경은 기존 대시보드와 알람 규칙에 영향을 미칠 수 있으므로. 변경 관리 절차를 반드시 준수해야 시스템 신뢰도를 유지할 수 있습니다.