#DevOps

VictoriaMetrics 운영기 2편 — 장비 증설 없이 리소스 위기를 해결한 3단계 최적화 전략

Summary

장비 증설 비용은 Zero! 네이버가 수백만 컨테이너 메트릭 폭탄에서 살아남은 3단계 생존 전략

VictoriaMetrics 내부 인덱싱 구조와 데이터 활용 분석을 통해 인프라 비용 한계를 정면 돌파한 DevOps 엔지니어링 사례

본 아티클은 대규모 쿠버네티스 환경에서 VictoriaMetrics를 운영하며 겪은 리소스 한계 문제를 장비 추가 없이 소프트웨어 및 정책 제어만으로 해결한 성과를 다룹니다. 데이터가 조회, 저장, 수집되는 전 단계에 걸쳐 심층적인 인프라 분석과 최적화를 적용했습니다. 시스템 내부 작동 방식을 꿰뚫어 보고 정량적인 실제 지표 분석을 통해 최선의 효율을 이끌어내는 DevOps 엔지니어링의 정수를 보여줍니다.

01접두사 필터 패턴 쿼리 분할로 대규모 집계 조회에 따른 vmselect 메모리 누적 현상 방지 및 응답 속도 최대 82% 향상
02UNIX 타임스탬프 기준의 3개 슬롯(prev, current, next) 순환형 IndexDB 로테이션 구조를 파헤치며 안전한 보관 주기 단축 시점 확보
03실제 API 조회 로그 분석을 통해 요청의 99.997%가 1개월 이내 데이터에 집중되어 있음을 정량 검증하여 합리적 보관 기간 재정립
04모니터링 대상 중 90% 이상을 차치하던 비서비스 컨테이너 수집 제외로 수집 파이프라인 부하 70% 및 Active Time Series 63.6% 대폭 감축
05만료 및 삭제 데이터량이 신규 적재량보다 많아지도록 역전시켜 스토리지 디스크 사용량 그래프의 감소 추세 전환 달성

RECOMMENDATION

Prometheus나 VictoriaMetrics 등 대규모 시계열 모니터링 시스템의 유지 비용 및 OOM 문제로 깊은 고민을 겪고 있는 아키텍트와 DevOps 엔지니어들에게 적극 추천합니다. 하드웨어 스케일업에 돌입하기 전, 쿼리 분할 및 타겟 수집 필터링만으로도 수배의 성능 향상을 끌어낼 수 있는 실질적인 지침을 얻을 수 있습니다.

The Problem

쿠버네티스 전환 가속화로 컨테이너 수가 급증하면서 모니터링 시스템의 카디널리티가 폭증하였습니다. 이로 인해 조회 컴포넌트인 vmselect의 메모리 점유율이 치솟아 OOM으로 Pod가 재시작되었고, 저장소인 vmstorage의 디스크 여유 공간이 고갈되는 물리 리소스 위기가 발생했습니다.

The Solution

조회 레이어에서는 고카디널리티 레이블 접두사를 기준으로 쿼리를 36개로 분할 요청하도록 수정했습니다. 저장 레이어에서는 IndexDB의 3-슬롯 로테이션 구조를 분석하여 Hot Tier의 보관 기간(RetentionPeriod)을 12개월에서 6개월로 단축하였고, 수집 레이어에서는 높은 비율을 차지하던 비서비스 컨테이너를 수집 대상에서 제외했습니다.

The Result

쿼리 분할을 통해 vmselect 단일 쿼리의 메모리 사용률이 기존 45%에서 12%로 대폭 줄고 API 응답 속도도 최대 82% 단축되었습니다. 또한 비서비스 컨테이너 제외로 수집 컨테이너가 91.6% 감소하였으며, 스토리지 유입량 감소로 디스크 가용량이 확보되어 우상향하던 디스크 사용량 그래프를 감소 추세로 전환하는 데 성공했습니다.

Trade-off

보관 기간을 12개월에서 6개월로 조정함에 따라 6개월 이전의 장기 데이터를 조회할 때는 비교적 속도가 느린 Warm Tier(HDD) 스토리지를 경유해야 하므로 조회 성능 지연이 발생할 수 있습니다. 아울러 비서비스 컨테이너의 시스템 지표 수집을 중단하면서 특정 보조 컨테이너에 대한 세부적인 실시간 하드웨어 모니터링은 제한되게 되었습니다.

Key Concepts

Concept · 01

IndexDB

VictoriaMetrics 저장 공간에서 수집된 메트릭 이름과 레이블 조합을 정규화하여 고유 식별자인 TSID를 부여하고, 이를 역색인 형태로 구성해 빠르게 검색할 수 있도록 지원하는 영역입니다. 조회 성능과 데이터 삽입 속도 개선을 위해 실제 시계열 데이터를 보관하는 Data 영역과 물리적으로 독립하여 운영됩니다.

메트릭 이름과 레이블 검색에 필요한 디스크 I/O를 제어하기 위해 인메모리 캐시 히트 실패 시 디스크 기반 검색을 실행함
UNIX Epoch 시간 기준으로 고정된 RetentionPeriod마다 로테이션되는 3개의 슬롯 구조를 취해 효율적으로 과거 인덱스를 제거함

Concept · 02

vmselect

사용자가 입력한 MetricsQL 질의를 파싱하여 클러스터 전반의 vmstorage 노드들로 쿼리를 팬아웃한 뒤, 수신된 데이터를 시간순으로 정렬 및 병합하여 반환하는 조회 전담 게이트웨이 컴포넌트입니다. 모든 노드의 분할 응답 셋을 한 대의 인메모리 버퍼에 올려 중복 제거 작업을 동시 수행합니다.