VictoriaMetrics vs Thanos vs Grafana Cloud 월 비용 비교 (시계열 100만)

전제 조건부터 못 박고 시작합니다

이 글의 계산은 아래 조건에 고정되어 있습니다. 조건이 다르면 결론도 달라지므로, 자기 환경 숫자를 옆에 놓고 읽으시길 권합니다.

기획 단계에서 "월 1억 샘플"로 잡는 경우가 많은데, 활성 시계열 100만 × 30초 스크레이프면 산술적으로 월 860억 샘플대가 나옵니다. 스토리지 산정에서 이 자릿수를 틀리면 비용이 세 자릿수 배로 어긋나므로, 활성 시계열 × (2,592,000초 ÷ 스크레이프 주기) 로 먼저 검산하세요.

이 규모에서 단일 Prometheus가 부딪히는 증상은 대개 셋입니다.

1. 메모리: head block 인덱스와 심볼 테이블이 상주하면서 100만 시계열 기준 30~50GB대 RSS가 흔합니다. 릴로드나 재시작 때 WAL 재생이 겹치면 스파이크가 나면서 OOMKilled.
2. 보존: 로컬 디스크 기반 리텐션이라 13개월을 로컬로 버티려면 TB 단위 EBS를 붙여야 하고, 백업·복구 시나리오가 없습니다.
3. HA: 2대를 띄워도 각각 별개의 데이터셋이라 쿼리 결과가 미세하게 어긋나고, 한쪽이 죽은 구간은 영원히 구멍으로 남습니다.

그래서 선택지는 사실상 셋으로 좁혀집니다.

• A) Prometheus + Thanos 자체운영
• B) Grafana Cloud Metrics(관리형)
• C) VictoriaMetrics 자체운영(단일 노드 → 클러스터)

참고로 이 글은 메트릭 축만 다룹니다. 로그 스택(Loki/ELK/CloudWatch Logs) 비용은 과금 단위 자체가 GB 인제스트라서 계산 구조가 완전히 다르고, 여기서 섞으면 결론이 흐려집니다. 인프라 전반의 TCO 계산 방식은 클라우드 비용 최적화 가이드: 서버리스 vs 쿠버네티스 TCO 비교를 참고하시면 됩니다.

30초 판정표: 5축 결정 매트릭스

먼저 답부터 찍고 근거는 뒤에서 확인하는 순서를 권합니다.

• B가 나왔다면 3장의 B 산식만 보고, 6장(망분리 체크)에서 탈락 조건에 걸리는지만 확인하세요.
• C가 나왔다면 3장은 훑고 7장 전환 런북으로 바로 가셔도 됩니다.
• A가 나왔다면 5장의 compactor 실패 분기를 반드시 읽으세요. A의 비용은 인스턴스가 아니라 사고에서 나옵니다.

3안의 월 비용을 산식째로

단가 고지: 아래 단가는 2026년 8월 기준 공개 가격표를 참고한 가정값이며, 리전·약정·계약 조건에 따라 변동합니다. 실제 의사결정 전에 AWS 요금 계산기와 벤더 견적으로 반드시 재검증하세요. 인건비는 시간당 60,000원(연봉+간접비 부담 포함 환산)으로 가정합니다.

A) Prometheus + Thanos 자체운영

구성: Prometheus 2대(HA, 로컬 15일) + Thanos sidecar 2 + store gateway 1 + query 1 + compactor 1, 장기보관은 S3.

• 인프라: 887 × 1,380 = 약 1,224,000원
• 운영공수: 월 16시간 × 60,000원 = 960,000원 (compactor 감시, 블록 겹침 대응, 버전 업그레이드, 룰 관리, 용량 예측)
• A 월 TCO ≈ 2,184,000원

B) Grafana Cloud Metrics

관리형 메트릭은 활성 시계열 단가가 전부를 결정합니다. 여기서 시나리오를 둘로 나눠야 정직한 비교가 됩니다.

여기서 실무 결론이 하나 나옵니다. B는 "관리형이라 편하다"가 아니라 "단가를 얼마에 받았느냐"로 승패가 갈립니다. 리스트가로 100만 시계열을 그대로 올리면 A·C 대비 5배 이상이 되고, 볼륨 계약 단가를 확보하면 A와 비슷한 선까지 내려옵니다. 견적 협상 전에는 B를 후보에 넣지 마세요. 그리고 egress는 활성 시계열이 아니라 샘플 수에 비례하므로, 스크레이프 주기를 30초→60초로 늘리면 절반이 됩니다.

