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

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

관련 문서: 00 인덱스, 01 문제·2축, 02 VM 아카이브, 03 Thanos, 04 Mimir, 05 VMCluster 확장, 06 단가, 08 권장·하지말것

질문의 구조

VM OSS에는 다운샘플링이 없습니다 — -downsampling.period는 Enterprise 전용(contact-sales)입니다. “5m 허용"이 확정되어 시나리오 ②(raw 90d + 전 메트릭 5m 집계 400d)가 전제가 되면 남는 질문은 이 5m을 무엇이 만드는가 하나로 좁혀집니다.

후보는 셋인데 Mimir는 OSS·GEM·3.0 어디에도 다운샘플링이 없어 이 요구에서 즉시 탈락합니다(04). 남는 실전 대결은 streamAggr(VM 아카이브안) 대 **Thanos downsampling(Thanos안)**입니다.

두 후보는 돌아가는 위치부터 다릅니다. streamAggr는 라우터 vmagent 파이프라인 안의 OSS 기능(v1.87.0+)입니다 — VM 인제스트 경로의 위치는 수집 (vmagent·vminsert) 참조합니다. Thanos downsampling은 S3에 raw 블록을 쌓은 뒤 compactor가 배치로 5m/1h 블록을 만듭니다.

4축 비교

축별 요약은 아래 표가, 상세 논거는 그 뒤 (a)~(d) 절이 받습니다.

(a) 확정 시점 — 의미론

streamAggr는 인제스트 시점에 집계가 확정됩니다. 나중에 “p99가 필요했다"라고 깨달아도 재계산은 불가합니다. 상태가 프로세스 메모리라 재시작 시 첫/마지막 interval이 기본 drop됩니다(flush_on_shutdown: true로 완화). 카운터는 staleness 초과 후 재등장 시 신규 시리즈로 리셋됩니다(rate()가 리셋을 흡수).

Thanos는 raw 블록에서 사후 계산하므로 raw 보존 기간 내에는 재계산 여지가 있습니다. --retention.resolution-raw로 raw를 지운 뒤에는 똑같이 확정 데이터이며 그 5m aggregate도 고정 5종일 뿐입니다. “사후 유연성"은 raw를 오래 들고 갈 비용을 낼 때만 실재합니다. raw 90d로 자르는 순간 양쪽 다 >90d 구간은 확정 데이터이며 의미론 격차는 raw 보존 창 안으로 수렴합니다.

(b) 출력 형태 — 쿼리 호환성 (Thanos가 우위)

Thanos 5m 블록은 시리즈당 5개 aggregate를 청크에 내장합니다 — 시리즈명·수 불변, 카운터/게이지 구분을 사람이 할 필요가 없습니다.

streamAggr는 output마다 별도 시리즈가 되어 쿼리를 출력명으로 바꿔야 합니다. keep_metric_names(단일 output 규칙에서만 허용)로 원래 이름을 보존하면 카운터→total·게이지→avg의 2규칙 설계에서 시리즈 수 ×1, 쿼리 재작성 0이 됩니다. 대가는 min/max 동시 보존 포기입니다 — 스파이크 조사용 max를 추가하면 게이지 시리즈 ×2, 별도 이름이 됩니다.

평가: Thanos는 “무설계로 전부 5종 보존”, streamAggr는 “설계한 만큼만, 이름 보존 가능"입니다. 재조사 UX(같은 쿼리로 datasource만 전환)는 keep_metric_names 설계로 동등해집니다.

(c) 저장량 — streamAggr가 압도 (결정적)

Thanos 공식 문서가 명시합니다: 다운샘플링은 “공간을 절약해 주지 않는다”. 5m·1h 블록이 raw와 비슷한 크기로 2세트 추가되어 공존 구간 ~3x가 됩니다. 샘플 수로는 5 aggregates/5m vs 10 raw samples/5m라 2x 감소지만 포인트당 5개 값 + 시리즈 수 불변(인덱스 불변)이 이를 상쇄합니다. 실제 절감은 오직 raw 삭제에서 나옵니다 — 그래서 Thanos안의 400d 5m+1h가 14.930.7 TiB로 부풀고 저장비가 VM 아카이브안의 두 배 이상이 됩니다.

streamAggr는 output을 12개로 제한하면 샘플 볼륨이 raw의 1030%로 실제 감소합니다. 기본 치환 의미론(또는 dropInput: true)으로 raw가 아카이브에 아예 들어가지 않으니 400d에 0.9~2.7 TiB에 그칩니다.

평가: 목표 함수가 “저장 비용 최소화"라면 이 축이 결정적입니다. Thanos 다운샘플링은 장기 쿼리 속도 장치이지 비용 장치가 아닙니다(→ 08 하지 말 것 #3). VM 측 압축·retention 모델은 저장과 압축, 서울 리전 단가 비교는 06.

(d) 전 메트릭 커버리지의 현실성

match는 시리즈 셀렉터이므로 접미사 regex 2규칙(_total|_count|_sum|_bucket = 카운터류 → total, 나머지 = 게이지 → avg)으로 전 메트릭 배타 커버가 가능합니다. by/without를 지정하지 않으면 입력 시리즈별 시간축 집계만 수행되어 라벨이 보존됩니다. 히스토그램(classic)의 _bucket/_sum/_count는 per-bucket 카운터라 total이 맞습니다. le 라벨이 보존되므로 histogram_quantile(rate(..._bucket[10m]))도 아카이브에서 그대로 동작합니다.

