단일 서버로 모든 요청을 받으면 트래픽이 몰릴 때 병목이 생기고, 서버가 죽으면 서비스 전체가 중단된다. Load Balancer는 여러 서버에 요청을 분산해 부하를 나누고, 특정 서버가 장애를 겪어도 서비스를 유지하는 고가용성(High Availability) 구조를 만든다.
Client
|
v
[Load Balancer]
| | |
v v v
[Server1][Server2][Server3]
Round Robin은 요청을 서버 목록에 순서대로 돌아가며 배분한다. 구현이 단순하고 서버 스펙이 동일할 때 효과적이다. 스펙 차이가 있으면 Weighted Round Robin으로 가중치를 부여해 처리 능력이 높은 서버에 더 많은 요청을 보낸다.
Least Connections는 현재 활성 연결 수가 가장 적은 서버에 요청을 보낸다. 요청마다 처리 시간 편차가 클 때 Round Robin보다 균형을 더 잘 맞춘다.
| 알고리즘 | 특징 | 적합한 상황 |
|---|---|---|
| Round Robin | 순서대로 분배 | 동일 스펙 서버, 짧은 요청 |
| Weighted Round Robin | 가중치 기반 분배 | 스펙이 다른 서버 혼용 |
| Least Connections | 연결 수 기준 분배 | 처리 시간 편차가 큰 요청 |
| IP Hash | 클라이언트 IP 해시 | Sticky Session 필요 시 |
L4 Load Balancer는 OSI 4계층(Transport)에서 동작한다. TCP/UDP 패킷의 IP 주소와 포트만 보고 라우팅하므로 속도가 빠르고 애플리케이션 프로토콜에 무관하게 작동한다.
L7 Load Balancer는 OSI 7계층(Application)에서 동작한다. HTTP 헤더, URL 경로, 쿠키 등 요청 내용을 파싱해 라우팅 규칙을 적용할 수 있다.
L4: IP + Port 기반 라우팅 / L7: HTTP URL, Header, Cookie 기반 라우팅
L7 Load Balancer 라우팅 예시
/api/* → [API Server]
/static/* → [CDN / Static Server]
/admin/* → [Admin Server]
L7은 콘텐츠 기반 라우팅, SSL Termination, 요청 리라이팅이 가능하지만 패킷을 파싱하는 오버헤드가 있다. Nginx, HAProxy, AWS ALB가 대표적인 L7 Load Balancer다.
Load Balancer는 Health Check를 통해 서버 상태를 주기적으로 확인한다. 서버가 응답하지 않거나 지정한 HTTP 상태 코드가 아닌 응답을 반환하면 해당 서버를 풀에서 제거하고, 복구되면 다시 추가한다.
Load Balancer
|
|-- GET /health --> [Server1] 200 OK → 정상, 트래픽 유지
|-- GET /health --> [Server2] 503 → 비정상, 풀에서 제거
|-- GET /health --> [Server3] timeout → 비정상, 풀에서 제거
Health Check 설정 예시 (Nginx):
upstream backend {
server server1:8080;
server server2:8080;
server server3:8080;
keepalive 32;
}
server {
location /health {
return 200 "ok";
}
}
Sticky Session은 동일 클라이언트의 요청을 항상 같은 서버로 보내는 방식이다. 서버 메모리에 세션을 저장하는 구조에서 필요하지만, 특정 서버에 부하가 쏠리고 해당 서버 장애 시 세션이 소실된다.
Sticky Session의 대안: Redis 등 외부 세션 저장소를 사용해 서버 간 세션을 공유하면 Sticky Session 의존을 없앨 수 있다.
세션을 외부 저장소(Redis 등)로 분리하면 어느 서버가 요청을 받아도 동일한 세션 데이터를 조회할 수 있어 Load Balancer 알고리즘 선택의 자유도가 높아진다.