C) VictoriaMetrics 단일 노드

100만 활성 시계열·33k samples/s는 단일 노드(vmsingle)로 충분히 소화되는 구간으로 알려져 있습니다. 클러스터(vminsert/vmselect/vmstorage)는 보통 수백만~천만 시계열대나 멀티테넌시 요구가 생길 때 검토합니다.

디스크 산정 근거: 압축 후 샘플당 약 0.4~0.7바이트가 일반적으로 보고되는 범위입니다. 860억 샘플/월 × 0.5B ≈ 43GB/월, 13개월 ≈ 560GB. 카디널리티 증가와 인덱스를 감안해 2배 여유로 1TB를 잡았습니다.

• 인프라: 621 × 1,380 = 약 857,000원
• 운영공수: 월 8시간 × 60,000원 = 480,000원
• C 월 TCO ≈ 1,337,000원

총액 비교표

반전 포인트 하나. 운영공수를 빼고 인프라만 비교하면 A(122만) < B 볼륨계약(212만)이라 A가 이깁니다. 하지만 공수를 넣는 순간 A와 B의 격차는 18만원까지 좁혀지고, "월 16시간을 Thanos에 쓸 사람이 실제로 있는가"라는 질문만 남습니다. 그 사람이 없으면 A의 실제 비용은 계산서가 아니라 장애 시간으로 청구됩니다. 반대로 그 사람이 있다면 C가 세 안 중 가장 싸고, 그 격차(월 약 100만원)는 연 1,200만원입니다.

왜 같은 100만 시계열인데 리소스가 갈리는가

Prometheus TSDB: 인덱스가 메모리를 먹는 지점

Prometheus는 최근 데이터를 head block에 두고, WAL에 기록한 뒤 2시간 단위로 디스크 블록을 만듭니다. 메모리를 차지하는 주범은 샘플 자체가 아니라 인덱스와 심볼 테이블입니다. 활성 시계열 하나마다 라벨 셋, 포스팅 리스트 엔트리, 청크 참조가 상주하므로 메모리는 샘플 수가 아니라 시계열 개수에 비례해서 증가합니다. 그래서 스크레이프 주기를 늘려도 메모리는 별로 안 줄고, 라벨 하나를 지우면 확 줄어드는 비대칭이 생깁니다.

재시작 시 WAL 재생 구간에서 순간 메모리가 정상 시보다 크게 뛰는 것도 여기서 옵니다. 노드에 메모리 한계선이 가까우면 "재시작 → 재생 중 OOM → 재시작" 루프에 빠집니다.

Thanos: 저렴한 저장의 대가는 조회 경로

Thanos는 sidecar가 2시간 블록을 S3에 올리고, store gateway가 그걸 조회합니다. 문제는 조회 경로입니다. store gateway는 블록의 인덱스 헤더를 로드하고, 필요한 청크 구간을 객체스토리지에서 range GET으로 긁어옵니다. 인덱스 캐시가 비어 있거나 조회 구간이 넓으면 네트워크 왕복이 그대로 쿼리 지연으로 붙습니다. 최근 2시간은 빠르고, 지난 분기 데이터를 조회하면 눈에 띄게 느려지는 패턴이 나오는 이유입니다. 대시보드에서 3개월 범위를 자주 본다면 store gateway 메모리와 캐시(인메모리 또는 memcached/Redis)에 추가 비용을 잡아야 합니다.

VictoriaMetrics: 압축과 백그라운드 머지

VictoriaMetrics는 시계열 데이터를 컬럼 지향에 가까운 형태로 저장하고, 타임스탬프와 값에 델타/델타-오브-델타 계열 인코딩을 적용합니다. 게다가 데이터가 들어오면 작은 파트로 쓰고 백그라운드에서 큰 파트로 머지(LSM 트리 계열 동작)하기 때문에, 인제스트 경로가 인덱스 상주에 덜 의존합니다. 결과적으로 같은 시계열 수에서 메모리 사용량과 디스크 점유가 Prometheus 대비 낮게 나오는 경향이 반복적으로 보고됩니다.

다만 공짜는 아닙니다. 머지가 밀리면 디스크 사용량이 일시적으로 부풀고, 머지 I/O가 쿼리 지연에 영향을 줍니다. vm_rows_merged_total과 파트 개수를 대시보드에 반드시 올려두세요. 벤치마크 수치는 하드웨어·라벨 구조·쿼리 패턴에 따라 편차가 크므로, 위 내용은 절대값이 아니라 경향으로 받아들이고 자기 데이터로 2주 병행 측정하는 걸 권합니다.

