VictoriaMetrics: Prometheus 호환 고성능 TSDB

Prometheus의 천장을 넘으려면

Prometheus는 단일 노드에서 동작하는 풀(pull) 기반 모니터링 도구다. 스크랩, 저장, 알림이 한 프로세스에 묶여 있어 운영이 단순하지만, 장기 보존과 수평 확장이 필요한 순간 한계가 명확해진다.

• 로컬 TSDB는 기본 15일 보존이며, 장기 저장을 위한 공식 해결책이 없다.
• 단일 노드이므로 초당 수백만 포인트 이상의 쓰기 처리량을 달성하기 어렵다.
• remote_write로 외부 스토리지에 보낼 수 있지만, 그 외부 스토리지를 직접 운영해야 한다.

이 자리를 채우는 대표적인 선택지가 Thanos, Grafana Mimir, 그리고 VictoriaMetrics다. 이 중 VictoriaMetrics는 단일 바이너리로 시작해 클러스터 모드로 수평 확장하는 경로가 매끄럽고, 압축 효율과 쓰기 처리량에서 두드러진 강점을 보인다.

핵심 설계 원칙

VictoriaMetrics의 스토리지는 세 가지 원칙 위에 설계되었다.

1. LSM 구조: 쓰기를 인메모리 버퍼에 먼저 받고, 백그라운드에서 디스크로 플러시해 쓰기 증폭을 최소화한다.
2. 컬럼 지향 저장: 같은 타입의 값을 묶어 저장하므로 압축률이 높고, 쿼리 시 필요한 컬럼만 로드한다.
3. 어펜드-온리: 불변(immutable) 파트(Part)에 데이터를 추가한 뒤 백그라운드 병합으로 정리하므로 임의 업데이트가 없다.

스토리지 내부 구조

TSID와 IndexDB

VictoriaMetrics는 {__name__="cpu_usage", host="web-01", env="prod"} 같은 레이블 집합을 TSID(Time Series ID)라는 내부 숫자 식별자로 변환한다. IndexDB는 이 매핑을 담당하는 역 인덱스(inverted index)다. LSM 트리 기반으로 구현되어 있으며, 각 행은 7가지 프리픽스 중 하나로 시작해 레이블→TSID, TSID→레이블, 날짜별 시리즈 목록 등 다양한 조회를 지원한다.

쿼리 시 레이블 필터(host="web-01")를 받으면, IndexDB에서 일치하는 TSID 목록을 꺼내고, 그 TSID에 해당하는 데이터 블록만 읽는다.

파트(Part) 구조

데이터는 파트 단위로 디스크에 저장된다. 파트는 단일 파일이 아니라 여러 컬럼 파일의 디렉터리다.

partition/
  2026_07/          ← 월별 파티션
    1720742400_1720742460_123456/    ← 파트 (시작시각_종료시각_시리즈수)
      index.bin      ← 블록 헤더: TSID, 시간 범위, 압축 정보
      timestamps.bin ← 타임스탬프 값
      values.bin     ← 샘플 값
      metaindex.bin  ← index.bin 탐색용 메타 인덱스

하나의 블록은 동일 TSID의 행 최대 8,192개를 담는다. 블록 내에서 타임스탬프와 값은 각각 다른 인코딩을 거쳐 압축된다.

압축 알고리즘

VictoriaMetrics의 인상적인 압축률(전형적인 node\_exporter 메트릭 기준 약 0.4 바이트/포인트, Prometheus 기준 약 3.5 바이트/포인트)은 여러 기법의 조합으로 달성된다.

백그라운드 병합

작은 파트들은 백그라운드에서 지속적으로 더 큰 파트로 병합(merge)된다. 병합할수록 같은 TSID의 데이터가 연속 배치되어 압축률이 높아지고, 쿼리 시 읽어야 할 파트 수가 줄어 성능이 향상된다. 이 과정은 애플리케이션 투명하게 실행되며 즉각 스냅샷이 가능한 이유도 이 구조에 있다(파트는 불변이므로 하드링크로 스냅샷 생성).

배포 아키텍처

단일 노드 모드

단일 바이너리 victoria-metrics 하나로 인제스트, 저장, 쿼리를 모두 처리한다. 운영 단순성이 최우선일 때, 또는 초당 100만 포인트 미만의 워크로드에서 선택한다. remote_write 엔드포인트를 그대로 받아 기존 Prometheus 설정 변경이 거의 없다.

클러스터 모드

세 가지 컴포넌트로 역할을 분리한다.

vminsert는 메트릭 이름과 레이블 전체를 키로 일관 해싱(consistent hashing)해 특정 vmstorage 노드로 라우팅한다. -replicationFactor=N 플래그를 주면 동일 데이터를 N개 노드에 복제해 N-1개 노드 장애까지 견딘다.

