System DesignNginx시뮬레이션

Load Balancing 완벽 이해

로드 밸런싱 알고리즘, Health Check, Failover를 직접 체험합니다.

왜 알아야 하나요?

서버 1대로 버티기 힘들어요!

"이벤트 때 트래픽이 10배로 늘었는데, 서버가 죽었어요..."

서버를 늘리면?

서버 3대로 늘렸는데, 어떻게 트래픽을 나눌까요?

로드 밸런서가 해결!

트래픽을 여러 서버에 분산하고, 장애 시 자동으로 다른 서버로 전환합니다.

한눈에 보기

Client

Load Balancer

트래픽 분산

Server 1

Server 2

Server 3

요청을 여러 서버에 분산하여 부하를 나누고 가용성을 높입니다.

핵심 알고리즘

Round Robin

서버를 순서대로 돌아가며 선택

예: 1 → 2 → 3 → 1 → 2 → 3 ...

장점: 단순, 균등 분배

단점: 서버 성능 차이 무시

Weighted Round Robin

가중치(성능)에 따라 분배량 조절

예: 서버1(3) : 서버2(2) : 서버3(1)

고성능 서버에 더 많은 요청 할당

Least Connections

현재 연결이 가장 적은 서버 선택

실시간 부하를 고려한 동적 분배

장점: 실제 부하 기반

단점: 연결 추적 오버헤드

IP Hash (Sticky Session)

같은 클라이언트는 항상 같은 서버로

세션 유지가 필요한 경우 사용

예: 로그인 세션, 장바구니

Health Check & Failover

Health Check

주기적으로 서버 상태를 확인합니다.

- HTTP 요청으로 /health 엔드포인트 확인
- 연속 N번 실패 시 서버 제외
- 복구 시 자동으로 다시 포함

Failover

장애 서버를 자동으로 제외합니다.

- 장애 감지 → 라우팅 제외
- 다른 정상 서버로 자동 전환
- 서비스 중단 없이 운영

Nginx 설정 예시

upstream backend {
    # Weighted Round Robin
    server 192.168.1.1:8080 weight=3;  # 고성능
    server 192.168.1.2:8080 weight=2;  # 중간
    server 192.168.1.3:8080 weight=1;  # 저성능

    # Least Connections
    # least_conn;

    # IP Hash (Sticky Session)
    # ip_hash;

    # Health Check
    server 192.168.1.1:8080 max_fails=3 fail_timeout=30s;
}

server {
    location / {
        proxy_pass http://backend;
    }
}

직접 체험하기

각 알고리즘의 분배 결과를 비교하고, 장애 상황에서 Failover를 관찰하세요.

Load Balancer 실습

로드 밸런서는 여러 서버에 요청을 분산합니다. 각 알고리즘마다 분산 방식이 달라요.

서버 상태

더 알아보기

L4 vs L7 로드밸런서

L4: TCP/UDP 레벨 (빠름)
L7: HTTP 레벨 (URL 기반 라우팅)
- AWS ALB: L7
- AWS NLB: L4