01 · 시계열 데이터와 VictoriaMetrics

시계열 데이터가 무엇이고 왜 “대용량"이 별도의 문제가 되는지, 그리고 그 문제를 푸는 도구로 VictoriaMetrics(이하 VM)가 어디에 서 있는지 정리한다. VM의 내부 컴포넌트 구조는 02 아키텍처에서 이어 다룬다.

관련 문서: 02 아키텍처 · 04 저장과 압축 · 실전 01 카디널리티 · 개념 인덱스

시계열 데이터란

TSDB(Time Series Database, 시계열 데이터베이스)는 한 줄로 줄이면 시간 순서대로 기록된 숫자 값들의 연속을 다루는 데이터베이스다. 9시에 36.5도, 10시에 36.7도, 11시에 36.6도처럼 시간 축을 따라 숫자가 하나씩 찍히는 체온 그래프가 가장 단순한 형태의 시계열이다. 시간 순서대로 나열된 숫자이기 때문에 2차원 테이블로도, 그래프로도 자연스럽게 표현된다.

우리가 다루는 모니터링 지표도 결국 똑같은 구조다. CPU 사용률, 요청 수, 응답 시간 전부 “어떤 시점에 어떤 숫자가 찍혔는가” 로 환원된다. 다만 그 숫자가 어떻게 찍히느냐에 따라 지표 타입이 4종류로 나뉜다.

지표 4타입

Prometheus 진영의 표준 분류이기도 하다.

실제로 이 4타입이 텍스트로 어떻게 노출되는지 보면 감이 잡힌다. Prometheus는 지표를 아래 형식(exposition format)으로 드러내고, 수집기가 이 텍스트를 긁어(scrape) 시계열로 저장한다.

# Counter — 단조 증가하는 누적 값
http_requests_total{method="post",code="200"} 1102

# Gauge — 위아래로 변동하는 값
memory_usage_percent 62.0

# Histogram — 버킷별 누적 카운트 + _sum + _count
http_request_duration_seconds_bucket{le="0.05"} 24054
http_request_duration_seconds_bucket{le="0.1"}  33444
http_request_duration_seconds_bucket{le="+Inf"} 144320
http_request_duration_seconds_sum   53423
http_request_duration_seconds_count 144320

# Summary — 클라이언트가 미리 계산한 분위수 + _sum + _count
rpc_duration_seconds{quantile="0.5"}  4773
rpc_duration_seconds{quantile="0.99"} 76656
rpc_duration_seconds_sum   1.7560473e+07
rpc_duration_seconds_count 2693

여기서 눈여겨볼 점은 한 지표가 TSDB에 몇 개의 시계열로 저장되느냐다. Counter·Gauge는 지표 하나가 시계열 하나로 끝나지만, Histogram·Summary는 한 줄처럼 보여도 내부적으로 여러 시계열로 분해된다. 동일 레이블 조합 기준으로 정리하면 다음과 같다.

위 Histogram 예시는 버킷이 3개라 시계열 5개(3+2)로 저장된다. 버킷을 10개로 잡으면 지표 하나가 시계열 12개가 된다 — Histogram·Summary가 카디널리티를 밀어 올리는 이유이며, 이는 실전 01 카디널리티에서 다룬다.

여기서 미리 붙잡아 둘 직관: Counter처럼 단조 증가하는 값은 압축이 극단적으로 잘 된다. 이 사실이 저장·압축을 설명할 때 계속 되돌아온다. Counter/Gauge를 어떻게 판별하고 어떻게 압축하는지는 04 저장과 압축에서 다룬다.

왜 “대용량"이 별도의 문제인가

질문을 하나 던져 보자. 이 모든 숫자를 시간 순서대로 그대로 저장해야 할까? 1초에 한 번씩만 찍어도 하루에 86,400개고, 지표가 수만 개라면 하루치만 해도 어마어마한 양이 된다. 그래서 TSDB의 핵심 과제는 제한된 자원으로 이 수많은 데이터를 얼마나 잘 압축하느냐가 된다.

“대용량 시계열"이라는 말에는 두 축이 있다. 시계열 개수가 많아지는 것과, 시간이 흐를수록 데이터가 쌓여 보관 기간이 길어지는 것이다. 규모의 감을 잡기 위해 대략의 구간을 나눠 보면 다음과 같다.

