용량 산정 — 월 0.7TB RUM 워크드 모델(3개월·6개월·1년)

용량 산정의 배경(로컬 NVMe 스펙·EBS 대역 한계·티어링≠내구성)은 로컬 NVMe 문서가, RF2 vs RF3 선택 확률·insert_quorum·쓰기 내구성 노브는 배포 플레이북이, TCO 비교와 관리형 단가는 managed vs self-host가 이미 다룬다. 이 페이지는 그 위에 우리 RUM 워크로드(0.7TB/월)의 산식만 얹는다 — 재조사는 relref로 넘기고, 산술을 그대로 노출해 독자가 자기 워크로드로 재계산할 수 있게 한다.

1. 입력 해석 — “월 0.7TB"는 raw인가 on-disk인가

사용자 입력 “prod 세션 샘플링 100%, 월 0.7TB"는 어느 지점의 바이트인지 불명하다. 캐파의 첫 갈림길이므로 두 해석을 모두 못박는다.

캐파 산정의 대상은 결국 디스크에 실제로 쌓이는 양이므로, 본 페이지는 해석 B(on-disk 단일사본 0.7TB/월)를 1차 모델로 삼고 해석 A는 §4.7 대조로 싣는다 ≈.

-- 테이블별 on-disk vs 압축 전 크기 & 실측 압축비
SELECT table,
       formatReadableSize(sum(bytes_on_disk))               AS on_disk,
       formatReadableSize(sum(data_uncompressed_bytes))     AS uncompressed,
       round(sum(data_uncompressed_bytes)/sum(bytes_on_disk),1) AS ratio
FROM system.parts
WHERE active AND database = 'default'
GROUP BY table ORDER BY sum(bytes_on_disk) DESC;

1.1 세션 수 역산 — 두 해석의 현실성 교차검증 ≈

RUM 볼륨은 세션 리플레이가 지배한다(§2). 리플레이 on-disk가 전체의 ~78%(§2.2)라 가정하면:

• 해석 B(on-disk 0.7TB/월): 리플레이 on-disk ≈ 0.55TB/월, 세션당 on-disk ~25KB ≈ → ~22M 세션/월. RUM 내재화 문서의 “월 30M 세션"과 동일 자릿수(중대형 웹 자산). ✅
• 해석 A(raw 0.7TB/월): 리플레이 raw ≈ 0.46TB/월, 세션당 wire ~150KB ≈ → ~3M 세션/월(중소 웹 자산). 역시 내부 정합.

두 해석은 모순이 아니라 서로 다른 크기의 자산을 기술한다. system.parts(위 콜아웃) 또는 collector 메트릭으로 1회 실측하면 갈린다.

2. 압축비 & on-disk 구성 — 산식을 노출한다

ClickHouse는 컬럼 저장 + ZSTD로 관측성 데이터를 크게 압축하지만 시그널마다 비율이 다르다. 리플레이는 고엔트로피 DOM이라 낮고, 로그/트레이스는 반복 구조라 높다.

2.1 시그널별 압축비 가정 ≈

nginx 로그 52~178x 같은 낙관 상한은 원문도 “typical app log에 비대표"라 명시하므로 RUM 산정에 쓰지 않는다 ✓.

2.2 블렌디드 압축비 & on-disk 구성비 — 재계산 가능한 산식

raw 볼륨 구성비(가정: 리플레이 65% / 로그 20% / 트레이스 13% / 메트릭 2% ≈)를 시그널 압축비로 가중한다:

on-disk 분율 = 0.65/5 + 0.20/10 + 0.13/10 + 0.02/8
            = 0.130 + 0.020 + 0.013 + 0.0025 = 0.1655
블렌디드 압축비 = 1 / 0.1655 ≈ 6.0x   (민감도 밴드 5x 보수 ~ 8x 낙관)

여기서 핵심은 on-disk 상에서는 리플레이 비중이 raw보다 더 커진다는 점이다 — 리플레이는 압축이 안 되니까:

