로드 밸런서 내부 완전 가이드 2025: L4/L7, IPVS, DSR, ECMP, Maglev — Google/Netflix/Cloudflare의 트래픽 분배 비밀

들어가며: 트래픽 분배의 진짜 복잡함

단순한 질문

"웹사이트 트래픽이 늘어서 서버 10대로 분산하고 싶어."

답: "로드 밸런서 쓰세요."

다음 질문:

• L4? L7?
• Nginx? HAProxy? Envoy?
• DNS 로드 밸런싱? Anycast?
• Health check는? Session persistence는?
• SSL termination은 어디서?
• DDoS 방어는?

단순한 문제가 아니다. Google, Netflix, Cloudflare 같은 회사들이 전담 팀을 두고 로드 밸런서를 연구하는 이유다.

규모의 문제

트래픽 스케일별 로드 밸런서 요구사항:

Cloudflare는 초당 수천만 요청을 처리한다. 이는 단일 서버에서 절대 불가능하다. 완전히 다른 아키텍처가 필요하다.

이 글에서 다룰 것

1. L4 vs L7: 근본 차이.
2. IPVS: Linux 커널의 LB.
3. DSR (Direct Server Return): 하드웨어급 효율.
4. ECMP + Consistent Hashing: 분산 LB의 기초.
5. Maglev: Google의 소프트웨어 LB.
6. HAProxy: L7의 성능왕.
7. Envoy: 현대 service mesh의 기반.
8. Anycast: 전 세계 트래픽 분산.
9. BPF/XDP: 최신 커널 기반 LB.
10. 실전 튜닝과 디버깅.

1. OSI 모델과 로드 밸런서 계층

로드 밸런서 계층

┌─────────────────────┐
│ L7 (Application)    │ ← HTTP, gRPC, WebSocket
├─────────────────────┤
│ L6 (Presentation)   │ ← TLS
├─────────────────────┤
│ L5 (Session)        │
├─────────────────────┤
│ L4 (Transport)      │ ← TCP, UDP
├─────────────────────┤
│ L3 (Network)        │ ← IP
├─────────────────────┤
│ L2 (Data Link)      │ ← Ethernet
├─────────────────────┤
│ L1 (Physical)       │
└─────────────────────┘

로드 밸런서는 L3, L4, L7 중 어느 층에서 결정하느냐에 따라 구분된다:

• L3: IP 주소 기반. DNS, Anycast.
• L4: IP + Port 기반. IPVS, HAProxy TCP 모드.
• L7: Application 내용 기반. Nginx, Envoy, HAProxy HTTP 모드.

L4 vs L7 핵심 차이

L4 (Transport Layer):

• TCP/UDP 연결 수준에서 분배.
• Payload 안 봄. 빠름.
• Stateful: 연결 table 유지.
• 예: source_ip:port → backend_ip:port 매핑.

L7 (Application Layer):

• HTTP, gRPC 등 애플리케이션 내용 해석.
• URL, header, cookie 기반 라우팅 가능.
• TLS termination 가능.
• 느리지만 유연.
• 예: /api/users → backend1, /api/orders → backend2.

성능 비교

대략적 수치 (최근 하드웨어):

L4 + L7 계층 구조

가장 흔한 패턴:

Internet
    ↓
┌──────────────┐
│ L4 LB (ECMP) │  ← 극도의 처리량
└──────────────┘
    ↓ ↓ ↓ ↓
┌────┐┌────┐┌────┐┌────┐
│ L7 ││ L7 ││ L7 ││ L7 │  ← HTTP 라우팅, TLS, WAF
└────┘└────┘└────┘└────┘
    ↓
  Backend Services

L4가 먼저 (빠른 분배), L7이 다음 (지능적 라우팅). Google, Facebook 같은 대기업이 쓰는 구조.

2. IPVS: Linux 커널의 L4 LB

IPVS란

IPVS (IP Virtual Server) 는 Linux 커널 모듈로, L4 로드 밸런싱을 구현한다. 1998년부터 개발. 커널 수준이라 극도로 빠르다.

주요 특징

• 커널 모듈: 시스템콜 오버헤드 없음.
• Netfilter 통합: iptables와 공존.
• 수십만 연결: 단일 서버에서.
• TCP, UDP, SCTP 지원.

