실제 Nginx 기반 L7 로드밸런싱 구축 설정법

by

웹 서비스의 사용자 수가 급격히 늘어나거나 대규모 프로모션으로 트래픽이 폭증할 때, 단일 서버만으로는 한계에 부딪히기 마련입니다.

이를 해결하기 위해 서버를 여러 대로 늘리는 스케일 아웃(Scale-out) 방식을 도입하게 되는데, 이때 여러 대의 서버 앞단에서 교통정리를 해주는 핵심 관문이 바로 로드밸런서(Load Balancer, 부하 분산기)입니다.

로드밸런서를 효과적으로 운영하기 위해 반드시 알아야 할 L4와 L7 로드밸런서의 차이점, 상황별 최적의 부하 분산 알고리즘, 그리고 실제 Nginx 기반 L7 로드밸런싱 구축 설정법까지 체계적으로 정리해 드립니다.

1. L4 로드밸런서 vs L7 로드밸런서 핵심 차이

네트워크 계층(OSI 7 Layer) 중 어느 계층에서 트래픽을 분석하고 분산하느냐에 따라 L4와 L7으로 구분됩니다.

  • L4 로드밸런서 (전송 계층 / Transport Layer)
  • 동작 원리: IP 주소와 포트(Port) 번호, TCP/UDP 프로토콜 헤더만을 보고 패킷 레벨에서 트래픽을 분산합니다.
  • 장점: 패킷의 내부 데이터(페이로드)를 열어보지 않으므로 처리 속도가 매우 빠르고 서버 자원(CPU, 메모리) 소모가 적습니다. 디도스(DDoS) 방어나 대규모 단순 TCP 트래픽 처리에 유리합니다.
  • 단점: HTTP 헤더, 쿠키, URL 경로 등을 읽을 수 없어 정교한 라우팅이 불가능합니다.
  • L7 로드밸런서 (응용 계층 / Application Layer)
  • 동작 원리: HTTP/HTTPS 요청의 URI 경로, 헤더, 쿠키, 메서드(GET/POST) 등 실제 애플리케이션 데이터를 분석하여 분산합니다.
  • 장점: /api 요청은 API 서버로, /images 요청은 정적 파일 서버로 전달하는 등 정교한 콘텐츠 기반 라우팅이 가능합니다. SSL/TLS 종단(Termination) 처리나 비정상 요청 필터링(WAF 연계)도 가능합니다.
  • 단점: 패킷을 파싱하고 복호화해야 하므로 L4에 비해 상대적으로 연산 부하가 큽니다.

2. 주요 부하 분산(Load Balancing) 알고리즘 비교

서비스의 아키텍처와 트래픽 특성에 맞춰 적절한 알고리즘을 선택해야 특정 서버로 부하가 쏠리는 현상을 방지할 수 있습니다.

알고리즘 동작 방식 적합한 환경
라운드 로빈 (Round Robin) 들어오는 요청을 백엔드 서버 목록 순서대로 공평하게 1:1 분배 서버들의 사양과 처리 능력이 동일하고, 요청당 소요 시간이 비슷한 경우
가중치 라운드 로빈 (Weighted Round Robin) 서버마다 가중치를 부여해 사양이 높은 서버에 더 많은 요청을 할당 고성능 서버와 구형 서버가 혼합된 이기종 인프라 환경
최소 연결 (Least Connections) 현재 활성 세션(연결 수)이 가장 적은 서버로 새 요청을 전달 웹소켓, 파일 업로드, 장기 트랜잭션 등 연결 유지 시간이 불규칙한 서비스
IP 해시 (IP Hash / Source Hash) 클라이언트의 IP 주소를 해싱하여 항상 동일한 백엔드 서버로 고정 전달 서버 간 세션 클러스터링이 구축되지 않아 세션 일관성(Sticky Session)이 필요한 환경

3. Nginx를 활용한 L7 로드밸런서 구축 실습

대표적인 오픈소스 웹 서버인 Nginx를 사용해 가중치 기반 라운드 로빈 및 헬스 체크가 적용된 L7 로드밸런서를 구성하는 실습 예제입니다.

/etc/nginx/nginx.conf 설정 예시

 

Nginx

events {
    worker_connections 1024;
}

http {
    # 1. 백엔드 애플리케이션 서버 풀 정의
    upstream backend_servers {
        # Least Connections 사용 시: least_conn;
        # IP Hash 사용 시: ip_hash;

        # 가중치(weight) 및 실패 감지(max_fails, fail_timeout) 설정
        server 10.0.1.11:8080 weight=3 max_fails=3 fail_timeout=10s;
        server 10.0.1.12:8080 weight=2 max_fails=3 fail_timeout=10s;
        server 10.0.1.13:8080 weight=1 max_fails=3 fail_timeout=10s;

        # 모든 주 서버 장애 시 동작할 백업 서버
        server 10.0.1.14:8080 backup;
    }

    # 2. 로드밸런서 프론트엔드 리스너 설정
    server {
        listen 80;
        server_name service.example.com;

        # 일반 트래픽 백엔드 풀로 프록시
        location / {
            proxy_pass http://backend_servers;
            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 3s;
            proxy_read_timeout 10s;
            proxy_send_timeout 10s;
        }

        # 정적 파일 전용 분기 (L7 콘텐츠 기반 라우팅)
        location /static/ {
            alias /var/www/static/;
            expires 30d;
        }
    }
}

4. 안정적인 로드밸런서 운영을 위한 3가지 핵심 수칙

  1. 주기적인 헬스 체크(Health Check): 다운된 서버로 트래픽이 전달되지 않도록 백엔드 인스턴스의 상태 확인 엔드포인트(예: /healthz)를 주기적으로 모니터링해야 합니다.
  2. 로드밸런서 자체의 단일 장애점(SPOF) 방지: 로드밸런서가 1대만 존재하면 해당 장비 장애 시 전체 서비스가 중단됩니다. Keepalived나 클라우드 기반 관리형 로드밸런서(ALB, NLB)를 통해 로드밸런서 자체도 이중화(Active-Standby 또는 Active-Active)해야 합니다.
  3. 클라이언트 실제 IP 보존: 프록시를 거치면 백엔드 서버 로그에 로드밸런서 IP만 남게 되므로, X-Forwarded-For 헤더 전달 설정을 반드시 적용하여 보안 분석 및 로깅에 활용해야 합니다.