Ops Insights – 메트릭 장기보관 아키텍처 비교

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

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 권장·하지말것

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종과 더 높은 저장비를 치릅니다.

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 쿼리·컴포넌트

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 · 스토리지 단가 & 볼륨 특성 — 서울 리전

서울 리전 $/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주 실측 목록을 정리합니다.