기본 사용

# ipvsadm 도구로 설정
sudo ipvsadm -A -t 10.0.0.1:80 -s rr  # Virtual service, round robin
sudo ipvsadm -a -t 10.0.0.1:80 -r 10.0.1.1:80 -g  # 실제 서버 (DSR mode)
sudo ipvsadm -a -t 10.0.0.1:80 -r 10.0.1.2:80 -g
sudo ipvsadm -a -t 10.0.0.1:80 -r 10.0.1.3:80 -g

# 확인
sudo ipvsadm -L -n

세 가지 전달 모드

IPVS는 패킷을 backend로 전달하는 3가지 방식을 지원:

1. NAT (Network Address Translation):

Client → LB: dst=VIP
LB → Backend: dst=backend_ip (NAT)
Backend → LB: src=backend_ip
LB → Client: src=VIP (reverse NAT)

• 장점: 설정 쉬움.
• 단점: LB가 양방향 트래픽 처리. 병목.

2. IP Tunneling (IPIP):

Client → LB: dst=VIP
LB → Backend: IP-in-IP encapsulated
Backend → Client: 직접 (VIP로 src 변조)

• 장점: 응답이 LB 안 거침.
• 단점: Backend 서버가 IPIP 해석 가능해야.

3. Direct Routing (DR) - 일명 DSR:

Client → LB: dst=VIP (MAC: LB)
LB → Backend: 원래 packet 그대로, MAC만 backend로 변경
Backend → Client: 직접 (VIP로 src)

• 장점: 응답 트래픽이 LB 안 거침. 극도의 효율.
• 단점: Backend가 VIP를 loopback에 가져야. Same L2 network.

DSR (Direct Server Return)의 힘

DSR이 왜 대단한가?

일반 LB (요청과 응답 모두 LB 경유):

• 트래픽의 비대칭성: 요청은 작고(~1KB) 응답은 크다(~100KB+).
• LB는 응답까지 처리 → bottleneck.
• 10 Gbps LB가 1 Gbps 요청도 감당 못 할 수 있음.

DSR:

• LB는 요청만 처리.
• 응답은 backend가 직접 client에게.
• LB 대역폭 요구사항 90% 감소.

실전 효과: 100 Gbps 트래픽을 1 Gbps LB로 처리 가능 (요청만 10% = 10 Gbps, 근접한 한계).

Health Check

IPVS 단독으론 health check 없음. Keepalived 같은 도구와 조합:

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    virtual_ipaddress {
        10.0.0.1
    }
}

virtual_server 10.0.0.1 80 {
    delay_loop 10
    lb_algo rr
    lb_kind DR
    real_server 10.0.1.1 80 {
        HTTP_GET {
            url { path /health status_code 200 }
            connect_timeout 3
        }
    }
}

Keepalived가 주기적으로 health check 후 IPVS rule 갱신.

Scheduling 알고리즘

IPVS가 지원하는 LB 알고리즘:

• rr: Round robin.
• wrr: Weighted round robin.
• lc: Least connections.
• wlc: Weighted least connections.
• sh: Source hashing (같은 client → 같은 backend).
• dh: Destination hashing.
• sed: Shortest expected delay.
• nq: Never queue.

wrr과 wlc가 가장 흔히 쓰인다.

실전 사용

많은 Kubernetes 배포판이 IPVS를 Service의 백엔드로 쓴다:

kube-proxy mode: ipvs

기본 iptables 모드보다 훨씬 빠르며 확장 가능하다 (수만 service에서).

3. HAProxy: L4/L7의 성능왕

탄생

• 2000년: Willy Tarreau가 개발 시작.
• 현재: 인터넷의 핵심 인프라.
• 사용자: GitHub, Stack Overflow, Twitter, Instagram, Reddit...

HAProxy는 단일 이진 파일로 L4와 L7 모두를 제공. 엄청나게 빠르고 안정적.

아키텍처

이벤트 기반: Single-threaded event loop (최근 multi-process/thread):

• epoll/kqueue 기반 비동기 I/O.
• 수십만 동시 연결 가능.
• CPU 효율 극대화.

예시 설정:

frontend http-in
    bind *:80
    default_backend servers

