Ops Insights – 모니터링

Prometheus가 하지 않는 일

Sun, 30 Aug 2026 00:00:00 +0000

Prometheus가 하지 않는 일 — 리텐션의 경계

Prometheus 리텐션을 늘려 장기 보관을 해결하려다 보면 곧 벽을 만납니다. 기간을 늘리면 용량이 선형으로 늡니다. 해상도를 깎아 완만하게 만들 방법이 Prometheus 안에는 없습니다.

Thanos Compactor가 채우는 자리

Sun, 30 Aug 2026 00:00:00 +0000

Thanos Compactor가 채우는 자리 — 다운샘플링의 실제 동작

Prometheus에 없는 해상도 티어링은 Thanos Compactor가 맡습니다. 오브젝트 스토리지 버킷을 훑으면서 블록을 병합하고 해상도를 깎은 블록을 새로 만들고 만료된 블록을 지웁니다.

Sidecar vs Receive

Sun, 30 Aug 2026 00:00:00 +0000

Prometheus에 붙이는 두 방식 — Sidecar vs Receive

“Thanos를 붙인다"는 한마디가 전혀 다른 배치 둘을 가리킵니다. 어느 쪽을 고르느냐에 따라 방화벽 정책과 장애 반경이 달라집니다.

VictoriaMetrics에 Thanos를 붙일 수 있나

Sun, 30 Aug 2026 00:00:00 +0000

VictoriaMetrics에 Thanos를 붙일 수 있나

“Prometheus를 VictoriaMetrics로 바꾸고 뒤에 Thanos를 붙여 S3 장기 보관을 한다"는 그림이 자연스러워 보입니다. 성립하지 않습니다.

Receive 실전 구성

Sun, 30 Aug 2026 00:00:00 +0000

Thanos Receive 실전 구성

앞 문서들의 결론을 배치로 옮깁니다. 파드 넷이 뜹니다 — Receive, Compactor, Store Gateway, Querier. 여기에 캐시를 붙이면 다섯입니다.

vmagent / Prometheus(agent) ──remote write──▶ Receive (로컬 TSDB → 2h마다 업로드)
│
▼
오브젝트 스토리지
▲
Compactor (병합·다운샘플·리텐션, 싱글턴)
│
Grafana ◀── Querier ◀── Store Gateway ────────────┘
└────── Receive (최근 구간)

버킷 설정 (공통)

네 컴포넌트가 같은 파일을 Secret으로 마운트합니다.

Thanos·VM·Mimir 선택 가이드

Sun, 30 Aug 2026 00:00:00 +0000

무엇을 고를 것인가

앞의 다섯 문서를 판단 순서로 압축합니다.

첫 질문 — 해상도 티어링이 정말 필요한가

필요 없을 수 있습니다. 카디널리티가 크지 않으면 raw를 그대로 오래 들고 가는 편이 단순하고 쌉니다.

네이버 검색 SRE 시계열 DB 운영기

Sat, 01 Aug 2026 00:00:00 +0000

01 · 네이버 검색 SRE의 시계열 데이터베이스 운영기 (2024-02)

참조한 내용정리 · 이 문서는 아래 네이버 D2 원문을 읽고 우리 지식베이스 형식으로 재구성한 요약입니다. 원문 자체가 아니며 정확한 워딩·전체 맥락·그림은 원문에서 확인합니다.

스택 구성

Sat, 01 Aug 2026 00:00:00 +0000

01 · 우리 스택 구성

k8s 위 VM operator가 vmagent를 Deployment(stateless)로 띄우고 중앙 VM 클러스터의 vminsert 엔드포인트로 remote_write 합니다.
목적지 경로 /insert/0/prometheus는 클러스터 모드 · tenant 0을 뜻합니다.
stage/prod는 값이 다릅니다 — 리소스·maxDiskUsagePerURL이 환경별로 달라지고 prod는 vmagent가 두 계열(용도별 분리)이라 extraArgs가 양쪽에 함께 걸립니다.
공통 수집 설정은 scrapeInterval 30s · promscrape.streamParse=true · promscrape.maxScrapeSize=24GiB.

