VictoriaMetrics 운영 비용 2026, 메트릭 저장소·장비·보안 기준

VictoriaMetrics 운영 비용 검토를 위한 메트릭 대시보드와 서버 스토리지 비용 회의 장면 — 메트릭 저장소 비용은 서버 가격보다 보존 기간, cardinality, query 부하, 백업 복구 체계에서 갈린다.

VictoriaMetrics 운영 비용을 묻는 팀은 보통 Prometheus 장기 저장소가 커진 뒤에 움직인다.

처음에는 디스크 몇 TB와 노드 몇 대를 보면 될 것 같지만, 실제 예산은 active time series, 보존 기간, query 부하, 백업 복구, 보안 경계에서 결정된다.

자체 구축은 오픈소스 라이선스 덕분에 소프트웨어 사용료가 낮아 보인다.

그러나 SRE가 업그레이드, shard 증설, cardinality 폭발, 장애 복구를 떠안으면 장비값보다 운영 시간이 더 커질 수 있다.

이 글은 VictoriaMetrics 공식 문서와 Cloud 가격 문서를 기준으로 자체 구축과 관리형 배포를 비용·보안·운영 관점에서 비교한다.

핵심 요약

VictoriaMetrics는 단일 바이너리 단일 노드부터 vmstorage·vminsert·vmselect 클러스터까지 선택지가 넓어 비용 구조가 배포 방식에 따라 달라진다.
VictoriaMetrics Cloud는 smallest tier가 약 $190/month부터 시작하고, 제품 페이지는 Single node $225/month와 Cluster $1,300/month 앵커를 공개한다.
자체 구축은 라이선스 비용보다 스토리지 성장, egress, 백업 복구, query cardinality, on-call 운영 시간을 먼저 계산해야 한다.
이 조건이면 single-node 또는 관리형으로 시작하고, multi-tenant와 수평 확장이 검증된 뒤 cluster 전환을 검토하는 편이 안전하다.

이 글이 필요한 사람

Prometheus 보존 기간을 늘리다 로컬 디스크와 query 성능 한계에 닿은 SRE 팀.
Thanos, Cortex, Mimir, Elastic Observability, VictoriaMetrics를 비용 기준으로 다시 비교해야 하는 플랫폼팀.
Kubernetes 모니터링 데이터를 장기 보관해야 하지만 SIEM 로그 비용과 혼동하고 있는 구매 담당자.
메트릭 데이터에 tenant, 서비스명, 사용자 라벨이 섞여 cardinality 폭발을 걱정하는 운영팀.
관리형 VictoriaMetrics Cloud와 자체 구축 중 어느 쪽이 더 싼지 내부 결재 문서로 설명해야 하는 팀.

먼저 결론: VictoriaMetrics는 싸게 시작할 수 있지만 공짜 운영은 아니다

VictoriaMetrics 문서는 단일 노드 버전이 작은 실행 파일과 명령줄 flag 중심 설정으로 운영된다고 설명한다.

이 구조는 Prometheus 장기 저장소를 빠르게 붙일 때 매력적이다.

하지만 비용 판단은 설치가 쉬운지보다 장애가 났을 때 누가 복구하는지에서 갈린다.

이 조건이면 단일 노드 자체 구축이 합리적이다.

월간 ingest가 예측 가능하고, 보존 기간이 짧으며, 복구 테스트를 맡을 SRE가 있고, query 사용자가 제한된 경우다.

이 경우는 관리형이나 클러스터 검토가 낫다.

팀별 tenant가 많고, 장애 허용 시간이 짧고, 저장 기간이 길며, metric cardinality가 계속 늘어나는 경우다.

선택지	비용 축	강점	보류 신호
Single-node 자체 구축	서버, SSD, 백업 저장소, SRE 시간	구성이 단순하고 작은 팀이 빠르게 시작 가능	HA 요구와 장기 retention이 강하면 리스크 증가
Cluster 자체 구축	vmstorage·vminsert·vmselect 노드, 네트워크, 운영 자동화	수평 확장과 multi-tenant 분리에 유리	팀에 VictoriaMetrics 운영 경험이 없으면 장애 대응 난이도 상승
VictoriaMetrics Cloud	tier, storage, egress, 월 invoice	업데이트, 보안 패치, 백업 부담 감소	리전, PrivateLink, egress, 계약 조건 확인 필요
기존 Prometheus 유지	로컬 디스크와 인스턴스 운영 시간	구조 변경 없이 짧은 retention 운영 가능	장기 보존과 global query 요구가 생기면 한계 노출
Elastic·Grafana Cloud 등 대안	SaaS 구독, ingest, retention, 사용자 비용	로그·APM·알림까지 묶기 쉬움	메트릭 장기 저장만 필요하면 과한 비용이 될 수 있음

