로드밸런싱

로드 밸런싱 (Load Balancing)

개요

로드 밸런싱이란 클라이언트 요청을 여러 대의 서버에 분산시켜 한 서버가 과부하되지 않도록 조절하는 기술이다.

쉽게 말해 "줄 세우기 도우미"예요!

마트에 계산대가 1개라면 아무리 직원이 빠르게 일해도 손님이 몰리면 줄이 엄청 길어지죠. 그런데 계산대를 3~4개로 늘리고 "손님 여기로 오세요, 저쪽으로 오세요" 하고 안내해주는 직원이 있다면? 훨씬 빠르게 처리할 수 있어요!

Nginx가 바로 그 안내 직원 역할을 하는 거예요. 요청이 들어오면 여러 백엔드 서버 중 적절한 곳으로 분산시켜 주는 거죠.

로드 밸런싱을 쓰면:

•

 고가용성 — 한 서버가 죽어도 다른 서버가 처리

•

 성능 향상 — 트래픽을 분산해 응답 속도 증가

•

 수평 확장 — 서버를 추가하면 성능이 선형적으로 증가

•

 무중단 배포 — 서버 하나씩 내렸다 올리며 업데이트

로드 밸런싱 아키텍처

graph TD
    A["👤 클라이언트 1"] -->|"요청"| LB
    B["👤 클라이언트 2"] -->|"요청"| LB
    C["👤 클라이언트 3"] -->|"요청"| LB
    D["👤 클라이언트 4"] -->|"요청"| LB

    LB["⚖️ Nginx<br/>로드 밸런서<br/>:80 / :443"]

    LB -->|"요청 1"| S1["🖥️ Server 1<br/>:8080"]
    LB -->|"요청 2"| S2["🖥️ Server 2<br/>:8081"]
    LB -->|"요청 3"| S3["🖥️ Server 3<br/>:8082"]

    style LB fill:#FFD700
    style S1 fill:#87CEEB
    style S2 fill:#87CEEB
    style S3 fill:#87CEEB
Mermaid
복사

로드 밸런싱 알고리즘 비교

알고리즘	Nginx 설정	분배 방식	적합한 상황
Round Robin	(기본값)	순서대로 돌아가며	서버 성능이 동일할 때
Least Connections	least_conn;	연결 수 적은 서버 우선	처리 시간이 다양할 때
IP Hash	ip_hash;	클라이언트 IP 기준 고정	세션 유지가 필요할 때
Weighted	weight=N;	비율에 따라 분배	서버 성능이 다를 때
Random	random;	무작위 분배	간단한 분산이 필요할 때
Hash	hash $변수;	특정 값 기준 고정	URL 캐싱 효율화

upstream 블록 — 핵심 설정

모든 로드 밸런싱의 시작은 upstream 블록이에요!

# upstream = 백엔드 서버 그룹을 정의하는 블록
upstream backend {
    server localhost:8080;
    server localhost:8081;
    server localhost:8082;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass <http://backend>;  # upstream 이름을 그대로 사용
    }
}
Plain Text
복사

upstream 블록에 서버 주소를 나열하면, Nginx가 알아서 분산해줘요!

알고리즘별 상세 설정

1. Round Robin (라운드 로빈) — 기본값

sequenceDiagram
    participant LB as ⚖️ Nginx
    participant S1 as 🖥️ Server 1
    participant S2 as 🖥️ Server 2
    participant S3 as 🖥️ Server 3

    LB->>S1: 요청 1
    LB->>S2: 요청 2
    LB->>S3: 요청 3
    LB->>S1: 요청 4 (다시 처음으로)
    LB->>S2: 요청 5
Mermaid
복사

upstream backend {
    # 별도 설정 없으면 자동으로 라운드 로빈
    server localhost:8080;
    server localhost:8081;
    server localhost:8082;
}
Plain Text
복사

특징: 가장 단순하고 공평하게 분배. 서버 성능이 동일한 경우 최적이에요.

2. Least Connections (최소 연결) — 실무 추천

graph LR
    LB["⚖️ Nginx"] -->|"다음 요청"| S2

    S1["🖥️ Server 1<br/>현재 연결: 10개"] -.->|"바쁨"| LB
    S2["🖥️ Server 2<br/>현재 연결: 2개 ⭐"] -.->|"여유 있음"| LB
    S3["🖥️ Server 3<br/>현재 연결: 7개"] -.->|"보통"| LB

    style S2 fill:#90EE90
Mermaid
복사