우리 환경에서 지표가 어디서 만들어져 어디로 흘러가는지, 그 구조와 stage/prod 값 차이를 정리합니다. 전송 안정화 Phase 1 튜닝은 02 vmagent 전송 튜닝에서, 장기보관 아키텍처는 메트릭 장기보관 챕터에서 따로 다룹니다.

카디널리티

Sat, 01 Aug 2026 00:00:00 +0000

01 · 카디널리티 — 시계열 폭발의 원리와 설계 원칙

시계열 = 지표 이름 + 레이블 집합. 레이블 값 하나만 달라도 완전히 다른 시계열이 됩니다.
New TSID 발급(=처음 보는 시계열)이 곧 카디널리티 폭발입니다. IndexDB에 인덱스를 쓰는 연산이라 데이터포인트 추가보다 CPU·메모리를 훨씬 많이 먹습니다.
Worst case는 pod_name·session_id처럼 자주 바뀌는 값을 레이블로 쓰는 것입니다. Best case는 설계 단계에서 배제하는 것 — 서비스 이름 같은 안정 레이블만 쓰고 자주 바뀌는 값은 로그·트레이스로 뺍니다.
런타임에는 churn rate(신규 시계열 생성 속도)와 slow insert rate(지속 10% 초과 시 메모리 부족 경고)를 봅니다.

VM 운영에서 가장 자주 사고를 내는 개념이 카디널리티입니다. 출발점은 “한 시계열이 무엇으로 정의되는가"입니다. 거기서 카디널리티 폭발이 왜 곧 메모리·인덱스 폭발인지, 설계 단계에서 어떻게 막는지까지 이어 봅니다.

TSDB와 VictoriaMetrics

Sun, 12 Jul 2026 00:00:00 +0000

01 · 시계열 데이터와 VictoriaMetrics

시계열은 “언제 어떤 숫자가 찍혔나"가 이어지는 데이터입니다. 지표에는 Counter/Gauge/Histogram/Summary 4타입이 있습니다. 그중 Counter류 단조증가값이 압축이 가장 잘 됩니다.
“대용량"을 나누는 기준은 시계열 개수와 보관 기간입니다. 수백만 개까지는 Prometheus 단일로 충분하지만 수천만~수십억 개부터는 별도 솔루션이 필요합니다.
TSDB 계보: Prometheus(2012) → Gorilla 압축(2015, Facebook) → Thanos/Cortex(Prometheus 확장) vs VictoriaMetrics(완전히 다른 계열).
VM은 Prometheus 호환(PromQL·remote_write 그대로)을 지키면서 자체 벤치마크 기준 메모리 5배·스토리지 7배 효율을 주장하는 오픈소스 TSDB입니다.

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

문제와 결정 2축

Sun, 12 Jul 2026 00:00:00 +0000

문제 정의와 결정 2축

목적은 과거 장애 재조사용 메트릭 400일 보관. >90d 구간은 5m 해상도 허용(확정), 전 메트릭 커버리지 필요, OSS 우선.
결정은 2축: (1) 무엇을 보관하나(raw 400d 전부 vs raw 90d + 5m 집계 400d — 후자가 비용을 자릿수로 낮춥니다) · (2) 어디에 저장하나(VM은 S3를 primary로 지원하지 않아 EBS 위에 둡니다).
서울 리전 단가는 sc1 < S3 Standard < st1 < gp3 — “S3라서 싸다"는 성립하지 않습니다.
확정 시나리오(raw 90d + 5m 집계 400d) 기준 VM 아카이브안이 월 $385~416로 최저, 단순 확장($1,642)보다 자릿수로 쌉니다.

메트릭 400일 보관 문제를 정의하고 비용을 자릿수 단위로 좌우하는 두 결정축(무엇을 보관 / 어디에 저장)을 정리합니다. 시나리오별 저장량·비용 규모와 검증된 서울 리전 단가 요약표를 함께 싣습니다.

대규모 메트릭 저장소 운영기 (1편)

