로드밸런서는 클라이언트의 요청을 여러 서버로 분산시켜 서비스의 가용성과 확장성을 높입니다.
이때 L4 로드밸런서(Layer 4)는 TCP/UDP 같은 전송 계층의 정보를 기반으로 분산하며,
L7 로드밸런서(Layer 7)는 HTTP/HTTPS와 같은 애플리케이션 계층의 정보를 이용해 더 정밀한 분산 처리가 가능합니다.
개념 정리
로드밸런서
클라이언트로부터의 트래픽을 여러 서버에 분산시켜, 서비스 과부하를 방지하고 고가용성(High Availability, HA)을 보장하는 시스템
주요 기능
서버 부하 분산
장애 서버 자동 제외 (Health Check)
세션 유지 (Sticky Session)
HTTPS 종료(TLS Termination) 등
로드밸런서의 종류
구분
계층 (OSI)
분산 기준
특징 및 설명
예시 시스템/기술
L2 로드밸런서
2계층 (데이터링크)
MAC 주소
매우 낮은 수준의 패킷 전달, 브리지 기반. 현재는 거의 사용되지 않음
일부 특수 네트워크 장비
L3 로드밸런서
3계층 (네트워크)
IP 주소
ECMP 등 라우터 레벨에서 경로 기반 부하 분산
ECMP, SDN 라우터
L4 로드밸런서
4계층 (전송)
IP + 포트 (TCP/UDP)
빠르고 범용적, HTTP 외에도 모든 TCP/UDP 트래픽 분산 가능
AWS NLB, LVS, F5, Azure Load Balancer
L7 로드밸런서
7계층 (애플리케이션)
URL, 헤더, 쿠키, 파라미터 등 요청 내용
정밀 제어 가능, 웹 서비스나 마이크로서비스에 적합
Nginx, Envoy, AWS ALB, Istio, Kong
DNS 기반
계층 외 (애플리케이션 이전)
도메인 → IP 매핑
단순/저비용, DNS 캐싱으로 실시간 제어 어려움
DNS Round Robin, GeoDNS
Anycast
계층 외 (네트워크)
네트워크 거리 기반 (최단 경로)
동일 IP에 여러 노드를 연결, 네트워크 경로 기반 자동 분산
Cloudflare, Google DNS, 글로벌 CDN
Client-side LB
계층 외 (앱단)
클라이언트 로직 내부 서버 선택
서버 대신 클라이언트가 분산 처리. 마이크로서비스 환경에서 자주 사용됨
Ribbon, gRPC RoundRobin, Spring Cloud
실무에서 주로 쓰이는 로드밸런서 활용 예시
용도
가장 많이 쓰이는 로드밸런서
이유
일반 웹 서비스
L7 로드밸런서 (HTTP 기반)
URL, 쿠키, 헤더 기반의 세밀한 라우팅이 가능해서 REST API, 웹 UI 라우팅 등에 적합
고속 트래픽 처리 / 범용 트래픽
L4 로드밸런서 (TCP/UDP 기반)
빠르고 가볍고, HTTP 외의 모든 TCP/UDP 트래픽에도 사용 가능 (DB, 게임, Redis 등)
글로벌 트래픽 분산
DNS 기반 + Anycast
대륙 간 지리적 분산, 전세계 사용자에 대해 가장 가까운 서버 연결
마이크로서비스 내부 통신
Client-side LoadBalancer
서비스 간 통신에서 개발자가 직접 서버를 선택 → 로드밸런서 비용 절감, 유연성 증가
L4 로드밸런서 (Layer 4 Load Balancer)
1. 개념 및 특징
L4 로드밸런서는 OSI 4계층(전송 계층)에서 동작하며, TCP/UDP 프로토콜의 IP 주소와 포트 번호를 기반으로 트래픽을 분산시키는 로드밸런서입니다.
주요 특징
전송 계층 정보(IP, 포트) 기반으로 트래픽을 분산
트래픽의 내용(URI, 헤더, 쿠키 등)은 보지 않음
빠르고 가벼움 (Payload를 해석하지 않기 때문)
HTTP 외에도 FTP, SMTP, DNS, DB 연결 등 모든 TCP/UDP 프로토콜에 사용 가능
2. 동작 원리
클라이언트가 특정 IP와 포트로 요청을 보냄 (예: 203.0.113.1:443)
L4 로드밸런서는 이 요청의 IP/Port/프로토콜 정보를 바탕으로 내부 서버 중 하나를 선택
네트워크 레벨에서 연결을 NAT(주소 변환)하거나 포워딩하여 백엔드 서버로 전달
백엔드 서버는 로드밸런서에서 받은 요청을 처리하고 응답
로드밸런서가 응답을 클라이언트에 다시 전달
3. 장점
항목
설명
고성능
애플리케이션 데이터를 해석하지 않아 처리 속도가 빠름
범용성
HTTP 외의 모든 TCP/UDP 기반 서비스에도 사용 가능
낮은 오버헤드
L7보다 리소스 소모 적고 설정이 간단
애플리케이션 독립적
애플리케이션의 구조를 몰라도 트래픽 분산 가능
4. 단점
항목
설명
트래픽 내용 파악 불가
URI, 헤더, 쿠키 등 기반 분산 불가능
세밀한 라우팅 불가
특정 경로(/api, /image)마다 다른 서버로 보내는 등의 동작 불가
SSL 종료 어려움
암호화된 트래픽을 해석하지 않기 때문에 HTTPS 트래픽 처리 제약 있음
Sticky Session 제약
같은 사용자 요청을 동일 서버로 보내기 위한 설정이 제한적
5. 실무에서의 구체적인 활용 예시
1. AWS NLB(Network Load Balancer) 사용 예시
API 서버 여러 대에 대한 TCP 443 포트 트래픽 분산
TLS 종료는 백엔드 서버(Spring Boot 등)에서 처리
높은 처리량과 낮은 지연이 요구될 때 사용
2. Kafka, MySQL 등의 내부 서비스 분산
Kafka, DB 서버는 일반적으로 TCP 기반 포트를 사용
L7 로드밸런서는 트래픽 내용을 모름 → L4에서 TCP 포트 기반으로 분산
3. 게임 서버/실시간 서비스 (UDP 기반)
FPS 게임, VoIP, 영상 스트리밍 등의 서비스는 UDP를 많이 사용
L7 로드밸런서는 UDP 지원이 어려움 → L4 기반으로 분산 필수
L7 로드밸런서 (Layer 7 Load Balancer)
1. 개념 및 특징
L7 로드밸런서는 OSI 7계층(애플리케이션 계층)에서 동작하며, HTTP/HTTPS 등 애플리케이션 프로토콜의 내용을 파악하여 요청을 분산한다.
주요 특징
HTTP 요청의 URI, 헤더, 쿠키, 쿼리 파라미터 등 애플리케이션 데이터를 분석하여 라우팅
트래픽의 내용 기반으로 정밀한 분산 처리 가능
TLS 종료(SSL Termination), 캐싱, 압축 등 부가 기능 지원
웹 서비스, REST API, 마이크로서비스 환경에서 주로 사용
2. 동작 원리
클라이언트가 HTTP/HTTPS 요청을 보냄
L7 로드밸런서는 요청의 URI, Host, Header, 쿠키 등 애플리케이션 레벨 데이터를 분석
조건에 따라 요청을 특정 백엔드 서버로 라우팅
백엔드 서버는 응답을 생성하여 로드밸런서로 전달
로드밸런서는 응답을 클라이언트에 다시 전달
3. 장점
항목
설명
정밀한 라우팅
요청 내용(URI, 쿠키, 헤더 등)에 따라 분산 처리 가능
HTTPS 처리
TLS 종료를 통해 백엔드 서버는 평문 HTTP로 통신 가능
고급 기능 지원
인증, 캐싱, 압축, 리다이렉션, 응답 재작성 등 다양한 제어 가능
마이크로서비스 친화
API Gateway 역할 가능 (인증, 버전 분기, 경로 라우팅 등)
4. 단점
항목
설명
상대적으로 느림
L4보다 트래픽을 분석해야 하므로 처리 시간이 길어질 수 있음
리소스 소모 큼
트래픽을 파싱하고 처리하기 때문에 CPU, 메모리 사용량이 많음
UDP 미지원
HTTP(S) 기반이므로 비HTTP 서비스에는 사용 불가
설정 복잡
다양한 조건 분기, 라우팅 규칙 구성 시 복잡해질 수 있음
5. 실무에서의 구체적인 활용 예시
1. API Gateway 역할 (도메인/경로 기반 라우팅)
/api/* 요청은 Spring API 서버로
/static/* 요청은 CDN 서버로
admin.example.com은 내부 관리자 서버로
2. TLS 종료(SSL Termination)
HTTPS 요청을 L7 로드밸런서에서 종료하고, 백엔드 서버는 HTTP로 통신
백엔드는 TLS 처리 부담을 덜고, 인증서 관리는 로드밸런서가 담당
3. 쿠키/세션 기반 라우팅 (Sticky Session)
로그인한 사용자의 쿠키 값을 기반으로 동일한 서버로 라우팅
특정 사용자 그룹은 별도 서버군으로 분기
4. A/B 테스트 및 블루-그린 배포
트래픽의 일부(예: 10%)만 새 버전 서버로 분산
쿠키나 헤더를 기준으로 특정 사용자만 새 버전 사용
새끼 질문
Q. L4와 L7 로드밸런서 중 어떤 것을 언제 사용해야 하나요?
A:
L4는 빠르고 가벼운 트래픽 분산이 필요한 경우, L7은 정밀한 라우팅과 고급 제어가 필요한 경우 적합합니다.
예를 들어, 정적 파일이나 DB 트래픽에는 L4를, API 게이트웨이처럼 경로별 분기 처리가 필요한 경우에는 L7을 사용합니다.
실무에서는 L4와 L7을 조합해서 사용하는 경우도 많습니다.
Q. L4 로드밸런서에서 세션 유지(Sticky Session)는 어떻게 구현하나요?
A:
L4 로드밸런서는 HTTP 레벨의 세션 정보를 볼 수 없기 때문에, 일반적으로 클라이언트 IP를 해시하여 동일 서버로 요청을 보내는 방식(IP Hash)을 사용합니다.
보다 정밀한 세션 유지가 필요하다면, 세션 쿠키 등을 인식할 수 있는 L7 로드밸런서를 사용하는 것이 좋습니다.
Q. MySQL 앞에 L4 로드밸런서를 둘 때 주의할 점은 무엇인가요?
A:
MySQL은 쓰기를 반드시 마스터에서만 해야 하므로, L4 로드밸런서를 쓰기/읽기 전용으로 나누어 구성해야 합니다.
쓰기 요청은 마스터로, 읽기 요청은 리플리카로 전달되도록 해야 하며, 이를 위해 L4 로드밸런서를 분리하거나 SQL-aware 프록시(예: ProxySQL)를 사용하는 방법이 있습니다.
Q. L7 로드밸런서를 쓸 때 리소스 과다 사용 문제는 어떻게 해결할 수 있나요?
A:
L7 로드밸런서는 트래픽을 파싱해야 하므로 CPU 및 메모리 부담이 큽니다.
이를 해결하기 위해:
클라이언트 → AWS NLB (TCP 443) → 백엔드 서버 그룹 (Spring Boot)
읽기/쓰기 분리
MySQL은 마스터-리플리카 구조로 복제를 구성할 수 있음
L4 로드밸런서를 통해 읽기 요청은 리플리카로, 쓰기 요청은 마스터로 분산 가능
애플리케이션
├──→ L4 로드밸런서 (쓰기용) → 마스터 DB
└──→ L4 로드밸런서 (읽기용) → 리플리카 1, 리플리카 2