본문으로 건너뛰기

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

  • raw는 S3에 짧게(730d)만 두고 400d 보관은 compactor가 사후에 만들어내는 5m/1h 다운샘플 블록이 맡습니다 — S3 내구성(11-nines) + 사후 재계산 보험을 얻는 대신 stateful 컴포넌트 34종과 더 높은 비용을 치릅니다.
  • 다운샘플링은 저장 절감 수단이 아닙니다(공식 명시) — 해상도가 공존하는 구간이 3x로 부풀어 총액이 월 **$7801,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종과 더 높은 저장비를 치릅니다.

관련 문서: 02 VM 아카이브(권장), 07 streamAggr vs downsampling, 06 스토리지 단가, 08 권장·하지 말 것

아키텍처

라우터 vmagent ──RW#4 (-remoteWrite.forcePromProto 권장, -remoteWrite.queues=1)──▶
  Thanos Receive (StatefulSet, ketama hashring, 로컬 TSDB → 2h마다 S3 업로드)
       └─▶ S3 Standard 버킷 ◀── Compactor (엄격한 싱글턴: compaction + downsample + retention)
                 ▲                --retention.resolution-raw=7~30d
                 │                --retention.resolution-5m=400d / --retention.resolution-1h=400d
Grafana(Prometheus 타입 DS) ◀─ Querier ◀─ Store Gateway (블록당 ~6MB 로컬 index-header)
  • Thanos Receive로 보내는 경로는 라우터 vmagent의 RW#4 하나뿐입니다. S3에서 raw는 짧게(7~30d), 5m/1h는 400d로 갑니다.
  • 조회 경로는 나뉩니다. ≤90d는 기존 vmselect가, >90d는 Thanos Querier가 받습니다 — Grafana에는 datasource 2개가 공존합니다.
  • 다운샘플 성립 조건: raw 보존이 >40h여야 5m 블록이 생성되고 5m 보존이 >10d여야 1h 블록이 생성됩니다. resolution-raw를 7~30d로 권장하는 이유입니다.

컴포넌트 — 신규 stateful/준-stateful 3~4종