Sat, 01 Aug 2026 00:00:00 +0000

02 · 네이버 검색의 대규모 메트릭 저장소, VictoriaMetrics 운영기 1편 (2026-04)

참조한 내용정리 · 아래 네이버 D2 원문을 읽고 우리 지식베이스 형식으로 재구성한 요약입니다. 원문 자체가 아니므로 정확한 워딩·전체 맥락·그림은 원문에서 확인합니다.

아키텍처

Sat, 01 Aug 2026 00:00:00 +0000

02 · 아키텍처 — 4개 컴포넌트와 저장 원리

VM 클러스터는 vmagent(수집) → vminsert(라우팅·샤딩) → vmstorage(저장, n노드) → vmselect(fanout+merge 쿼리) 4컴포넌트로 흐릅니다.
배포 모드는 SingleNode(간편, SPOF)와 Cluster(수평확장, replicationFactor로 유실 방지) 둘입니다. vminsert/vmselect는 stateless라 k8s에, vmstorage는 stateful이라 물리 장비에 두는 편이 유리합니다.
대용량 write와 read를 함께 만족시키는 자료구조가 LSM 트리(append로 빠른 write, 정렬 유지로 빠른 read, merge는 백그라운드)입니다. VM의 파티션 구조가 이 구체화입니다.
IndexDB(거의 불변, 지표이름+레이블 역색인)와 DataDB(TSID → timestamp+value, 계속 쌓임)를 나눠 두면 정규화 효과로 압축 효율이 크게 올라갑니다.

여기서는 VM 클러스터를 이루는 컴포넌트, 그 사이를 흐르는 데이터, 그 아래를 떠받치는 두 아이디어 — LSM 트리와 IndexDB/DataDB 분리 — 를 정리합니다. 컴포넌트 하나하나의 내부 동작은 뒤 문서에서 따로 깊게 파고듭니다.

초대규모 운영과 무중단 전환

Sat, 01 Aug 2026 00:00:00 +0000

02 · 초대규모 운영기 — 멀티버스와 무중단 장비 전환

진화 경로: SingleNode(SPOF) → Cluster(이질적 접근 패턴이 한 클러스터를 과부하) → 멀티버스(대시보드·알람별 클러스터 분리) + vmauth 라우팅.
현재 규모: 180노드(Hot 120·Warm 60), 12.5억 활성 시계열, 555조 데이터포인트(0.92바이트/DP) — 공개 사례 중 최상위권.
Hot/Warm 2계층(SSD 12개월/HDD 36개월)으로 성능·비용 균형을 잡습니다 — dual write + 쿼리 시간범위 기반 읽기 분기.
무중단 128GB→512GB 장비 전환: Hot은 랑데부 해싱 역순 추가(기존 장비 부하 최소화), Warm은 vmbackup/vmrestore(vmctl은 API 부하로 배제) — 서비스 중단 0분·메트릭 유실 0건.

네이버 검색은 5년에 걸쳐 VictoriaMetrics를 굴리며 12.5억 시계열·555조 데이터포인트·180노드라는 초대규모에 도달했습니다. 그 현장 이야기입니다. 단일 클러스터가 무너지는 지점, 여러 클러스터로 쪼갠 “멀티버스”, Hot/Warm 2계층, 180대를 무중단으로 갈아 끼운 전환 설계를 다룹니다.

vmagent 전송 튜닝

Sat, 18 Jul 2026 00:00:00 +0000

02 · vmagent 전송 안정화 (Phase 1)

remoteWrite.forceVMProto=true — 자동 협상을 없애고 VM native protocol(zstd)로 고정합니다. 로그 없이 일어나던 snappy 다운그레이드가 사라지므로 전송량 2~4x 절감을 보장합니다. 수신측 vminsert v1.88+ 필요.
remoteWriteSettings.maxDiskUsagePerURL — 기본값 0(무제한)이라 링크 장애가 길어지면 노드 디스크가 고갈됩니다. 상한에 도달하면 오래된 블록부터 FIFO drop합니다. 적용값은 stage 1000MiB / prod 2000MiB.
대안(미적용) statefulMode=true — 큐를 PVC로 옮기면 유실이 없어집니다. 그런데 무상태 원칙의 예외라서 그 예외를 인정할 때만 택합니다.
적용 순서는 stage 먼저 → 수일 관찰 → prod 순입니다. 적용 후 확인은 03 자기감시 메트릭.

