수평 확장 vs 수직 확장 판단

Vertical (Scale Up)
- 서버 한 대 더 강하게 (CPU·RAM 추가)
- 단순
- 한계 명확 (HW 한계)
- DB·Stateful 서비스에 적합

Horizontal (Scale Out)
- 서버 여러 대로 분산
- 복잡 (로드밸런서·세션·분산)
- 무한 확장 가능
- Stateless 서비스에 적합

현재 부하?
├─ < 1K RPS
│   └─ Vertical 충분 (단일 큰 인스턴스)
│
├─ 1K~10K RPS
│   └─ Vertical 한계 → Horizontal 시작
│
└─ 10K+ RPS
    └─ Horizontal 필수 + 다중 리전


상태 관리?
├─ Stateless (Web·API)
│   → Horizontal 쉬움
└─ Stateful (DB·Cache)
    → Vertical + Read Replica
    → 또는 Sharding (대규모)


비용 효율?
- Vertical: c5.4xlarge $300/mo
- Horizontal: c5.large × 4 $200/mo + 로드밸런서 $20
- → 같은 처리량이면 Horizontal이 저렴 + 가용성 우수

// ❌ 메모리에 세션 저장
const sessions = {};

app.post('/login', (req, res) => {
  const id = crypto.randomUUID();
  sessions[id] = { userId };
  res.cookie('sessionId', id);
});


// ✅ Redis에 저장 (분산)
import session from 'express-session';
import RedisStore from 'connect-redis';

app.use(session({
  store: new RedisStore({ client: redis }),
  // ...
}));


// ❌ 로컬 디스크에 파일
app.post('/upload', upload.single('file'), (req, res) => {
  // /tmp/uploads/... → 다른 인스턴스에서 못 봄
});


// ✅ S3 등 공유 스토리지
const url = await uploadToS3(file);

일관성(Consistency) + 가용성(Availability) + 분할 내성(Partition tolerance)
→ 3중 2개만 선택


CP: PostgreSQL, MongoDB
- 강한 일관성
- 분할 시 일부 불가
- 금융·이커머스 적합

AP: Cassandra, DynamoDB
- 항상 응답 (eventual consistency)
- 분할에도 작동
- 소셜·로그 적합

CA: 단일 노드 DB
- 분산 X (실용적 선택지 X)

[Vertical 한계]
- AWS m5.24xlarge: 96 vCPU, 384GB RAM
- 그 이상 = Horizontal 필수


[수직 → 수평 마이그레이션 시점]
1. 다운타임 위험 (단일 장애점)
2. 비용 비효율 (큰 인스턴스 비싸짐)
3. 응답 시간 한계


[중간 단계 — Read Replica]
DB 1개 → Primary + 2 Replica
- 쓰기: Primary
- 읽기: Replica로 부하 분산
- 95% 케이스에 충분