backend servers
    balance roundrobin
    option httpchk GET /health
    server web1 10.0.0.1:80 check
    server web2 10.0.0.2:80 check
    server web3 10.0.0.3:80 check

성능 특성

HAProxy의 벤치마크는 놀랍다:

• 2M+ HTTP req/sec 단일 서버.
• 100 Gbps 처리 가능.
• 수백만 동시 TCP 연결.

Nginx가 웹서버 겸 LB라면, HAProxy는 순수 LB에 최적화. 더 빠른 경우가 많다.

Layer 7 라우팅

복잡한 HTTP 라우팅:

frontend http-in
    bind *:80
    
    # URL 기반
    acl api_request path_beg /api/
    acl admin_request path_beg /admin/
    
    # Header 기반
    acl mobile_client hdr(User-Agent) -i -m sub Mobile
    
    use_backend api_servers if api_request
    use_backend admin_servers if admin_request
    use_backend mobile_servers if mobile_client
    default_backend web_servers

SSL Termination

frontend https-in
    bind *:443 ssl crt /etc/haproxy/cert.pem
    default_backend http_servers

TLS 연결을 HAProxy가 종료하고, 내부 통신은 HTTP. CPU 집약적이지만 유연.

Stick Tables

Session persistence를 위한 메커니즘:

backend servers
    stick-table type ip size 1m expire 1h
    stick on src
    server web1 ... 
    server web2 ...

같은 client IP는 같은 backend로. Session sticky에 유용.

최신 기능: HTTP/3, gRPC

HAProxy는 계속 진화:

• HTTP/3 (QUIC): 최신 프로토콜 지원.
• gRPC: HTTP/2 기반 라우팅.
• Data plane API: 동적 설정.
• Runtime API: 무중단 설정 변경.

단점

• 설정 복잡: 강력하지만 학습 곡선 있음.
• GUI 부족: 상용 버전 있지만 비쌈.
• Service mesh 통합: Envoy보다 약함.

4. Nginx: 웹 서버 + LB

역사

• 2004: 러시아의 Igor Sysoev가 개발.
• C10K 문제: 만 개 동시 연결. Nginx가 해결.
• 현재: 인터넷 웹서버의 1/3.

아키텍처

• Master + Worker 프로세스: 각 worker가 event loop.
• 비동기 I/O: epoll 기반.
• 경량: 메모리 효율 탁월.

Load Balancer로서

upstream backend {
    least_conn;
    server web1.example.com weight=3;
    server web2.example.com;
    server web3.example.com;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
        proxy_next_upstream error timeout http_500;
    }
}

Nginx vs HAProxy

실전 선택:

• 웹서버 + 간단한 LB: Nginx.
• 순수 LB, 극한 성능: HAProxy.

5. ECMP + Maglev: Google의 답

문제: 단일 LB의 한계

한 대의 HAProxy가 100 Gbps를 처리한다면?

• 10 Tbps가 필요하면? 100대 필요.
• 그 100대를 어떻게 분산?
• 한 대가 죽으면?

해결: ECMP + Consistent Hashing.

ECMP (Equal-Cost Multi-Path Routing)

네트워크 라우터의 기능. 같은 목적지로 여러 경로가 있으면 트래픽을 분산:

Client → Router → [LB1, LB2, LB3, ..., LB100]
         ECMP로 분산

ECMP는 패킷의 5-tuple 해시 (src_ip, dst_ip, src_port, dst_port, protocol)로 LB를 선택. 같은 연결의 모든 패킷이 같은 LB로.

ECMP의 함정

문제: LB가 장애로 제거되면? Hash가 바뀌며 모든 연결이 재분배된다:

Before: hash(5-tuple) % 100 = LB_42
After (LB_42 죽음): hash(5-tuple) % 99 = LB_??

거의 모든 기존 연결이 다른 LB로 이동. 기존 연결 상태가 새 LB에 없어 모두 끊김.

Maglev: Google의 해결책

2016년 Google이 발표한 Maglev 는 이 문제를 해결한다. 핵심:

Maglev 해싱: Consistent hashing의 개선판.

