⚖️ 스케일 업 vs 스케일 아웃

✅ 왜 확장이 필요할까?

서비스가 성장하면서 유저 수, 트래픽, 요청 처리량이 증가하면 기존 서버로는 감당이 어려워집니다.
이때 고려할 수 있는 두 가지 대표 확장 전략이 있습니다:

🔼 스케일 업 (Scale-Up)

기존 서버의 사양을 업그레이드하여 성능을 높이는 방식

💡 예시

• AWS EC2 t3.micro → t3.large
• DB 서버에 메모리/디스크 증설

✅ 장점

• 적용 간단 (코드 수정 거의 없음)
• 관리 대상 1대 → 모니터링, 유지보수 편함

❌ 단점

• 서버 사양에는 물리적 한계 존재
• 단일 서버 장애 발생 시 전체 장애 위험
• 고사양 장비는 비용이 급격히 증가

🔽 스케일 아웃 (Scale-Out)

서버를 수평적으로 확장해서 트래픽을 여러 대로 분산 처리하는 방식

💡 예시

• 웹 서버 1대 → 4대 + 로드 밸런서 구성
• 캐시, DB 샤딩 또는 복제

✅ 장점

• 장애에 강한 고가용성(HA) 환경 구성 가능
• 필요 시 유연하게 확장/축소 가능
• 클라우드와 잘 어울리는 확장 방식

❌ 단점

• 서버 수 ↑ → 관리 복잡도 ↑
• 세션 공유, 캐시 동기화 등 설계 고려 필요
• 로드 밸런싱 필수 구성 요소

🌐 로드 밸런서란?

로드 밸런서(Load Balancer)는 여러 서버 간 트래픽을 분산시켜주는 장치입니다.
사용자의 요청을 적절한 서버로 전달해주는 진입 관문 역할을 합니다.

🎯 왜 필요할까?

• 요청을 균등하게 분산시켜 과부하 방지
• 서버 장애 발생 시 정상 서버로 우회 가능
• 스케일 아웃 환경에서 필수

🔄 동작 구조 예시

[Client]
   ↓
[Load Balancer]
   ├──> Server A
   ├──> Server B
   └──> Server C

🔧 대표적인 분산 알고리즘

☁️ 클라우드 환경

🎯 정리 비교표

🧠 실무에서 어떻게 선택할까?

✅ 마무리 요약

• 스케일 업: 빠르고 간단하지만 한계 있음
• 스케일 아웃: 복잡하지만 확장성과 안정성이 뛰어남
• 로드 밸런서: 스케일 아웃에서 요청을 분산하는 핵심 역할