upstream backend {
    least_conn;  # 연결 수가 가장 적은 서버로 요청 전달

    server localhost:8080;
    server localhost:8081;
    server localhost:8082;
}
Plain Text
복사

특징: 처리 시간이 들쑥날쑥한 API 서버에 딱! 파일 업로드, 동영상 처리 등에 유리해요.

3. IP Hash — 세션 고정

graph LR
    C1["👤 IP: 1.1.1.1"] -->|"항상"| S1["🖥️ Server 1"]
    C2["👤 IP: 2.2.2.2"] -->|"항상"| S2["🖥️ Server 2"]
    C3["👤 IP: 3.3.3.3"] -->|"항상"| S1["🖥️ Server 1"]
    C4["👤 IP: 4.4.4.4"] -->|"항상"| S3["🖥️ Server 3"]

    LB["⚖️ Nginx<br/>(ip_hash)"] --- C1
    LB --- C2
    LB --- C3
    LB --- C4

    style LB fill:#FFD700
Mermaid
복사

upstream backend {
    ip_hash;  # 클라이언트 IP를 해시해서 항상 같은 서버로

    server localhost:8080;
    server localhost:8081;
    server localhost:8082;
}
Plain Text
복사

특징: 같은 사용자는 항상 같은 서버에 접속해요. 로그인 세션이 서버에 저장된 경우 필수! 단, 서버가 다운되면 세션이 날아갈 수 있어요.

4. Weighted (가중치)

graph LR
    LB["⚖️ Nginx"] -->|"6번 중 3번"| S1["🖥️ Server 1<br/>weight=3<br/>(고성능 서버)"]
    LB -->|"6번 중 2번"| S2["🖥️ Server 2<br/>weight=2<br/>(중간 서버)"]
    LB -->|"6번 중 1번"| S3["🖥️ Server 3<br/>weight=1<br/>(저성능 서버)"]

    style S1 fill:#90EE90
    style S2 fill:#FFD700
    style S3 fill:#FFB366
Mermaid
복사

upstream backend {
    server localhost:8080 weight=3;  # 3/6 = 50% 트래픽
    server localhost:8081 weight=2;  # 2/6 = 33% 트래픽
    server localhost:8082 weight=1;  # 1/6 = 17% 트래픽
}
Plain Text
복사

특징: 서버 사양이 다를 때 유용해요. 고성능 서버에 더 많은 요청을 보낼 수 있어요.

서버 상태 설정

서버마다 특수 상태를 지정할 수 있어요!

upstream backend {
    server localhost:8080;               # 정상 서버
    server localhost:8081 down;          # 완전 비활성화 (유지보수 중)
    server localhost:8082 backup;        # 평소엔 안 쓰고 다른 서버 모두 다운 시 사용
    server localhost:8083 max_fails=3    # 3번 실패하면
                          fail_timeout=30s;  # 30초간 제외
}
Plain Text
복사

옵션	설명	사용 상황
weight=N	분배 비율 조정	서버 성능 차이가 있을 때
max_fails=N	N번 실패 시 비활성화	자동 장애 감지
fail_timeout=Ns	N초 후 재시도	max_fails와 함께 사용
down	서버 완전 비활성화	유지보수
backup	예비 서버	모든 서버 다운 시 투입
max_conns=N	최대 동시 연결 수 제한	서버 보호

Health Check (헬스 체크)

서버가 살아있는지 주기적으로 확인!

stateDiagram-v2
    [*] --> Active: 서버 정상
    Active --> Inactive: 요청 실패 (max_fails 초과)
    Inactive --> Active: fail_timeout 후 재시도 성공
    Inactive --> Inactive: 재시도 실패
Mermaid
복사

패시브 헬스 체크 (Nginx 무료)

요청이 실패하면 자동으로 서버를 비활성화해요:

upstream backend {
    server localhost:8080 max_fails=3 fail_timeout=30s;
    server localhost:8081 max_fails=3 fail_timeout=30s;
}

server {
    location / {
        proxy_pass <http://backend>;

        # 실패 시 다음 서버로 자동 재시도
        proxy_next_upstream error timeout http_500 http_502 http_503;
        proxy_next_upstream_tries 2;
    }
}
Plain Text
복사

액티브 헬스 체크 (Nginx Plus 유료)

upstream backend {
    server localhost:8080;
    server localhost:8081;
}

server {
    location / {
        proxy_pass <http://backend>;
        health_check interval=5s fails=2 passes=2 uri=/health;
    }
}
Plain Text
복사

무료 버전에서 헬스 체크가 필요하다면 nginx_upstream_check_module 같은 써드파티 모듈을 사용하면 돼요.