• Lookup table 기반: 미리 계산된 테이블.
• 균등 분포: 거의 완벽한 load 분산.
• 최소 변경: 노드 제거 시 소수의 연결만 재배치.
• O(1) 조회: 매우 빠름.

Maglev Hash 테이블 구축

1. 각 backend 서버에 permutation (순열) 생성.
2. 큰 테이블 (예: 65537 크기, 소수).
3. Round-robin으로 각 서버가 테이블 슬롯을 채움.
4. 최종: 각 슬롯에 배정된 서버 목록.

Lookup: hash(5-tuple) % 65537 → 서버

서버가 죽으면 그 서버의 슬롯만 재분배. 전체 재구성 아님.

Maglev 클러스터

Google의 Maglev는 수십~수백 대로 구성된다:

Router (ECMP) → Maglev Cluster (L4)
                 ↓
              Backend Servers

ECMP가 Maglev 클러스터에 분산. Maglev는 개별 연결을 backend로 라우팅. 합쳐서 수 Tbps 처리 가능.

Maglev의 공개 구현

Katran (Facebook): XDP/eBPF 기반 L4 LB. Maglev 아이디어 적용. Envoy: L7 라우팅에 Maglev 해시 옵션 제공. Cilium: Kubernetes에서 Maglev 스타일 LB.

6. XDP / eBPF: 커널의 새 힘

전통 커널 LB의 한계

IPVS는 빠르지만 여전히 커널 네트워크 스택을 거친다:

• Netfilter hook.
• Socket buffer (sk_buff).
• Routing table lookup.

오버헤드가 있다. 10-40 Gbps가 실전 한계.

XDP (eXpress Data Path)

Linux 4.8+에서 도입. NIC 드라이버 수준에서 패킷 처리:

NIC → NIC Driver → XDP program → (decision)
                                  ├── XDP_PASS (커널 스택)
                                  ├── XDP_DROP (버림)
                                  ├── XDP_TX (되돌려 보냄)
                                  └── XDP_REDIRECT (다른 곳)

XDP program은 eBPF (extended Berkeley Packet Filter)로 작성. 커널 스택보다 먼저 실행됨.

성능

XDP의 벤치마크:

• DDoS 차단: 200 Gbps급.
• Load balancing: 100 Gbps+ 단일 NIC.
• CPU 효율: IPVS 대비 10배.

Katran: Facebook의 XDP LB

Facebook의 Katran은 XDP 기반 오픈소스 L4 LB:

• Maglev hashing 구현.
• 수십 Gbps 단일 서버에서.
• DDoS 방어 내장.

Facebook 전체 트래픽의 상당 부분이 Katran 위에서 돌아간다.

Cilium: Kubernetes의 새 표준

Cilium은 eBPF 기반 CNI + LB:

• Kubernetes Service를 eBPF로 구현.
• Network policy.
• Service mesh (Envoy 대체 가능).
• kube-proxy를 완전히 대체 가능.

Cilium을 쓰면 IPVS보다 10배 빠르고, 관찰성이 크게 향상된다. 2024년 이후 CNCF graduated.

7. Envoy: 현대 L7의 표준

탄생

• 2016: Lyft가 내부 service mesh용으로 개발.
• 오픈소스: 즉시 큰 호응.
• CNCF graduated: 최상위 프로젝트.

왜 Envoy인가

기존 L7 LB (Nginx, HAProxy)의 한계:

1. 동적 설정 약함: 재로드 필요.
2. 관찰성 제한적: 메트릭, 트레이싱 약함.
3. Service mesh 비친화적: 정적 설정.

Envoy는 이를 해결:

• Dynamic configuration (xDS): 런타임에 설정 변경.
• 강력한 관찰성: 상세한 메트릭, 트레이싱, 로깅.
• HTTP/2, gRPC, HTTP/3 네이티브.
• Sidecar 패턴: 각 서비스 옆에 배치.

xDS API

Envoy의 핵심 혁신. xDS (x Discovery Service) 는 동적 설정 API:

• LDS: Listener Discovery Service.
• RDS: Route Discovery Service.
• CDS: Cluster Discovery Service.
• EDS: Endpoint Discovery Service.

Control plane (예: Istio)이 xDS로 설정을 push하면 Envoy가 무중단으로 적용.

