Load Balancer

AI
gemma-4-31b
작성자
익명
작성일
2026.08.16
조회수
20
버전
v1
기술 → 네트워크 → 연결 기술
로드 밸런서 L4/L7 스위치 부하 분산 알고리즘 고가용성 GSLB Nginx 네트워크 인프라 중급

Load Balancer (로드 밸런서)

개요

로드 밸런서(Load Balancer)란 네트워크 트래픽을 여러 대의 백엔드 서버로 효율적으로 분산시켜, 특정 서버에 부하가 집중되는 것을 방지하고 서비스의 가용성과 응답 속도를 최적화하는 장치 또는 소프트웨어를 말한다.

현대적인 웹 서비스는 단일 서버만으로는 수많은 사용자의 요청을 처리하는 데 한계가 있으며, 서버 한 대에 장애가 발생할 경우 전체 서비스가 중단되는 SPOF(Single Point of Failure, 단일 장애점) 문제가 발생한다. 로드 밸런서는 이러한 위험을 제거하고, 서버를 수평적으로 확장(Scale-out)함으로써 시스템의 전체적인 처리량(Throughput)을 높이고 고가용성(High Availability)을 확보하는 핵심 역할을 수행한다.

동작 원리 및 구조

로드 밸런서는 클라이언트와 서버 사이에서 중개자(Proxy) 역할을 수행한다. 클라이언트는 개별 서버의 IP 주소를 알 필요 없이 로드 밸런서의 대표 IP(VIP, Virtual IP)로 요청을 보내며, 로드 밸런서는 설정된 알고리즘에 따라 최적의 서버를 선택해 요청을 전달한다.

[데이터 흐름 비교]

단계 흐름 설명 비고
1단계 클라이언트 $\rightarrow$ 로드 밸런서 사용자가 서비스 도메인(DNS)을 통해 요청 전송 VIP로 접속
2단계 로드 밸런서 $\rightarrow$ 판단 알고리즘 및 헬스 체크 상태를 기반으로 대상 서버 선정 부하 분산 로직 적용
3단계 로드 밸런서 $\rightarrow$ 서버 선정된 백엔드 서버로 패킷/요청 전달 내부 네트워크 통신
4단계 서버 $\rightarrow$ 로드 밸런서 $\rightarrow$ 클라이언트 서버의 처리 결과를 로드 밸런서를 거쳐 사용자에게 반환 응답 전달

로드 밸런싱 알고리즘

트래픽을 분배하는 방식은 서비스의 특성과 서버의 성능 상태에 따라 다양하게 선택할 수 있다.

[알고리즘별 비교 분석]

알고리즘 작동 방식 장점 단점 적합한 사례
라운드 로빈 (Round Robin) 순차적으로 서버에 요청을 배분 구현이 매우 단순함 서버 성능 차이를 고려하지 않음 서버 사양이 동일한 환경
가중치 라운드 로빈 (Weighted RR) 서버 성능에 따라 가중치를 부여해 배분 서버 성능 차이 반영 가능 가중치 설정의 수동 관리 필요 서버 사양이 서로 다른 환경
최소 연결 (Least Connection) 현재 연결 수가 가장 적은 서버로 배분 동적 부하 상태를 잘 반영함 연결 유지 시간이 긴 요청 시 불균형 가능 세션 유지 시간이 긴 서비스
IP 해시 (IP Hash) 클라이언트 IP를 해싱하여 특정 서버에 매핑 동일 사용자는 항상 동일 서버 접속 특정 IP(예: 기업 내부 프록시 서버)를 통해 많은 사용자가 접속할 경우, 특정 서버로 트래픽이 쏠리는 현상 발생 세션 유지가 필요한 서비스

계층별 분류 (L4 vs L7)

로드 밸런서는 OSI 7계층 모델 중 어느 계층에서 데이터를 처리하느냐에 따라 L4와 L7로 구분된다.

L4 로드 밸런서 (Transport Layer)

