Load Balancing

여러 백엔드에 트래픽을 분산하는 메커니즘. 어느 계층에서 분산하느냐(DNS / L4 / L7), VIP를 어떻게 띄우느냐(고정 IP / VRRP / BGP), 헬스체크·failover를 어디서 처리하느냐가 설계 축이다.

분류

DNS 레벨

도메인의 A 레코드에 여러 IP를 매핑해 클라이언트가 받아가는 IP를 분산시키는 방식. **DNS Round Robin (DNS RR)**이 대표적.

• 가장 원시적이고 외부 의존성 없음.
• 한계:
  • 헬스체크 부재: 노드 1대가 다운돼도 DNS는 그 IP를 계속 반환. 클라이언트가 죽은 IP를 받으면 그냥 실패.
  • DNS 캐싱으로 분산 비균등: TTL 동안 동일 클라이언트가 같은 IP에 묶임.
  • 동적 failover 불가: DNS 갱신이 TTL에 묶여 즉시성이 없음.
• 발전형: GSLB(Route 53 health check, NS1 등)는 DNS 응답을 동적으로 조정해 헬스체크·지역별 라우팅을 처리한다.

L4 (전송 계층)

IP/TCP/UDP 레벨에서 분산. 페이로드를 보지 않으므로 빠르고 프로토콜 중립적.

• VIP(Virtual IP) + Failover: 여러 노드가 하나의 IP를 공유하고, 액티브 노드가 죽으면 다른 노드가 인계.
  • Keepalived / VRRP: 전통적인 On-premise 패턴.
  • MetalLB Layer 2 / BGP 모드: On-premise K8s 환경에서 사실상 표준. BGP 모드는 라우터와 BGP 피어링하여 ECMP로 분산까지 처리.
  • kube-vip: 컨트롤 플레인 VIP·Service VIP 모두 처리. ARP 또는 BGP 기반.
• IPVS / LVS: Linux 커널 레벨 L4 LB. K8s kube-proxy의 ipvs 모드도 같은 기술.
• 클라우드 매니지드: AWS NLB, GCP Network LB, Azure LB. 헬스체크·자동 failover·고가용성을 매니지드로 제공.

L7 (응용 계층)

HTTP 헤더·경로·호스트 기반 라우팅. URL/path/Host/Header 룰로 백엔드 선택.

• 소프트웨어: NGINX, HAProxy, Envoy, Traefik.
• K8s: Ingress Controller, Gateway API 구현체(Envoy Gateway, Istio, NGINX Gateway Fabric, AGC 등).
• 클라우드 매니지드: AWS ALB, GCP HTTP(S) LB, Azure Application Gateway.

알고리즘

알고리즘	동작	비고
Round Robin	순서대로 백엔드 순환	가장 단순, 백엔드 동질 가정
Least Connections	현재 연결 수 가장 적은 백엔드	연결 시간 편차 클 때 유효
Source IP Hash	클라이언트 IP 해시 기반 고정	sticky session 효과
Weighted	가중치 비례 분산	백엔드 사양 차이 보정
Maglev / EH	일관성 해싱 기반 (Google)	노드 추가·삭제 시 재할당 최소화

핵심 고려사항

• 헬스체크: 모던 LB의 가장 중요한 기능. DNS RR이 가장 약함, 클라우드 LB가 가장 강함.
• 세션 유지(Sticky Session): 상태 있는 백엔드를 위한 클라이언트-백엔드 고정. cookie 기반(L7) 또는 source IP hash(L4).
• TLS 종단: L7 LB는 보통 TLS termination을 담당. 백엔드까지 TLS를 끌고 갈지(end-to-end) 결정 필요.
• PROXY protocol: L4 LB가 클라이언트 IP를 백엔드에 전달하는 표준. NGINX·HAProxy 모두 지원.

무중단 이관 (Zero-downtime Migration)

Docker Compose → K8s 같은 백엔드 인프라 이관 시 흔한 함정과 정답.

Backend: LB 백엔드 풀 가중치

DNS 가중치 라우팅(Route 53 weighted 등)만으로는 무중단이 불가능하다 — resolver·OS·JVM 캐시로 TTL이 무시되어 즉시 반영이 안 됨. DNS는 유입 비율 조절 도구이지 스위칭 도구가 아니다.

정답: 단일 LB 뒤에 구·신 백엔드 풀을 동시에 등록하고 LB 레벨에서 가중치 조절.

• ALB target group weighted routing (즉시 반영, 헬스체크·connection draining 자동)
• 더 정밀한 제어가 필요하면 Service Mesh(Istio) traffic split
• 데이터 레이어(DB·세션 store)는 양쪽이 같은 곳을 보도록 사전 정렬 필수

Frontend: Hash 기반 Cache Busting

브라우저·CDN 캐시 때문에 백엔드만 옮겨선 안 됨 — 클라이언트가 옛 번들을 들고 새 API를 호출하면 깨짐.

정답: 번들 파일명에 contenthash를 박아 새 버전을 새 파일로 만들고, HTML만 짧은 TTL/no-cache로 둔다.

• app.[contenthash].js — 내용 같으면 파일명 동일, CDN immutable 캐싱 적극 활용
• HTML은 매번 fresh fetch → 그 안의 새 hash 번들 참조
• SPA에 Service Worker가 있으면 새 SW 감지 시 사용자 새로고침 유도(skipWaiting + clients.claim) 별도 처리

경험 회고

SK hynix On-premise (2021~2024)

깡통 프록시 노드 3대를 두고, 도메인의 A 레코드를 3개 IP에 매핑하여 트래픽을 분산했다. 프록시 노드는 백엔드로 포워딩만 담당.

• 클라우드 LB도 K8s MetalLB/kube-vip도 없는 최소 구현이었다.
• 지금이라면: MetalLB BGP 또는 kube-vip로 VIP failover까지 자동화할 영역이다.