공식 가격표 핵심 숫자: 관리형 기준선을 먼저 잡는다

비용 의도 글에서 “오픈소스라 싸다”라고만 쓰면 결재 자료가 되지 않는다.

관리형 기준선을 먼저 잡아야 자체 구축의 인건비와 장애 리스크를 비교할 수 있다.

VictoriaMetrics Cloud billing 문서는 compute, storage, network로 비용을 나누고, 사용량을 시간 단위로 누적한 뒤 월 단위로 청구한다고 설명한다.

같은 문서는 외부 egress를 GB당 $0.09로 공개하고, smallest tier 가격이 약 $190/month부터 시작한다고 적는다.

제품 페이지는 starter Single node를 월 $225부터, starter Cluster를 월 $1,300부터 제시한다.

공식 항목	공개 숫자	과금 단위	예산 해석
Cloud smallest tier	~$190/month	최소 tier 기준	PoC와 소규모 운영의 관리형 기준선
Cloud Single node	$225/month	starter single-node deployment	500k active time series와 1개월 retention 예시
Cloud Cluster	$1,300/month	starter cluster deployment	250K active time series와 1개월 retention 예시
Network egress	$0.09/GB	외부 egress 트래픽	Grafana, federation, 외부 조회 위치에 따라 누적
Billing cadence	hourly accumulated, monthly charged	사용량 누적과 월 청구	테스트 deployment 방치 비용을 태그로 관리
SLA Single node	99.5%	제품 페이지 기준	운영 리스크를 자체 구축 장애 허용 시간과 비교
SLA Cluster	99.95%	제품 페이지 기준	HA 요구가 강하면 단순 월액 비교보다 SLA가 중요

이 숫자는 환율과 세금, 계약 할인, 리전 조건에 따라 달라질 수 있다.

그래도 내부 견적표에는 반드시 넣어야 한다.

Prometheus API나 remote_write라는 표현이 있어도 이 글의 비용 기준은 LLM API처럼 입력·출력 토큰을 USD 단가로 청구하는 구조가 아니다.

자체 구축안이 월 $225 또는 $1,300보다 싸다고 주장하려면, 서버비뿐 아니라 on-call과 복구 테스트 시간을 함께 계산해야 한다.

단일 노드와 클러스터를 비용표에서 분리한다

VictoriaMetrics cluster 문서는 단일 노드가 백만 data points per second 미만 ingestion rate에서 권장될 수 있다고 설명한다.

문서는 cluster를 고르기 전에 다시 생각하라고 명시한다.

cluster는 vmstorage, vminsert, vmselect를 나눠 확장할 수 있지만, 그만큼 장애 지점과 운영 절차도 늘어난다.

따라서 PoC 예산표에서 “cluster면 안전하다”라는 문장을 넣으면 위험하다.

구분	Single-node	Cluster	결정 질문
구성 요소	단일 VictoriaMetrics 프로세스 중심	vmstorage, vminsert, vmselect 분리	팀이 각 구성 요소별 지표를 볼 수 있는가
확장 방식	CPU, RAM, storage 수직 확장 중심	서비스별 수평 확장 가능	병목이 ingest인지 query인지 storage인지 측정했는가
운영 난이도	설정과 백업이 상대적으로 단순	routing, replication, tenant, rolling upgrade 고려	운영 문서와 rehearsal 시간이 있는가
비용 위험	큰 서버와 빠른 SSD에 집중	노드 수, cross-zone network, automation 비용 증가	고가용성 요구가 실제 SLA로 정의됐는가
적합한 시작점	작은 팀, 명확한 retention, 제한된 사용자	다수 tenant, 높은 ingest, 장애 허용 낮음	single-node로 30일 측정 후 전환해도 되는가

이 조건이면 단일 노드로 30일 측정을 먼저 한다.

peak ingest, active series, top query, storage growth, backup duration을 실제 값으로 잡은 뒤 cluster 전환을 논의한다.

이 경우는 처음부터 cluster를 검토한다.

조직별 tenant 격리가 필요하고, query와 write를 분리해야 하며, 장애 시 특정 노드 손실을 견뎌야 하는 경우다.

