[Network] Load Balancer: L4 vs L7, 알고리즘, sticky session

Load Balancer, L4 LB, L7 LB, round-robin, least connections, consistent hashing, health check, sticky session

정의

Load Balancer 는 트래픽을 여러 백엔드로 분산 하는 인프라. 수평 확장 + 가용성 + 무중단 배포 의 토대.

L4 vs L7

구분	L4 (Transport)	L7 (Application)
본 계층	TCP/UDP	HTTP/gRPC/WebSocket
보는 정보	IP + port	URL, 헤더, 쿠키, body
처리 비용	가벼움	무거움 (parse)
기능	단순 분산	path/header routing, rewrite, auth, rate limit
TLS 종료	옵션 (passthrough 가능)	보통 종료 후 분배
예	AWS NLB, HAProxy TCP, IPVS	AWS ALB, nginx, Envoy, Traefik

flowchart LR
    subgraph L4
        C1[Client] -->|TCP| LB4[L4 LB]
        LB4 -->|TCP forward| B1[Backend 1]
        LB4 -->|TCP forward| B2[Backend 2]
    end
    subgraph L7
        C2[Client] -->|HTTP| LB7[L7 LB]
        LB7 -->|URL = /api| BA[API service]
        LB7 -->|URL = /static| BS[Static service]
    end

알고리즘

알고리즘	동작
Round Robin	순서대로
Weighted RR	가중치 비율
Least Connections	현재 연결 가장 적은 백엔드
Least Response Time	평균 응답 시간 가장 짧은
IP Hash	클라이언트 IP 해시 → 같은 IP 는 같은 백엔드
Consistent Hashing	hash 링 → 노드 추가/제거 시 최소 재분배
Random (P2C)	무작위 2개 중 덜 바쁜

Power of Two Choices (P2C)

flowchart LR
    R[Request] -->|random pick 2| P[Pool of N]
    P --> S1[Server A: load=5]
    P --> S2[Server B: load=8]
    P -->|선택| S1

Consistent Hashing

노드 추가/제거 시 N/M 만 재분배 (vs 일반 hash 의 전체 재분배).

flowchart LR
    Ring(("Hash Ring<br/>0 → 2^32")) --> N1[Node A<br/>at hash 100]
    Ring --> N2[Node B<br/>at hash 500]
    Ring --> N3[Node C<br/>at hash 900]
    Key1[key: hash 300] -->|시계방향| N2
    Key2[key: hash 700] -->|시계방향| N3

• Sticky session, cache 라우팅, DB sharding.
• virtual node (각 노드를 수십 개 ring 점) 로 분포 균등화.

Health Check

sequenceDiagram
    loop 30초마다
        LB->>Backend: GET /health
        Backend-->>LB: 200 OK
    end
    Note over Backend: 다운
    LB->>Backend: GET /health
    Backend-xLB: timeout
    Note over LB: 3회 연속 실패 → 풀에서 제외

• Active: LB 가 주기 ping.
• Passive: 실제 요청 실패율로 판단.
• Composite: 둘 다.

Sticky Session

방식	동작	단점
Cookie	LB 가 쿠키 박음	쿠키 위변조 / 제거 시 깨짐
IP Hash	클라이언트 IP 기준	NAT 뒤 사용자가 같은 노드 몰림
Application	앱이 자기 ID 응답 헤더로	구현 복잡

자세한 건 Sticky Session 참고.

보안 / 옵저버빌리티

L7 LB 의 추가 능력:

• TLS termination (인증서 관리)
• WAF (SQLi, XSS 차단)
• Rate limiting
• Request/response 로깅
• Header rewrite, redirect
• Path-based routing
• A/B testing, canary

실전 LB 선택

도구	L4/L7	사용처
AWS ALB	L7	AWS 표준 L7
AWS NLB	L4	초저지연, gRPC, WebSocket
AWS CLB	L4/L7	(legacy)
nginx	L7 (L4 옵션)	self-host 가장 흔함
HAProxy	L4/L7	고성능
Envoy	L7	service mesh, gRPC
Traefik	L7	K8s 친화
IPVS	L4	커널 모듈, 극저지연
Caddy	L7	자동 TLS

