로드 밸런싱

L4/L7부터 eBPF, 서비스 메시까지 부하 분산의 계층·알고리즘·운영 패턴을 정리합니다.

개요

로드 밸런싱(Load Balancing)은 들어오는 네트워크 트래픽을 여러 서버에 균등하게 분산하여 시스템의 가용성, 성능, 확장성을 확보하는 기술입니다. 단일 서버의 한계를 넘어 수평적 확장(Horizontal Scaling)을 가능하게 하며, 대규모 트래픽을 받는 서비스에서 널리 쓰입니다.

Cilium의 eBPF(extended Berkeley Packet Filter) 로드 밸런싱은 iptables의 선형 탐색을 해시 조회로 바꿉니다. 서비스 수가 많으면 규칙 탐색 비용의 차이가 커질 수 있습니다. 애플리케이션 수준의 트래픽 관리는 서비스 메시(Service Mesh)로 다루는 사례가 늘고 있습니다.

L4 vs L7 로드 밸런싱

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

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

특징:

패킷 헤더만 검사 → 매우 빠른 처리 속도
요청 내용(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, 헤더, 쿠키 등)을 분석하여 트래픽을 분산합니다.

특징:

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

대표 구현:

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

L4 vs L7 비교

항목	L4	L7
OSI 계층	전송 계층 (TCP/UDP)	애플리케이션 계층 (HTTP)
판단 기준	IP, Port	URL, Header, Cookie, Body
성능	매우 높음	상대적으로 낮음
TLS 종료	불가	가능
콘텐츠 기반 라우팅	불가	가능
WebSocket 지원	기본	완전 지원
비용	낮음	높음
사용 사례	고성능 TCP 서비스	웹 API, 마이크로서비스

로드 밸런싱 알고리즘

1. 라운드 로빈 (Round Robin)

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

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

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

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

서버	Weight	배분된 요청
서버 A	3	요청 1, 2, 3
서버 B	2	요청 4, 5
서버 C	1	요청 6

3. 최소 연결 (Least Connections)

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

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

4. IP 해시 (IP Hash)

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

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

5. 일관된 해싱 (Consistent Hashing)

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

해시 링 위에 서버 A·B·C·D와 키1~키4가 시계 방향으로 배치됩니다. 서버 B 제거 시 키2, 키3만 서버 C로 이동하고 나머지 키는 영향받지 않습니다.

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

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

헬스 체크 (Health Checks)

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

유형	방법	예시
Active	로드 밸런서가 주기적으로 프로브 전송	`/health` 엔드포인트 호출
Passive	실제 요청의 응답을 모니터링	연속 5xx 에러 감지

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

typescript

// /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(),
  });
});

checks는 데이터베이스·Redis·외부 API의 의존성 상태를 모은 객체입니다. 하나라도 up이 아니면 isHealthy가 false가 되어 503을 반환하므로, 로드 밸런서는 의존성 장애를 겪는 인스턴스를 트래픽에서 빼냅니다.

서킷 브레이커 (Circuit Breaker)

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

상태	동작
Closed	정상 요청 전달, 실패 횟수 추적
Open	모든 요청 즉시 실패 반환 (서비스 보호)
Half-Open	제한된 요청만 통과시켜 복구 여부 확인

서비스 메시 (Service Mesh)

개념

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

주요 서비스 메시 비교

서비스 메시	데이터 플레인	특징
Istio	Envoy	기능이 풍부, 복잡도 높음, Google 지원
Linkerd	linkerd2-proxy (Rust)	경량, 단순, CNCF 졸업
Cilium	eBPF (사이드카 없음)	커널 레벨, 사이드카 오버헤드 제거
Consul Connect	Built-in 또는 Envoy	HashiCorp 생태계 통합

Envoy Proxy

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

주요 기능:

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

eBPF 기반 로드 밸런싱

개념

**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 라우팅

성능 비교:

항목	iptables	eBPF (Cilium)	비고
지연 시간	기준	워크로드에 따라 단축	서비스 수가 많을수록 격차 확대
처리량	기준	워크로드에 따라 향상	네트워크 정책이 많을수록 격차 확대
규칙 수 증가 시 성능	선형 저하	영향 작음 (해시 테이블)	확장성
메모리 사용	높음	낮음	효율적

개선 폭은 워크로드와 규칙 수, 네트워크 구성에 따라 달라집니다. Cilium 성능 측정 문서의 실험 조건을 확인해야 결과를 비교할 수 있습니다. 특정 지연 감소율을 모든 클러스터에 적용하지 않고 실제 서비스 수와 정책을 넣어 측정합니다.

Global Server Load Balancing (GSLB)

개념

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

라우팅 정책:

지리적 근접성 (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)

yaml

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"

minReplicas와 maxReplicas는 파드 수의 하한과 상한입니다. averageUtilization: 70은 CPU 요청량 대비 평균 사용률의 목표를 70%로 정합니다. 두 번째 메트릭의 목표는 파드당 초당 HTTP 요청 100건입니다.

HPA는 각 메트릭으로 필요한 파드 수를 계산하고 가장 큰 값을 선택합니다. 실제 변경에는 허용 오차와 안정화 설정도 적용되므로 임계값을 넘는 즉시 반드시 증설하는 것은 아닙니다.

