문제 정의와 결정 2축

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

관련 블록: 00 인덱스, 02 A안(권장), 06 스토리지 단가, 07 핵심논점

1. 문제 정의

대상: chain 클러스터 VMCluster OSS (vmstorage×4, 900Gi gp3, RF=2, 현행 80d) / AWS ap-northeast-2(서울).

확정된 요구는 넷이다.

목적 = 과거 장애 재조사. 400d 보관은 지난 장애를 되짚어 원인·추세를 재확인하기 위한 것이다.
>90d 구간은 5m 해상도 허용(확정). 90일이 지난 데이터에 raw 30s는 불필요하고 5m이면 충분하다는 것이 사용자 확정 사항이다.
전 메트릭 커버리지. 재조사 시점에 어떤 메트릭이 필요할지 사전에 알 수 없으므로, keep-list가 아니라 전 메트릭을 대상으로 한다.
OSS 우선. VM Enterprise는 비교 기준으로만 다루고 기본 배제한다.

400d 보관 비용은 엔진 선택보다 데이터 형태 선택이 자릿수를 먼저 가른다. 그래서 이 문제는 두 개의 독립 결정축으로 분해된다.

2. 결정은 2축

축 1 — 무엇을 400d 보관하나 (비용을 자릿수로 가름)

보관 형태	저장량(현 워크로드 외삽)	월 저장비 규모
① raw 30s × 400d 전 구간 (현 구조 그대로 연장, RF2 gp3)	~18.0 TiB	~$1,642/mo
② raw 90d + 전 메트릭 5m 집계 400d (아카이브 RF1, 저가 EBS)	hot ~4.0 TiB + 아카이브 0.9~2.7 TiB	~$385~416/mo (범위 $390~510)

"5m 허용"이 확정됐으므로 ②가 기본 전제다. 그러면 중심 질문은 하나로 좁혀진다.

VM OSS에는 다운샘플링이 없다. -downsampling.period는 Enterprise 전용(contact-sales)이다. 이 갭을 무엇으로 5m을 만들어 메우는가?

후보는 셋이다.

vmagent streamAggr(OSS, v1.87.0+) — 인제스트 시점에 5m 집계를 만들어 별도 장기 tier로 보낸다(사전 집계) → A안. 개념 상세는 ../chapter9/03-ingestion.md.
Thanos compactor downsampling — S3에 raw 블록을 쌓고 사후에 5m/1h 블록을 만든다(사후 집계) → B안.
Mimir — 다운샘플링이 OSS/GEM 어디에도 없다(3.0에서도 미추가) → 이 요구에서는 사실상 탈락.

사전 집계 vs 사후 집계의 대비가 이 챕터의 핵심 논점이다. 판정과 비교표는 07 핵심논점에서 다룬다.

축 2 — 어디에 저장하나

VM은 S3를 primary(쿼리 가능) 스토리지로 지원하지 않는다. 2019년 issue #38 이래 2026-07 현재까지 미출시이며, 유지보수자의 "VictoriaLogs 구현 후 검토" 입장과 #38 self-assign(2026-03)은 신호일 뿐 일정 약속이 없다 — 계획에 반영 금지. 따라서 VM 계열 아카이브는 EBS(gp3/st1/sc1) 위에, Thanos/Mimir 아카이브는 S3 위에 놓인다.
서울 단가 순서: sc1 $0.0174 < S3 Standard $0.025 < st1 $0.051 < gp3 $0.0912 ($/GB·월).
즉 "S3라서 무조건 싸다"는 서울 단가에서 성립하지 않는다. sc1이 S3 Standard보다 싸다. 차이는 단가가 아니라 내구성 모델(EBS 단일 볼륨 vs S3 11-nines)과 운영 컴포넌트 수에서 난다. 압축·retention·볼륨 특성은 ../chapter9/04-storage-and-compression.md와 06 스토리지 단가를 참조하라.

3. 검증된 서울 단가 요약

출처: AWS Price List Bulk API (publicationDate 2026-07-10, AmazonEC2/S3 ap-northeast-2) — 적대적 검증 통과.