전송 계층(TCP/UDP)에서 동작하며, IP 주소와 포트 번호를 기반으로 트래픽을 분산한다. 데이터의 내용을 확인하지 않고 패킷의 헤더 정보만 보고 전달하므로 처리 속도가 매우 빠르다. 일반적으로 NAT(Network Address Translation) 방식을 사용하지만, 응답 트래픽이 로드 밸런서를 거치지 않고 서버에서 클라이언트로 직접 전달되어 성능을 높이는 DSR(Direct Server Return) 방식이 사용되기도 한다.

L7 로드 밸런서 (Application Layer)

응용 계층(HTTP/HTTPS, FTP, SSH 등)에서 동작하며, 실제 데이터(Payload)의 내용을 분석하여 분산한다. URL 경로, HTTP 헤더, 쿠키 값 등을 기준으로 정교한 라우팅이 가능하다.

[L4 vs L7 비교 분석]

구분 L4 로드 밸런서 L7 로드 밸런서
판단 기준 IP, Port, TCP/UDP 프로토콜 URL, HTTP Header, Cookie, Payload
처리 속도 매우 빠름 (단순 패킷 전달) 상대적으로 느림 (데이터 분석 필요)
정교함 낮음 (단순 분산) 높음 (콘텐츠 기반 라우팅 가능)
주요 특징 NAT/DSR 기반 프록시(Proxy) 기반, SSL 복호화 가능
제품 예시 AWS NLB, F5 BIG-IP (L4 mode) AWS ALB, Nginx, HAProxy

주요 기능 및 고급 설정

효율적인 부하 분산을 위해 로드 밸런서는 다음과 같은 부가 기능을 제공한다.

  • 헬스 체크 (Health Check): 로드 밸런서가 주기적으로 백엔드 서버에 신호를 보내 정상 작동 여부를 확인한다. 응답이 없거나 오류가 발생한 서버는 자동으로 대상 목록에서 제외하여 장애 전파를 막는다. 주요 확인 방법은 다음과 같다.
    • TCP 연결 확인: 3-way handshake 성공 여부를 통해 포트 활성화 상태 확인
    • HTTP 상태 코드 확인: 특정 경로(예: /health) 호출 시 200 OK 응답 확인
    • ICMP Ping 확인: 서버의 네트워크 생존 여부 확인
  • 스티키 세션 (Sticky Session): 특정 사용자의 요청이 처음 연결된 서버로 계속 전달되도록 보장하는 기능이다. 주로 L7의 쿠키 기반으로 구현된다.
  • SSL 종단점 (SSL Termination): 클라이언트와 로드 밸런서 사이의 암호화 통신(HTTPS)을 로드 밸런서에서 복호화하여 백엔드 서버로 전달하는 방식이다. 서버의 암복호화 부하를 줄여 성능을 향상시킨다.

GSLB (Global Server Load Balancing)

GSLB는 단일 데이터 센터 내의 분산이 아니라, 지리적으로 떨어진 여러 데이터 센터(Region) 간의 트래픽을 분산하는 기술이다.

  • 동작 방식: DNS(Domain Name System) 수준에서 동작하며, 사용자의 위치, 데이터 센터의 상태, 네트워크 지연 시간(Latency) 등을 고려하여 가장 가까운 혹은 최적의 데이터 센터 IP를 응답한다.
  • 목적: 재해 복구(DR, Disaster Recovery) 및 글로벌 서비스의 응답 속도 최적화. 이를 통해 특정 지역의 데이터 센터가 완전히 마비되더라도 다른 지역의 센터로 트래픽을 즉시 우회시켜 서비스 연속성을 보장한다.

세션 클러스터링과의 차이점

로드 밸런싱 환경에서 '사용자 상태 유지'를 위해 스티키 세션과 세션 클러스터링이 언급되지만, 두 개념은 근본적으로 다르다.

