로드 밸런싱
여러 서버에 네트워크 트래픽을 분산시켜 특정 서버에 부하가 집중되지 않도록 하는 기술입니다.
동작 흐름
→ 서버 A (처리 중)
클라이언트 → 로드밸런서 → 서버 B (여유 있음) ← 요청 전달
→ 서버 C (처리 중)
로드밸런싱 알고리즘
| 알고리즘 | 설명 |
|---|---|
| 라운드 로빈 | 서버에 순서대로 돌아가며 요청 분배 |
| 가중 라운드 로빈 | 서버 성능에 따라 가중치를 부여하여 분배 |
| 최소 연결(Least Connection) | 현재 연결 수가 가장 적은 서버에 분배 |
| IP 해시 | 클라이언트 IP를 해싱하여 항상 같은 서버로 분배 (세션 유지) |
| 최소 응답 시간 | 응답 시간이 가장 빠른 서버에 우선 분배 |
L4 vs L7 로드밸런싱
| 항목 | L4 (전송 계층) | L7 (응용 계층) |
|---|---|---|
| 기준 | IP, Port, TCP/UDP | HTTP 헤더, URL, 쿠키 |
| 속도 | 빠름 (패킷 단위 처리) | 상대적으로 느림 (콘텐츠 분석) |
| 기능 | 단순 분산 | URL 기반 라우팅, SSL 종료 등 |
| 예시 | AWS NLB, HAProxy(TCP) | AWS ALB, Nginx |
[L7 로드밸런싱 예시]
/api/* → API 서버 그룹
/images/* → 정적 파일 서버 그룹
/admin/* → 관리자 서버 그룹
헬스 체크
로드밸런서는 주기적으로 헬스체크를 수행하여 장애 서버를 자동으로 제외합니다.
upstream backend {
server 10.0.0.1:8080 max_fails=3 fail_timeout=30s;
server 10.0.0.2:8080 max_fails=3 fail_timeout=30s;
server 10.0.0.3:8080 backup; # 장애 시에만 사용
}
- Active 헬스 체크: 로드밸런서가 직접 서버에 요청을 보내 확인
- Passive 헬스 체크: 실제 트래픽의 응답 실패를 감지하여 판단
세션 유지(Sticky Session) 문제
상태를 가진 애플리케이션에서 같은 사용자가 매번 다른 서버로 연결되면 세션이 유지되지 않는 문제가 발생합니다.
| 해결 방법 | 설명 |
|---|---|
| Sticky Session | 쿠키/IP 기반으로 같은 서버에 연결 유지 |
| 세션 외부 저장 | Redis 등에 세션을 저장하여 어떤 서버든 접근 가능 |
| Stateless 설계 | JWT 등으로 서버가 상태를 갖지 않도록 설계 |