Phase 1의 목표는 전송 안정화입니다. 전송 프로토콜을 zstd로 고정했고 디스크 큐에 상한을 명시했습니다. 각 변경의 근거와 트레이드오프, 적용 순서를 아래에 정리했습니다.

VictoriaMetrics 아카이브

Sun, 12 Jul 2026 00:00:00 +0000

VictoriaMetrics 아카이브 — 라우터 RW#4 + streamAggr 5m → vmsingle 400d

권장안: 기존 라우터 vmagent에 RW#4를 추가하고 streamAggr로 전 메트릭을 5m 집계해 별도 vmsingle-archive(400d, RF1)에 적재합니다 — 신규 기술 0.
월 $385~416, 단순 확장안($1,642) 대비 ~70% 절감. hot(raw 90d)은 그대로 남습니다. keep_metric_names로 기존 쿼리·대시보드도 그대로 동작합니다.
리스크: 집계는 인제스트 시점에 확정돼 사후 재계산이 불가, RF1이라 vmbackup으로 이중화를 보완, 접미사 휴리스틱 오분류 가능성.
구조는 가역적입니다 — RW#4를 Thanos Receive로 교체하면 Thanos안으로 전환됩니다. 드라이런 2주로 집계 축소율(f)을 실측한 뒤 확정합니다.

관련 문서: 01 문제·2축, 03 Thanos, 05 VMCluster 확장, 06 스토리지 단가, 07 streamAggr vs downsampling, 08 권장·하지말것

Inside VictoriaMetrics

Sat, 01 Aug 2026 00:00:00 +0000

03 · Inside VictoriaMetrics — 내부 동작 정독 (2026-06)

수집 (vmagent·vminsert)

Sat, 01 Aug 2026 00:00:00 +0000

03 · 수집 — vmagent와 vminsert

vmagent는 OTel·InfluxDB·Datadog 등 다양한 프로토콜을 받아 릴레이블·dedup·스트리밍 집계 후 remote_write로 내보내는 만능 어댑터입니다. Fast Queue(메모리)→Persistent Queue(디스크) 버퍼링으로 지표를 잃지 않습니다.
vminsert는 저장하지 않고 랑데부 해싱으로 vmstorage에 라우팅만 합니다 — 노드를 추가해도 재배치가 약 1/(N+1)에 그쳐 리밸런싱 폭풍을 피합니다.
노드 다운 시 페일오버(살아있는 노드로 균등 재분배), replicationFactor로 복제 후 vmselect 쿼리 시 dedup — 쓰기 시점 복제(안정성)와 읽기 시점 dedup(정확성)이 짝을 이룹니다.
vminsert↔vmstorage 연결은 압축 방식을 협의하며 rpc.disableCompression으로 CPU↔대역폭 트레이드오프를 조절할 수 있습니다.

VM에서 데이터가 들어오는 관문은 둘입니다. vmagent는 무엇이든 받아 정제해 리모트로 흘려보내는 만능 어댑터이자 버퍼입니다. vminsert는 그렇게 받은 데이터를 여러 vmstorage 노드로 흩뿌리는 라우팅 게이트웨이입니다. 이 둘을 차례로 봅니다.

자기감시 메트릭

Sat, 18 Jul 2026 00:00:00 +0000

03 · 우리가 보는 자기감시 메트릭