스토리지	$/GB·월	성능/제약	부대 비용
EBS gp3	0.0912	3,000 IOPS·125 MiB/s 기본 포함, 1 GiB~64 TiB	추가 IOPS/스루풋 별도
EBS st1	0.051	기본 40 MiB/s/TiB, 버스트 250 MiB/s/TiB, 125 GiB~16 TiB	—
EBS sc1	0.0174	기본 12 MiB/s/TiB, 버스트 80 MiB/s/TiB, 최대 250 IOPS	—
S3 Standard	0.025 (≤50TB)	11-nines 내구성	GET $0.0035/1만건, PUT $0.0045/1천건
S3 Standard-IA	0.0138	최소 30일·128KB 과금	리트리벌 $0.01/GB
S3 Glacier IR	0.005	최소 90일·128KB 과금	리트리벌 $0.03/GB

같은 리전 S3↔EC2 전송은 무료다. IA/GIR의 GB당 리트리벌 수수료 때문에 자주 읽는 primary 저장에는 부적합 — 백업 콜드 사본에만 쓴다. 볼륨 타입 선택 가이드(gp3 시작 → IO 실측 후 st1/sc1)는 06 스토리지 단가의 주인 항목이다.

4. 시나리오별 저장량·비용 규모

공통 기호(실측 대입용)는 아래와 같다. 모든 수치는 프로비저닝 3,600 GiB를 100% 사용한다는 상한 가정이며, 실사용률로 선형 보정한다.

U(80d, RF2 상한) = 3,600 GiB
δ = U/(80×2)     = 22.5 GiB/day (사본 1개 기준)
S ≈ 2.2×10¹⁰ samples/day (~254k samples/s)
bytes/sample: VM ~1 B / Prom·Thanos 1.5~2 B / Mimir ~2 B (베스트케이스 0.4~0.8 B는 예산 근거 금지)

hot 90d RF2 gp3 = 4,050 GiB × 0.0912 = $369/mo
아카이브(A)     = δ × 400 × f × 단가  (f = 집계 축소율 0.1~0.3, 드라이런 실측 필요)

시나리오 ① — 400d 전부 raw 30s

옵션	저장 구성	월 저장비
D 현 클러스터 확장	18.0 TiB gp3 RF2	$1,642 (헤드룸 미포함 하한)
A′ hot + VM raw 아카이브	9.0 TiB RF1 (sc1/st1)	$485(sc1) / $787(st1)
B hot + Thanos raw 400d S3	12.3~16.4 TiB S3 + Receive 로컬 EBS	~$680~800 + 컴퓨트
C hot + Mimir raw 400d S3	~16.4 TiB S3	~$740 + Kafka·컴퓨트

시나리오 ② — raw 90d + 전 메트릭 5m 집계 400d (사용자 확정 시나리오)

옵션	저장 구성	월 저장비	5m 구현 방식
A ★권장	hot 90d $369 + 집계 0.9~2.7 TiB (sc1)	$385~416 (st1 $415~507 / gp3 $451~615)	streamAggr(인제스트 시점, OSS)
B	hot 90d $369 + S3 14.9~30.7 TiB	$780~1,200 + 컴퓨트	compactor downsampling(사후)
C	(5m 불가 → raw 400d 강제)	부적합	다운샘플링 부재
D′ Ent	`-downsampling.period=90d:5m` 한 줄	~$497 + 라이선스(비공개)	Enterprise 다운샘플링

시나리오 ②의 옵션 종합 비교표·판단 트리는 07 핵심논점이 주인이며, 권장 A안의 구성·가역성 상세는 02 A안에서 다룬다.

불확실성 명시: (i) 모든 수치는 3.6 TiB 100% 사용 상한 가정 — 실사용률로 선형 보정한다. (ii) A의 f=0.1~0.3 범위는 드라이런 2주 실측이 확정치(검증 필요). (iii) B의 S3 범위 하한/상한은 "5m·1h 블록이 raw와 비슷한 크기"라는 공식 문서 서술의 해석 범위다.

출처

README.md §1(문제의 구조 — 결정은 2축), §2(비용 비교표)
99-full-report.md §1(문제 정의 — 무엇을 보관하는가, 검증된 단가 표), §2.0(공통 전제·기호)
05-storage-pricing.md(서울 리전 단가표, bytes/sample 기준치, 빠른 환산)

문제와 결정 2축