Scale Up Scale Out Partitioning Sharding

확장은 서버를 더 크게 만들거나 더 많이 띄우는 일이 아니라, 병목 위치를 찾아 성능·정합성·장애 격리·운영 복잡도 중 무엇을 바꿀지 선택하는 일이다.
Scale up은 변화가 작지만 상한과 비용이 있고, scale out은 처리량을 늘리지만 상태·DB·외부 의존성 병목을 더 빨리 드러낸다.
Partitioning과 sharding은 데이터 한계를 나누는 선택이지만 key 선택, routing, cross-shard query, rebalancing, hot partition 운영 비용을 만든다.

먼저 병목이 app CPU, app memory, DB read, DB write, lock, network, external API, storage 중 어디인지 분리한다.
App이 stateless라면 scale out이 쉽지만 session, local file, scheduler, local cache, connection pool이 숨어 있으면 깨진다.
DB read 병목은 cache, replica, query tuning으로 먼저 완화할 수 있고, DB write 병목은 sharding 전에 hot row와 transaction을 봐야 한다.
Partitioning은 한 저장소 안에서 데이터를 나누는 경우가 많고, sharding은 여러 저장소로 쓰기와 저장량을 나누는 경우가 많다.
Shard key는 가장 많은 쿼리를 빠르게 만들지만 다른 쿼리를 어렵게 만든다.
Rebalancing은 설계 이후의 운영 비용이다. 데이터 이동, dual routing, 검증, rollback, hot key 완화가 필요하다.

병목을 숫자로 고정한다.
- CPU, memory, DB connection, lock wait, read/write QPS, p95 latency, queue age를 본다.
작은 변경으로 풀 수 있는지 확인한다.
- query 개선, cache, rate limit, batch 분리, instance size 조정부터 본다.
App scale out 가능성을 점검한다.
- session, file, scheduler, local lock, connection pool 총합을 확인한다.
데이터 분할 필요성을 판단한다.
- table size, write TPS, index 크기, retention, hot key를 본다.
분할 key를 선택한다.
- 조회 패턴, write 분산, cross-shard transaction, rebalancing 비용을 비교한다.
운영 절차를 붙인다.
- migration, backfill, 검증, 모니터링, 장애 시 우회, 비용 추적을 설계에 포함한다.

Scale out이 항상 scale up보다 성숙한 선택이라고 오해하기 쉽다.
- 단일 DB write, hot row, 외부 API quota가 병목이면 app instance를 늘려도 장애가 커질 수 있다.
Stateless App이면 모든 것이 수평 확장된다고 생각하기 쉽다.
- App은 stateless여도 DB connection, Redis, session store, scheduler, 파일 저장소는 별도 한계를 가진다.
Sharding을 적용하면 저장량 문제가 끝난다고 느끼기 쉽다.
- query routing, cross-shard 조회, rebalancing, 데이터 검증, shard별 장애 대응이 새로 생긴다.
Hash key를 쓰면 hot partition이 사라진다고 생각하기 쉽다.
- 유명 판매자, 대형 tenant, 이벤트 상품처럼 특정 key 자체가 뜨거우면 hash만으로 부족하다.

01. Scale Up과 Scale Out 판단 상세.md: 병목 위치에 따라 수직/수평 확장을 고르는 기준을 다룬다.
02. Stateless App 수평 확장 상세.md: Spring App을 여러 인스턴스로 늘릴 때 숨은 상태와 downstream 한계를 점검한다.
03. Partitioning과 Sharding 기본 상세.md: partition과 shard의 차이, key 선택, routing, query 비용을 다룬다.
04. Rebalancing과 Hot Partition 상세.md: 데이터 이동과 특정 key 과열을 운영 관점에서 다룬다.
05. 확장 전후 운영 비용 상세.md: 확장으로 늘어나는 배포, 관측, 마이그레이션, 장애 대응 비용을 정리한다.

확인 질문: 지금 병목은 어느 계층의 어떤 지표로 증명되는가?
- 답변: CPU, connection pool, lock wait, DB write latency, external quota처럼 관측 가능한 포화 지표로 설명해야 한다.
확인 질문: App을 2배 늘리면 downstream 부하는 어떻게 되는가?
- 답변: DB connection, Redis QPS, 외부 API 호출도 같이 늘 수 있으므로 전체 capacity budget을 다시 계산해야 한다.
확인 질문: Sharding을 선택했다면 어떤 비용을 같이 받아들이는가?
- 답변: routing, rebalancing, cross-shard query, 장애 격리, 데이터 검증, 운영 자동화 비용을 함께 받아들인다.

동블