언제, 어떻게 터지는가: 실패 분기

Thanos 운영 난이도(A안)

• compactor는 사실상 단일 인스턴스 제약이 있습니다. 같은 버킷·같은 스트림에 두 개를 띄우면 블록이 꼬입니다. 즉 compactor는 SPOF에 가깝고, 죽어 있으면 다운샘플링과 리텐션 적용이 조용히 멈춥니다. "S3 요금이 계속 오르는데 이유를 모르겠다"의 8할이 compactor 중단입니다.
• overlapping blocks: HA 페어의 external label이 잘못 붙거나 sidecar가 중복 업로드하면 겹치는 블록이 생기고, compactor가 halt 상태로 멈춥니다. 복구는 thanos tools bucket verify/bucket inspect로 대상 블록을 찾아 마킹·삭제하는 수작업입니다.
• 다운샘플링 지연: 5m/1h 다운샘플 블록이 안 만들어지면 장기 범위 쿼리가 원본 해상도를 긁어 타임아웃이 납니다.

카디널리티 폭발: A/B/C별 증상과 첫 24시간

트리거는 늘 비슷합니다. 파드 이름·request_id·user_id·전체 URL 경로가 라벨로 유입되는 경우입니다.

첫 24시간 대응 순서(공통)

1. topk(20, count by (__name__)({__name__=~".+"}))로 메트릭별 시계열 수 상위 확인.
2. 범인 메트릭의 라벨별 고유값 수 확인 → 어느 라벨이 터졌는지 특정.
3. 수집단에서 즉시 차단: scrape config의 metric_relabel_configs로 해당 라벨 labeldrop 또는 메트릭 drop.
4. 애플리케이션 팀에 라벨 제거 티켓 발행(근본 조치).
5. 이미 저장된 시계열 정리: A는 admin API의 delete_series, C는 /api/v1/admin/tsdb/delete_series.

# 수집 단계에서 고카디널리티 라벨을 잘라내는 최소 방어
metric_relabel_configs:
  - regex: '(request_id|trace_id|session_id|pod_template_hash)'
    action: labeldrop
  - source_labels: [__name__]
    regex: 'app_http_request_duration_seconds_bucket'
    action: drop   # 히스토그램 버킷이 범인일 때 임시 차단

VictoriaMetrics는 -maxLabelsPerTimeseries, -maxLabelValueLen, -search.maxUniqueTimeseries 같은 방어 플래그와 vmagent의 -remoteWrite.maxHourlySeries, -remoteWrite.maxDailySeries로 유입 자체를 상한선으로 막을 수 있어 상대적으로 완충이 있습니다. 다만 상한을 넘긴 시계열은 버려지므로 알럿을 반드시 함께 걸어야 합니다.

리텐션 변경 난이도

한국 실무 조건: 원화, 망분리, 그리고 문서

환율 리스크. B의 비용은 달러 표기입니다. 환율이 1,380원에서 1,500원으로 움직이면 위 계산의 B는 월 약 18만원이 그냥 늘어납니다. A·C도 클라우드 인스턴스가 달러 기준이라 영향을 받지만, 비중이 큰 인건비가 원화라 변동 폭이 상대적으로 작습니다. 예산 승인 문서에는 환율 시나리오(±10%)를 함께 넣는 편이 안전합니다.

국내 리전과 egress. 관리형 백엔드가 국내 리전에 없으면 두 번 손해입니다. 첫째, 원격 쓰기 왕복 지연과 재시도로 vmagent/Prometheus 큐가 밀립니다. 둘째, 인터넷 아웃바운드 전송량이 그대로 요금입니다. 계약 전에 "우리 클러스터에서 해당 엔드포인트까지의 실제 RTT"와 "월 송신 GB"를 먼저 측정하세요.

망분리에서는 B가 후보에서 사라집니다. 금융·공공의 폐쇄망 요건에서는 외부 SaaS로 메트릭을 내보내는 것 자체가 불가한 경우가 많습니다(구체적 규정 적용 여부는 소속 기관의 보안 지침과 감독기관 고시를 직접 확인해야 합니다). 이 경우 판정은 단순해집니다.