구분 스티키 세션 (Sticky Session) 세션 클러스터링 (Session Clustering)
접근 방식 로드 밸런서가 특정 서버로 계속 보냄 서버 간 세션 데이터를 공유함
장점 설정이 간단하고 서버 부하가 적음 특정 서버 장애 시에도 세션 유지 가능
단점 특정 서버에 부하 집중 가능, 서버 장애 시 세션 소실 서버 간 데이터 동기화 비용 발생 (오버헤드)
해결책 L7 로드 밸런서 설정 Redis, Memcached 등 외부 세션 저장소 활용

구현 방식 및 솔루션

로드 밸런서는 구현 형태에 따라 하드웨어, 소프트웨어, 클라우드 기반으로 나뉜다.

  • 하드웨어 기반 (L4 스위치): 전용 ASIC 칩을 사용하여 처리 성능이 매우 높으나, 비용이 비싸고 유연한 설정 변경이 어렵다. 주로 대규모 트래픽 처리가 필요한 엔터프라이즈 네트워크의 입구에 배치된다. (예: F5 Big-IP, Citrix ADC)
  • 소프트웨어 기반 (Software LB): 범용 서버에 설치하여 사용하며, 설정이 유연하고 비용 효율적이다. 애플리케이션 레벨의 세밀한 제어가 가능하며 오픈소스 기반으로 빠르게 배포할 수 있다. (예: Nginx, HAProxy)
  • 클라우드 기반 (Cloud LB): 클라우드 제공사가 관리하는 서비스형 로드 밸런서로, 자동 확장(Auto-scaling)과 연동되어 트래픽 변화에 유연하게 대응한다. 인프라 관리 부담이 적다. (예: AWS ALB/NLB, Azure Load Balancer, GCP Cloud Load Balancing)

[Nginx 업스트림 설정 예시]

Nginx를 사용하여 3대의 백엔드 서버로 트래픽을 분산하는 간단한 설정 코드이다.

http {
    # 백엔드 서버 그룹 정의 (업스트림)
    upstream backend_servers {
        # 가중치 기반 라운드 로빈 설정
        server 10.0.0.1:8080 weight=3; 
        server 10.0.0.2:8080 weight=1;
        server 10.0.0.3:8080;
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            # 정의된 업스트림 그룹으로 요청 전달
            proxy_pass http://backend_servers;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }
    }
}

실제 서비스 아키텍처 다이어그램 (개념도)

실제 엔터프라이즈 환경에서의 트래픽 흐름은 다음과 같은 계층 구조를 가진다.

graph TD
    User((사용자)) --> DNS[DNS / GSLB]
    DNS -->|최적의 리전 선택| RegionA[Region A - Seoul]
    DNS -->|최적의 리전 선택| RegionB[Region B - Virginia]
    
    subgraph "Region A Architecture"
        RegionA --> L7LB[L7 Load Balancer]
        L7LB -->|URL /api/v1/user| Server1[User Service Server 1]
        L7LB -->|URL /api/v1/user| Server2[User Service Server 2]
        L7LB -->|URL /api/v1/order| Server3[Order Service Server 1]
        L7LB -->|URL /api/v1/order| Server4[Order Service Server 2]
        
        Server1 & Server2 & Server3 & Server4 --> SessionStore[(Redis Session Store)]
    end
(위 다이어그램은 GSLB $\rightarrow$ L7 LB $\rightarrow$ 마이크로서비스 $\rightarrow$ 공통 세션 저장소로 이어지는 전형적인 고가용성 아키텍처를 나타낸다.)

참고 문헌

AI 생성 콘텐츠 안내

이 문서는 AI 모델(gemma-4-31b)에 의해 생성된 콘텐츠입니다.

주의사항: AI가 생성한 내용은 부정확하거나 편향된 정보를 포함할 수 있습니다. 중요한 결정을 내리기 전에 반드시 신뢰할 수 있는 출처를 통해 정보를 확인하시기 바랍니다.

이 AI 생성 콘텐츠가 도움이 되었나요?