로드 밸런싱: L4/L7부터 eBPF, 서비스 메시까지

개요

로드 밸런싱(Load Balancing)은 들어오는 네트워크 트래픽을 여러 서버에 균등하게 분산하여 시스템의 가용성, 성능, 확장성을 확보하는 핵심 기술이다. 단일 서버의 한계를 넘어 수평적 확장(Horizontal Scaling)을 가능하게 하는 기반 기술이며, 모든 상용 서비스의 아키텍처에 필수적이다.

2026년 현재, eBPF 기반 로드 밸런싱(Cilium)은 iptables 대비 10배 이상의 지연 시간 및 처리량 개선을 제공하며, 서비스 메시(Service Mesh)를 통한 애플리케이션 수준의 트래픽 관리가 표준화되고 있다.

L4 vs L7 로드 밸런싱

L4 로드 밸런서 (전송 계층, Transport Layer)

TCP/UDP 수준에서 IP 주소와 포트 번호만을 기반으로 트래픽을 분산한다.

클라이언트 → [L4 LB] → 서버 A (IP:Port 기반 라우팅)
                     → 서버 B
                     → 서버 C

특징:

• 패킷 헤더만 검사 → 매우 빠른 처리 속도
• 요청 내용(HTTP 헤더, URL 등)을 알 수 없음
• NAT(Network Address Translation) 기반 동작
• TLS 종료(TLS Termination) 불가 (L4에서는 암호화된 내용 판독 불가)

대표 구현:

• AWS NLB (Network Load Balancer)
• HAProxy (TCP 모드)
• IPVS (Linux Virtual Server)
• Cilium (eBPF 기반)

L7 로드 밸런서 (애플리케이션 계층, Application Layer)

HTTP/HTTPS 수준에서 요청 내용(URL, 헤더, 쿠키 등)을 분석하여 트래픽을 분산한다.

