로드밸런싱 개념 완전 정복
현대 웹 서비스는 단일 서버로는 수천~수만 명의 동시 접속을 감당하기 어렵습니다. **로드밸런싱(Load Balancing)**은 여러 서버에 트래픽을 분산시켜 고가용성과 높은 처리량을 동시에 달성하는 핵심 기술입니다. 이 챕터에서는 로드밸런싱의 근본 개념부터 실무에서 선택해야 할 알고리즘까지 체계적으로 학습합니다.
로드밸런싱이란?
로드밸런싱은 클라이언트 요청을 다수의 백엔드 서버(업스트림)에 고르게 분배하여 어느 한 서버에 부하가 집중되지 않도록 하는 기술입니다. 이를 담당하는 장치나 소프트웨어를 **로드밸런서(Load Balancer)**라고 합니다.
로드밸런서가 없으면 단일 서버 장애 시 서비스 전체가 다운됩니다. 반면 로드밸런서를 도입하면 서버 한 대가 죽어도 나머지 서버가 트래픽을 이어받아 서비스를 유지합니다.
로드밸런싱으로 얻는 이점
| 이점 | 설명 |
|---|---|
| 고가용성(HA) | 일부 서버 장애 시에도 서비스 지속 |
| 수평 확장(Scale-out) | 서버를 추가해 처리 용량 증가 |
| 성능 향상 | 요청을 분산해 응답 시간 감소 |
| 무중단 배포 | 순차적 서버 교체로 배포 중 다운타임 없음 |
| 유지보수 용이 | 서버를 하나씩 내려도 서비스 유지 |
L4 vs L7 로드밸런싱
로드밸런서는 OSI 모델의 어느 계층에서 동작하느냐에 따라 L4와 L7으로 구분됩니다.
L4 로드밸런싱 (전송 계층)
L4 로드밸런서는 IP 주소와 포트(TCP/UDP) 정보만으로 트래픽을 분산합니다. 패킷 내용을 들여다보지 않아 처리 속도가 매우 빠릅니다.
[클라이언트: 1.2.3.4:54321]
↓
[L4 LB: 목적지 80/443 포트 확인]
↓
[App1: 10.0.0.1:8080] 또는 [App2: 10.0.0.2:8080]
특징:
- HTTP 헤더, 쿠키, URL 경로를 볼 수 없음
- NAT(Network Address Translation) 방식 동작
- 하드웨어 로드밸런서(F5, Citrix)가 주로 L4 기반
- Linux 커널의 IPVS, AWS NLB가 대표적
L7 로드밸런싱 (응용 계층)
L7 로드밸런서는 HTTP 헤더, URL 경로, 쿠키, 메서드 등 애플리케이션 데이터를 분석해 라우팅합니다. 더 정교한 규칙이 가능하지만 L4보다 처리 비용이 높습니다.
[클라이언트 요청]
GET /api/users HTTP/1.1
Host: example.com
↓
[L7 LB: URL, 헤더, 쿠키 분석]
/api/* → API 서버 그룹
/static/* → 파일 서버 그룹
/admin/* → 관리자 서버 (IP 제한)
특징:
- URL 경로, 호스트 헤더 기반 라우팅 가능
- SSL 종료(SSL Termination) 처리
- 세션 쿠키 기반 Sticky Session 구현 가능
- Nginx, HAProxy, AWS ALB가 대표적
L4 vs L7 비교표
| 항목 | L4 | L7 |
|---|---|---|
| 동작 계층 | 전송 계층(TCP/UDP) | 응용 계층(HTTP/HTTPS) |
| 라우팅 기준 | IP, 포트 | URL, 헤더, 쿠키 |
| 처리 속도 | 매우 빠름 | 상대적으로 느림 |
| 내용 검사 | 불가 | 가능 |
| SSL 오프로딩 | 불가 | 가능 |
| 대표 제품 | AWS NLB, IPVS | Nginx, HAProxy, AWS ALB |
하드웨어 vs 소프트웨어 로드밸런서
하드웨어 로드밸런서
전용 하드웨어 장비에 탑재된 로드밸런서입니다. F5 BIG-IP, Citrix ADC 등이 대표적이며, 수십만~수백만 TPS를 처리할 수 있습니다.
장점:
- 극단적인 고성능 (ASIC 칩 활용)
- 안정성과 신뢰성이 높음
- 네트워크 팀에서 중앙 관리
단점:
- 수천만 원~수억 원의 도입 비용
- 설정 변경이 느리고 유연성이 떨어짐
- 클라우드 환경과 궁합이 나쁨
소프트웨어 로드밸런서
범용 서버에서 소프트웨어로 구현한 로드밸런서입니다. Nginx, HAProxy, Envoy 등이 대표적입니다.
장점:
- 저렴한 비용 (오픈소스 대부분 무료)
- 설정이 코드로 관리됨 (GitOps 친화적)
- 클라우드/컨테이너 환경과 궁합이 좋음
- 기능 추가·업그레이드 용이
단점:
- 하드웨어 대비 성능이 낮음 (단, 현대 서버에서는 충분)
- 운영 노하우가 필요
클라우드 관리형 로드밸런서:
| 클라우드 | 제품 | 계층 |
|---|---|---|
| AWS | ALB (Application LB) | L7 |
| AWS | NLB (Network LB) | L4 |
| GCP | Cloud Load Balancing | L4/L7 |
| Azure | Application Gateway | L7 |
로드밸런싱 알고리즘
로드밸런서가 어느 서버로 요청을 보낼지 결정하는 방식입니다. 서비스 특성에 맞는 알고리즘을 선택하는 것이 중요합니다.
Round Robin (라운드 로빈)
가장 단순한 방식으로, 서버를 순서대로 돌아가며 요청을 할당합니다.
요청1 → App1
요청2 → App2
요청3 → App3
요청4 → App1 ← 다시 처음으로
적합한 상황: 모든 서버의 스펙이 동일하고, 요청 처리 시간이 유사할 때.
단점: 처리 시간이 긴 요청이 특정 서버에 몰리면 불균형 발생.
Weighted Round Robin (가중 라운드 로빈)
서버마다 가중치(Weight)를 부여해 성능이 높은 서버에 더 많은 요청을 배분합니다.
App1 (weight=3): 요청1, 요청2, 요청3
App2 (weight=1): 요청4
App1 (weight=3): 요청5, 요청6, 요청7
App2 (weight=1): 요청8
Nginx 설정 예시:
upstream backend {
server app1.example.com weight=3;
server app2.example.com weight=1;
}
적합한 상황: 서버 스펙이 다를 때 (고사양 서버에 가중치를 높게 설정).
Least Connections (최소 연결)
현재 활성 연결 수가 가장 적은 서버로 요청을 보냅니다. 처리 시간이 긴 요청이 섞여 있을 때 효과적입니다.
App1: 연결 100개
App2: 연결 30개 ← 신규 요청은 App2로
App3: 연결 75개
Nginx 설정 예시:
upstream backend {
least_conn;
server app1.example.com;
server app2.example.com;
server app3.example.com;
}
적합한 상황: 요청 처리 시간이 들쑥날쑥할 때 (예: API 서버, DB 쿼리 포함 서비스).
IP Hash (IP 해시)
클라이언트 IP 주소를 해시해서 항상 같은 서버로 라우팅합니다. 세션 공유 없이도 특정 사용자를 동일 서버에 묶을 수 있습니다.
1.2.3.4 → 해시 → App2 (이후에도 항상 App2)
5.6.7.8 → 해시 → App1 (이후에도 항상 App1)
Nginx 설정 예시:
upstream backend {
ip_hash;
server app1.example.com;
server app2.example.com;
}
적합한 상황: 세션 공유 인프라(Redis 등)가 없을 때 임시방편으로 Sticky Session 구현.
단점: 서버 추가/제거 시 해시가 재계산되어 기존 사용자가 다른 서버로 이동 → 세션 유실.
Least Time (최소 응답 시간, Nginx Plus)
응답 시간과 활성 연결 수를 종합해 가장 빠르게 응답하는 서버를 선택합니다. Nginx Plus 상용 버전에서 지원합니다.
Random (랜덤)
서버를 무작위로 선택합니다. 단순하지만 서버 수가 많을수록 통계적으로 균등해집니다.
알고리즘 선택 가이드
| 상황 | 권장 알고리즘 |
|---|---|
| 서버 스펙 동일, 짧은 요청 | Round Robin |
| 서버 스펙 상이 | Weighted Round Robin |
| 요청 처리 시간 불균일 | Least Connections |
| 세션 공유 없는 환경 | IP Hash |
| 최고 성능 추구 (Nginx Plus) | Least Time |
실전 로드밸런싱 아키텍처 패턴
패턴 1: 단순 Active-Active
인터넷
│
[로드밸런서]
├── App Server 1
├── App Server 2
└── App Server 3
│
[데이터베이스]
가장 일반적인 패턴. 세션은 Redis 등 외부 저장소에서 공유.
패턴 2: 2계층 로드밸런싱
인터넷
│
[L4 LB: VIP]
├── [L7 LB (Nginx) 1]
└── [L7 LB (Nginx) 2]
│
[App 서버 그룹]
로드밸런서 자체도 이중화. 대규모 트래픽 처리 시 사용.
패턴 3: 서비스별 분리
인터넷
│
[L7 LB]
├── /api/* → API 서버 그룹
├── /static/* → CDN or 파일 서버
└── /admin/* → 관리자 서버 (IP 제한)
URL 경로에 따라 서로 다른 서버 그룹에 라우팅.
헬스체크의 중요성
로드밸런서는 주기적으로 백엔드 서버의 상태를 확인해 장애 서버를 자동으로 제외해야 합니다.
Passive Health Check (소극적 헬스체크)
실제 요청에 대한 응답을 모니터링해 오류가 일정 횟수 발생하면 서버를 제외합니다.
upstream backend {
server app1.example.com max_fails=3 fail_timeout=30s;
server app2.example.com max_fails=3 fail_timeout=30s;
}
Active Health Check (적극적 헬스체크)
주기적으로 전용 헬스체크 요청을 보내 서버 상태를 사전에 확인합니다. 장애를 더 빨리 감지할 수 있습니다. (Nginx Plus, HAProxy 지원)
정리
로드밸런싱은 현대 웹 인프라의 핵심 기술입니다. 이번 챕터의 학습 순서는 다음과 같습니다:
- Nginx 로드밸런싱 — 오픈소스 기반 가장 널리 쓰이는 방식
- Apache mod_proxy_balancer — Apache 환경에서의 로드밸런싱
- mod_jk 로드밸런싱 — AJP 프로토콜 기반 Tomcat 클러스터
- 헬스체크 — 장애 노드 자동 감지와 제거
다음 페이지에서는 Nginx upstream 설정으로 실제 로드밸런싱을 구성해봅니다.