Keepalive 연결 최적화

백엔드 서버와 연결을 재사용해서 성능을 높여요!

upstream backend {
    server localhost:8080;
    server localhost:8081;

    keepalive 32;  # 최대 32개 연결 재사용 (커넥션 풀)
}

server {
    location /api/ {
        proxy_pass <http://backend>;

        # keepalive를 쓰려면 아래 두 줄이 반드시 필요해요!
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}
Plain Text
복사

keepalive 없이: 요청할 때마다 TCP 연결 새로 맺음 → 느림

keepalive 있이: 기존 연결 재사용 → 빠름, 서버 리소스 절약

실전 설정 예제

Spring Boot 고가용성 구성

upstream spring_backend {
    least_conn;

    server 10.0.0.10:8080 weight=2 max_fails=3 fail_timeout=30s;
    server 10.0.0.11:8080 weight=2 max_fails=3 fail_timeout=30s;
    server 10.0.0.12:8080 weight=1 max_fails=3 fail_timeout=30s backup;

    keepalive 64;
}

server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://spring_backend;

        proxy_http_version 1.1;
        proxy_set_header Connection "";

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_connect_timeout 5s;
        proxy_read_timeout 60s;
        proxy_send_timeout 60s;

        proxy_next_upstream error timeout http_500 http_502 http_503;
        proxy_next_upstream_tries 2;
    }
}
Plain Text
복사

무중단 배포 플로우

sequenceDiagram
    participant Dev as 👨‍💻 개발자
    participant LB as ⚖️ Nginx
    participant S1 as 🖥️ Server 1
    participant S2 as 🖥️ Server 2

    Note over S1,S2: 평상시 — 두 서버 모두 트래픽 처리

    Dev->>S1: 배포 시작 (S1 종료)
    Note over LB: S1 max_fails 감지 → 자동 제외
    LB->>S2: S2로만 요청 전달

    Dev->>S1: 새 버전 배포 후 기동
    Note over LB: S1 복구 감지 → 자동 포함
    LB->>S1: S1, S2 양쪽으로 분배 재개

    Dev->>S2: S2도 같은 방식으로 배포
    Note over LB: S2 max_fails 감지 → 자동 제외
    LB->>S1: S1으로만 요청 전달

    Dev->>S2: 새 버전 배포 후 기동
    Note over S1,S2: 배포 완료 — 두 서버 모두 최신 버전
Mermaid
복사

성능 비교

구성	초당 처리 요청	장애 복구	배포 방식
서버 1대	1,000 RPS	불가	서비스 중단
서버 2대 (로드밸런싱)	2,000 RPS	가능	무중단
서버 4대 (로드밸런싱)	4,000 RPS	가능	무중단

RPS(Requests Per Second) — 초당 처리 가능한 요청 수. 서버를 N배 늘리면 처리량도 거의 N배!

로드 밸런싱 상태 확인

# Nginx 설정 테스트
nginx -t

# 설정 적용
systemctl reload nginx

# 에러 로그 실시간 확인
tail -f /var/log/nginx/error.log

# 연결 상태 확인
ss -tnp | grep nginx

# 각 upstream 서버 응답 테스트
curl -H "Host: api.example.com" <http://localhost>
Bash
복사

체크리스트

upstream 블록에 백엔드 서버 주소 모두 등록?

로드 밸런싱 알고리즘 선택 완료? (round robin / least_conn / ip_hash)

max_fails, fail_timeout 설정으로 자동 장애 감지?

keepalive 설정으로 연결 재사용 최적화?

proxy_next_upstream으로 실패 시 자동 재시도?

backup 서버 지정 완료?

nginx -t 설정 테스트 통과?

각 백엔드 서버 직접 접속 테스트 완료?

무중단 배포 흐름 검증 완료?

헬스 체크 엔드포인트(/health) 구성 완료?

핵심 정리

로드 밸런싱 = 여러 서버에 요청을 분산해 성능과 안정성을 동시에 확보

upstream 블록 = 백엔드 서버 그룹 정의 → proxy_pass로 연결

알고리즘 선택: 기본은 Round Robin, 처리 시간 다양하면 Least Conn, 세션 유지 필요하면 IP Hash

max_fails + fail_timeout = 자동 장애 감지 및 복구 (패시브 헬스 체크)

keepalive = 연결 재사용으로 성능 향상 (proxy_http_version 1.1 + Connection "" 필수)

backup 서버 = 모든 서버 다운 시 최후의 보루

무중단 배포 = 서버 하나씩 내렸다 올리며 서비스 중단 없이 업데이트 가능