실무 시나리오 1: Kubernetes 플랫폼팀의 90일 메트릭 보존

플랫폼팀이 Kubernetes control plane, node exporter, application metrics를 90일 보존하려고 한다고 가정한다.

현재 Prometheus는 15초 scrape interval과 로컬 디스크로 15일만 버틴다.

이때 VictoriaMetrics 자체 구축 비용은 서버 한 대 가격으로 끝나지 않는다.

비용 항목	확인값	누락하면 생기는 문제	담당자
active series	서비스·pod·tenant label별 unique series	cardinality 폭발로 storage와 query 지연 증가	SRE
retention	90일, 180일, 13개월 중 감사 요구 확인	필요 이상 저장으로 SSD와 백업 비용 증가	운영 책임자
storage growth	일별 증가량과 압축률 추정	디스크 증설 시점과 장애 여유 미확정	인프라팀
query pattern	Grafana dashboard, alert rule, ad-hoc query	heavy query가 장애 원인이 됨	서비스 오너
backup restore	snapshot, remote backup, 월 1회 복구 테스트	장애 때 데이터 보존 약속을 증명 못함	SRE

이 시나리오에서는 관리형 $225/month 기준선과 자체 구축 서버비를 비교하되, SRE 월 10시간 이상이 들어가면 계산이 바뀐다.

서버비가 낮아도 장애 대응 리허설과 복구 테스트가 없으면 운영 리스크가 예산 절감보다 크다.

실무 시나리오 2: 여러 팀이 쓰는 multi-tenant 메트릭 플랫폼

두 번째 시나리오는 사내 여러 서비스팀이 같은 메트릭 저장소를 쓰는 경우다.

cluster 문서는 tenant를 accountID와 projectID로 식별하고, vmauth나 vmgateway 같은 앞단 서비스가 인증과 라우팅을 맡아야 한다고 설명한다.

이 구조에서는 메트릭 저장 비용보다 tenant 경계, 권한, 쿼리 남용 제어가 더 중요해진다.

검토 항목	단일팀 운영	멀티팀 운영	예산 영향
tenant 분리	라벨 규칙으로 충분할 수 있음	accountID, projectID, gateway 정책 필요	인증·권한 컴포넌트 운영비 추가
query 제어	대시보드 owner가 제한됨	ad-hoc query 사용자 증가	heavy query 방지와 교육 필요
chargeback	공유 비용으로 처리 가능	팀별 series, storage, egress 배부 필요	FinOps 태그와 월 리포트 필요
장애 대응	한 팀의 영향으로 한정	한 팀의 cardinality가 전체 플랫폼을 흔듦	quota와 격리 설계 비용 증가
보안	관리자 수가 적음	운영자와 tenant 관리자 권한 분리 필요	감사 로그와 접근 승인 프로세스 필요

이 조건이면 자체 cluster를 선택할 수 있다.

tenant별 비용 배부와 권한 분리가 이미 내부 정책으로 필요하고, 운영 자동화를 만들 팀이 있는 경우다.

이 경우는 관리형을 먼저 검토한다.

공유 메트릭 플랫폼이 필요하지만 내부에 storage, network, query 장애를 맡을 사람이 없는 경우다.

vmagent와 remote write 비용을 따로 본다

VictoriaMetrics 운영 비용에서 저장소만 보면 절반만 본 것이다.

vmagent 문서는 Prometheus compatible target을 scrape하고 relabel과 filter를 적용해 remote_write로 보낼 수 있다고 설명한다.

또한 원격 저장소가 불안정할 때 임시 데이터를 디스크에 buffer하고, remoteWrite.maxDiskUsagePerURL로 사용량을 제한할 수 있다고 설명한다.

이 말은 수집 계층에도 디스크와 네트워크 비용이 있다는 뜻이다.

수집 계층 항목	비용이 생기는 지점	운영 기준	실패 신호
scrape target 수	agent CPU와 메모리	서비스 디스커버리와 owner 라벨 필수	target owner 없이 scrape만 증가
relabel과 filter	운영 설정 검토 시간	고카디널리티 라벨 차단 규칙 필요	user_id, session_id 같은 라벨 유입
remote write bandwidth	네트워크와 egress	동일 리전과 private path 우선	외부 Grafana와 cross-region 조회 증가
buffer disk	장애 시 임시 저장소	max disk usage와 알림 설정	원격 저장소 장애 때 agent 디스크 full
HA 수집	agent 중복과 dedup 설정	중복 sample 처리 기준 확정	중복 ingest로 storage가 불필요하게 증가

