Load Balancing

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

분류

DNS 레벨

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

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

L4 (전송 계층)

IP와 Port를 기준으로 TCP/UDP 연결을 분산. 응용 계층의 Payload를 해석하지 않으므로 빠르고 프로토콜 중립적.

• VIP(Virtual IP) + Failover: 여러 노드가 하나의 IP를 공유하고, 액티브 노드가 죽으면 다른 노드가 인계.
  • Keepalived / VRRP: 전통적인 On-premise 패턴.
  • MetalLB: Bare-metal K8s의 대표 구현. Layer 2 모드는 한 노드가 VIP를 광고하고 장애 시 다른 노드가 인계한다. BGP 모드는 여러 노드가 동등한 경로를 광고하고, Multipath를 지원하는 라우터가 ECMP로 연결을 분산한다.
  • kube-vip: 컨트롤 플레인 VIP·Service VIP 모두 처리. ARP 또는 BGP 기반.
• IPVS / LVS: Linux 커널 레벨 L4 LB. K8s kube-proxy의 IPVS 모드는 1.35부터 Deprecated되었으며, 기존 환경을 식별하고 문제를 조사할 정도로만 알아두면 됨. 대체재인 nftables 모드는 1.33부터 GA이며, 1.37에서도 기본값은 아직 iptables지만 향후 변경에 대비해 모드를 명시하지 않으면 경고함.
• 클라우드 매니지드: 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	가중치 비례 분산	백엔드 사양 차이 보정
Consistent Hash / Maglev	요청 키를 기준으로 백엔드 고정	노드 추가·삭제 시 재할당 최소화

핵심 고려사항

• 헬스체크: 비정상 백엔드를 분산 대상에서 제외하거나 failover하는 기준. 단순 DNS RR에는 없지만 GSLB나 Load Balancer가 별도로 제공할 수 있음.
• 세션 유지(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처럼 인프라와 Application을 이관할 때의 기본 패턴.

Backend: DNS와 LB의 전환 정밀도

DNS 가중치 라우팅(Route 53 weighted 등)으로도 구·신 환경을 함께 유지하며 무중단 이관할 수 있다. 다만 Resolver·OS·Runtime Cache 때문에 설정한 Weight가 실제 유입 비율에 정확히 반영되지 않고, 모든 Client의 전환 시점도 통제할 수 없다. DNS는 느슨한 점진적 이관에는 쓸 수 있지만 즉시 스위칭과 Rollback에는 적합하지 않다.

정밀한 전환이 필요하면 단일 LB 뒤에 구·신 백엔드 풀을 동시에 등록하고 LB 레벨에서 가중치를 조절한다.

• Weight 변경은 운영자나 배포 Pipeline이 설정 또는 API로 명시적으로 수행하며, LB가 시간에 따라 자동으로 이관하지는 않음
• ALB는 Target Group 내부의 개별 Target을 자동으로 Health Check하고, 등록 해제된 Target의 Connection을 Draining
• 한 Weighted Target Group 전체가 비정상이 되어도 다른 Group으로 Weight를 자동 이전하지 않으므로 별도 감시와 Rollback이 필요
• 더 정밀한 제어가 필요하면 Service Mesh(Istio) traffic split
• DB·Session Store는 구·신 버전이 함께 동작하도록 호환성을 먼저 확보

Frontend: Hash 기반 Cache Busting

Frontend와 API를 함께 변경하면 브라우저·CDN에 남은 이전 Bundle이 새 API를 호출할 수 있으므로, API 하위 호환성과 Cache 갱신을 함께 설계해야 한다.

기본 패턴은 번들 파일명에 contenthash를 박아 새 버전을 새 파일로 만들고, HTML만 짧은 TTL/no-cache로 두는 것이다.

• app.[contenthash].js — 내용 같으면 파일명 동일, CDN immutable 캐싱 적극 활용
• HTML은 매번 fresh fetch → 그 안의 새 hash 번들 참조
• SPA에 Service Worker가 있으면 별도의 갱신 정책이 필요. skipWaiting과 clients.claim은 새 Worker를 즉시 활성화하므로 기존 Page와의 호환성 또는 새로고침 흐름을 함께 설계

경험 회고

SK hynix On-premise (2021~2024)

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

• 클라우드 LB도 K8s MetalLB/kube-vip도 없는 최소 구현이었다.
• 지금이라면: 네트워크 환경에 따라 MetalLB 또는 kube-vip로 VIP Failover를 자동화할 영역이다.

참고 자료

• Virtual IPs and Service Proxies | Kubernetes
• MetalLB Layer 2 Mode
• MetalLB BGP Mode
• Action Types for ALB Listener Rules | AWS