한계: 접미사 휴리스틱은 완벽하지 않습니다 — 비표준 네이밍 카운터는 avg로 집계돼 rate 불가, _total로 끝나는 게이지는 total로 왜곡됩니다. 드라이런에서 오분류 목록을 뽑아 예외 match 규칙으로 보강해야 합니다. 전 메트릭 집계 상태가 라우터 vmagent 메모리에 추가되므로 사이징 실측도 필요합니다(검증 필요).

평가: “넓은 커버리지"는 keep-list 없이 2규칙으로 충족되지만 Thanos처럼 무설계 자동은 아닙니다.

판단 기준 트리

Q1. >90d 구간에도 raw 30s가 필수인가? (규제·감사 등)
 ├─ 예 → 예산 허용: 단순 확장 ($1,642+) / 비용 우선: VM raw 아카이브 (RF1 sc1/st1 + vmbackup, $485~787)
 │        S3 내구성·사후 재계산이 필수면: Thanos-raw400d (~$680~800 + 컴포넌트 4종)
 └─ 아니오, 5m 허용 (← 본 건 확정)
     Q2. 신규 스택(Thanos) 상시 운영 여력이 있는가? (hashring·compactor halt·캐시 계층)
      ├─ 없음/최소화 원함 → VM 아카이브안
      └─ 있음 → Q3. raw의 사후 재계산 보험 + S3 내구성이 집계 확정 리스크보다 중요한가?
           ├─ 예 → Thanos안 (S3 Standard 필수 — IA/GIR 금지)
           └─ 아니오 → VM 아카이브안
     Q3′. MetricsQL 의존(대시보드/vmalert)이 있거나 미확인인가?
      └─ 예 → VM 아카이브안 가중 (Thanos/Mimir는 아카이브 쿼리 PromQL 재작성)
     Q4. Mimir? → 5m 요구에서 항상 탈락. Grafana 멀티테넌시 표준화가 독립 목표이고
                  raw 400d S3 + Kafka 운영을 수용할 때만 별도 검토.

본 건은 Q1=아니오(5m 허용 확정) → Q2=최소화 원함 → VM 아카이브안으로 흐릅니다. MetricsQL 보존까지 VM 아카이브안을 가중합니다(쿼리·운영 컴포넌트의 MetricsQL 기능은 Thanos/Mimir의 PromQL 전용 경로에서 상실됩니다).

시나리오 ② 비용 종합 비교표 (VM아카이브/Thanos/Mimir/확장/확장+Ent)

raw 90d + 전 메트릭 5m 집계 400d, 월 저장비 기준(컴퓨트 별도). 공통 수식은 hot(90d) = U×(90/80)×0.0912 = $369, 아카이브(VM 아카이브안) = δ×400×f×단가(δ=22.5 GiB/day, f=집계 축소율 0.1~0.3).

VM아카이브 월 저장비는 sc1 기준이며 st1로 하면 $415~507로 늘어납니다. Mimir가 부적합한 이유는 다운샘플링 부재이고 raw로 우회하면 시나리오 ① 경제성으로 취급합니다.

불확실성 명시: VM 아카이브안의 f=0.1~0.3은 [샘플 수 축소] + [인덱스 몫(20%, 시리즈 수는 안 줄음)] + [집계값 압축률 저하 가능성]의 합이며 드라이런 2주 실측이 확정치(검증 필요)입니다. Thanos안의 S3 범위(14.930.7 TiB)는 “5m·1h 블록이 raw와 비슷"이라는 공식 서술의 해석 폭입니다. 모든 수치는 3.6 TiB 100% 사용 상한 가정이므로 실측 사용률로 선형 보정합니다. 옵션별 상세 저장 구성은 각 옵션 문서(02/03/04/05), 시나리오 ① 표는 01.

판정

의미론·자동성은 Thanos가 낫습니다. 저장량·운영 표면·MetricsQL 보존은 streamAggr가 낫습니다. 일반론으로는 불완전한 대체입니다. 그러나 이 사용자는 (i) 5m 허용을 이미 확정했고 (ii) 비용 최소가 목표이며 (iii) 신규 stateful 스택 3~4종의 대가가 크므로 — “5m 허용 + 비용 최소 + 신규 스택 회피"라는 이 건의 조건에서는 streamAggr(VM 아카이브안)가 대체로 성립합니다.

남는 잔여 리스크는 “확정 집계가 재조사에 부족할 가능성"입니다. hot 90d raw가 최근 장애의 golden window를 담당하고, >90d 재조사는 추세·수준 비교가 주라는 전제로 이를 수용합니다. 그래서 아카이브 검증 전 hot retention을 축소하지 않습니다 — streamAggr 집계는 인제스트 시점 확정이라 hot raw가 유일한 재계산 원본입니다(→ 08 하지 말 것 #10). 이 구조는 가역적입니다: RW#4를 Thanos Receive로 갈아끼우면 언제든 Thanos안으로 전환됩니다.

출처

• /home/mont/evejuni/monitoring/longterm-400d/README.md — §2 비용 비교표, §3 판단 기준 트리, §4 핵심 논점(streamAggr vs downsampling)
• /home/mont/evejuni/monitoring/longterm-400d/99-full-report.md — §3 비용 모델 표(시나리오 ②), §3-1 핵심 질문(streamAggr 대체 가능성 축별 분석), §4 판단 기준 트리