스케일링 전략

방식	동작	장점	단점
반응적 (Reactive)	메트릭 임계값 초과 시 스케일링	단순, 보편적	지연 발생 (콜드 스타트)
예측적 (Predictive)	과거 패턴 기반 사전 스케일링	피크 전 대비	예측 오류 가능
스케줄 기반	시간 기반 스케일링	패턴이 명확한 경우 효과적	유연성 부족

WebSocket 로드 밸런싱

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

과제

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

해결 방안

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

CDN과 엣지 로드 밸런싱

CDN (Content Delivery Network)

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

엣지 컴퓨팅 통합:

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

정리

로드 밸런싱은 계층(L4/L7), 알고리즘, 운영 패턴을 워크로드에 맞춰 조합하는 작업입니다. L4는 IP·포트만 보고 빠르게 분산하고, L7은 URL·헤더를 읽어 콘텐츠 기반 라우팅과 TLS 종료를 처리합니다. 서버가 자주 바뀌는 환경에서는 일관된 해싱으로 재배치를 줄이고, 헬스 체크와 서킷 브레이커로 장애 서버를 트래픽에서 격리합니다.

마이크로서비스 간 통신은 서비스 메시로, 커널 레벨 부하 분산은 eBPF로 다루되 그 효과는 서비스·규칙 수가 많을수록 커집니다. 다음 글에서는 분산 시스템의 상태를 추적하는 모니터링과 관측 가능성을 다룹니다.

L4/L7부터 eBPF, 서비스 메시까지 부하 분산의 계층·알고리즘·운영 패턴을 정리합니다.

개요

L4 vs L7 로드 밸런싱

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

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

특징:

패킷 헤더만 검사 → 매우 빠른 처리 속도
요청 내용(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, 헤더, 쿠키 등)을 분석하여 트래픽을 분산합니다.

특징:

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

대표 구현:

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

L4 vs L7 비교

항목	L4	L7
OSI 계층	전송 계층 (TCP/UDP)	애플리케이션 계층 (HTTP)
판단 기준	IP, Port	URL, Header, Cookie, Body
성능	매우 높음	상대적으로 낮음
TLS 종료	불가	가능
콘텐츠 기반 라우팅	불가	가능
WebSocket 지원	기본	완전 지원
비용	낮음	높음
사용 사례	고성능 TCP 서비스	웹 API, 마이크로서비스

로드 밸런싱 알고리즘

1. 라운드 로빈 (Round Robin)

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

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

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

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

서버	Weight	배분된 요청
서버 A	3	요청 1, 2, 3
서버 B	2	요청 4, 5
서버 C	1	요청 6

3. 최소 연결 (Least Connections)

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

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

4. IP 해시 (IP Hash)

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

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

5. 일관된 해싱 (Consistent Hashing)

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

해시 링 위에 서버 A·B·C·D와 키1~키4가 시계 방향으로 배치됩니다. 서버 B 제거 시 키2, 키3만 서버 C로 이동하고 나머지 키는 영향받지 않습니다.

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

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

헬스 체크 (Health Checks)

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

유형	방법	예시
Active	로드 밸런서가 주기적으로 프로브 전송	`/health` 엔드포인트 호출
Passive	실제 요청의 응답을 모니터링	연속 5xx 에러 감지

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

typescript

// /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	제한된 요청만 통과시켜 복구 여부 확인

서비스 메시 (Service Mesh)

개념

주요 서비스 메시 비교

서비스 메시	데이터 플레인	특징
Istio	Envoy	기능이 풍부, 복잡도 높음, Google 지원
Linkerd	linkerd2-proxy (Rust)	경량, 단순, CNCF 졸업
Cilium	eBPF (사이드카 없음)	커널 레벨, 사이드카 오버헤드 제거
Consul Connect	Built-in 또는 Envoy	HashiCorp 생태계 통합

Envoy Proxy

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

주요 기능:

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

eBPF 기반 로드 밸런싱

개념

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 라우팅

성능 비교:

항목	iptables	eBPF (Cilium)	비고
지연 시간	기준	워크로드에 따라 단축	서비스 수가 많을수록 격차 확대
처리량	기준	워크로드에 따라 향상	네트워크 정책이 많을수록 격차 확대
규칙 수 증가 시 성능	선형 저하	영향 작음 (해시 테이블)	확장성
메모리 사용	높음	낮음	효율적

Global Server Load Balancing (GSLB)

개념

라우팅 정책:

지리적 근접성 (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)

yaml

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"

스케일링 전략

방식	동작	장점	단점
반응적 (Reactive)	메트릭 임계값 초과 시 스케일링	단순, 보편적	지연 발생 (콜드 스타트)
예측적 (Predictive)	과거 패턴 기반 사전 스케일링	피크 전 대비	예측 오류 가능
스케줄 기반	시간 기반 스케일링	패턴이 명확한 경우 효과적	유연성 부족

WebSocket 로드 밸런싱

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

과제

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

해결 방안

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

CDN과 엣지 로드 밸런싱

CDN (Content Delivery Network)

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

엣지 컴퓨팅 통합:

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