이 조건이면 vmagent를 먼저 표준화한다.

서비스별 Prometheus가 제각각이고, remote_write 실패 시점에 누락과 중복이 반복되는 경우다.

이 경우는 저장소 증설보다 scrape 설정 정리가 먼저다.

라벨 폭발을 막지 않으면 어떤 저장소를 써도 비용이 다시 증가한다.

보안·백업·복구 비용은 초기 견적에 넣는다

메트릭은 로그보다 민감도가 낮다고 여겨지지만, 서비스명, tenant, endpoint, 장애 패턴이 들어가면 내부 구조를 드러낼 수 있다.

VictoriaMetrics 운영 비용에는 관리자 접근, tenant 경계, 백업 저장소, snapshot 복구 테스트가 포함되어야 한다.

Cloud를 쓰면 업데이트와 일부 운영 부담은 줄지만, 계정 권한과 네트워크 경계는 여전히 고객이 확인해야 한다.

보안·복구 항목	자체 구축 비용	Cloud 확인 질문	통과 기준
관리자 권한	SSH, service account, secret 관리	조직 관리자와 deployment 관리자 분리 가능 여부	break-glass 계정과 승인 기록 존재
네트워크 경계	VPN, private subnet, firewall rule	PrivateLink 또는 private endpoint 조건	공개 endpoint를 기본값으로 두지 않음
백업	snapshot, object storage, restore rehearsal	scheduled backup과 export 가능 여부	월 1회 복구 테스트 결과 저장
감사	admin action log, query access 기록	Billing page와 usage report 보존 방식	비용과 변경 이력을 결재 문서에 연결
데이터 삭제	retention 변경과 삭제 절차	storage 축소와 retention 변경 영향	장기 보존 요구와 삭제 요구 충돌 없음

이 조건이면 보안팀을 PoC 첫 주부터 넣어야 한다.

메트릭 endpoint가 외부 SaaS와 연결되고, production service 이름과 tenant label이 그대로 나가는 경우다.

이 경우는 비용 테스트보다 접근 통제 테스트를 먼저 한다.

운영자가 누구인지 모르는 상태에서 저장소만 먼저 열면, 나중에 권한 회수가 더 어렵다.

도입 순서: 30일 측정 후 결재한다

VictoriaMetrics 운영 비용을 산정할 때 가장 나쁜 방식은 공식 가격표와 서버 견적을 바로 비교하는 것이다.

먼저 30일 동안 실제 ingest, active series, top query, storage growth를 측정해야 한다.

현재 Prometheus와 exporter 목록에서 target owner, scrape interval, label 규칙을 수집한다.
상위 active series와 고카디널리티 label을 뽑아 user_id, request_id, session_id 유입을 차단한다.
단일 노드 VictoriaMetrics 또는 Cloud trial deployment에 remote_write를 붙여 7일 이상 쓰기 부하를 본다.
Grafana dashboard와 alert rule을 복제해 top query 지연과 timeout을 기록한다.
retention 30일, 90일, 180일별 storage 증가량과 백업 소요 시간을 추정한다.
Cloud 기준 $190, $225, $1,300/month와 자체 구축 서버·스토리지·SRE 시간을 같은 통화로 환산한다.
복구 테스트와 관리자 권한 회수 테스트를 통과한 뒤 production 전환 여부를 결정한다.

이 순서를 거치면 “서버 한 대면 충분하다”와 “처음부터 cluster가 필요하다”라는 주장을 데이터로 걸러낼 수 있다.

PoC 결과가 없으면 어떤 쪽도 비용 절감이라고 말하기 어렵다.

실무 스켈레톤: 비용·cardinality·복구 검산

아래 템플릿은 바로 배포하는 코드가 아니라 결재 전 검산용 스켈레톤이다.

공식 문서와 내부 운영 기준을 확인한 뒤 실제 계정, 리전, retention, 접근 권한을 바꿔 적용해야 한다.

비용 검산 YAML

# victoriametrics-cost-plan.yaml
# 목적: VictoriaMetrics 운영 비용을 자체 구축과 Cloud 기준으로 같은 표에 올린다.
# 실제 금액은 장비 견적, 환율, 리전, 계약 할인, 네트워크 요금, 내부 인건비로 다시 확인한다.