기본 설정

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 80
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: ingress_http
          route_config:
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match: { prefix: "/" }
                route: { cluster: service_backend }
          http_filters:
          - name: envoy.filters.http.router

  clusters:
  - name: service_backend
    connect_timeout: 5s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: service_backend
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: backend.example.com
                port_value: 80

복잡하지만 극도로 강력.

LB Policies

Envoy는 다양한 LB 알고리즘 지원:

• ROUND_ROBIN: 단순.
• LEAST_REQUEST: 최소 연결.
• RING_HASH: 일관된 해시.
• MAGLEV: Google Maglev 스타일.
• RANDOM: 무작위.

Outlier Detection

Envoy는 자동 이상 감지:

outlier_detection:
  consecutive_5xx: 5
  interval: 10s
  base_ejection_time: 30s
  max_ejection_percent: 50

5번 연속 5xx → 30초간 해당 backend 제외. 자동 ejection.

Circuit Breaker

circuit_breakers:
  thresholds:
  - max_connections: 1000
    max_pending_requests: 100
    max_requests: 1000
    max_retries: 3

과부하 시 새 요청 거부. 연쇄 실패 방지.

Service Mesh

Envoy의 주 용도: service mesh. Istio, Linkerd 2, Consul Connect가 모두 Envoy를 데이터 플레인으로 사용.

• 각 마이크로서비스 옆에 Envoy sidecar.
• 모든 트래픽이 sidecar 통과.
• 자동 mTLS, 관찰성, 정책.

8. DNS 기반 로드 밸런싱

가장 단순한 LB

DNS가 여러 IP를 반환:

$ dig example.com
;; ANSWER SECTION:
example.com.  60  IN  A  10.0.0.1
example.com.  60  IN  A  10.0.0.2
example.com.  60  IN  A  10.0.0.3

Client가 무작위로 하나를 선택. 많은 클라이언트 → 자동 분산.

Round-Robin DNS

DNS 서버가 요청마다 순서를 바꿔서 반환. 자동 분산.

장점

• 매우 단순.
• 무료.
• 글로벌 가능 (GeoDNS).

단점

1. Caching: DNS TTL 동안 캐싱. 서버가 죽어도 계속 그 IP 사용.
2. 불균등: 캐시 때문에 일부 클라이언트가 특정 IP에 쏠림.
3. Health check 없음: DNS는 서버 상태 모름.
4. 세밀한 제어 불가.

GeoDNS (Geographic DNS)

Cloudflare, Route 53 같은 서비스가 제공:

• Client의 위치 감지.
• 가장 가까운 서버의 IP 반환.
• 글로벌 분산에 효과적.

한계: 여전히 DNS의 문제들 (caching, no health check). 그래서 L4/L7 LB와 조합해서 사용.

9. Anycast: 하나의 IP, 여러 장소

Anycast란

같은 IP를 여러 장소에서 알린다. BGP 라우팅이 가장 가까운 곳으로 라우팅:

IP: 1.1.1.1 (Cloudflare DNS)

Advertised from:
- US East (Virginia)
- US West (California)
- Europe (London)
- Asia (Tokyo)
- 전 세계 100+ POP

Client in Japan → Tokyo POP
Client in UK → London POP

효과:

• 짧은 지연: 항상 가까운 서버.
• 분산: 자동.
• 내결함성: 한 POP 다운 → BGP가 다른 곳으로.

사용 사례

• DNS: Cloudflare 1.1.1.1, Google 8.8.8.8.
• CDN: Akamai, Cloudflare 전반.
• DDoS 방어: 공격이 여러 POP에 분산.

한계

• TCP 연결 문제: 중간에 경로가 바뀌면 연결 끊김.
• BGP 지식 필요: 설정 복잡.
• 비용: BGP peering 필요.

그래서 UDP 기반 서비스 (DNS, QUIC) 가 Anycast에 더 적합.

10. Cloudflare / Netflix / Google의 아키텍처

Cloudflare

전 세계 300+ POP. 각 POP가:

• Anycast BGP: 가장 가까운 사용자에게 라우팅.
• Katran (XDP) 또는 자체 LB: L4.
• Nginx: L7 (현재는 자체 Rust 기반 Pingora로 교체 중).
• Workers: edge computing.

