스케일 업

기존 서버의 하드웨어 성능을 높여 처리 능력을 향상시키는 수직 확장 방식입니다.

동작 방식

Before: [CPU 4core, RAM 8GB,  SSD 500GB]
                    ↓ 업그레이드
After:  [CPU 16core, RAM 64GB, SSD 2TB]

서버 대수는 그대로, 성능만 향상

장단점

장점
O 구현 단순 (서버 추가 없음)
O 분산 환경 고려 불필요
O 데이터 정합성 유지 쉬움
O 관리 포인트 적음

단점
X 물리적 한계 존재 (무한 업그레이드 불가)
X 고사양일수록 비용 급증 (가격이 선형이 아닌 지수적 증가)
X 업그레이드 시 다운타임 발생
X 단일 장애점 (서버 1대 장애 = 전체 장애)

비용 문제

CPU 4core  → 8core  : 2배 성능, 3배 비용
CPU 8core  → 16core : 2배 성능, 4배 비용
CPU 16core → 32core : 2배 성능, 6배 비용

성능은 선형 증가, 비용은 지수적 증가 X

언제 선택하나?

O RDB (MySQL, PostgreSQL)
   → 분산 환경에서 정합성 유지가 어렵기 때문에
   → 단일 서버 성능을 높이는 것이 현실적

O 서비스 초기 단계
   → 트래픽이 적고 구조가 단순할 때
   → 스케일 아웃보다 빠르고 쉬운 해결책

O 단기간 빠른 성능 향상이 필요할 때
   → 스케일 아웃 준비가 안 된 상황

실무에서의 현실

일반적인 흐름

1단계: 서비스 초기 → 단일 서버
2단계: 트래픽 증가 → 스케일 업으로 버팀
3단계: 스케일 업 한계 도달 → 스케일 아웃으로 전환

RDB는 스케일 업      ─┐
WAS/캐시는 스케일 아웃 ─┤ 혼합 사용

스케일 업은 "빠르고 단순하지만 한계가 명확한 확장 방식" 입니다. 서비스 초기나 RDB처럼 분산이 어려운 환경에서 유효하지만, 장기적으로는 스케일 아웃과 병행하는 전략이 필요합니다.