도입
처음에는 로드 밸런서를 “트래픽을 여러 서버에 나누는 장비” 정도로 이해하기 쉽습니다. 방향은 맞지만, 실무에서는 그 설명만으로는 부족합니다.
로드 밸런서는 단순 분산 장치가 아니라, 헬스 체크, 백엔드 풀 관리, 알고리즘 선택, L4/L7 라우팅, 세션 선호도, TLS 종료 같은 역할을 함께 맡는 경우가 많습니다. 그래서 로드 밸런서를 이해한다는 것은 트래픽 분산만이 아니라, 서비스 진입점에서 장애와 확장을 어떻게 통제할지를 이해하는 일에 가깝습니다.
필요성
서버를 여러 대 두는 것만으로는 고가용성이 자동으로 생기지 않습니다. 사용자 요청이 여전히 특정 서버로만 몰리거나, 죽은 서버로 계속 전달되면 서비스는 쉽게 장애를 일으킵니다.
로드 밸런서는 이 문제를 줄이는 진입점입니다. 요청을 여러 백엔드로 나누고, 건강하지 않은 대상을 풀에서 빼고, 경우에 따라 특정 URL은 A 그룹으로, 다른 URL은 B 그룹으로 보내는 식의 규칙도 적용할 수 있습니다. 그래서 로드 밸런서는 확장성뿐 아니라 장애 회피 장치로도 중요합니다.
- 같은 서비스를 여러 서버가 동시에 처리해야 할 때
- 서버 일부가 죽어도 트래픽을 우회해야 할 때
- HTTP 경로, 호스트명, 포트 기준으로 라우팅을 나눠야 할 때
- 상태 저장 앱에서 세션 선호도(sticky session)가 필요할 때
- 쿠버네티스나 클라우드 환경에서 진입점을 표준화해야 할 때
정의
로드 밸런서는 보통 클라이언트가 가장 먼저 만나는 서버 측 네트워크 진입점입니다. 외부에서는 하나의 주소처럼 보이지만, 내부적으로는 여러 서버에 요청을 나눠 보냅니다.
중요한 점은 단순히 분산만 하는 것이 아니라는 점입니다. 실제 제품들은 종종 health check, TLS 종료, 라우팅 규칙, 세션 선호도, 접근 로그, WAF 연계 같은 기능까지 함께 제공합니다. 그래서 로드 밸런서는 “분산 장치”이면서 동시에 “트래픽 제어 계층”입니다.
핵심 원리
단순 round robin만 있으면 로드 밸런서가 아닙니다. 실제 운영에서는 어떤 백엔드가 응답 가능한지, 어떤 서버가 이미 바쁜지, 어떤 요청은 특정 그룹으로 보내야 하는지를 계속 판단해야 합니다.
즉, 로드 밸런서는 “여러 서버가 있다”는 사실을 전제로 하지만, 실제로는 건강한 대상 선택, 분산 정책, 규칙 기반 라우팅이라는 세 축으로 동작합니다. 여기서 health check가 약하면 죽은 서버로 계속 보내고, 알고리즘이 서비스 특성과 맞지 않으면 특정 노드에 과부하가 집중됩니다.
기본 구조
| 구성 요소 | 역할 | 실무 포인트 |
|---|---|---|
| Listener | 어떤 프로토콜/포트 요청을 받을지 정의 | HTTP, HTTPS, TCP, UDP 등 진입 규칙의 시작점 |
| Backend / Target Group | 실제 요청을 처리할 서버 묶음 | 인스턴스, 컨테이너, IP 단위로 구성 가능 |
| Health Check | 백엔드 상태를 주기적으로 확인 | 죽은 서버를 빨리 빼고, 살아난 서버를 다시 넣는 기준 |
| Routing Rule | 요청을 어떤 백엔드로 보낼지 결정 | L7에서는 host/path/header 단위 규칙도 가능 |
| Session Affinity | 같은 클라이언트를 같은 서버로 보내는 옵션 | 상태 저장 앱에서 유용하지만 만능은 아님 |
| Logs / Metrics | 요청과 응답 흐름을 기록 | 장애 분석과 튜닝의 핵심 자료 |
기본 흐름
클라이언트 요청
↓
로드 밸런서
├─ 헬스 체크 결과 확인
├─ 라우팅 규칙 평가
└─ 분산 알고리즘 적용
↓
건강한 백엔드 서버 중 하나로 전달패턴 1. L4 와 L7 로드 밸런싱
L4 로드 밸런서는 주로 IP 주소, 포트, 프로토콜(TCP/UDP) 수준에서 동작합니다. 즉, 애플리케이션 메시지의 의미를 깊게 보지 않고 연결이나 패킷 수준에서 트래픽을 분산합니다.
반면 L7 로드 밸런서는 HTTP 같은 애플리케이션 프로토콜을 이해합니다. 그래서 URL 경로, Host 헤더, 요청 속성 등을 바탕으로 /api는 A 그룹으로, /static은 B 그룹으로 보내는 식의 더 세밀한 라우팅이 가능합니다. TLS 종료, 웹 방화벽, 쿠키 기반 세션 선호도도 L7 장치에서 자주 같이 보입니다.
| 구분 | L4 로드 밸런서 | L7 로드 밸런서 |
|---|---|---|
| 기준 | IP, 포트, TCP/UDP 연결 | HTTP/HTTPS 요청 의미 |
| 장점 | 빠르고 단순하며 범용적 | 경로/호스트 기반 라우팅 등 정교한 제어 가능 |
| 대표 기능 | TCP/UDP 분산, 포트 단위 서비스 노출 | Path 기반 라우팅, Host 기반 라우팅, TLS 종료 |
| 적합한 경우 | DB, 게임, TCP 서비스, 일반 네트워크 분산 | 웹 애플리케이션, API 게이트웨이 성격의 트래픽 |
패턴 2. 헬스 체크와 분산 알고리즘
헬스 체크는 로드 밸런서의 가장 중요한 기본기입니다. health check가 없거나 너무 부정확하면, 로드 밸런서는 장애 난 서버에도 계속 요청을 보낼 수 있습니다.
알고리즘도 중요합니다. 가장 흔한 것은 Round Robin이지만, 연결 수가 불균형하면 Least Connections가 더 나을 수 있고, 같은 클라이언트를 같은 서버로 보내야 하면 IP Hash / Generic Hash 계열이 유리할 수 있습니다.
| 알고리즘 | 설명 | 언제 적합한가 |
|---|---|---|
| Round Robin | 백엔드에 순서대로 요청 분산 | 비교적 단순하고 서버 성능이 비슷할 때 |
| Least Connections | 현재 연결 수가 적은 서버 우선 | 연결 길이가 들쭉날쭉하고 편차가 클 때 |
| IP Hash / Generic Hash | 특정 키를 기준으로 같은 서버에 매핑 | 세션 선호도나 캐시 지역성이 필요할 때 |
- 로드 밸런서가 주기적으로 백엔드 상태를 확인한다.
- 비정상 서버는 풀에서 제외한다.
- 남은 healthy 대상 중 알고리즘으로 다음 서버를 선택한다.
- 장애가 회복되면 다시 풀에 편입한다.
패턴 3. 세션 선호도와 상태 저장 애플리케이션
일반적인 웹/API 서버는 가능하면 무상태(stateless)로 만드는 편이 좋습니다. 그래야 어느 서버로 보내도 같은 처리가 가능하고, 로드 밸런서도 자유롭게 분산할 수 있기 때문입니다.
하지만 일부 애플리케이션은 특정 서버의 메모리에 세션 변수나 로컬 캐시를 들고 있습니다. 이런 경우에는 같은 클라이언트 요청을 계속 같은 백엔드로 보내는 session affinity 또는 sticky session이 필요할 수 있습니다. 다만 이는 확장성과 장애 회복을 약하게 만들 수 있으므로, 가능하면 세션 저장소를 외부화해 서버를 무상태에 가깝게 만드는 쪽이 더 좋습니다.
쿠버네티스에서의 로드 밸런싱
쿠버네티스에서는 Service가 여러 Pod를 하나의 논리적 endpoint 뒤로 묶어 줍니다. 그래서 클러스터 내부에서는 Service IP 하나만 보면 되고, 실제 요청은 그 뒤의 여러 Pod로 자동 분산됩니다.
외부 노출이 필요하면 type: LoadBalancer Service를 통해 클라우드 외부 로드 밸런서를 만들 수도 있고, HTTP 계층 규칙이 필요하면 Ingress를 통해 host/path 기반 라우팅을 구성할 수 있습니다. 즉, 쿠버네티스에서 로드 밸런싱은 “하나의 장비”보다 네트워크 추상화와 컨트롤러의 조합에 가깝습니다.
apiVersion: v1
kind: Service
metadata:
name: web
spec:
type: LoadBalancer
selector:
app: web
ports:
- port: 80
targetPort: 8080로드 밸런서와 클러스터 차이
두 개념은 자주 함께 등장하지만 같은 말은 아닙니다. 로드 밸런서는 주로 입구에서 요청을 분배하는 역할을 하고, 클러스터는 뒤에서 여러 노드가 하나의 시스템처럼 동작하게 만드는 구조입니다.
즉, 로드 밸런서가 있다고 해서 자동으로 클러스터가 되는 것도 아니고, 클러스터가 있다고 해서 반드시 외부 로드 밸런서가 필요한 것도 아닙니다. 하지만 웹/API 서비스에서는 두 개념이 매우 자주 결합됩니다.
| 구분 | 로드 밸런서 | 클러스터 |
|---|---|---|
| 중심 역할 | 요청 분산과 진입 제어 | 여러 노드의 협력과 상태 유지 |
| 관심사 | 헬스 체크, 알고리즘, 라우팅 규칙 | 페일오버, 쿼럼, 동기화, 오케스트레이션 |
| 위치 | 서비스 앞단 | 서비스 내부 또는 백엔드 구조 |
한계와 주의점
로드 밸런서가 있어도 백엔드가 모두 같은 병목을 공유하면 결국 전체 서비스는 느려집니다. 예를 들어 앱 서버는 여러 대로 늘렸지만 데이터베이스가 단일 병목이면, 앞단 분산만으로는 큰 효과를 보기 어렵습니다.
또한 상태 저장 애플리케이션에 sticky session만 걸고 문제를 끝냈다고 생각하면 위험합니다. 특정 서버에 세션이 몰리고, 해당 서버가 죽었을 때 사용자 상태가 같이 날아갈 수 있기 때문입니다. 결국 로드 밸런서는 강력한 도구이지만, 애플리케이션 상태 모델과 저장소 구조까지 함께 맞아야 진짜 효과가 납니다.
- 로드 밸런서는 진입 계층이지 전체 병목 해결기가 아님
- 헬스 체크가 부정확하면 오히려 장애를 확대할 수 있음
- sticky session은 상태 저장 앱을 단기적으로만 편하게 만들 수 있음
- L7 기능이 많아질수록 설정 복잡도와 운영 책임도 커짐
자주 하는 실수
- 로드 밸런서 = round robin 정도로만 생각함
- 헬스 체크 없이 분산만 하면 된다고 착각함
- L4와 L7의 차이를 무시한 채 제품을 고름
- 상태 저장 앱에 sticky session만 걸고 구조 문제를 해결했다고 생각함
- 로드 밸런서와 클러스터를 같은 개념으로 봄
- 쿠버네티스 Service, Ingress, 외부 LoadBalancer의 역할을 섞어 봄
- 로그와 메트릭 없이 장애를 감으로만 분석함
실무 루틴
- 먼저 트래픽이 L4 중심인지 L7 규칙이 필요한지 구분한다.
- 백엔드가 무상태인지 상태 저장형인지 확인한다.
- 헬스 체크 기준을 애플리케이션 특성에 맞게 정한다.
- 알고리즘을 round robin, least connections, hash 계열 중 서비스 특성에 맞게 고른다.
- 세션 선호도가 정말 필요한지, 아니면 세션 외부화가 가능한지 판단한다.
- 접근 로그, 에러 로그, 헬스 상태, 백엔드 메트릭을 함께 수집한다.
- 마지막으로야 제품과 배포 위치를 정한다.
디버깅
로드 밸런서 장애를 볼 때 먼저 나눌 질문
- 백엔드가 정말 unhealthy 인가?
- health check 기준이 잘못된 것은 아닌가?
- L4/L7 계층 선택이 문제인가?
- 알고리즘이 서비스 특성과 맞는가?
- session affinity 때문에 특정 서버에 쏠리고 있지 않은가?
- 로드 밸런서 앞단 문제인가, 뒤쪽 앱/DB 문제인가?요약
- ✅ 로드 밸런서는 여러 백엔드 대상으로 요청을 분산하는 진입 계층이다.
- ✅ 핵심은 분산 자체보다 healthy target만 고르고 적절히 라우팅하는 데 있다.
- ✅ L4는 IP/포트/전송 계층 중심, L7은 HTTP 의미 중심 제어에 가깝다.
- ✅ 대표 알고리즘은 Round Robin, Least Connections, Hash 계열이다.
- ✅ session affinity는 상태 저장 앱에 유용하지만 장기 해법은 아닐 수 있다.
- ✅ 쿠버네티스에서는 Service와 Ingress가 로드 밸런싱 추상화의 핵심이다.
- ✅ 로드 밸런서와 클러스터는 자주 함께 쓰이지만 같은 개념은 아니다.
- ✅ 좋은 로드 밸런서는 “고르게 나누는 장치”가 아니라 “서비스 입구를 통제하는 장치”다.