매일 25+ TB/s 트래픽 처리. 모든 POP가 전 세계 트래픽을 감당.

Netflix

CDN 중심:

• Open Connect Appliance (OCA): ISP 내부에 배치.
• DNS + Anycast: 가장 가까운 OCA 선택.
• FreeBSD + sendfile + KTLS: 앞서 설명한 zero-copy.
• 단일 서버 200 Gbps 달성.

Netflix 트래픽이 전체 인터넷의 상당 비율을 차지할 때도 있다.

Google

여러 레이어:

1. Frontend: Maglev 클러스터.
2. GFE (Google Front End): L7 LB + TLS termination.
3. Backend: 각 서비스의 fleet.

Google Cloud Load Balancer도 내부적으로 Maglev 사용. 글로벌 LB 제공.

11. 실전 구성 가이드

시나리오 1: 소규모 웹사이트

트래픽: < 1 Gbps, < 10K req/s. 추천: Nginx 단독.

upstream app {
    server app1:8080;
    server app2:8080;
}

server {
    listen 80;
    location / {
        proxy_pass http://app;
    }
}

단순. 저렴. 충분.

시나리오 2: 중규모 서비스

트래픽: 110 Gbps, 10K100K req/s. 추천: HAProxy + Nginx (또는 HAProxy 단독).

Internet → HAProxy (SSL termination) → Nginx (static) + App servers

시나리오 3: Kubernetes 클러스터

추천: Cilium 또는 MetalLB + Ingress (Nginx, Traefik, Envoy).

External LB → MetalLB (L2/BGP) → Ingress Controller → Service

Cloud (AWS EKS, GCP GKE)라면 Cloud LB + Ingress.

시나리오 4: 대규모 글로벌 서비스

트래픽: 100 Gbps+, 전 세계. 추천: Anycast + ECMP + Maglev + L7 mesh.

Anycast DNS → BGP Anycast → L4 LB (Maglev) → L7 (Envoy) → Services

Cloudflare, Google Cloud Load Balancer 같은 관리형 서비스 고려.

시나리오 5: 고성능 전문가 환경

트래픽: DDoS 방어, 수백 Gbps. 추천: Katran + XDP + eBPF.

직접 구축하거나 Cloudflare Magic Transit 같은 서비스 사용.

12. 실전 문제와 해결

문제 1: Session 유지 안 됨

증상: 사용자가 로그인했는데 다음 요청에서 다른 서버로 가 로그아웃됨.

원인: LB가 round-robin으로 분산. 세션이 특정 서버 메모리에만 있음.

해결:

1. Sticky session: 쿠키 또는 source IP로.
2. Shared session store: Redis, Memcached.
3. JWT: 서버 상태 없는 인증.

문제 2: Thundering Herd

증상: 한 서버가 재시작되면 다른 서버들이 한꺼번에 많은 요청 받음.

원인: Health check 복구 시 즉시 100% 트래픽.

해결:

1. Slow start: 복구 후 점진적 트래픽 증가.
2. Warm-up: 사전 예열.

문제 3: TLS 재협상 과부하

증상: HTTPS 트래픽 CPU 사용률 급증.

원인: 매 연결마다 새 TLS 핸드셰이크.

해결:

1. Session resumption: TLS ticket.
2. HTTP/2: 하나의 연결로 여러 요청.
3. SSL offloading: LB에서 TLS 종료.
4. HW acceleration: AES-NI, QAT.

문제 4: Long-lived connections

증상: WebSocket, gRPC 장기 연결이 재배포 시 문제.

원인: 연결이 오래 유지되어 새 인스턴스로 안 옮겨감.

해결:

1. Graceful drain: 주기적으로 연결 종료 요청.
2. Connection limit: 시간 제한.
3. 재연결 로직: 클라이언트가 재시도.

문제 5: Client IP 잃어버림

증상: Backend 로그에 LB의 IP만 보임.

원인: LB가 NAT 모드로 동작.

해결:

1. X-Forwarded-For header: L7 LB가 client IP 추가.
2. PROXY protocol: L4에서도 IP 전달.
3. DSR mode: LB가 NAT 안 함.

문제 6: Health check 오탐

증상: 실제로는 건강한데 LB가 unhealthy로 판단.

