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

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

한 줄 요약

기존 chain 라우터 vmagent에 remoteWrite 하나(RW#4)를 더하고 그 URL에만 per-URL 스트림 집계(streamAggr, OSS)를 걸어 전 메트릭을 5m 해상도로 치환합니다. 산출물은 별도 vmsingle(-retentionPeriod=400d, RF1, 저가 EBS, VM OSS만)에 적재합니다. 라우터 vmagent 패턴에 RW#4 하나가 늘어날 뿐, 새로 배우거나 배포할 스택은 없습니다. streamAggr·vmagent 파이프라인의 개념은 VM 챕터의 03 인제스트, vmsingle의 저장·압축은 04 저장·압축을 참조합니다.

아키텍처

[service — 무상태, 변경 없음]
  vmagent ──(Istio ingress, remote_write)──▶
[chain]
  라우터 vmagent ──RW#1──▶ VMCluster hot (raw, 90d, RF2, gp3)     ← 기존
              │──RW#2──▶ keep-list tier                            ← 기존 설계
              │──RW#3──▶ 집계 tier                                 ← 기존 설계
              └──RW#4──▶ [per-URL streamAggr: 5m, 전 메트릭 치환]
                          └─▶ vmsingle-archive (400d, RF1, EBS PVC)
                               └─(CronJob) vmbackup → S3   ← DR용 콜드 사본
Grafana: DS#1 vmselect(≤90d raw) / DS#2 vmsingle-archive(>90d, 5m)

집계는 RW#4에만 걸리므로 hot(RW#1) raw는 그대로 90d 유지됩니다. hot은 최근 장애의 golden window를, 아카이브는 >90d 추세·수준 비교를 맡는 2계층입니다.

핵심 설정 (검증된 필드만)

전 메트릭을 접미사 regex 2규칙으로 배타 커버합니다 — 카운터류는 total, 나머지 게이지는 avg. 두 규칙 모두 keep_metric_names: true라 원래 메트릭 이름이 보존됩니다.

# 라우터 VMAgent — RW#4
remoteWrite:
  - url: http://vmsingle-archive.monitoring.svc:8428/api/v1/write
    streamAggrConfig:
      rules:
        - match: '{__name__=~".+(_total|_count|_sum|_bucket)"}'   # 카운터류(히스토그램 포함)
          interval: 5m
          outputs: [total]
          keep_metric_names: true       # 단일 output일 때만 허용 — 원래 이름 유지 → rate() 그대로
          flush_on_shutdown: true       # 재시작 시 첫/마지막 interval drop 방지
        - match: '{__name__!~".+(_total|_count|_sum|_bucket)"}'   # 나머지 = 게이지 가정
          interval: 5m
          outputs: [avg]                # 스파이크 조사용 max 필요 시 별도 규칙 추가(시리즈 ×2)
          keep_metric_names: true
          flush_on_shutdown: true

# vmsingle-archive (VMSingle CR)
spec:
  retentionPeriod: "400d"
  storage:                    # 시작은 gp3 권장(기본값) — 06 문서 참조. 최적화 시 st1/sc1
    resources: { requests: { storage: 1.5Ti } }   # f 실측 후 조정 (0.9~2.7 TiB 예상)

전 메트릭 커버리지 원리

• 접미사 regex 2규칙이 서로 배타적으로 전체를 덮습니다. by/without 미지정 → 입력 시리즈별 라벨 보존, 시간축 집계만 수행합니다. match된 raw는 집계 산출물로 치환되므로 아카이브에 raw가 유출되지 않습니다.
• 히스토그램(classic): _bucket은 per-bucket 카운터라 total이 맞고 le가 보존돼 histogram_quantile(rate(..._bucket[10m]))이 아카이브에서 그대로 동작합니다(5m 입도).
• keep_metric_names 덕에 기존 대시보드·vmalert 쿼리가 datasource 전환만으로 동작합니다. 아카이브도 VM이라 MetricsQL이 그대로 유지됩니다 — MetricsQL/PromQL·vmselect는 VM 챕터 05 쿼리·운영 컴포넌트 참조. 미확인 MetricsQL 의존도 리스크도 사라집니다.

비용

시나리오 ②(raw 90d + 전 메트릭 5m 집계 400d) 기준. 아카이브 저장량은 δ × 400d × f로 산출합니다. f(집계 축소율)는 드라이런에서 실측해 확정합니다.

아카이브 = δ × 400d × f × 단가
  δ = 22.5 GiB/day (사본 1개; 3.6 TiB/80d/RF2 상한 가정)
  f = 집계 축소율 0.1~0.3 (샘플 수 1/10 + 인덱스 몫 + 집계값 압축률 저하 감안 — 실측 확정)
  → 0.9~2.7 TiB

• 선택: vmbackup S3-IA 콜드 사본 $12~37/mo.

단순 확장안($1,642/mo) 대비 약 70%를 절감합니다. 확장안이 비싼 이유(gp3 단가 × RF2)는 05 VMCluster 확장에서 다룹니다. 4안 종합 비용표·판단 트리는 07 핵심논점, 서울 리전 단가 상세는 06 스토리지 단가에 있습니다.

강점과 리스크

강점

• 4안 중 최저 비용(확장안 대비 ~70%↓), 신규 stateful 컴포넌트 1개(vmsingle)뿐이며 그마저 기존과 동일 기술스택 — 신규 기술 학습 0.
• MetricsQL·기존 대시보드 쿼리 보존 → 의존도 미확인 리스크 소멸.
• service 무상태 원칙 무영향. 기존 라우터 설계에 RW 하나 추가로 자연 결합.
• RW#4 대상만 교체하면 Thanos안으로 전환되므로 가역적입니다(아래 참조).

리스크

• 집계가 인제스트 시점에 확정됩니다 — “나중에 p99 필요"는 불가. hot 90d raw가 유일한 재계산 원본이므로 검증 전 hot 축소 금지.
• streamAggr 상태는 프로세스 메모리에 있어 크래시가 나면 현재 5m 윈도우가 유실됩니다. flush_on_shutdown: true로 완화합니다. 재조사 용도라면 수용할 만합니다. 카운터 리셋은 rate()가 흡수합니다.
• 접미사 휴리스틱이 오분류할 수 있습니다 — 비표준 카운터가 avg로 집계되면 rate 불가. 드라이런에서 오분류 목록을 추출한 뒤 예외 match 규칙으로 보강합니다.
• 전 메트릭 집계 상태만큼 라우터 vmagent 메모리가 늘고 활성 시리즈 수에 비례합니다. 사이징 실측 필요(검증 필요).
• RF1이라 아카이브 이중화가 없어 vmbackup 주기 백업으로 보완합니다. vmbackup/vmrestore·무중단 운영은 VM 챕터 07 대규모 운영 참조.

streamAggr는 사전에 확정돼 재계산이 불가하고 Thanos downsampling은 사후 재계산이 되는 대신 공간을 절감하지 못합니다. 둘의 축별 비교와 “이 건에서 성립하는 대체"라는 판정 근거는 07 핵심논점에 있습니다.

가역성 (탈출구)

이 구조는 가역적입니다. RW#4는 언제든 Thanos Receive로 갈아끼울 수 있고 그러면 그대로 03 Thanos안으로 전환됩니다. 드라이런 실측에서 f가 예상을 크게 벗어나거나 “확정 집계가 재조사에 부족"이 드러나면 그때 재평가하면 됩니다 — VM 아카이브안을 채택해도 Thanos안이 영구히 배제되지는 않습니다.

롤아웃

1. vmsingle-archive 배포(gp3로 시작).
2. RW#4 드라이런 2주: 일일 GiB 증가율(f 실측) · 시리즈 수 · 카운터 오분류 목록 · rate/histogram_quantile 정합 확인.
3. 예외 규칙 보강 → Grafana DS 추가 + 재조사 대시보드 1개 시범 이관.
4. vmbackup CronJob(S3, 네이티브 증분 — OSS). vmbackupmanager(스케줄 자동화)는 Enterprise라 k8s CronJob으로 직접.
5. (선택) vmctl로 기존 80d raw 시드 [검증 필요].
6. hot retention 80d→90d 상향(+$41/mo) — 아카이브 검증 전까지 hot 축소 금지.

모니터링 대상은 RW#4의 vmagent_remotewrite_pending_data_bytes, 라우터 vmagent 메모리, vmsingle 디스크 증가율입니다. 진행 전 실측 항목 전체 목록은 08 권장·하지말것에 정리돼 있습니다.

출처

• 01-option-a-vm-archive.md — A안 아키텍처·핵심 설정·비용 계산·롤아웃·검증된 사실
• 99-full-report.md §2.1(A안 상세), §5(권장안·구체 설계·탈출구)
• README.md §5(권장안 요약·가역성·업계 선례)