• B열을 지우고 A vs C만 비교 → 위 표에서 A 218만 vs C 134만.
• 폐쇄망은 인터넷 미러가 없어 이미지·바이너리 반입 절차가 붙습니다. 구성요소 개수가 곧 반입 티켓 개수입니다. Thanos는 sidecar/store/query/compactor에 객체스토리지(MinIO 등)까지 반입 대상이 되고, VictoriaMetrics는 vmsingle + vmagent 두 개 바이너리로 끝납니다.
• 결론적으로 폐쇄망에서는 비용과 반입 난이도 모두 C가 유리합니다. 예외는 이미 사내 S3 호환 스토리지가 표준으로 운영 중이고 Thanos 운영 경험이 축적된 조직입니다.

문서와 대응 시간대. 세 프로젝트 모두 공식 문서는 영어가 기준이고, 커뮤니티 대응은 한국 시간 기준 새벽에 몰립니다. 상용 지원 계약이 없다면 장애 시 1차 대응은 온전히 내부 몫이라고 보고 인력 계획을 세우세요.

마이그레이션 런북: Prometheus → VictoriaMetrics

1단계: 이중 기록으로 병행 운영(2주 권장)

기존 Prometheus는 그대로 두고 remote_write만 추가합니다. 롤백이 config 한 블록 제거로 끝나는 게 핵심입니다.

# prometheus.yml
global:
  scrape_interval: 30s
  external_labels:
    cluster: prod-a
    replica: "0"

remote_write:
  - url: http://vmsingle.monitoring.svc:8428/api/v1/write
    remote_timeout: 30s
    queue_config:
      capacity: 10000          # 샤드당 버퍼
      max_shards: 50           # 백로그 시 확장 상한
      min_shards: 4
      max_samples_per_send: 2000
      batch_send_deadline: 5s
      min_backoff: 100ms
      max_backoff: 5s
    write_relabel_configs:
      - regex: '(request_id|trace_id)'
        action: labeldrop

병행 기간에 감시할 지표:

# 원격 쓰기 백로그 (0 근처를 유지해야 정상)
prometheus_remote_storage_samples_pending

# 재시도/실패율
rate(prometheus_remote_storage_samples_failed_total[5m])

# 큐 지연 (초 단위, 지속 상승하면 max_shards 상향)
prometheus_remote_storage_queue_highest_sent_timestamp_seconds
  - ignoring(url) prometheus_remote_storage_highest_timestamp_in_seconds

정상 결과: samples_pending은 스파이크 후 수십 초 내 0 근처 복귀, samples_failed_total 증가율 0. 지속적으로 pending이 쌓이면 네트워크 대역이 아니라 대체로 max_shards 부족이거나 수신측 CPU 포화입니다. vmsingle의 CPU 사용률과 vm_rows_inserted_total을 함께 보세요.

2단계: 과거 데이터 이관

# Prometheus 로컬 TSDB → VictoriaMetrics
# 이관 중 Prometheus는 읽기 전용 스냅샷을 사용
curl -XPOST http://prometheus:9090/api/v1/admin/tsdb/snapshot

vmctl prometheus \
  --prom-snapshot=/prometheus/snapshots/20260819T031500Z-abcdef \
  --vm-addr=http://vmsingle:8428 \
  --vm-concurrency=4 \
  --vm-batch-size=200000 \
  --prom-filter-time-start=2025-08-01T00:00:00Z

# Thanos 버킷(S3)에 이미 장기 데이터가 있다면
vmctl remote-read \
  --remote-read-src-addr=http://thanos-query:9090 \
  --remote-read-filter-time-start=2025-08-01T00:00:00Z \
  --remote-read-step-interval=day \
  --vm-addr=http://vmsingle:8428

정상 결과: vmctl이 처리한 시계열/샘플 카운트를 출력하며 종료 코드 0. context deadline exceeded가 반복되면 --vm-batch-size를 절반으로 줄이고 --remote-read-step-interval을 hour로 낮춥니다.

3단계: 검증 쿼리

같은 질의를 양쪽에 던져 차이를 확인합니다.

Q='sum(rate(container_cpu_usage_seconds_total[5m]))'
for U in http://prometheus:9090 http://vmsingle:8428; do
  curl -sG "$U/api/v1/query" --data-urlencode "query=$Q" | jq -r '.data.result[0].value[1]'
done

허용 오차는 rate 계열 1% 이내, counter 총합 0.1% 이내를 기준선으로 잡으면 무난합니다. 차이가 크면 대개 (1) 이관 시작 시각이 겹치지 않았거나 (2) external_labels가 달라 시계열이 분리된 경우입니다.