전송 상태는 네 지표로 봅니다 — retries(재시도), packets_dropped(드랍), bytes_sent(전송량), pending_data_bytes(대기 큐).
bytes_sent로 forceVMProto 효과를 판정합니다 — 적용 후 뚝 떨어졌으면 여태 snappy로 나갔고 그대로면 이미 zstd였습니다. 둘 다 정상입니다.
pending_data_bytes가 평시 0 근처를 벗어나 계속 증가하면 목적지 병목 신호입니다.
카디널리티 감시(churn rate · slow insert)는 D2 개념을 계승합니다 → 실전 01 카디널리티. 인벤토리는 vmui + metric_names_stats로 뽑습니다.

Phase 1이 제대로 적용됐는지 전송이 건강한지 판정할 때 보는 자기감시(self-monitoring) 메트릭을 정리합니다. 02의 적용 후 확인이 여기로 이어집니다.

쿼리 패턴

Sat, 18 Jul 2026 00:00:00 +0000

03 · 쿼리 패턴 — PromQL에서 MetricsQL까지

지표 타입이 쿼리를 결정합니다 — Counter는 rate/increase, Gauge는 순간값·sum/avg_over_time, 지연 분포는 histogram_quantile, 차원을 접는 sum by 가 실전 4대 패턴입니다.
VM 계열 클라이언트의 히스토그램은 le 대신 vmrange 버킷을 씁니다(클래식 le 히스토그램도 그대로 저장·쿼리됩니다) — MetricsQL histogram_quantile는 vmrange를 그대로 받고 Prometheus 형식이 필요하면 prometheus_buckets() 로 변환합니다.
MetricsQL은 PromQL 상위호환입니다 — rate/increase가 외삽하지 않고 range를 생략하면 창을 max(step, scrape_interval)로 자동 결정하며 default_rollup·keep_metric_names·WITH·topk_avg 등 확장을 더합니다.
무거운 쿼리(넓은 시간범위 × 고카디널리티)는 vmselect 메모리를 먹습니다 — 차원 축소·recording rule 선계산·캐시로 회피하고 카디널리티는 /api/v1/status/tsdb 와 vmui 카디널리티 익스플로러로 점검합니다.

01 카디널리티와 02 대규모 운영이 “무엇을 저장하고 어떻게 운영하는가"였다면, 이 문서의 주제는 저장한 것을 어떻게 꺼내 읽는가 — 곧 쿼리입니다. VM은 PromQL을 그대로 받으면서 그 상위호환인 MetricsQL로 확장합니다. 지표 타입별 실전 패턴, MetricsQL만의 확장, 무거운 쿼리의 회피, 카디널리티 점검 쿼리를 차례로 정리합니다.

Thanos

Sun, 12 Jul 2026 00:00:00 +0000

Thanos — Receive → S3 (cold 400d, compactor downsampling)

raw는 S3에 짧게(730d)만 두고 400d 보관은 compactor가 사후에 만들어내는 5m/1h 다운샘플 블록이 맡습니다 — S3 내구성(11-nines) + 사후 재계산 보험을 얻는 대신 stateful 컴포넌트 34종과 더 높은 비용을 치릅니다.
다운샘플링은 저장 절감 수단이 아닙니다(공식 명시) — 해상도가 공존하는 구간이 ~~3x로 부풀어 총액이 월 **$780~~1,200 + 컴퓨트**가 됩니다.
Receive는 hashring 상태를 쥔 StatefulSet이라 반드시 chain에 둬야 하고 Compactor는 오류를 만나면 알림 없이 halt하므로 감시 알림이 필수입니다.
아카이브 쿼리는 PromQL 전용이 되어 MetricsQL 전 기능을 상실합니다 — 대신 VM 아카이브안에서 RW#4 대상만 교체하면 언제든 이 안으로 전환 가능합니다.

VM hot은 단기로 유지하고 raw는 S3에 짧게만 쌓습니다. 400d를 채우는 쪽은 Thanos compactor가 사후에 생성하는 5m/1h 다운샘플 블록입니다. 이 구성으로 S3 내구성 + 사후 재계산 보험을 얻고 대가로 stateful 컴포넌트 3~4종과 더 높은 저장비를 치릅니다.

운영기 2편 — 3단계 최적화

Sat, 01 Aug 2026 00:00:00 +0000