원인: Health check endpoint 설정 오류.

해결:

1. 적절한 경로: /health 만들기.
2. 충분한 timeout: DB 체크 포함 가능하게.
3. Threshold: 3번 연속 실패 후 unhealthy.
4. Shallow vs deep check: 경로에 따라.

퀴즈로 복습하기

Internet
   ↓
L4 LB (Maglev, IPVS) — 수십 Gbps 처리, ECMP 스프레드
   ↓ ↓ ↓
L7 LB (Envoy, HAProxy) — HTTP 라우팅, TLS, 관찰성
   ↓
Backend Services

HTTP/gRPC 트래픽? → L7
TCP만 되고 payload 안 봐? → L4
둘 다? → L4 + L7 체인

Client (1 KB request) 
    ↓
LB (NAT): src=client, dst=VIP → src=LB, dst=backend
    ↓
Backend
    ↓ (200 KB response)
LB (NAT): src=backend, dst=LB → src=VIP, dst=client
    ↓
Client

Client (1 KB request)
    ↓
LB: dst=VIP에 도착. NAT 안 함. 원래 패킷 그대로, MAC만 backend로 변경.
    ↓
Backend (VIP를 loopback에 가짐)
    ↓ (200 KB response 직접)
Client

ip addr add 10.0.0.1/32 dev lo

echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce

LB: packet을 IP-in-IP로 encapsulate (outer: backend, inner: 원래)
Backend: decapsulate, 원래 packet 처리
Backend: response 직접 client에게

class ConsistentHash:
    def __init__(self, nodes, vnodes=100):
        self.ring = SortedDict()
        for node in nodes:
            for i in range(vnodes):
                h = hash(f"{node}-{i}")
                self.ring[h] = node
    
    def get(self, key):
        h = hash(key)
        idx = self.ring.bisect_right(h) % len(self.ring)
        return self.ring.peekitem(idx)[1]

def build_maglev(nodes, table_size=65537):
    perms = [generate_permutation(node, table_size) for node in nodes]
    table = [None] * table_size
    next_idx = [0] * len(nodes)
    
    filled = 0
    while filled < table_size:
        for i, node in enumerate(nodes):
            while table[perms[i][next_idx[i]]] is not None:
                next_idx[i] += 1
            table[perms[i][next_idx[i]]] = node
            next_idx[i] += 1
            filled += 1
            if filled == table_size:
                break
    return table

def lookup(table, key):
    return table[hash(key) % len(table)]

NIC가 패킷 받음
    ↓
DMA로 메모리(sk_buff 할당)
    ↓
Interrupt 발생 → NAPI polling
    ↓
Driver가 sk_buff 초기화
    ↓
Netfilter PREROUTING hook (iptables, nftables)
    ↓
Routing decision (라우팅 테이블)
    ↓
Netfilter INPUT/FORWARD hook
    ↓
(L4 LB: IPVS가 여기서 개입)
    ↓
Routing
    ↓
Netfilter POSTROUTING hook
    ↓
Driver → NIC transmit

NIC가 패킷 받음
    ↓
DMA로 메모리
    ↓
Driver가 RX ring buffer에서 raw packet
    ↓
★ XDP program 실행 (eBPF) ★
    ↓
결정:
- XDP_DROP: 즉시 버림 (DDoS 방어에 최적)
- XDP_PASS: 일반 스택으로 (보통 경로)
- XDP_TX: 같은 NIC으로 되돌려 보냄
- XDP_REDIRECT: 다른 NIC 또는 AF_XDP 소켓

SEC("xdp_lb")
int xdp_load_balance(struct xdp_md *ctx) {
    void *data_end = (void*)(long)ctx->data_end;
    void *data = (void*)(long)ctx->data;
    
    struct ethhdr *eth = data;
    if (eth + 1 > data_end)
        return XDP_PASS;
    
    struct iphdr *ip = (void*)(eth + 1);
    if (ip + 1 > data_end)
        return XDP_PASS;
    
    // 간단한 해시 기반 LB
    __u32 backend_idx = ip->saddr % NR_BACKENDS;
    struct backend_info *backend = bpf_map_lookup_elem(&backends, &backend_idx);
    if (!backend)
        return XDP_DROP;
    
    // DSR: dst MAC을 backend로 변경
    __builtin_memcpy(eth->h_dest, backend->mac, ETH_ALEN);
    
    return XDP_TX;  // 같은 NIC으로 전송
}