4단계: 대시보드·알럿 호환성 체크리스트

• Grafana 데이터소스를 Prometheus 타입으로 추가(VictoriaMetrics는 PromQL 호환 API 제공)
• subquery·@ modifier·histogram_quantile 사용 패널 개별 확인
• recording rule / alerting rule은 vmalert로 이관, 평가 주기와 for 값 동일하게 유지
• Alertmanager 연동 경로 유지 여부 확인 — 알림 파이프라인 설계는 Grafana 대시보드 Prometheus 연동과 Alerting 설정 참고
• 장기 범위(3개월) 패널의 응답 시간 별도 측정
• 백업: /snapshot/create API로 스냅샷 → 객체스토리지 업로드 크론 등록

5단계: 롤백 판정 기준

병행 기간 중 아래 중 하나라도 48시간 연속 위반하면 remote_write 블록을 제거하고 원복합니다.

결론: 이 경우엔 그냥 이거 쓰세요

1. 전담 SRE가 없고 망분리도 아니라면 → B(Grafana Cloud). 단, 리스트가로는 절대 가지 마세요. 볼륨 계약 단가를 문서로 확보하지 못하면 그 순간 B는 후보에서 빠집니다.
2. 폐쇄망이거나 예산 압박이 크고 엔지니어를 0.3명이라도 붙일 수 있다면 → C(VictoriaMetrics). 위 조건에서 월 TCO가 가장 낮고, 반입할 바이너리가 두 개뿐이라 폐쇄망 절차 비용도 가장 작습니다.
3. 이미 Thanos가 안정적으로 돌고 조직 표준이 Prometheus 생태계라면 → A 유지. 이 경우 전환 이득(월 약 85만원)보다 전환·재학습 비용이 큽니다. 다만 compactor 헬스체크 알럿만은 오늘 걸어두세요.

메트릭 백엔드 교체 비용은 OpenTelemetry와 remote_write 표준화 덕분에 예전보다 확실히 낮아졌습니다. 반대로 말하면, 비싼 선택지에 계속 머무를 이유도 그만큼 줄었다는 뜻입니다. 모니터링 스택 전체 아키텍처를 다시 그리는 단계라면 Prometheus·Grafana·Datadog 비교 가이드를 함께 보시길 권합니다. 로그 축 비용은 과금 단위가 달라 별도 계산이 필요합니다.

자주 묻는 질문 (FAQ)

Q. 활성 시계열 100만이면 VictoriaMetrics 단일 노드로 정말 버티나요? A. 8vCPU/64GB급 인스턴스 한 대로 소화되는 구간으로 일반적으로 보고됩니다. 다만 판단 기준은 시계열 수만이 아니라 동시 쿼리 수와 쿼리 범위입니다. 3개월 범위 대시보드를 여러 명이 동시에 본다면 CPU가 먼저 포화되므로, vm_concurrent_select_capacity와 CPU 사용률을 2주간 관측한 뒤 클러스터 전환을 검토하세요.

Q. Grafana Cloud 요금이 갑자기 뛰는 걸 막을 방법이 있나요? A. 근본 대책은 수집 단계 차단입니다. metric_relabel_configs로 고카디널리티 라벨을 원격 전송 전에 잘라내고, 활성 시계열 수 자체를 알럿 대상으로 삼으세요(예: 전일 대비 20% 증가 시 경고). 벤더가 제공하는 사용량 대시보드와 상한/알림 옵션도 계약 시점에 함께 협의하는 것이 좋습니다.

Q. Thanos를 걷어내지 않고 VictoriaMetrics를 같이 쓸 수 있나요? A. 가능합니다. Prometheus의 remote_write에 VictoriaMetrics를 추가해도 기존 sidecar → S3 경로는 그대로 동작하므로, 병행 운영 기간 동안 두 백엔드를 동시에 유지할 수 있습니다. 다만 병행 기간에는 인프라 비용이 두 배로 나가므로 2~4주 안에 결론을 내는 일정으로 잡으세요.

Q. 위 비용표의 단가를 그대로 예산안에 써도 되나요? A. 아닙니다. 본문 단가는 2026년 8월 기준 공개 가격표를 참고한 가정값이며 리전·약정·환율에 따라 달라집니다. 산식 구조(인스턴스 × 시간 + 스토리지 GB + 전송 + 운영공수)만 가져다 쓰시고, 숫자는 AWS 요금 계산기와 벤더 공식 견적으로 반드시 재검증하세요.