컴포넌트상태성배치핵심 리스크
Receivehashring 상태 보유(StatefulSet)chain 필수설정 변경 시 전 파드 flush로 ~5분 unready, OOM 사례 다수
Compactor스트림당 엄격한 싱글턴chain데이터 오류 시 crash 대신 halt → 조용한 정지
Store Gateway블록당 ~6MB 로컬 index-headerchain캐시 계층 없으면 쿼리 팬아웃 GET 급증
캐시(권장)index/chunk/bucket 캐시chainStore GW 지연·S3 요청비 완화용, 3~4번째 유형
  • Receive가 쥔 hashring 상태는 StatefulSet을 요구합니다 — service 클러스터의 무상태 원칙과 양립 불가이므로 반드시 chain에 둡니다. 로컬 TSDB의 기본값이 --tsdb.retention=15d라 EBS도 별도로 붙습니다.
  • Compactor는 자체 실패 모드가 있습니다: 데이터 오류를 만나면 죽는 대신 halt(thanos_compact_halted=1) 합니다. halt 이후에는 compaction·다운샘플·retention이 알림 없이 전면 정지하고 S3는 계속 늘어납니다(반복 보고된 운영 이슈 #517 / #6748 / #5211). → halt 알림은 필수입니다.

송신 레그 주의 (vmagent → Receive)

  • Thanos Receive는 out-of-order 샘플을 기본 거부(409) 합니다 → VM 공식 가이드가 해당 URL에 -remoteWrite.queues=1을 권고합니다(기본값은 2×CPU코어). per-URL queues 설정은 vmagent v1.135.0+ 입니다.
  • queues=1에는 vmagent_remotewrite_pending_data_bytes 증가·OOM 리스크가 실증돼 있어(#7108) -remoteWrite.maxDiskUsagePerURL 버퍼 설계가 필수입니다.
  • -remoteWrite.forcePromProto는 자동 다운그레이드가 있어 필수는 아니나 명시 권장입니다.
  • vmagent 파이프라인·remoteWrite 세부는 VM 챕터 인제스트 참조.

비용 (시나리오 ②: raw 90d + 5m 집계 400d)

시나리오 정의와 검증된 서울 단가의 주인은 01 문제·2축·06 단가입니다. 이 절은 Thanos안 대입만 옮깁니다.

S3 = S × (1.5~2 B/sample) × (raw일수 + 400d × 1.2~1.8) × $0.025
  S ≈ 2.2×10¹⁰ samples/day (254k samples/s 상한 가정)
  ×1.2~1.8 = "5m·1h 블록이 raw와 비슷한 크기"라는 공식 서술의 해석 범위
  → 14.9~30.7 TiB ≈ $374~767/mo
항목월 저장비
hot 90d (기존 VMCluster)$369
S3 (5m+1h 400d + raw 7~30d)$374~767
Receive 로컬 TSDB EBS (기본 15d, 축소 가능)$42~56
S3 요청비 (compactor 재작성 + Store GW GET)+α (쿼리 패턴 의존, 미산입)
합계$7801,200/mo + 컴퓨트 4종
  • 시나리오 ①(raw 400d 전 구간)로 가면 S3가 12.316.4 TiB = $307409, 총 $680800 + 컴퓨트입니다. raw를 통째로 400d 들고 가도 이 정도입니다 — Thanos안의 “사후 재계산 보험"이 서는 근거가 여기입니다.
  • S3 범위가 이렇게 넓은 이유는 다운샘플링이 공간을 줄이지 않기 때문입니다 — 공식 문서가 5m·1h 블록을 raw와 “약간 작거나 비슷한 크기"라 명시합니다. 공존 구간은 ~3x로 부풀고 실제 절감은 오직 --retention.resolution-raw 단축(=raw 삭제)에서만 나옵니다. 이 논점의 심층 대조는 07이 주인입니다.

쿼리 경로 — PromQL 전용

  • Grafana에 Prometheus 타입 DS로 공존시킬 수는 있지만 쿼리는 PromQL 전용입니다. WITH 템플릿, rollup_*, histogram_share, keep_metric_names modifier, default/if/ifnotMetricsQL 전 기능을 아카이브 쿼리에서 상실합니다 → 재작성 비용이 듭니다.
  • 반대급부: 5m 블록은 시리즈당 5 aggregate(sum/count/min/max/counter) 를 청크에 자동 내장합니다. 덕분에 시리즈명·수가 불변이고 rate()가 투명하게 동작합니다. 카운터/게이지 구분을 사람이 할 필요가 없습니다.
  • MetricsQL/PromQL 차이는 VM 챕터 쿼리·운영 컴포넌트 참조.

버킷 스토리지 클래스 — S3 Standard 필수

  • Store Gateway가 읽는 버킷은 반드시 S3 Standard($0.025/GB-mo, 리트리벌 수수료 없음)여야 합니다.
  • S3 Standard-IA/Glacier IR 금지: IA는 +리트리벌 $0.01/GB(최소 30일), Glacier IR은 +$0.03/GB(최소 90일)입니다. 이 GB당 리트리벌 수수료가 Store Gateway 동기화·쿼리마다 부과됩니다. 자주 읽는 primary 저장에는 부적합하고 IA/GIR는 vmbackup류 콜드 사본 전용입니다(하지 말 것 #5, 08).
  • 같은 리전 S3↔EC2 전송은 무료입니다. 단가·클래스 상세는 06.

강점·약점 요약

강점

  • S3 내구성(11-nines) — RF1 EBS 아카이브보다 우월(감사 등 조직 요구 대응).
  • 사후 재계산 보험 — raw를 S3에 두는 기간 안에서는 “5m으로 부족했다” 시나리오에 대응 가능합니다.
  • 카운터/게이지 구분·설계 불필요(5 aggregate 자동 내장).

약점 / 리스크

  • 다운샘플링은 저장 절감 수단이 아닙니다(공식 명시) — 공존 시 ~3x.
  • 신규 stateful/준-stateful 3~4종의 상시 운영 부담(Receive hashring, Compactor halt, Store GW + 캐시).
  • PromQL 전용 — MetricsQL 의존이 있거나 미확인이면 재작성 리스크.
  • Receive는 service 클러스터 부적합(hashring stateful).

언제 Thanos안을 고르나

  • raw의 사후 재계산 보험이 집계-확정 리스크보다 중요할 때.
  • S3 내구성이 조직 요구(감사 등)일 때.
  • Thanos 운영 경험·여력이 이미 있을 때(hashring·compactor halt·캐시 계층 상시 운영).
  • VM 아카이브안에서 전환할 수 있습니다 — 라우터의 RW#4 대상만 Thanos Receive로 갈아끼우면 되므로 처음부터 Thanos안으로 갈 필요는 없습니다. VM 아카이브안 구성과 가역성은 02 참조.

출처

  • 02-option-b-thanos.md — B안 아키텍처·컴포넌트·비용·실패 모드 상세
  • 99-full-report.md §2.2 — B안 옵션 비교(컴포넌트 3~4종, 송신 레그, 강점/약점), §1·§3 검증된 서울 단가·비용 모델
  • 근거: thanos.io compact 문서(“downsampling doesn’t save you any space”, 해상도 공존 ~3x, 해상도별 retention 플래그) / docs.victoriametrics.com 통합 가이드(queues=1 권고, forcePromProto 선택) / Prometheus TSDB “1-2 bytes per sample” / Thanos GitHub 이슈 #517·#6748·#5211·#7108 및 커뮤니티 운영 보고
마지막 수정 일자