의사결정 가이드 — 기본값·승급 트리거·실측 체크리스트

앞의 다섯 페이지가 각 축을 깊게 팠다면, 이 페이지는 그 결론을 결정 매트릭스 하나로 접는다 — 매트릭스의 기준 문서는 이 페이지다. 각 축의 “왜"의 전개는 아키텍처부터 규모 산정까지의 섹션 페이지와 챕터 기준 문서로 위임하고, 여기서는 판단에 필요한 최소 근거·수치, 그리고 로드맵 요약에는 없던 한 단계 — 승급 트리거의 관측 지점 — 를 더한다.

1. 결정 매트릭스 — 기본값·왜 안전/충분·승급 트리거

“왜 안전/충분” 열은 성격이 다른 두 계열이 섞여 있음을 구분해 읽는다. 안전의 근거는 장애 방어 메커니즘 — EBS reattach·RF 복제·Keeper 정족수·스냅샷 롤백 — 이고, 충분의 근거는 규모 여유 — 0.7TB/월의 인제스트 피크 ~8 MB/s가 CPU·I/O 모두에 한참 못 미친다는 사실 — 이다 ≈. 승급 트리거도 이 구분을 따른다: 안전 계열(RF3·Keeper 5노드)은 요구사항이 바뀔 때 발동하고, 충분 계열(io2·shard)은 관측된 부하가 임계를 넘을 때 발동한다. 전자는 지표를 아무리 봐도 안 나오는 트리거라는 점이 §2 표의 “요구사항 신호” 행들이 존재하는 이유다.

2. 승급 트리거의 관측 지점 — 무엇을 어디서 보면 발동인가

매트릭스의 트리거를 “관측 가능한 신호 + 그 신호를 보는 자리"까지 내린다. 임계값은 새로 만들지 않고 각 기준 문서의 수치를 그대로 쓴다.

두 가지를 덧붙인다. 첫째, cold 축은 “이동이 실제로 도는가"도 관측 대상이다 — TTL MOVE의 동작은 system.storage_policies(정책 로드)·system.disks(티어 등록)·system.parts의 disk_name(파트가 어느 티어에 있나)·system.part_log(이동 이력) 조회로 확인 가능한 표준 인터페이스다 ✓(S3 티어링 기준 문서). 이동이 멎으면 hot이 차오르며 아래 경보로 이어지므로, cold 축의 일상 헬스는 이 네 뷰가 담당한다.

둘째, hot gp3의 일상 경보(승급 아닌 운영 대응)는 규모 산정의 기준을 쓴다: 사용률 70% 경고 / 80% 조치 / 85% 하드실링, 조치는 gp3 온라인 확장 또는 TTL 단축·cold 이동 가속 ≈ — 디스크가 차면 머지 중단→TOO_MANY_PARTS→인서트 차단으로 이어지므로 hot 볼륨은 항상 30~40% 여유를 남긴다 ✓/≈.

3. 배포 전 실측 체크리스트 — ? 4항목을 staging에서 ✓로

아래 4개는 공개 실측이 없거나 문서 간 상충이 있어 전부 ?다. staging에서 측정해 ✓로 승격한다.

항목 1·2는 쿼리 하나로 같이 잡힌다(용량 산정 기준 문서):

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;

ratio가 시그널별 실제 압축비, on_disk의 월 증가분이 해석 확정값이다. 항목 4의 리허설은 두 갈래로 한다 — graceful(cordon→drain: PDB 준수·자동 reattach)과 ungraceful(강제 종료: StatefulSet+RWO는 자동 복구가 안 되고 out-of-service taint 개입이 정석 ✓). 실소요는 hot 데이터량·파트 수에 좌우되며 아직 실측 전이다 ?(operator 패턴 · 토폴로지·다운타임). 여기에 버전 매트릭스 함정 하나를 staging 검증에 얹는다: operator 0.27.0+는 async_replication/use_xid_64를 기본 활성화해 Keeper 25.3+를 요구하는데 ✓, 우리는 CH/Keeper를 24.8 LTS로 핀하므로 이 조합의 실동작 확인이 필요하다 ?(버전·업그레이드).

왜 staging인가 — 캐파상 이유. 위 4항목과 산정 모델의 ≈(압축비·구성비 65/20/13/2)는 트래픽이 실제로 흘러야만 확정된다. staging은 샘플링 510% · RF1 · 짧은 TTL(cold 없음)로 극소화해도($150~250/mo ≈) 이 실측이 전부 가능하다 — 즉 staging의 진짜 역할은 “동작 검증"이 아니라 실측 캘리브레이션이고, 이것이 staging을 두는 캐파상 이유다(규모 산정).

우리 케이스에서는

기본값 세트 — HyperDX Only+Altinity CHI/CHK, 단일 gp3, S3 TTL MOVE(리플레이는 hot 30일 DELETE), 1 shard × RF2(2 AZ), Keeper 3노드(gp3·3 AZ), MongoDB members:3, CH/Keeper 24.8 LTS 핀 — 로 시작하고, io2·block-only·RF3·shard·Keeper 5노드·Atlas는 §2의 관측 지점에서 해당 신호가 실제로 잡힐 때만 올린다. 특히 io2는 gp3 provisioned throughput 상향이라는 선행 단계를 건너뛰고 갈 이유가 없고, RF3는 insert_quorum:2 상시 요구와 짝일 때만 의미가 있다.

착수 1번 작업은 §3의 4개 ?를 staging에서 ✓로 승격하는 것이다 — 0.7TB 해석 하나가 배포 규모·비용을 2~3배 가르므로, 이 실측 전의 모든 산정은 밴드로만 다룬다. 그리고 업그레이드 축만은 승급이 아니라 불가역의 축임을 기억한다: 올리기 전 EBS 스냅샷이 유일한 되돌림이므로, 매트릭스의 다른 축과 달리 “일단 올리고 관측"이 성립하지 않는다. 시점 기준 2026-07.