04 · VictoriaMetrics 운영기 2편 — 장비 증설 없이 리소스 위기를 해결한 3단계 최적화 (2026-07)

저장과 압축

Sat, 01 Aug 2026 00:00:00 +0000

04 · 저장과 압축 — vmstorage와 Gorilla 계열 압축

지표는 Time Series(이름+레이블, 거의 불변)와 Sample(timestamp+value, 계속 쌓임)로 분리 저장됩니다 — IndexDB/DataDB 정규화의 근거.
저장 경로: 로우 파싱 → Canonical Name 정규화 → TSID 변환(캐시 hit=빠른 경로, miss=New TSID 발급=카디널리티 폭발 원인) → 압축 → 파티션(인메모리→Small→Big, Merge Multiplier로 비슷한 크기끼리 합침).
압축 비결은 Gorilla 계열 차분 인코딩: Gauge→Delta, Counter→Delta-of-Delta(단조증가값이 압축에 극단적으로 유리) + ZigZag/Varint로 바이트 절약. 네이버 실운영 실측 0.92바이트/데이터포인트(원래 16바이트 대비 ~17배 압축).
retention은 기본 1개월, IndexDB는 단건 삭제 비용을 피하려 3단계(Current/Previous/Next) 로테이션으로 통째로 드롭합니다.

vminsert가 흩뿌린 데이터를 실제로 디스크에 눕히는 컴포넌트가 vmstorage입니다. 여기서는 지표 하나가 TSID로 바뀌어 파티션에 저장되기까지의 경로를 따라갑니다. 이어서 VM의 메모리·스토리지 효율을 떠받치는 Gorilla 계열 차분 압축을 다룹니다.

스케일링·용량 기준치

Sat, 18 Jul 2026 00:00:00 +0000

04 · 스케일링·용량 기준치

디스크 큐 상한 산정식: sum(rate(vmagent_remotewrite_bytes_sent_total[1h])) × 버틸 장애 시간 (실측 후 조정). 현행 stage 1000MiB / prod 2000MiB.
vmagent 리소스는 현행값을 기준치로 두고, 실측 후 조정은 TODO로 남깁니다.
HA(replicaCount: 2)는 의도적 미적용 — replica가 각자 전량 전송해 cross-cluster 트래픽이 2배가 되고 dedup은 저장만 절약하므로 전송 절감 목표와 상충합니다.
slow insert 지속 10% 초과 = 메모리 부족 경고 (D2 계승) → 실전 01 카디널리티.

큐 상한·리소스·HA·메모리 임계를 어떤 근거로 잡는지 적어 둡니다. 확정 숫자보다 판단 기준과 산정식에 무게를 둡니다 — 실제 값은 실측으로 조정합니다.

Mimir

Sun, 12 Jul 2026 00:00:00 +0000

Mimir — Grafana Mimir 장기 tier

Mimir는 다운샘플링이 OSS·GEM·3.0 어디에도 없어 “5m 해상도 400d” 요구를 원리적으로 충족할 수 없습니다 — 이 시나리오에서 탈락.
유일한 실현 형태는 raw 400d 전부 S3 — 경제성이 시나리오 ①(전 구간 raw)로 되돌아가 월 ~$740 + Kafka·컴퓨트.
운영 footprint가 최대입니다 — distributor/ingester/compactor/store-gateway/querier/query-frontend에 3.0부터 Kafka 기본 의존까지 8~10종.
PromQL 전용이라 MetricsQL을 잃는 건 Thanos안과 같습니다. 재검토는 대규모 멀티테넌시·Grafana 스택 표준화가 독립 목표일 때만.

관련 문서: 01 문제·2축, 02 VictoriaMetrics, 03 Thanos, 07 핵심논점 · PromQL vs MetricsQL은 VM 쿼리·컴포넌트

쿼리·운영 컴포넌트

Sat, 01 Aug 2026 00:00:00 +0000

05 · 쿼리·운영 컴포넌트 — vmselect / vmalert / vmauth