수백만 개까지는 Prometheus 하나만 설치해도 웬만큼 해결된다. 문제는 그 위다. 수천만 개를 넘어서는 순간부터는 기존 모니터링 시스템과 단일 시계열 DB로는 감당이 안 돼 별도의 솔루션이 필요하다 — 이것이 “대용량"을 굳이 구분하는 이유다. 개수가 왜 이렇게까지 폭증하는지, 즉 카디널리티 문제는 실전 01 카디널리티에서 본격적으로 다룬다.

TSDB의 히스토리

대용량 시계열을 다루는 도구들이 어떻게 등장했는지를 짚으면 VM의 위치가 선명해진다.

• 2012 · Prometheus 등장. 모니터링 업계에서 사실상 디팩토 표준에 가까운 도구다. 앞서 본 지표 4타입 분류도 Prometheus 진영에서 왔다.
• 2015 · Gorilla 압축 알고리즘. Facebook이 방대한 서버를 모니터링하면서 시계열 데이터를 효율적으로 처리하기 위해 만든 특화 압축 기술이다. “시계열 데이터를 어떻게 효율적으로 다룰 것인가"라는 아이디어가 이때부터 여러 모니터링 도구로 퍼졌다. Gorilla 계열 압축(Delta / Delta-of-Delta)의 실제 동작은 04 저장과 압축에서 다룬다.
• 그 위의 스케일 문제. 수천만 개를 넘는 대용량은 Prometheus 하나만으로는 풀리지 않는다. 여기서 갈래가 나뉜다. 널리 쓰이는 것이 Thanos와 Cortex — 스케일러블한 Prometheus 확장 솔루션이다. 반면 네이버 검색 SRE는 이들과 완전히 다른 계열인 VM을 택했다.

VictoriaMetrics의 위치

VM은 대용량 시계열을 정면으로 겨냥한 TSDB다.

• Apache 2.0 라이선스의 오픈소스 TSDB이며 Prometheus와 호환된다. 즉 PromQL을 그대로 쓸 수 있고, Prometheus가 쓰는 remote_write 프로토콜도 그대로 받아들인다. 기존 Prometheus 생태계를 버리지 않고 백엔드만 갈아 끼울 수 있다는 뜻이다.
• 자체 벤치마크 기준으로 메모리 5배, 스토리지 7배 더 효율적이라고 주장한다. 이 효율의 비결이 앞서 본 Time Series/Sample 분리와 Gorilla 계열 압축이며, 실제 운영에서 데이터포인트당 1바이트 미만까지 줄어드는 수치로 확인된다(상세는 04 저장과 압축).
• 왜 VM인가. Thanos·Cortex 대비 의존성이 적고 아키텍처가 단순해 운영이 편하며, 압축 효율과 성능이 앞선다. 이 때문에 대규모 모니터링 시스템의 백엔드로 선택된다. 네이버 검색 SRE도 하루 수십억 건의 검색 요청, 수만 대의 서버, 수백 개 서비스를 모니터링하는 환경에서 같은 이유로 VM을 택했다.

VM이 이 효율을 어떻게 내는지 — 4개 컴포넌트로 데이터가 흐르는 구조, LSM 트리, IndexDB/DataDB 분리 — 는 02 아키텍처에서 이어진다.

출처

• Inside VictoriaMetrics (강민구, NAVER · 40:37) — 01:09~04:35 TSDB 정의, 지표 4타입, 압축 과제, VM 위치(Apache 2.0 / Prometheus 호환 / 메모리 5배·스토리지 7배). https://d2.naver.com/helloworld/9290861
• VictoriaMetrics: 시계열 데이터 대혼돈의 멀티버스 (DEVIEW 2023, 손주식·이선규 · 33:50) — 01:54~05:47 시계열 정의, 대용량의 정의(100만→수백만→수천만·수십억), TSDB 히스토리(Prometheus 2012 / Gorilla 2015 / Thanos·Cortex vs VM 선택). https://youtu.be/OUyXPgVcdw4
• 골격: chapter9/victoriametrics.md §1.