에코시스템 컴포넌트

VictoriaMetrics 클러스터 주변에는 여러 경량 컴포넌트가 있다.

MetricsQL: PromQL의 상위 호환

VictoriaMetrics의 쿼리 언어 MetricsQL은 PromQL을 완전히 포함하면서 몇 가지 편의 기능을 추가한다.

# PromQL은 rate() 앞에 반드시 irate() 또는 rate()를 써야 함
# MetricsQL: 피리어드 없이 increase_pure() 같은 함수 제공

# 다중 메트릭 한 번에 선택
{__name__=~"node_(cpu|memory)_.*", host="web-01"}

# 기본 기간 자동 추론
# PromQL: rate(http_requests_total[5m])
# MetricsQL: rate(http_requests_total)  ← step 크기를 자동 사용

# default_rollup: 누락 데이터 자동 처리
# keep_last_value: 마지막 값으로 갭 채우기

기존 Prometheus 알림 규칙과 Grafana 대시보드는 MetricsQL과 거의 완벽하게 호환된다.

성능과 압축 효율

커뮤니티 벤치마크(Aliaksandr Valialkin, VictoriaMetrics 창업자 직접 수행) 기준:

이 차이는 알고리즘만의 결과가 아니다. Prometheus는 각 시리즈를 별도 청크로 관리하므로 카디널리티가 높아질수록 메모리 압박이 크다. VictoriaMetrics는 TSID 기반 일괄 블록 처리와 컬럼 압축으로 카디널리티 증가에 더 선형적으로 대응한다.

운영 주요 설정

# 단일 노드: 12개월 보존, 데이터 경로 지정
./victoria-metrics \
  -retentionPeriod=12 \
  -storageDataPath=/var/lib/victoria-metrics-data \
  -httpListenAddr=:8428

# 클러스터: vminsert 3중 복제, vmselect 캐시 활성화
./vminsert \
  -storageNode=storage-1:8400,storage-2:8400,storage-3:8400 \
  -replicationFactor=2

./vmselect \
  -storageNode=storage-1:8401,storage-2:8401,storage-3:8401 \
  -cacheDataPath=/cache/vmselect

# 스냅샷 생성 (백업 전 항상 수행)
curl http://localhost:8428/snapshot/create

보존 기간 세분화: -retentionPeriod 외에 레이블별로 보존 기간을 다르게 설정하는 퍼-테넌트 보존을 엔터프라이즈 버전에서 지원한다. 오픈소스 버전에서는 단일 전역 보존만 가능하다.

VictoriaMetrics를 선택하는 기준

운영자 시점의 핵심: VictoriaMetrics는 단일 노드로 시작해 vmstorage를 노드 단위로 추가하는 경로가 명확하다. Thanos는 사이드카 배포와 오브젝트 스토리지 의존이 필수이며, Mimir는 Cortex 기반의 마이크로서비스 운영 복잡도를 감수해야 한다. 클러스터 규모가 크지 않고 Prometheus 호환이 중요하다면 VictoriaMetrics가 가장 낮은 진입 장벽을 제공한다.

References

• VictoriaMetrics 공식 문서 — 클러스터 버전, https://docs.victoriametrics.com/victoriametrics/cluster-victoriametrics/
• VictoriaMetrics 공식 문서 — vmagent, https://docs.victoriametrics.com/victoriametrics/vmagent/
• VictoriaMetrics 블로그 — vmstorage IndexDB 동작 원리, https://victoriametrics.com/blog/vmstorage-how-indexdb-works/
• VictoriaMetrics 블로그 — vmstorage 보존·병합·중복 제거, https://victoriametrics.com/blog/vmstorage-retention-merging-deduplication/
• VictoriaMetrics 블로그 — vmstorage 데이터 인제스트 처리, https://victoriametrics.com/blog/vmstorage-how-it-handles-data-ingestion/
• system-design.space — VictoriaMetrics 역사와 아키텍처, https://system-design.space/en/chapter/victoriametrics-architecture/
• sreschool.com — What is VictoriaMetrics? (2026 Guide), https://sreschool.com/blog/victoriametrics/
• sanj.dev — Scaling Prometheus in 2026: The Complete Comparison Guide, https://sanj.dev/post/prometheus-scaling-thanos-mimir-victoriametrics/
• Aliaksandr Valialkin — High-cardinality TSDB benchmarks: VictoriaMetrics vs TimescaleDB vs InfluxDB, https://valyala.medium.com/high-cardinality-tsdb-benchmarks-victoriametrics-vs-timescaledb-vs-influxdb-13e6ee64dd6b
• last9.io — Performance Impact of High Cardinality in Time-Series DBs, https://last9.io/blog/performance-implications-of-high-cardinality-in-time-series-databases/