vmselect는 저장을 하지 않는 stateless 쿼리 엔진입니다. 모든 vmstorage에 Fanout으로 던지고 돌아온 결과를 Merge·Sort해 반환합니다.
쿼리는 3-Prefix(태그→Metric ID→TSID→값·이름 복원)로 풀립니다. 쓰기 시점 정규화를 역방향으로 되짚는 대칭 구조입니다.
메모리 관리 3포인트: 쿼리 시점 dedup, Rollup Result Cache(허용 메모리 12.5%, 최근 5분 제외), Query Latency Offset(기본 30초, 정확성↔실시간성 트레이드오프).
vmalert는 Recording rules로 무거운 집계를 미리 계산해 조회 부하를 쓰기 시점으로 옮깁니다. vmauth는 멀티 클러스터 앞단 라우팅 게이트웨이로 사용자 배포 없이 장애 전환을 처리합니다.

데이터가 들어가는 길(03 수집·04 저장)은 이미 다뤘습니다. 이 문서는 데이터가 빠지는 길, 그리고 그 주변에 붙는 운영 컴포넌트를 봅니다. 쿼리 엔진 vmselect, 지표를 미리 계산해 두는 vmalert, 멀티 클러스터의 앞단을 지키는 라우팅 게이트웨이 vmauth 셋입니다.

VMCluster 확장

Sun, 12 Jul 2026 00:00:00 +0000

VMCluster 확장 — 현행 클러스터 단순 확장 & Enterprise 다운샘플(확장+Ent)

단순 확장안 = retentionPeriod만 400d로 늘리고 PVC 증설. 신규 컴포넌트·쿼리 변화 0으로 가장 단순하지만 gp3×RF2×raw 30s 과잉으로 4안 중 최고가(월 ~$1,642, 헤드룸 시 ~$2,000) — 다른 안의 비용을 재는 기준선입니다.
확장+Ent(-downsampling.period=90d:5m 한 줄)는 저장비만 ~$497로 단순 확장안의 약 1/3이지만 **Enterprise 라이선스(비공개)**가 필요해 OSS 우선 제약상 참고용.
다운샘플링은 시리즈 수를 줄이지 않습니다(공식 caveat) — 고카디널리티·고churn 워크로드에서는 저장 절감 효과가 제한됩니다.
확장+Ent는 VM 아카이브안 운영이 검증 후에도 부담스러울 때만 고려하는 대안입니다.

현행 VMCluster를 그대로 400d로 늘리는 가장 단순한 길이 단순 확장안, 그 위에 설정 한 줄로 다운샘플을 더하는 Enterprise 경로가 확장+Ent입니다. 앞쪽은 채택 후보라기보다 다른 옵션의 비용 비교 기준선이고 뒤쪽은 OSS-우선 제약 때문에 참고용에 머뭅니다.

소스맵

Sun, 12 Jul 2026 00:00:00 +0000

06 · 소스맵 — 발표 영상·기사·전사본 가이드

이 지식베이스의 바탕은 네이버 D2/DEVIEW가 공개한 VictoriaMetrics 자료 5건입니다 — 발표 영상 2편과 텍스트 기사 3편. 이 자료를 주제별로 다시 묶어 개념/실전/우리 운영 문서로 엮었습니다. 자료 하나하나를 원문 단위로 정리한 판은 원문별 정리에 따로 있습니다. 여기서는 각 문서가 어떤 원본에서 나왔는지, 원본을 직접 확인하려면 어디를 봐야 하는지 적었습니다.

스토리지 단가

Sun, 12 Jul 2026 00:00:00 +0000

06 · 스토리지 단가 & 볼륨 특성 — 서울 리전

서울 리전 $/GB·월 서열: sc1($0.0174) < S3 Standard($0.025) < st1($0.051) < gp3($0.0912) — “S3라서 싸다"는 성립하지 않습니다.
S3 IA/Glacier IR은 GB당 리트리벌 수수료 때문에 자주 읽는 primary 아카이브에 맞지 않습니다. vmbackup 콜드 사본 전용입니다.
아카이브 볼륨은 gp3로 시작해 IO 실측 후 st1/sc1로 최적화합니다 — sc1의 250 IOPS 상한이 미검증 리스크입니다. 시나리오②의 절대액 차이(월 $66~199)도 작으니 검증 전 채택은 금지.
bytes/sample 기준치: VM ~1B, Prometheus/Thanos ~~1.5~~2B, Mimir ~2B — 벤더 베스트케이스는 예산 근거로 쓰지 않습니다.

