scale-out

스케일아웃(Scale-Out)은 서버의 처리 능력을 높이기 위해 동일한 역할의 서버 수를 늘려 부하를 분산하는 확장 방식입니다.

scale-up vs Scale-Out

[Scale-Up — 수직 확장]
기존 서버의 하드웨어 성능을 올림
┌──────────┐        ┌──────────┐
│  서버 1   │   →    │  서버 1   │
│  4GB RAM  │        │  64GB RAM │
│  2 Core   │        │  16 Core  │
└──────────┘        └──────────┘

[Scale-Out — 수평 확장]
같은 사양의 서버를 여러 대 추가
┌──────────┐        ┌──────────┐ ┌──────────┐ ┌──────────┐
│  서버 1   │   →    │  서버 1   │ │  서버 2   │ │  서버 3   │
│  4GB RAM  │        │  4GB RAM  │ │  4GB RAM  │ │  4GB RAM  │
└──────────┘        └──────────┘ └──────────┘ └──────────┘
                           ↑ 로드밸런서가 요청 분배 ↑

Scale-Up vs Scale-Out 비교

항목Scale-Up (수직 확장)Scale-Out (수평 확장)
방법서버 1대의 사양 업그레이드서버 대수 추가
비용고성능 장비일수록 기하급수적 증가저렴한 서버 여러 대로 분산
확장 한계하드웨어 물리적 한계 있음이론적으로 무한 확장
장애 대응단일 장애점 (SPOF)한 대 장애 시 나머지가 처리
구현 복잡도단순 (기존 구조 유지)복잡 (세션 공유, 데이터 동기화 등)
적합 대상DB, 고성능 연산 서버웹/API 서버, 무상태 서비스

Scale-Out 구조

                    ┌──────────┐
  클라이언트 ──→    │ 로드밸런서 │
                    └────┬─────┘
                ┌────────┼────────┐
                ▼        ▼        ▼
           ┌────────┐┌────────┐┌────────┐
           │ 서버 1  ││ 서버 2  ││ 서버 3  │
           └────────┘└────────┘└────────┘

로드밸런서가 들어오는 요청을 여러 서버에 분배하며, 대표적인 분배 알고리즘은 다음과 같습니다.

알고리즘설명
라운드 로빈순서대로 돌아가며 배분
가중 라운드 로빈서버 성능에 비례하여 배분
Least Connection현재 연결 수가 가장 적은 서버에 배분
IP Hash클라이언트 IP 기반으로 항상 같은 서버에 배분 (Sticky Session)

Scale-Out 시 고려해야 할 문제

1. 세션 불일치

요청 1 → 서버A (세션 생성)
요청 2 → 서버B (세션 없음 → 로그인 풀림 X)

해결: Redis 세션 저장소 / JWT / Sticky Session

2. 데이터 정합성

서버A: 재고 5개 확인 → 주문 처리
서버B: 재고 5개 확인 → 주문 처리  ← 동시에 처리되면 재고 초과 X

해결: DB 수준 락, 분산 락(Redis Redlock), 메시지 큐 등

3. 파일 저장

서버A: 이미지 업로드 → 서버A 로컬에 저장
서버B: 이미지 요청 → 서버B에는 파일 없음 X

해결: S3 같은 외부 스토리지 사용

무상태와 Scale-Out의 관계

Stateful 서버  → 상태를 서버가 갖고 있어 특정 서버에 종속
               → Scale-Out 어려움

Stateless 서버 → 서버가 상태를 갖지 않아 어떤 서버든 동일 처리
               → Scale-Out 용이 O

그래서 REST API가 무상태를 권장하고, JWT 같은 토큰 기반 인증이 선호되는 이유가 바로 Scale-Out 친화적이기 때문입니다.

면접 포인트

CSLOG에서 보기