VictoriaMetrics, 장비 증설 없이 3단계 최적화로 리소스 위기 극복!
by DD
5일 전
조회수 20
쿠버네티스 전환 후 컨테이너 수 급증으로 인한 카디널리티 폭증(Cardinality Explosion) 문제 발생
장비 증설 대신 쿼리 분할, RetentionPeriod 재설계, 수집 범위 축소 등 3단계 소프트웨어 최적화 진행
응답 시간 82% 단축, 디스크 사용량 8.7% 감소 등 비용 효율적 운영 모델 구축 성공
vmselect OOM 방지를 위한 쿼리 분할 전략
카디널리티 급증으로 인한 vmselect의 OOM(Out Of Memory) 문제는 단일 쿼리가 처리하는 시계열 수 과다에서 기인했습니다. 이를 해결하기 위해 레이블 접두사(Label Prefix) 기반의 쿼리 분할을 적용했습니다.
쿼리 분할 전: 단일 쿼리로 모든 컨테이너 집계, vmselect 메모리 점유율 90% 초과 및 OOM 발생
쿼리 분할 후: container 레이블의 알파벳/숫자(a-z, 0-9) 기준으로 36개 쿼리로 분할, 쿼리당 메모리 점유율 45% → 12%로 감소
결과: API 응답 시간 40초 → 7초로 단축, vmselect 메모리 부하 분산 및 안정성 확보
이처럼 대규모 환경에서는 단일 쿼리 부하를 분산하는 것만으로도 OOM 위험을 낮추고 응답 시간을 크게 개선할 수 있습니다.
vmstorage IndexDB 로테이션과 RetentionPeriod 정책 재설계
저장소 디스크 고갈 위기를 해결하기 위해 Hot Tier의 RetentionPeriod를 12개월에서 6개월로 축소하는 방안을 검토했습니다. 이 변경이 저장소 각 영역에 미치는 영향을 예측하기 위해 IndexDB의 3-슬롯 순환 구조를 분석했습니다.
IndexDB 로테이션: UNIX 타임스탬프 0 기준, RetentionPeriod 주기마다 prev 슬롯 삭제 및 슬롯 순환 발생
Data 영역 영향: RetentionPeriod 단축 시, 보관 범위를 벗어난 월별 파티션 즉시 삭제로 단기 디스크 확보
IndexDB 영역 영향: 로테이션 주기 단축으로 다음 로테이션 시점에 과거 인덱스 슬롯 크기 감소 예상
실제 쿼리 패턴 분석 결과, 99.997%의 쿼리가 1개월 이내 데이터를 대상으로 하여 서비스 영향이 미미함을 확인했습니다. 이를 근거로 정책 변경을 진행하여 디스크 고갈 위기를 해소했습니다.
수집 대상 정책 변경으로 인한 메트릭 유입량 통제
카디널리티 폭증의 근본 원인인 과도한 메트릭 유입을 해결하기 위해 수집 대상 정책을 '모든 컨테이너'에서 '서비스 컨테이너'로 변경했습니다.
기존 정책: 클러스터 내 모든 컨테이너의 시스템 및 서비스 지표 수집
변경 후: 서비스 지표만 수집, 비서비스 컨테이너(90% 이상 비율) 제외
결과: 수집 컨테이너 수 91.6% 감소, Active Time Series 63.6% 감소, vmstorage Ingestion Rate 64.4% 감소
이 최적화를 통해 수집 파이프라인부터 저장소까지 데이터 경로 전반의 향후 증설 비용을 선제적으로 절감했으며, Data 영역 디스크 사용량은 약 8.7% 감소 추세로 전환되었습니다.
VictoriaMetrics의 데이터 저장 및 조회 메커니즘
VictoriaMetrics의 vmstorage는 메트릭을 IndexDB(인덱스 관리)와 Data 영역(압축된 시계열 데이터)으로 분리하여 저장합니다. IndexDB는 메트릭 이름과 레이블 조합으로 TSID(TimeSeries ID)를 생성하고, 역색인 구조를 통해 원하는 시계열을 빠르게 찾습니다.
IndexDB: 메트릭 존재 여부 확인, TSID 조회 및 생성, 레이블 기반 TSID 목록 교집합 계산
Data 영역: TSID별 타임스탬프-값 쌍을 블록으로 묶어 Part 단위로 저장, 시간 범위 메타데이터로 불필요한 Part 스캔 방지
vmselect는 쿼리 파싱 후 모든 vmstorage 노드에 팬아웃(Fan-out)하여 데이터를 수집하고, 각 노드에서 받은 데이터를 병합하여 최종 결과를 반환합니다. 이 과정에서 대규모 시계열 데이터 병합 시 vmselect Pod의 메모리 사용량이 급증하는 구조적 문제가 발생합니다.