context:
  owner_team: sre-platform
  checked_date: 2026-07-31
  workload: prometheus_long_term_metrics
  retention_days: 90
  scrape_interval_seconds: 15
  estimated_active_time_series: 420000
  peak_ingest_samples_per_second: 180000

managed_reference:
  victoriametrics_cloud_smallest_tier_usd_month: 190
  victoriametrics_cloud_single_node_anchor_usd_month: 225
  victoriametrics_cloud_cluster_anchor_usd_month: 1300
  egress_usd_per_gb: 0.09
  single_node_sla_percent: 99.5
  cluster_sla_percent: 99.95

self_hosted_cost_items:
  compute:
    node_count: 3
    cpu_reserved: true
    memory_reserved: true
  storage:
    local_ssd_required: true
    backup_snapshot_required: true
    growth_buffer_percent: 30
  network:
    cross_zone_replication_checked: true
    remote_write_bandwidth_checked: true
  operations:
    upgrade_window: monthly
    oncall_owner: sre-platform
    query_cardinality_review: weekly
  security:
    tenant_isolation: required
    private_endpoint_or_vpn: required
    admin_audit_log: required

approval_gate:
  require_30_day_ingest_sample: true
  require_cardinality_topn: true
  require_restore_test: true
  require_cloud_vs_self_hosted_cost_review: true

scrape target 위험 점검 스크립트

#!/usr/bin/env python3
# vmagent_scrape_guard.py
# 목적: VictoriaMetrics 이전 전 scrape target과 cardinality 위험을 사전에 분류하는 검사용 스켈레톤이다.
# 실제 운영에서는 Prometheus 설정, 서비스 디스커버리, 보안 정책을 확인한 뒤 read-only로 실행한다.

from dataclasses import dataclass

@dataclass
class ScrapeTarget:
    name: str
    samples_per_second: int
    active_series: int
    owner: str
    contains_user_label: bool

    def risk(self) -> str:
        if self.contains_user_label:
            return "block: user-level label may explode cardinality"
        if self.active_series > 100_000:
            return "review: high cardinality target"
        if self.samples_per_second > 50_000:
            return "review: high ingest target"
        return "allow"

targets = [
    ScrapeTarget("kubernetes-control-plane", 42000, 88000, "platform", False),
    ScrapeTarget("api-user-metrics", 12000, 210000, "service-a", True),
]

for target in targets:
    print(target.name, target.owner, target.risk())

retention과 복구 정책 JSON

{
  "victoriametrics_retention_review": {
    "default_retention_days": 90,
    "hot_query_days": 14,
    "downsampling_needed": "check_enterprise_or_cloud_feature_before_commit",
    "backup": {
      "snapshot_frequency": "daily",
      "restore_test_frequency": "monthly",
      "owner": "sre-platform"
    },
    "security": {
      "admin_access": "break-glass-only",
      "tenant_routing": "vmauth-or-gateway-required",
      "public_endpoint": false
    }
  }
}

비용 절감보다 먼저 볼 실패 패턴

VictoriaMetrics 전환은 메트릭 비용을 줄일 수 있지만, 실패 패턴을 무시하면 더 비싼 운영 사고가 된다.

첫 번째 실패는 cardinality를 정리하지 않고 저장소만 바꾸는 것이다.

두 번째 실패는 single-node를 작은 비용으로 시작한 뒤 백업과 복구 테스트를 미루는 것이다.

세 번째 실패는 cluster를 만들고도 tenant별 quota와 query 제한을 설계하지 않는 것이다.

네 번째 실패는 관리형 Cloud 비용을 월액만 보고 egress와 외부 조회 경로를 빠뜨리는 것이다.

실패 패턴	초기 증상	비용 영향	막는 방법
cardinality 폭발	active series가 주 단위로 급증	storage, CPU, query 지연 증가	label allowlist와 topN 리뷰
백업 부재	snapshot은 있지만 restore 기록 없음	장애 때 장기 메트릭 손실	월 1회 restore rehearsal
query 남용	Grafana 대시보드 하나가 전체 지연 유발	노드 증설과 사용자 불신	top query 리포트와 owner 지정
tenant 미분리	팀별 비용과 장애 원인 추적 불가	공유 플랫폼 갈등 증가	accountID, projectID, gateway 설계
egress 누락	외부 조회와 cross-region 전송 증가	$0.09/GB 비용 누적	리전 근접성과 private path 검토