즉 on-disk 0.7TB/월(해석 B)의 월간 시그널별 생성량(단일사본)은:

이 표가 §4 전체 산정의 입력이다. ≈ — staging에서 §1 콜아웃 쿼리로 압축비를 실측해 밴드를 좁혀야 한다.

3. 캐파의 지렛대 — 리플레이는 “안 쌓인다”

여기가 이 페이지에서 가장 중요한 지점이다. TTL 정책의 기준 문서는 /hyperdx/03-s3-cold-tiering/이고, 그 핵심은:

• hyperdx_sessions(리플레이): hot(gp3)만, S3로 내리지 않고 30일 후 DELETE. 오래된 리플레이는 거의 안 보고 볼륨을 지배하므로 S3 이전조차 낭비다.
• otel_logs/otel_traces: hot 14일 → TO VOLUME 'cold'(S3) → 지평별 DELETE.
• otel_metrics_*: hot 30일 → S3 → 지평별 DELETE.

on-disk의 78.5%를 차지하는 리플레이가 30일 상한으로 잘리고 S3로도 안 가면, 리플레이는 시간이 지나도 누적되지 않는다(steady-state ~0.55TB 단일). 누적을 만드는 건 나머지 ~22%(로그+트레이스+메트릭 ≈ 0.15TB/월)뿐이다.

4. 보관 지평별 산정 — 3/6/12개월 워크드 모델 (해석 B)

4.1 공통 가정

• hot 창(EBS gp3): 리플레이·메트릭 30일, 로그·트레이스 14일(/hyperdx/03-s3-cold-tiering/ 기준 문서와 정합). hot 창 밖은 로그/트레이스/메트릭만 S3 cold로, 리플레이는 DELETE.
• cold도 replica마다 사본(self-host S3 = shared-nothing, UltraWarm식 단일사본 절감 없음, /clickhouse/02-storage-local-nvme/) → cold도 ×RF.
• 머지 헤드룸 = hot gp3에 +40%(30~40% 여유; 디스크가 차면 머지 중단·TOO_MANY_PARTS·인서트 차단) ✓/≈.
• 노드 = EBS-first Graviton r7g(메모리 최적, RUM 쿼리는 page cache 이점). r8g(Graviton4)는 여유 시 각주 옵션 ≈.

4.2 지평별 누적·hot·cold (단일사본 & RF 배수) ≈

리플레이 hot 고정분(~0.55TB)에 로그/트레이스(hot 14일)·메트릭(hot 30일) hot 잔량(~0.076TB)을 더해 hot 단일 ≈ 0.63TB(지평 무관 고정). cold는 로그/트레이스/메트릭이 hot 창을 지나 DELETE 지평까지 쌓인 양이다.

(cold = Σ 로그·트레이스·메트릭 월생성 − hot 잔량, DELETE 지평까지. 리플레이는 30일 DELETE라 누적 기여 0. 메트릭 DELETE는 180/365일.)

hot은 지평이 늘어도 ~0.63TB로 고정되고, 늘어나는 건 오직 싼 cold S3다.

4.3 물리 배치 — hot gp3 / cold S3 (RF2 기준)

• hot gp3는 지평과 무관하게 ~2TB로 고정(노드당 ~1TB). gp3 단일 볼륨 상한 64 TiB에 여유롭게 들어간다(/hyperdx/02-hot-storage-ebs/).
• cold S3만 지평 따라 증가 → 1년까지 늘려도 추가 비용은 대부분 $0.023/GB S3. 백업은 리플레이 제외(가치 급감) 후 로그/트레이스/메트릭만 Glacier IR.

4.4 노드/shard/replica — 지평 무관 고정 ≈

이 규모(hot 물리 ~2TB, raw ingest ~4.2TB/월 ≈ 평균 1.6 MB/s, 피크 ×5 ≈ 8 MB/s)에서:

• 인제스트 CPU: ClickStack “10 MB/s당 1 vCPU” → 피크 8MB/s = <1 vCPU Ⓥ. 무시 수준.
• 쿼리: RUM 대시보드·세션 검색 위주 light~moderate, page cache가 hot을 흡수.
• 결론: 1 shard × 2 replica(RF2) 로 1년+ 충분. 샤딩 불필요(조기 수평 확장은 안티패턴). RF3는 임의 2대 동시 유실 방어가 필요할 때만(/clickhouse/04-deployment-playbook/).

인스턴스 EBS 대역이 실질 병목: gp3 볼륨 스펙(최대 2,000 MiB/s)보다 인스턴스의 EBS 파이프 상한이 먼저 천장을 친다 — r7g.2xlarge의 EBS 대역이 볼륨 스펙보다 낮으므로 노드 사이즈업이 볼륨 프로비저닝보다 먼저 효과를 낸다(/clickhouse/02-storage-local-nvme/) ✓. 이 스케일(피크 8MB/s)에선 둘 다 여유라 무관하지만, 성장 시 이 순서를 기억한다. lean 옵션: 쿼리가 가벼우면 2× r7g.xlarge(4vCPU/32GB) 로 낮춰도 된다. 헤드룸을 위해 2xlarge 권장.

4.5 Keeper·MongoDB — 데이터량과 무관하게 소형 고정

• Keeper: 정족수 3(1 장애 허용), 4GB RAM·gp3 20GB면 충분. Keeper 부하는 데이터량이 아니라 INSERT 빈도·파트 생성 수에 비례하므로 지평이 늘어도 커지지 않는다(/hyperdx/05-keeper/) ✓.
• MongoDB: 메타데이터(user/dashboard/alert/source) 전용, 데이터셋 수 GB. members:3이 값싼 HA 보험, 인제스트 경로 밖이라 규모 무관(/rum/07-hyperdx-mongodb/) ✓.

4.6 월 비용 산정 (해석 B, us-east-1, on-demand) ≈

단가 ✓: gp3 $0.08/GB-mo(+$0.005/IOPS·$0.04/MBps 초과분), S3 Standard $0.023/GB-mo, Glacier IR $0.004/GB-mo, S3 PUT $0.005/1k. 인스턴스 시급은 ≈(AWS Calculator로 확정 권장).

고정 컴포넌트(지평 무관):

컴퓨트  2× r7g.2xlarge  = 2 × $0.4284/hr × 730 ≈ $626/mo   [추정 단가]
Keeper  3× t4g.medium  = 3 × $0.0336/hr × 730 ≈ $74 + gp3 60GB×$0.08 $5  ≈ $79/mo
Mongo   3× t4g.small   = 3 × $0.0168/hr × 730 ≈ $37 + gp3 30GB×$0.08 $2  ≈ $39/mo
hot gp3 2.0TB          = 2000GB × $0.08 (baseline IOPS·throughput 무료)   ≈ $160/mo
────────────────────────────────────────────────────────────────────────────
고정 소계 ≈ $904/mo

지평별 가변(cold S3 + 백업 + cross-AZ 전송, RF2):

*1yr Savings Plan은 컴퓨트에만 ~40% 적용, 스토리지·S3·전송은 정가 ≈.

RF3(12개월): 컴퓨트 3대 $938 + hot gp3 3TB $240 + cold S3 ×RF3=5.16TB $119 + Keeper/Mongo $118 + 백업 $7 + 전송 $70 ≈ ~$1,500/mo(on-demand), 1yr SP ~$1,150/mo ≈.

읽는 법: hot gp3·컴퓨트·Keeper·Mongo는 지평 무관 고정 $904. 3→12개월 확장 비용은 거의 전부 S3 cold($9→$79 증가). 긴 보관이 싼 이유는 EBS가 아니라 S3에 쌓이고, 심지어 볼륨 지배자인 리플레이는 30일에 잘리기 때문이다. Datadog RUM으로 같은 워크로드(≈월 22M 세션)를 태우면 RUM 문서 기준 블렌디드 $0.42/1k → **연 수만십수만 $**대인데, self-host는 월 ~$1.0K(연 $12K) — 수 배10배 절감(단 people TCO 별도, /clickhouse/01-managed-vs-selfhosted/).