흔한 함정

Connection Draining (드레이닝)

배포/유지보수 시 서버를 안전하게 풀에서 제거하는 과정.

sequenceDiagram
    participant LB as Load Balancer
    participant Old as Old Server
    participant New as New Server
    LB->>Old: 새 연결 중단 신호
    LB->>New: 새 연결 전달
    Old-->>LB: 진행 중 요청 처리 완료 대기
    Old-->>LB: 완전 종료
    Note over LB,Old: grace period 30-60s 내 완료

• AWS ALB: deregistration delay (default 300s, 조정 가능)
• Kubernetes: terminationGracePeriodSeconds + readiness probe 제거
• 드레이닝 없이 즉시 종료 = 진행 중 요청 손실.

Blue-Green 배포 / Canary 배포

LB 는 무중단 배포의 핵심 인프라.

flowchart LR
    LB[Load Balancer]
    Blue["Blue v1.0<br/>기존 버전"]
    Green["Green v1.1<br/>신 버전"]
    LB -->|"100% → 0%"| Blue
    LB -->|"0% → 100%"| Green

전략	설명	롤백 속도
Blue-Green	동시 운영, 트래픽 전환	즉시
Canary	소수 % 부터 점진 증가	비율 감소
Rolling	순차 교체 (구/신 혼재)	느림
Shadow	복제 트래픽, 결과 비교	없음

DSR (Direct Server Return)

트래픽 반환 경로를 LB 를 거치지 않고 서버에서 클라이언트로 직접 전달.

flowchart LR
    Client -->|"요청 via LB"| LB["L4 LB"]
    LB -->|"포워딩 (DIP to RIP)"| Server
    Server -->|"응답 직접 반환"| Client

• 응답 트래픽 (보통 요청 대비 10x 이상) 이 LB 를 우회 → LB 처리량 병목 해소.
• 주로 L4 LB (IPVS, HAProxy) 에서 구현.
• 서버가 VIP (Virtual IP) 를 loopback 에 설정해야 함.

Global LB vs Regional LB

구분	Global LB	Regional LB
역할	DNS 기반 지역 선택	지역 내 서버 분산
지연 최적화	GeoDNS + anycast	지역 내 최적
예	AWS Route 53, Cloudflare	AWS ALB, nginx
페일오버 단위	지역 전체 이전	서버 단위

flowchart TD
    User[글로벌 사용자]
    User --> DNS["GeoDNS / Anycast"]
    DNS --> RegionA["Region A (서울) ALB"]
    DNS --> RegionB["Region B (도쿄) ALB"]
    RegionA --> SA1[Server A1]
    RegionA --> SA2[Server A2]
    RegionB --> SB1[Server B1]

클라이언트 사이드 LB

인프라 LB 대신 클라이언트가 서버 목록을 직접 관리하여 선택.

구분	서버 사이드 LB	클라이언트 사이드 LB
예	AWS ALB, nginx	gRPC, Ribbon (Netflix)
장점	투명, 단순	레이턴시 1 hop 감소
단점	중앙 병목 가능	클라이언트 복잡도
서버 목록	LB 가 관리	서비스 레지스트리 (Consul, etcd)

실전 LB 설정 패턴

상황	권장 설정
WebSocket	idle timeout 조정 (>60s), proxy_read_timeout 증가
gRPC	HTTP/2 지원 LB, keepalive 설정
Auto-scaling	Connection Draining 활성화, Health check 간격 단축
무중단 배포	Blue-Green 또는 Canary + draining
세션 유지 필요	Sticky session (단, Redis 세션 스토어 권장)
초저지연	DSR 고려 (L4), IPVS

관련 위키

• Sticky Session
• HTTP/2 (long-lived 연결과 LB)
• Redis Pub Sub vs Streams (분산 fan-out)
• Kubernetes Service (K8s LB)
• AWS ALB NLB