서울 리전(ap-northeast-2)의 스토리지 단가와 gp3/st1/sc1/S3의 성능·내구성 특성을 여기 모아 두었습니다. 아카이브 볼륨 타입을 고르는 판단 구조도 함께 담았습니다 — gp3로 시작 → 실측 → st1/sc1 최적화. 단가 상세는 이 문서에 있습니다.

streamAggr vs downsampling

Sun, 12 Jul 2026 00:00:00 +0000

streamAggr(사전) vs Thanos downsampling(사후) — 핵심 논점

실전 대결은 streamAggr(인제스트 시점 사전 집계, VM 아카이브안) 대 Thanos compactor downsampling(사후 집계, Thanos안) — Mimir는 다운샘플링 부재로 즉시 탈락.
저장량 축이 결정적입니다. Thanos 다운샘플링은 공식 문서상 “공간 절감 없음”(공존 시 ~~3x)입니다. streamAggr는 raw의 **10~~30%**로 실제 감소합니다.
의미론·자동성은 Thanos가 우위(사후 재계산 가능, 무설계 5-aggregate 보존)지만 이 건의 조건(5m 허용 확정+비용 최소+신규 스택 회피)에서는 streamAggr가 대체로 성립합니다.
판정: VM 아카이브안 채택, 단 아카이브 검증 전까지 hot 90d raw retention 축소 금지 — 가역적(RW#4를 Thanos Receive로 교체하면 언제든 전환).

“400d 아카이브의 5m 해상도를 누가 만드느냐"를 정하는 문서입니다. VM OSS의 streamAggr(인제스트 시점 사전 집계, VM 아카이브안)와 Thanos compactor downsampling(사후 집계, Thanos안)을 4축으로 대조하고 판단 기준 트리와 시나리오 ② 비용 종합표(VM아카이브/Thanos/Mimir/확장/확장+Ent)를 여기서 확정합니다. 비교표·판단 트리·비용 종합표의 주인 문서입니다 — 다른 문서는 이리로 링크합니다.

권장안·하지 말 것

Sun, 12 Jul 2026 00:00:00 +0000

08 · 권장안(VM OSS 아카이브) 종합 근거 · 업계 선례 · 하지 말 것 10선

권장은 VM OSS 아카이브안(라우터 RW#4 + streamAggr 5m → vmsingle-archive 400d)입니다. 4안 중 비용이 월 $385~416으로 가장 낮고 되돌릴 수 있으며 service 무상태에 영향이 없습니다. 신규 기술은 0이고 MetricsQL도 그대로 남습니다.
업계 선례가 “장기 = 집계만"을 뒷받침합니다. Criteo(계층화 절감), Uber M3(1h/5y rollup), MHI Vestas(VM 13개월 안정 운영) — 방향성 근거이고 예산 근거는 아닙니다.
검증에서 기각된 함정 10선: VM에 S3 primary 기대 금지, vmbackup을 쿼리 가능한 아카이브로 착각 금지, Thanos downsampling을 저장 절감 수단으로 오인 금지, 아카이브 검증 전 hot retention 축소 금지 등.
진행 전 드라이런 2주로 실측해야 하는 항목: 집계 축소율 f(가정 0.1~0.3), 카운터/게이지 오분류, 라우터 vmagent 메모리 증분, sc1/st1 부하.

400d 보관 결정의 최종 종합입니다. VM 아카이브안을 왜 권장하는지 근거를 한자리에 모읍니다. 업계 선례로 패턴을 뒷받침한 뒤 검증에서 기각된 함정 10개와 진행 전 드라이런 2주 실측 목록을 정리합니다.