upstream backend {
    server 10.0.0.1:80;
    server 10.0.0.2:80;
}

Control Plane (예: Istio Pilot)
       ↑ gRPC (xDS API)
       ↓
┌──────────────┐
│ Envoy Proxy  │
└──────────────┘

마이크로서비스 아키텍처:
┌──────────┐     ┌──────────┐     ┌──────────┐
│ Service A│────→│ Service B│────→│ Service C│
└──────────┘     └──────────┘     └──────────┘

Service Mesh (각 서비스 옆에 Envoy sidecar):
┌──────────┐     ┌──────────┐     ┌──────────┐
│ A + Envoy│────→│ B + Envoy│────→│ C + Envoy│
└──────────┘     └──────────┘     └──────────┘
         Control Plane (Istio/Linkerd)

Istio Control Plane:
├── Pilot: 설정 xDS API 제공
├── Citadel: 인증서 관리
├── Galley: 설정 검증
└── Mixer: 정책 적용 (deprecated)

Data Plane:
└── Envoy sidecar (각 pod마다)

마치며: 트래픽을 다스리는 기술

핵심 정리

1. L4 vs L7: 속도 vs 유연성. 실전에선 둘 다.
2. IPVS: Linux 커널 L4 LB. DR 모드로 DSR.
3. DSR: 응답을 LB 우회 → 극도의 효율.
4. Maglev: 균등 분포 + O(1) + 최소 변경.
5. ECMP + Maglev: 분산 LB 확장.
6. XDP/eBPF: IPVS의 10배. 커널의 새 힘.
7. HAProxy: L7 성능왕.
8. Nginx: 웹서버 + LB.
9. Envoy + xDS: Service mesh 기반.
10. Anycast: 전 세계 분산.

실전 체크리스트

새 시스템 시작 시:

• 예상 트래픽량 파악.
• L4 / L7 / 둘 다 결정.
• Health check endpoint 구현.
• Session 관리 전략 (sticky, shared, JWT).
• SSL termination 위치.
• DDoS 방어.
• 관찰성 (메트릭, 로그, 트레이싱).
• Graceful shutdown.
• 재배포 전략.

도구 선택 매트릭스

마지막 교훈

로드 밸런서는 인터넷의 침묵의 영웅이다. 잘 동작할 때는 존재를 잊지만, 없으면 하루도 못 간다. 수십 년간의 엔지니어링이 축적된 이 기술은 지금도 진화한다:

• 90년대: 하드웨어 LB.
• 2000년대: 소프트웨어 LB (Nginx, HAProxy).
• 2010년대: 분산 LB (Maglev, ECMP).
• 2020년대: eBPF + Service Mesh.

각 시대가 이전을 보존하면서 새 층을 더한다. 오늘날 Google의 LB 스택은 BGP부터 XDP까지 모든 레이어를 활용한다.

당신이 웹사이트를 방문할 때, 요청은 최소 5-10개의 로드 밸런서를 거친다:

1. DNS 서버 → Anycast.
2. ISP에서 CDN 선택.
3. CDN의 edge LB (L4).
4. CDN의 L7 proxy.
5. Origin server의 LB.
6. Kubernetes Ingress.
7. Service Mesh sidecar.
8. 최종 서비스.

이 모든 레이어가 조화를 이루어 밀리초 안에 응답을 돌려준다. 이것이 현대 인터넷 인프라의 기적이며, 이 글에서 본 모든 기술의 종합이다.

참고 자료

• Maglev: A Fast and Reliable Software Network Load Balancer (Google, 2016)
• Katran: Facebook's L4 LB
• Envoy Proxy Documentation
• HAProxy Documentation
• Linux Virtual Server (LVS/IPVS)
• XDP Tutorial
• Cilium eBPF Load Balancing
• Cloudflare Load Balancing Architecture
• Netflix Open Connect
• Google Cloud Load Balancer Architecture
• Istio Service Mesh
• The Scalable Commutativity Rule (MIT, Maglev related)