클라이언트 → [L7 LB] → /api/users → 서버 A (User Service)
                     → /api/orders → 서버 B (Order Service)
                     → /static/*   → CDN

특징:

• 요청 내용에 기반한 세밀한 라우팅 가능
• TLS 종료, 압축, 캐싱, 인증 등 부가 기능 수행
• L4보다 느리지만 더 지능적인 분산
• WebSocket, gRPC 등 프로토콜별 처리 가능

대표 구현:

• AWS ALB (Application Load Balancer)
• NGINX
• HAProxy (HTTP 모드)
• Envoy Proxy
• Traefik

L4 vs L7 비교

로드 밸런싱 알고리즘

1. 라운드 로빈 (Round Robin)

요청을 서버 목록에 순차적으로 분배한다.

요청 1 → 서버 A
요청 2 → 서버 B
요청 3 → 서버 C
요청 4 → 서버 A (순환)

• 장점: 구현이 단순, 균등한 분배
• 단점: 서버 성능 차이를 고려하지 않음

2. 가중 라운드 로빈 (Weighted Round Robin)

서버별 **가중치(Weight)**를 부여하여 성능이 높은 서버에 더 많은 요청을 배분한다.

서버 A (Weight: 3): 요청 1, 2, 3
서버 B (Weight: 2): 요청 4, 5
서버 C (Weight: 1): 요청 6

3. 최소 연결 (Least Connections)

현재 활성 연결 수가 가장 적은 서버에 요청을 보낸다.

• 장점: 서버 부하를 실시간으로 반영
• 단점: 느린 서버에 연결이 쌓이는 문제 가능

4. IP 해시 (IP Hash)

클라이언트 IP를 해시하여 동일 클라이언트는 항상 같은 서버로 라우팅한다.

• 장점: 세션 지속성(Session Persistence) 보장
• 단점: 서버 추가/제거 시 리밸런싱 문제

5. 일관된 해싱 (Consistent Hashing)

해시 링(Hash Ring)을 사용하여 서버 추가/제거 시 최소한의 키만 재배치되도록 한다.

          서버 A
         /      \
      키1         키2
      /             \
  서버 D ── 해시 링 ── 서버 B
      \             /
      키4         키3
         \      /
          서버 C
 
서버 B 제거 시: 키2, 키3만 서버 C로 이동 (나머지는 영향 없음)

가상 노드(Virtual Node): 실제 서버 하나가 해시 링 위에 여러 가상 노드로 매핑되어 더 균등한 분배를 달성한다.

헬스 체크와 서킷 브레이커 (Health Checks and Circuit Breaking)

헬스 체크 (Health Checks)

로드 밸런서가 백엔드 서버의 상태를 주기적으로 확인하여, 비정상 서버로 트래픽을 보내지 않도록 한다.

건강한 헬스 체크 엔드포인트:

// /health 또는 /healthz
app.get('/health', async (req, res) => {
  const checks = {
    database: await checkDatabase(),
    redis: await checkRedis(),
    externalApi: await checkExternalApi(),
  };
 
  const isHealthy = Object.values(checks).every(c => c.status === 'up');
 
  res.status(isHealthy ? 200 : 503).json({
    status: isHealthy ? 'healthy' : 'unhealthy',
    checks,
    timestamp: new Date().toISOString(),
  });
});

서킷 브레이커 (Circuit Breaker)

장애가 발생한 서비스에 대한 호출을 일시적으로 차단하여 연쇄 장애(Cascading Failure)를 방지한다.

         Closed (정상)
         ↓ (실패 임계치 초과)
         Open (차단)
         ↓ (타임아웃 후)
         Half-Open (시험)
         ↓ (성공) → Closed
         ↓ (실패) → Open

서비스 메시 (Service Mesh)

개념

마이크로서비스 간의 네트워크 통신을 인프라 레벨에서 관리하는 전용 레이어이다. 로드 밸런싱, 서비스 디스커버리, 트래픽 관리, 보안(mTLS), 관측 가능성을 애플리케이션 코드 변경 없이 제공한다.

┌──────────────────────┐     ┌──────────────────────┐
│ Service A            │     │ Service B            │
│ ┌─────────────────┐  │     │ ┌─────────────────┐  │
│ │ App Container   │  │     │ │ App Container   │  │
│ └────────┬────────┘  │     │ └────────┬────────┘  │
│ ┌────────▼────────┐  │     │ ┌────────▼────────┐  │
│ │ Sidecar Proxy   │◄─┼─────┼─▶ Sidecar Proxy   │  │
│ │ (Envoy)         │  │     │ │ (Envoy)         │  │
│ └─────────────────┘  │     │ └─────────────────┘  │
└──────────────────────┘     └──────────────────────┘
           │                            │
           └───────── Control Plane ────┘
                    (Istio / Linkerd)

주요 서비스 메시 비교

Envoy Proxy

CNCF 졸업 프로젝트로, 대부분의 서비스 메시에서 데이터 플레인으로 사용되는 고성능 프록시이다.

주요 기능:

• L3/L4 필터: TCP 프록시, Rate Limiting
• L7 필터: HTTP 라우팅, gRPC, WebSocket
• 서비스 디스커버리: xDS API
• 로드 밸런싱: Round Robin, Least Request, Ring Hash
• 관측 가능성: 분산 트레이싱, 메트릭, 액세스 로그

eBPF 기반 로드 밸런싱 (2026 트렌드)

개념

**eBPF(extended Berkeley Packet Filter)**를 활용하여 Linux 커널에서 직접 로드 밸런싱을 수행한다. 기존의 iptables나 사이드카 프록시를 대체하여 극적인 성능 향상을 달성한다.

Cilium의 로드 밸런싱

Cilium은 kube-proxy를 eBPF로 대체하여 Kubernetes 서비스의 로드 밸런싱을 수행한다.

기능:

• North-South LB: 외부 트래픽 → 클러스터 내부, XDP 활용
• East-West LB: 클러스터 내부 서비스 간 통신
• Direct Server Return (DSR): 응답 패킷이 로드 밸런서를 우회하여 직접 클라이언트로 전송
• Maglev Consistent Hashing: Google Maglev 논문 기반 일관된 해싱
• L7 로드 밸런싱: Envoy와 통합하여 TPROXY를 통해 L7 라우팅

외부 트래픽 → [LoadBalancer IP]
                    ↓
            Cilium eBPF (커널 레벨)
                    ↓
            TPROXY → Envoy (L7 규칙)
                    ↓
            Backend Pods

성능 비교:

Global Server Load Balancing (GSLB)

개념

지리적으로 분산된 데이터센터 간에 트래픽을 분배하는 기술이다. DNS 기반으로 동작하며, 사용자를 가장 가까운 또는 가장 건강한 데이터센터로 라우팅한다.

사용자 (한국) → DNS 쿼리 → GSLB
                             ├── 서울 DC (지연 시간: 5ms)   ✓ 선택
                             ├── 도쿄 DC (지연 시간: 30ms)
                             └── 미국 DC (지연 시간: 150ms)

라우팅 정책:

• 지리적 근접성 (Geo-proximity): 가장 가까운 데이터센터
• 지연 시간 기반 (Latency-based): 가장 빠른 응답의 데이터센터
• 가중치 기반 (Weighted): 데이터센터별 트래픽 비율 지정
• 장애 조치 (Failover): 주 데이터센터 장애 시 대체 데이터센터로 전환

도구:

• AWS Route 53: 글로벌 DNS 기반 GSLB
• Cloudflare Load Balancing: 에지 네트워크 기반
• F5 BIG-IP DNS: 엔터프라이즈 GSLB
• NS1: 지능형 DNS 트래픽 관리

오토스케일링과 로드 밸런싱 통합

Kubernetes HPA (Horizontal Pod Autoscaler)

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: payment-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: payment-service
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "100"

스케일링 전략

WebSocket 로드 밸런싱

WebSocket은 **장기 연결(Long-lived Connection)**이므로 일반적인 HTTP 로드 밸런싱과 다른 고려가 필요하다.

과제

1. 세션 어피니티: 동일 클라이언트가 항상 같은 서버에 연결되어야 함
2. 연결 드레이닝: 서버 제거 시 기존 WebSocket 연결을 안전하게 종료
3. 불균등 분배: 장기 연결로 인해 새 서버가 연결을 받지 못하는 문제

해결 방안

• 스티키 세션 (Sticky Session): IP Hash 또는 쿠키 기반 어피니티
• Redis Pub/Sub: 서버 간 메시지 브로드캐스트로 세션 무관 동작
• 연결 재분배: 주기적으로 클라이언트 재연결 유도

클라이언트 ─── WebSocket ─── 서버 A
              │
              ├── Redis Pub/Sub ─── 서버 B
              │                      ↑
              └── 다른 클라이언트 ── WebSocket

CDN과 엣지 로드 밸런싱

CDN (Content Delivery Network)

전 세계에 분산된 **엣지 서버(Edge Server)**를 통해 정적/동적 콘텐츠를 사용자에게 가까운 위치에서 제공한다.

엣지 컴퓨팅 통합 (2026):

• Cloudflare Workers: V8 엔진 기반 서버리스 컴퓨팅
• AWS CloudFront Functions: 엣지에서의 경량 함수 실행
• Vercel Edge Functions: Next.js 통합 엣지 컴퓨팅

엣지에서 로드 밸런싱, 인증, 캐싱, A/B 테스트까지 수행하여 오리진 서버 부하를 최소화한다.

참고 자료

• Designing Data-Intensive Applications - Martin Kleppmann (Chapter 6)
• Envoy Proxy Documentation: https://www.envoyproxy.io/docs
• Cilium Documentation: https://docs.cilium.io
• NGINX Load Balancing Guide: https://docs.nginx.com/nginx/admin-guide/load-balancer