리전 주석: 위는 us-east-1 기준. 서울(ap-northeast-2)은 인스턴스·EBS·S3가 1015% 비싸다 — 서울 배포 시 총액에 ×1.1~1.15 ≈. 즉 RF2 12개월 서울 ≈ ~$1.2K/mo.

5. gp3면 충분 — io2 트리거는 도달 안 함

gp3 vs io2 Block Express 실전 스펙(gp3 80,000 IOPS/2,000 MiB/s/64TiB ✓, io2 BE 256,000 IOPS/4,000 MiB/s/99.999% ✓)·요금 3분해는 /hyperdx/02-hot-storage-ebs/가 기준 문서다. 캐파 관점의 판단만 요약한다.

• 우리 hot 물리 ~2TB, 노드당 ~1TB, 인제스트 피크 ~8 MB/s → gp3 baseline 3,000 IOPS + 125 MiB/s로도 대부분 커버. 부족하면 gp3 위로 IOPS/throughput을 싸게 프로비저닝(예: +3,000 IOPS·+125 MiB/s = 추가 ~$15+$5/mo)한다.
• 내구성은 gp3(99.8~99.9%)로 충분 — 진짜 내구성은 RF 복제 + 백업이 담당한다(티어링≠내구성, /clickhouse/02-storage-local-nvme/). io2의 99.999%는 이 스케일에 과잉.
• io2 전환 트리거: (a) 단일 볼륨 >2,000 MiB/s 지속, (b) >80,000 IOPS/vol, (c) 규제상 볼륨 자체 99.999% 요구. → 0.7TB/월 RUM은 셋 다 도달 안 함 → io2 채택 근거 없음 ≈.

6. TTL — 지평별 DELETE 변주 (기준 문서는 03)

TTL 정책의 기준 문서(storage_policy·TO VOLUME 'cold'·move_factor 안전판·시간 컬럼명 확인)는 /hyperdx/03-s3-cold-tiering/에 있다. 여기서 재정의하지 않는다 — 캐파 지평에 따라 달라지는 건 오직 DELETE 간격뿐이다.

-- 지평별로 바뀌는 것은 DELETE INTERVAL 하나뿐. MOVE·정책은 03 기준 문서를 따른다.
-- 로그/트레이스: hot 14일 → cold → DELETE(3개월=90 / 6개월=180 / 1년=365)
ALTER TABLE default.otel_logs MODIFY TTL
  toDateTime(Timestamp) + INTERVAL 14  DAY TO VOLUME 'cold',
  toDateTime(Timestamp) + INTERVAL 365 DAY DELETE      -- ← 지평별 90/180/365
  SETTINGS materialize_ttl_after_modify = 0;

-- 메트릭: hot 30일 → cold → DELETE(180 또는 365)
ALTER TABLE default.otel_metrics_gauge MODIFY TTL
  toDateTime(TimeUnix) + INTERVAL 30  DAY TO VOLUME 'cold',
  toDateTime(TimeUnix) + INTERVAL 365 DAY DELETE;

-- 리플레이: hot 30일만, S3 안 감, DELETE 30일 (지평이 늘어도 여기는 그대로 짧게)
ALTER TABLE default.hyperdx_sessions MODIFY TTL
  TimestampTime + INTERVAL 30 DAY DELETE;

materialize_ttl_after_modify = 0으로 기존 파트 즉시 재작성을 피해 운영 중 부하 폭증을 막는다 ≈. 시간 컬럼명(Timestamp/TimestampTime/TimeUnix)은 테이블마다 다를 수 있으니 SHOW CREATE TABLE로 확인 후 적용 ?. ClickStack OSS 기본 TTL은 ${TABLES_TTL} 단일값(문서상 3일)이며, 위 값은 우리 권장 오버라이드다 — 배포 시 실 스키마로 확정 ?.

