로드밸런싱 — L4 vs L7, 라운드로빈부터 Consistent Hashing까지
서버가 한 대면 로드밸런서가 필요 없습니다. 그런데 서버가 두 대가 되는 순간 — "어디로 보낼 것인가?"라는 질문이 시작됩니다.
로드밸런싱은 트래픽을 여러 서버에 분배하는 기술입니다. 단순해 보이지만, L4와 L7의 차이, 알고리즘 선택, Consistent Hashing의 원리까지 들어가면 꽤 깊은 주제입니다.
왜 로드밸런서가 필요한가
- **가용성 **: 서버 하나가 죽어도 나머지가 트래픽을 처리
- ** 확장성 **: 서버를 추가하면 자연스럽게 처리 용량이 증가
- ** 성능 **: 부하를 분산하여 응답 시간을 낮춤
로드밸런서 없이 DNS 라운드로빈만으로도 기본적인 분배는 가능하지만, 헬스 체크나 세션 유지 같은 기능이 없어서 프로덕션에서는 한계가 있습니다.
L4 vs L7 — 동작 차이
L4 로드밸런서 (전송 계층)
- ** 보는 것 **: IP 주소 + 포트 번호 (TCP/UDP 헤더까지)
- ** 못 보는 것 **: HTTP 헤더, URL 경로, 쿠키
- ** 동작 방식 **: TCP 연결 자체를 특정 서버로 전달 (패킷 포워딩)
- ** 성능 **: 10~40 Gbps 처리, 마이크로초 수준의 지연
클라이언트 → [L4 LB] → 서버 A (포트 기반 분배)
→ 서버 B
L7 로드밸런서 (응용 계층)
- ** 보는 것 **: HTTP 메서드, URL 경로, 헤더, 쿠키, 요청 본문
- ** 동작 방식 **: HTTP 요청을 파싱한 후 라우팅 규칙에 따라 분배
- ** 성능 **: 5~20ms 추가 지연 (HTTP 파싱 비용)
- ** 할 수 있는 것 **: URL 기반 라우팅, 쿠키 기반 세션 어피니티, HTTP/2 스트림 카운팅
클라이언트 → [L7 LB] → /api/* → API 서버 그룹
→ /static/* → 정적 파일 서버 그룹
비교 정리
| 항목 | L4 | L7 |
|---|---|---|
| 판단 기준 | IP, 포트 | URL, 헤더, 쿠키 |
| 지연 | 마이크로초 | 밀리초 (5~20ms 추가) |
| 처리량 | 매우 높음 (10-40 Gbps) | 상대적으로 낮음 |
| SSL 종료 | 불가 (또는 별도 구성) | 가능 |
| 세밀한 라우팅 | 불가 | 가능 |
빠르지만 "멍청한" L4, 느리지만 "똑똑한" L7. 대부분의 웹 서비스는 L7이 필요합니다.
분배 알고리즘
Round Robin
- 요청을 순서대로 돌아가며 분배
- 가장 단순하고 서버 스펙이 동일할 때 효과적
- 문제: 요청 처리 시간이 불균일하면 특정 서버에 부하 집중
Weighted Round Robin
- 서버마다 가중치를 부여 (예: 고사양 서버에 가중치 3, 저사양에 1)
- 서버 스펙이 다를 때 유용
Least Connections
- 현재 활성 연결 수가 가장 적은 서버에 분배
- 요청 처리 시간이 들쭉날쭉할 때 Round Robin보다 효과적
- 단점: 연결 수 추적 오버헤드
IP Hash
- 클라이언트 IP를 해시하여 항상 같은 서버로 분배
- 세션 유지가 필요할 때 간단한 방법
- 문제: 서버 추가/제거 시 대부분의 매핑이 바뀜 → Consistent Hashing으로 해결
Least Response Time
- 응답 시간이 가장 빠른 서버에 분배
- 서버 상태를 실시간으로 반영하지만, 측정 오버헤드 존재
Consistent Hashing — 서버가 바뀌어도 대부분의 매핑을 유지
일반 해시 분배의 문제를 먼저 보겠습니다.
# 일반 해시: 서버 3대
server = hash(key) % 3
# 서버 1대 추가 → 서버 4대
server = hash(key) % 4
# → 대부분의 키가 다른 서버로 재배치됨
해시 링 구조
Consistent Hashing은 해시 공간을 원형 링으로 만들고, 서버와 키를 모두 이 링 위에 배치합니다.
0
┌───────┐
S3│ │S1
│ 링 │
K2│ │K1
└───────┘
S2
K3
키 → 시계 방향으로 가장 가까운 서버에 매핑
K1 → S1, K2 → S3, K3 → S2
서버 하나가 추가되거나 제거되면, 링 위에서 해당 서버와 인접한 키들만 재배치됩니다. 전체의 1/N만 영향을 받습니다.
가상 노드 (Virtual Node)
물리 서버가 3대뿐이면 링 위에 3개의 점만 찍히므로 키 분포가 불균형해질 수 있습니다.
# 가상 노드 없이 (불균형)
S1 → 전체 키의 60%
S2 → 전체 키의 10%
S3 → 전체 키의 30%
# 가상 노드 150개씩 (균형)
S1 → 전체 키의 ~33%
S2 → 전체 키의 ~33%
S3 → 전체 키의 ~34%
각 물리 서버를 100~200개의 가상 노드로 복제하면 링 위에 고르게 분산됩니다. Redis Cluster, Cassandra, Amazon DynamoDB 등이 이 방식을 사용합니다.
Google의 Maglev 알고리즘은 링 대신 룩업 테이블을 사용하여 Consistent Hashing보다 메모리 효율이 높고 조회가 빠릅니다. 대규모 L4 로드밸런싱에서 사용됩니다.
AWS 로드밸런서 매핑
| AWS 서비스 | 계층 | 용도 |
|---|---|---|
| NLB (Network Load Balancer) | L4 | TCP/UDP, 초저지연, 고처리량 |
| ALB (Application Load Balancer) | L7 | HTTP/HTTPS, 경로/호스트 기반 라우팅 |
| CLB (Classic Load Balancer) | L4/L7 혼합 | 레거시, 신규 사용 비권장 |
| GLB (Gateway Load Balancer) | L3/L4 | 서드파티 보안 어플라이언스 연동 |
실무에서 가장 많이 쓰는 조합:
- **웹 서비스 **: ALB (HTTPS 종료 + 경로 라우팅)
- ** 게임/IoT**: NLB (TCP/UDP 저지연)
- ** 마이크로서비스 **: ALB + 타겟 그룹으로 서비스별 라우팅
2계층 아키텍처 — L4 + L7 조합
대규모 서비스에서는 L4와 L7을 직렬로 배치하는 패턴이 일반적입니다.
인터넷 → [L4 LB] → [L7 LB 클러스터] → [서비스 서버]
빠른 분배 세밀한 라우팅 실제 처리
DDoS 흡수 SSL 종료
헬스체크 경로 라우팅
- **L4 단 **: 마이크로초 수준으로 트래픽을 빠르게 분산 + DDoS 흡수
- **L7 단 **: HTTP 파싱 후 URL/헤더 기반 라우팅 + SSL 종료
이 구조의 장점:
- L4에서 DDoS를 걸러내므로 L7에 도달하는 트래픽이 깨끗합니다
- L7을 수평 확장하기 쉽습니다 (L4가 L7 인스턴스들에 분배)
- 역할 분리로 장애 범위가 좁아집니다
정리
- L4: IP/포트만 보고 빠르게 분배, 마이크로초 지연
- L7: HTTP까지 파싱하여 세밀한 라우팅, 5~20ms 추가 지연
- ** 알고리즘 선택 **: 균일한 요청 → Round Robin, 불균일 → Least Connections, 세션 유지 → IP Hash/Consistent Hashing
- Consistent Hashing: 서버 추가/제거 시 전체의
1/N만 재배치, 가상 노드로 균형 확보 - ** 실무 패턴 **: L4(속도) → L7(지능) 2계층 구조가 대규모 서비스의 표준