Load Balancer - 컴퓨터공학 > 컴퓨터 네트워크 | AI Insight Note

로드 밸런서(Load Balancer)는 들어오는 트래픽을 여러 서버에 분산하여 가용성(Availability)과 성능(Performance)을 높이는 네트워크 장비 또는 소프트웨어다. 단일 서버 장애 시에도 서비스를 지속하는 고가용성(HA, High Availability)의 핵심 구성 요소다.

기본 동작

클라이언트
    ↓ (가상 IP 또는 도메인)
[로드 밸런서]
   /    |    \
서버1  서버2  서버3

클라이언트는 로드 밸런서 하나의 주소만 알고 있다. 뒷단의 서버 구성은 클라이언트에게 보이지 않는다.

L4 vs L7 로드 밸런서

항목	L4 (전송 계층)	L7 (응용 계층)
기반 정보	IP + Port	URL, HTTP 헤더, 쿠키
라우팅 기준	네트워크 정보만	콘텐츠 내용까지
속도	빠름	상대적으로 느림
기능	단순 분산	URL 기반 라우팅, SSL 종료
예시	AWS NLB, HAProxy (L4 모드)	AWS ALB, Nginx, HAProxy (L7)

부하 분산 알고리즘

알고리즘	설명	적합 상황
라운드 로빈 (Round Robin)	순차적으로 서버에 분배	서버 사양이 동일한 경우
가중 라운드 로빈 (Weighted RR)	서버 가중치 비례 분배	서버 사양이 다른 경우
최소 연결 (Least Connection)	현재 연결이 가장 적은 서버로	요청 처리 시간이 다양한 경우
가중 최소 연결 (Weighted LC)	가중치 + 최소 연결	혼합 환경
해시 (Hash/IP Hash)	출발지 IP 해시로 항상 같은 서버로	세션 유지가 필요한 경우
최소 응답 시간	응답이 빠른 서버 우선	처리 속도 편차가 큰 경우
무작위 (Random)	랜덤 서버 선택	다중 LB 인스턴스 환경 (동기화 불필요)
Power of Two	2개 무작위 선택 후 연결 적은 쪽	서버 수가 많은 대규모 환경

일관된 해싱 (Consistent Hashing)

단순 IP 해시에서 서버를 추가/제거하면 거의 모든 키가 재배치된다. 이를 해결하는 기법.

•해시 링(Hash Ring)에 서버와 키를 배치
•서버 추가/제거 시 영향받는 키가 일부에 그침
•활용: 분산 캐시(Redis Cluster), 분산 DB(Cassandra), CDN 라우팅

글로벌 로드 밸런싱 (GSLB)

여러 지역의 데이터센터 중 사용자에게 가장 가까운 곳으로 라우팅.

방식	설명
DNS 기반	GeoDNS로 위치별 다른 IP 반환 (TTL 제한으로 즉각 페일오버 약함)
Anycast	같은 IP를 여러 데이터센터가 광고, 라우터가 가장 가까운 곳으로 자동 전달

Anycast 활용 예: Cloudflare, Google의 8.8.8.8 DNS — 전 세계 어디서 접속해도 가장 가까운 PoP로 자동 연결됨.

세션 지속성 (Session Persistence / Sticky Session)

상태(State)가 있는 서버(세션을 메모리에 저장하는 서버)에서는 같은 사용자가 항상 같은 서버로 연결되어야 한다.

•IP Hash: 출발지 IP 기반 고정
•Cookie 기반 Sticky: 쿠키에 서버 ID 포함
•한계: 해당 서버 장애 시 세션 손실 → 스테이트리스(Stateless) 아키텍처 또는 세션 외부 저장소(Redis)로 해결

헬스 체크 (Health Check)

로드 밸런서가 주기적으로 서버 상태를 확인한다.