7. staging vs prod — 규모 차이

staging은 “동작 검증 + 실측 캘리브레이션"이 목적이므로 샘플링 축소 + 단일 replica + 짧은 TTL로 극소화한다.

staging의 진짜 역할 = 실측 캘리브레이션: §2 압축비·구성비·세션당 KB는 전부 ≈이다. staging에서 §1 콜아웃 쿼리로 실제 압축비와 세션당 바이트를 측정해 prod 모델의 ≈을 ✓으로 바꾼다. 이게 staging을 두는 캐파상 이유다.

8. 성장 버퍼 & 경보 기준

8.1 디스크 헤드룸 — 여유 공간이 곧 안정성 ✓/≈

• 머지는 여유 공간을 먹는다: 병합 대상 파트 합만큼의 여유가 필요. 디스크가 차면 머지 중단 → 파트 누적 → TOO_MANY_PARTS → 인서트 차단.
• hot gp3 사용률 경보: 70% 경고 / 80% 조치 / 85% 하드실링. hot 볼륨은 항상 30~40% 여유(§4.1 헤드룸).

8.2 경보 항목 & 증설 트리거 ≈

8.3 언제 shard / io2 / RF3로 가나 ≈

• shard 추가: 이 워크로드는 1년+ 불필요. 트리거는 (a) hot 단일사본/노드가 노드 실용 상한(예 4~8TB)에 접근, (b) 머지/쿼리 CPU 지속 포화, (c) 재수화 위험 창을 줄이려 노드당 데이터를 낮추고 싶을 때. 신규 shard 스키마·리밸런싱은 수동(/clickhouse/05-altinity-operations/).
• io2 전환: §5 — >2,000 MiB/s·>80,000 IOPS/vol·볼륨 99.999% 요구 시. RUM 0.7TB/월엔 도달 안 함.
• RF2→RF3: 임의 2대 동시 유실 무손실 또는 재수화 창 동안 2차 장애 방어가 필요할 때. 비용은 컴퓨트+cold S3가 ×1.5. 확률·비용 결정은 /clickhouse/04-deployment-playbook/.

10. RUM 볼륨 흐름 & 해석 분기

우리 케이스에서는

해석 B(on-disk 0.7TB/월)를 1차 모델로 잡되, 배포 후 system.parts로 1회 실측해 raw인지 on-disk인지, 그리고 시그널별 실제 압축비를 확정하는 것이 사이징의 전부다 — 이 한 번의 실측이 배포 규모·비용의 2~3배 불확실성을 없앤다. 실측 전까지는 1 shard × RF2, 2× r7g.2xlarge, hot gp3 노드당 ~1TB, Keeper 3 / MongoDB 3멤버로 시작한다. 이 구성은 3개월이든 1년이든 hot·컴퓨트가 고정이고, 보관을 늘려도 늘어나는 건 싼 S3 cold뿐이라(1년 RF2 us-east-1 $1.0K/mo, 서울 +1015%) 지평 결정을 미뤄도 손해가 없다.

가장 크게 못박을 한 가지는 리플레이 TTL 분리다. 리플레이는 on-disk의 78%를 먹지만 가치는 급감하므로 hot 30일 + S3 미이동 + 30일 DELETE로 잘라 누적에서 빼낸다(/hyperdx/03-s3-cold-tiering/) — 이걸 안 하면 “0.7TB×12=8.4TB"의 함정에 빠져 gp3·S3·백업을 모두 34배로 과산정하게 된다. io2·로컬 NVMe·RF3·샤딩은 §8.3 트리거를 실제로 넘길 때만 승급한다. 압축비 5x·구성비 65/20/13/2·ClickStack 기본 TTL은 전부 ≈·?이니 staging 실측으로 승격하는 것을 배포 체크리스트 1번에 둔다. 시점 기준 2026-07.