로드밸런서 설계: 가용성과 확장성을 확보하는 트래픽 분산
로드밸런서의 VIP, NAT·DSR·터널링 방식과 분산 알고리즘, 이중화·세션·SSL 운영 고려사항을 정리한다.
2026-08-14 · 최초 발행 2025-08-10
트래픽의 단일 접점을 만드는 장치
로드밸런서는 여러 서버에 네트워크 트래픽을 나눠 보내는 장치다. 사용자는 가상 IP(VIP)를 통해 서비스에 접속하고, 내부 서버 구성이 바뀌더라도 같은 접점을 이용한다. 서버 팜을 하나의 서비스처럼 제공할 수 있어 고가용성 시스템과 대규모 웹 서비스, 클라우드 환경에서 핵심 역할을 맡는다.
부하분산은 여러 컴퓨팅 자원에 작업을 배치해 전체 시스템의 효율을 높이는 방식이다. 특정 서버에 요청이 몰리는 상황을 피하고, 필요한 경우 서버 노드를 추가해 서비스 용량을 확장할 수 있다.
서버 증설과 장애 대응을 함께 다루는 이유
수평 확장은 서버 노드를 추가해 처리 용량을 늘리는 방식이다. 트래픽이 증가할 때 서버를 더 투입할 수 있으며, Black Friday 쇼핑 시즌처럼 일시적인 요청 증가에도 대응할 수 있다.
장애 대응도 같은 구조에서 이뤄진다. 헬스 체크로 장애 서버를 감지하고, 과부하 상태인 노드를 분산 대상에서 제외하면 서비스 중단 없이 요청을 계속 처리할 수 있다. 서버 간 부하를 고르게 유지하면 특정 서버의 과부하를 줄이고 응답 시간과 전체 처리량, 사용자 경험을 개선하는 데도 도움이 된다.
요청과 응답을 전달하는 경로
NAT 방식
NAT는 외부에 내부 서버 IP 주소를 노출하지 않고 하나의 공인 IP로 여러 서버를 제공하는 방식이다. 로드밸런서는 VIP로 들어온 패킷의 목적지 주소를 실제 서버 IP로 바꾸며, 요청과 응답의 양방향 흐름을 모두 처리한다.
DSR 방식
DSR(Direct Server Return)에서는 요청이 로드밸런서를 거쳐 서버로 전달되지만, 응답은 서버가 클라이언트에 직접 보낸다. 응답 처리 부담이 줄어 대용량 트래픽 환경에서 로드밸런서 병목을 방지할 수 있다. 반면 서버 구성이 복잡해진다.
터널링 방식
터널링은 캡슐화 기술로 패킷을 전달한다. IP-in-IP, GRE 등의 프로토콜을 활용하며, 서로 다른 네트워크 환경 사이의 통신이나 지리적으로 분산된 서버 환경에 사용할 수 있다.
워크로드에 맞는 분산 정책
Round Robin은 요청을 서버에 순차적으로 배분하는 기본 방식이다. 구현이 단순하고 서버 사양이 같을 때 적합하지만, 서버 간 성능 차이는 반영하지 못한다. 대부분의 로드밸런서에서 기본 알고리즘으로 제공된다.
Weighted Round Robin은 서버 처리 능력에 맞춰 가중치를 부여한다. 고성능 서버에 더 많은 요청을 배정할 수 있어 이기종 서버 환경에서 활용된다. 예를 들어 서버A는 가중치 5, 서버B는 가중치 3, 서버C는 가중치 2로 설정할 수 있다.
Least Connection은 현재 연결 수가 가장 적은 서버를 선택한다. 연결 지속 시간이 일정하지 않은 동적 워크로드와 세션 기반 애플리케이션에 적합하다.
IP Hash는 클라이언트 IP 주소를 해싱해 같은 사용자의 요청을 같은 서버로 보낸다. 세션 지속성이 필요한 쇼핑몰이나 뱅킹 시스템처럼 사용자 상태 유지가 중요한 서비스에서 세션 일관성을 유지하는 데 쓴다.
장비와 소프트웨어의 선택
하드웨어 로드밸런서는 F5 BIG-IP, Citrix NetScaler 같은 전용 장비로 구현한다. 고성능과 안정성을 제공하지만 초기 도입 비용이 높아 엔터프라이즈급 대규모 시스템에 적합하다.
소프트웨어 로드밸런서는 HAProxy, Nginx, AWS ELB 등을 일반 서버 환경에서 사용한다. 유연성과 확장성이 높고 비용 효율적이어서 클라우드 환경에 적합하다.
서비스 구성에서 만나는 부하분산
웹 서비스에서는 여러 웹 서버에 HTTP 트래픽을 나눠 보내고, 사용자 증가에 맞춰 서버를 확장한다. Netflix, Amazon 같은 대규모 웹 서비스가 이 유형에 해당한다.
마이크로서비스 아키텍처의 API 게이트웨이는 API 요청을 서비스별로 라우팅하고 부하를 분산한다. 카카오, 네이버 같은 대형 플랫폼 서비스에서도 서비스별 독립 확장을 위해 활용할 수 있다.
데이터베이스 클러스터에서는 읽기 작업을 여러 DB 서버로 분산하고, 쓰기는 마스터로, 읽기는 복제본으로 분리한다. MySQL 클러스터와 MongoDB 샤딩이 예시다.
운영 설계에서 남는 과제
로드밸런서 자신도 장애 지점이 될 수 있다. Active-Standby 또는 Active-Active 구성을 검토하고, VRRP(Virtual Router Redundancy Protocol)를 활용한 Failover 구성을 마련해야 한다.
세션 지속성(Sticky Session)이 필요한지 먼저 확인해야 한다. 세션 클러스터링이나 Redis 등의 외부 세션 저장소를 고려할 수 있으며, 상태 비저장(Stateless) 애플리케이션 설계도 선택지다.
SSL Termination과 SSL Passthrough 중 어느 방식을 쓸지 결정하고, 인증서 관리와 갱신 자동화, 보안 취약점 대응 방안을 함께 준비한다. 로드밸런서 상태와 서버 헬스체크 결과를 기록·분석하고, 이상 징후에 자동으로 알리는 체계도 필요하다.