방식:
- TCP 연결: 포트 열려있는지 확인
- HTTP: 특정 URL에 GET 요청 → 200 OK 확인
- 커스텀 스크립트: 애플리케이션 레벨 상태 확인

장애 서버는 트래픽 풀(Pool)에서 자동 제외 → 복구 후 자동 복귀.

헬스 체크: Active vs Passive

방식	설명	특징
능동(Active) 헬스 체크	LB가 주기적으로 /health 요청 전송	즉각적 감지, 부하 증가
수동(Passive) 헬스 체크	실제 트래픽의 응답을 관찰해 실패율로 판단	실사용 기반, "좀비 서버" 감지

HAProxy, Envoy는 두 방식을 함께 사용한다.

헬스 체크 설정 팁:

•검사 주기: 2~5초
•실패 임계값: 2~3회 연속 실패 시 제외 (순간적 지연으로 과도한 제외 방지)
•복귀 기준: 1~2회 연속 성공 시 복귀

Active-Active vs Active-Standby

구성	설명	장점
Active-Active	로드 밸런서 2대 모두 트래픽 처리	처리 용량 2배
Active-Standby	1대는 대기, 장애 시 전환 (Failover)	단순한 구성

주요 소프트웨어 로드 밸런서

이름	특징
Nginx	정적 파일 서빙 + 리버스 프록시 + L7 LB
HAProxy	고성능 TCP/HTTP LB, 대규모 트래픽에 최적
Envoy	서비스 메시(Istio)의 사이드카 프록시
AWS ALB/NLB	AWS 관리형 로드 밸런서

무중단 배포 활용

로드 밸런서를 이용한 롤링 배포(Rolling Deployment):

1. LB 풀에서 서버 1 제거
2. 서버 1에 새 버전 배포
3. 서버 1을 LB 풀에 다시 추가 (헬스 체크 통과 후)
4. 서버 2~N에 동일하게 반복

→ 사용자는 배포 중에도 서비스 중단 없이 이용 가능.

리버스 프록시 vs 로드 밸런서

항목	리버스 프록시	로드 밸런서
핵심 역할	백엔드를 대신해 요청 중계	트래픽 분산
백엔드 수	1대도 사용 가능	복수 서버에 의미 있음
부가 기능	SSL 종료, 캐싱, 압축, 헤더 조작	분산 알고리즘, 헬스체크
대표 도구	Nginx, HAProxy	Nginx, HAProxy, AWS ALB

실무에서는 Nginx, HAProxy 같은 도구 하나가 두 역할을 동시에 수행한다.

서킷 브레이커 (Circuit Breaker)

로드 밸런서와 함께 사용하는 장애 격리 패턴. 반복 실패 서버로의 요청을 자동 차단.

상태 전환:
CLOSED ──(실패 임계 초과)──> OPEN ──(타임아웃)──> HALF-OPEN
  ↑                                                      │
  └──────────(성공)──────────────────────────────────────┘

CLOSED: 정상 동작, 모든 요청 통과
OPEN: 차단 상태, 즉시 에러 반환 (원본 서버 보호)
HALF-OPEN: 소수 요청만 통과, 복구 여부 확인

활용: Envoy Proxy, Netflix Hystrix, Resilience4j

속도 제한 (Rate Limiting)

로드 밸런서 레벨에서 클라이언트별 요청 수를 제한해 과부하와 DDoS를 방어.

알고리즘	방식	특징
Fixed Window	N초마다 카운터 리셋	구현 단순, 경계 근처 버스트 허용
Sliding Window	이전 N초 요청 수를 실시간 추적	정확하지만 메모리 사용
Token Bucket	초당 토큰 보충, 토큰 소모로 요청 처리	버스트 허용 가능
Leaky Bucket	고정 속도로만 처리 (큐 오버플로우 드롭)	균일한 처리율 보장

nginx

# Nginx 속도 제한 예시
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
location /api/ {
    limit_req zone=api burst=20 nodelay;
}

Load Balancer로드 밸런서