Load Balancer

Load Balancer

로드 밸런서는 클라이언트 요청을 다수의 서버에 분산하여 시스템의 과부하를 방지하고, 고가용성, 확장성, 장애 대응성을 확보하는 핵심 인프라 구성 요소이다.

네트워크 계층 (L4) 또는 애플리케이션 계층 (L7) 에서 동작하며, 라운드로빈, 최소 연결, IP 해시 등의 알고리즘을 통해 요청을 최적의 서버로 전달한다. 또한, 헬스 체크, 세션 유지, SSL 종료, 콘텐츠 기반 라우팅, 자동 장애 조치 등의 기능을 제공하며, NGINX, HAProxy, Envoy 같은 소프트웨어 기반이나 AWS ALB, GCP Load Balancer 같은 클라우드 서비스, F5 같은 하드웨어 장비 형태로 구현된다.

대규모 트래픽을 처리하는 현대 웹 아키텍처에서 필수 요소로 활용된다.

등장 배경 및 발전 과정

1990 년대 후반 인터넷 서비스의 급속한 성장과 함께 단일 서버로는 증가하는 트래픽을 처리할 수 없는 한계에 직면했다. 이로 인해 서버 클러스터링과 트래픽 분산 기술의 필요성이 대두되었다.

등장 배경

• 단일 서버로 감당할 수 없는 대규모 트래픽의 증가
• 시스템 가용성 (Availability) 확보 필요성
• SPOF (Single Point of Failure) 해소

발전 과정

• 1 세대 (1990 년대): 하드웨어 기반 L4 로드 밸런서 등장
• 2 세대 (2000 년대): L7 애플리케이션 로드 밸런서 도입
• 3 세대 (2010 년대): 소프트웨어 정의 로드 밸런서와 클라우드 네이티브 솔루션
• 4 세대 (현재): AI/ML 기반 지능형 트래픽 분산 및 마이크로서비스 지원

목적 및 필요성

목적

1. 성능 향상: 트래픽을 여러 서버에 분산하여 응답 시간 단축
2. 고가용성 확보: 서버 장애 시 자동 장애 조치로 서비스 연속성 보장
3. 확장성 제공: 서버 추가/제거를 통한 동적 확장
4. 자원 최적화: 서버 자원의 효율적 활용

필요성

• 트래픽 급증 대응: 갑작스런 트래픽 증가에 대한 탄력적 대응
• 비즈니스 연속성: 24/7 무중단 서비스 요구사항 충족
• 비용 효율성: 인프라 투자 최적화 및 운영비용 절감
• 사용자 경험: 일관된 서비스 품질 제공

핵심 개념

Load Balancer (로드 밸런서) 는 클라이언트 요청을 여러 백엔드 서버에 분산하여 처리하는 네트워크 장비 또는 소프트웨어이다. 트래픽 분산을 통해 단일 서버의 과부하를 방지하고 시스템 전체의 성능과 안정성을 향상시킨다.

실무 연관성

• 서비스 무중단 배포, 장애 서버 자동제외, 트래픽 피크/스파이크 대응, 보안 (SSL 처리) 등 백엔드/프론트엔드 구간에서 모두 필요.
• 클라우드 (AWS ELB, Azure Load Balancer, Google Cloud Load Balancing 등) 및 쿠버네티스 (Kubernetes) 환경에서 필수적으로 사용됨.
• 마이크로서비스 아키텍처, API Gateway, CDN(콘텐츠 전송 네트워크) 등과의 연동 또한 중요.

주요 기능 및 역할

특징

• 유연성/확장성: 서버 수, 트래픽 변화에 능동적으로 대응
• 다양한 분산 알고리즘: 트래픽 특성에 맞춘 세부 정책
• 고가용성/내결함성: 장애시 부하 자동 전환, 헬스 체크 내장
• 보안 연계: SSL 처리, DDoS 방어, 인증 연동
• 실시간 모니터링/운영: 트래픽 로그, 분산 상태 실시간 감시

핵심 원칙

• Failover 우선 원칙: 장애 서버는 자동 제외
• Stateless 원칙 유지: 로드 밸런서는 상태 정보를 최소화
• 공정 분산 원칙: 라운드로빈, 최소 연결 등 균형 유지
• 속도 vs 정밀도 절충: 트래픽 분산 성능과 사용자 속성 고려
• 보안 우선 설계: SSL 종료, 방화벽 역할 병행

주요 원리 및 작동 방식

flowchart LR
    Client-->|요청|LB[Load Balancer]
    LB-->|Server-A로 분산|A[Application Server 1]
    LB-->|Server-B로 분산|B[Application Server 2]
    LB-->|Server-C로 분산|C[Application Server 3]
    A-->|응답|LB
    B-->|응답|LB
    C-->|응답|LB
    LB-->|클라이언트에게 최종 응답|Client

• 클라이언트 요청이 Load Balancer 를 통해 여러 서버에 분배됨.
• 서버가 응답 후, Load Balancer 가 응답을 취합/전달.
• 헬스 체크, 장애감지는 내부적으로 순환.

구조 및 아키텍처

graph TB
    subgraph "클라이언트 계층"
        A[웹 브라우저]
        B[모바일 앱]
        C[API 클라이언트]
    end
    
    subgraph "로드 밸런서 계층"
        D[L7 로드 밸런서]
        E[L4 로드 밸런서]
        F[Health Check 모듈]
        G[SSL 터미네이션]
    end
    
    subgraph "백엔드 서버 계층"
        H[웹 서버 1]
        I[웹 서버 2]
        J[웹 서버 3]
        K[애플리케이션 서버]
    end
    
    A --> D
    B --> D
    C --> E
    D --> H
    D --> I
    E --> J
    F --> H
    F --> I
    F --> J

구성요소

구현 기법 및 방법

요약

장점

CDN 장점별 실무 적용 사례

CDN 장점별 아키텍처

고가용성 및 장애 자동 복구

graph TD
  Client --> CDN[CDN PoP]
  CDN --> Check{Health Check}
  Check -->|Healthy| Origin1
  Check -->|Unhealthy| Origin2[Failover Origin]

확장성 및 글로벌 분산 처리

graph TD
  User1[User - Asia] --> PoP1[PoP - Singapore]
  User2[User - US] --> PoP2[PoP - Virginia]
  User3[User - EU] --> PoP3[PoP - Frankfurt]
  PoP1 --> Origin
  PoP2 --> Origin
  PoP3 --> Origin

성능 최적화 (캐시 + 압축 + 최신 프로토콜)

graph TD
  Browser --> CDN
  CDN -->|Cache Hit| Response[Serve from Cache]
  CDN -->|Cache Miss| Origin
  CDN -.-> Compress[Brotli / Gzip Compression]
  CDN -.-> Protocol[HTTP/2 / HTTP/3]

보안 아키텍처

graph TD
  User --> TLS[Edge TLS Termination]
  TLS --> WAF
  WAF --> BotFilter[Bot Mitigation]
  BotFilter --> CDN
  CDN --> Origin[Origin Server]

운영 및 관측

graph TD
  CDN --> Metrics[Logpush / Analytics]
  Metrics --> Dashboard[Observability Platform]
  Dashboard --> Alerts[SLI/SLO Alerts]

비용 최적화 (Edge Compute + Cache 우선 전략)

graph TD
  Request --> CDN
  CDN -->|Match| Cache[Serve from Cache]
  CDN -->|No Match| EdgeFn[Edge Function 처리]
  EdgeFn --> Origin

단점과 문제점 그리고 해결방안

단점

문제점

도전 과제

• 전통적인 LB 방식만으로는 마이크로서비스, 클라우드 네이티브, 멀티리전 환경에 한계가 존재함
• 운영 효율성 및 자동화를 위해 서비스 메시, AI 기반 최적화, 관측 도구와 통합 설계가 필수
• 단일 장애 지점 제거 및 보안 강화를 위한 멀티계층적 접근이 필요 (L4+L7, PoP, CDN, Sidecar LB 등)

현대 시스템에서의 Load Balancer 확장 방식

1. Global Load Balancing (글로벌 로드 밸런싱)

   • 다수의 지역 (Region, POP) 에 분산된 서버 간 트래픽을 분배
   • DNS 기반 (예: Route 53), Anycast IP 방식
   • 주로 다국적 서비스, CDN, 게임 트래픽 등에 활용

2. Load Balancer Chaining (다단계 로드 밸런서 구성)

   • 외부 L7 LB → 내부 L4 LB → 서비스 메쉬 Proxy (Envoy)
   • 보안/트래픽 제어/세션 처리 등의 계층적 분리
   • 단일 LB 성능 한계 극복 + 기능 분산 설계

3. Service Mesh 기반 라우팅

   • Istio, Linkerd 등의 사이드카 패턴
   • 트래픽 분산, 보안 정책, 텔레메트리 통합
   • K8s 환경에서 마이크로서비스 간 로드 밸런싱 고도화

로드 밸런서 설계 시 안티 패턴 (Anti-Patterns)

단일 LB 구성 (Single Point of Failure)

문제: 로드 밸런서 인스턴스가 하나일 경우, 해당 인스턴스 장애 시 전체 서비스 중단 (SPOF) 발생

해결 방안: Active-Active 이중화

flowchart TB
  Client1 --> DNS
  DNS --> LB1
  DNS --> LB2
  LB1 --> App1
  LB1 --> App2
  LB2 --> App1
  LB2 --> App2
  LB1 <--> LB2
  subgraph Load Balancers
    LB1[Load Balancer A]
    LB2[Load Balancer B]
  end
  subgraph App Layer
    App1[Backend Server 1]
    App2[Backend Server 2]
  end

• LB1, LB2 는 VIP 구성 (VRRP) 또는 클라우드 라운드로빈 DNS로 동시 서비스 제공
• 양쪽 모두 상태 공유 및 failover 대응

구현 예시:

• 구성 방식: 이중 로드 밸런서를 L4 수준에서 VIP(Virtual IP) 또는 DNS 라운드로빈을 통해 동시에 서비스

• 예시 (Kubernetes 환경):

  • MetalLB 또는 AWS NLB 를 활용한 LB IP 이중화
  • External-DNS + 클라우드 로드밸런서 연동으로 다중 AZ 기반 분산

• 하드웨어 환경:

  • VRRP 프로토콜 기반 Keepalived 설정으로 HA Proxy 이중화

  • 구성 예시:

    1 2 3 4 5 6 7 8 9

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

Kubernetes 기반 YAML 구성 예시:

• Active-Active Ingress 이중화
• MetalLB + HAProxy + Keepalived

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# MetalLB config for static IP allocation (L2 mode)
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: pool1
spec:
  addresses:
  - 192.168.1.100-192.168.1.101

---

apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2adv

• 두 개의 LB 가 동시에 IP 를 제공
• Keepalived 또는 dual Ingress controller 로 이중화

세션 서버 종속 (Session Stickiness by Local Storage)

문제: 세션 정보가 로컬 서버에 저장되면 요청이 다른 서버로 분산될 때 로그인 상태 끊김 발생

해결 방안: 외부 세션 저장소

• Redis 기반 세션 클러스터링

sequenceDiagram
  participant Client
  participant LB as Load Balancer
  participant App1 as App Server 1
  participant App2 as App Server 2
  participant Redis

  Client->>LB: HTTP 요청
  LB->>App1: 요청 전달
  App1->>Redis: 세션 저장
  Client->>LB: 다음 요청
  LB->>App2: 요청 전달
  App2->>Redis: 세션 조회
  App2-->>Client: 응답 (세션 유지됨)

• 세션은 서버 로컬이 아닌 Redis 에 저장되어 서버 간 상태 공유
• 로드밸런서가 어떤 서버로 보내든 세션은 유지됨

구성 예시:

• Redis 기반 세션 스토리지:

  • Express.js:

    1 2 3 4 5 6 7 8 9

    const session = require('express-session'); const RedisStore = require('connect-redis').default; app.use(session({ store: new RedisStore({ client: redisClient }), secret: 'keyboard cat', resave: false, saveUninitialized: false }));

  • Django:

    1 2	SESSION_ENGINE = "django.contrib.sessions.backends.cache" SESSION_CACHE_ALIAS = "default"

• Sticky Session 대신 Stateless JWT 적용:

  • 세션 정보를 클라이언트에 저장 (JWT), 로드 밸런서 뒤 서버 간 상태 공유 불필요

Kubernetes 기반 YAML 구성 예시:

• Redis 기반 세션 저장
• Express.js Deployment 예시

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: express
        image: myorg/express-app:latest
        env:
        - name: REDIS_HOST
          value: redis-master
        - name: SESSION_SECRET
          valueFrom:
            secretKeyRef:
              name: session-secret
              key: secret

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# Redis StatefulSet
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis
spec:
  serviceName: "redis"
  replicas: 1
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis
        image: redis:6.2
        ports:
        - containerPort: 6379

과도한 헬스체크 (Aggressive Health Check)

문제: 짧은 주기로 헬스체크를 수행하면, 실제 트래픽 외에도 과부하를 유발

해결 방안: 주기 조정 및 Concurrency 제한

구현 예시:

• NGINX 헬스체크 설정 (NJS + OpenResty):

  1 2 3 4 5 6 7

  server { location /health { proxy_pass http://backend/health; proxy_next_upstream error timeout http_500; health_check interval=5 fails=3 passes=2; } }

• AWS ALB 기준:

  • 기본 헬스체크 간격을 30초 로 설정
  • Unhealthy threshold 를 5 이상으로 조정하여 순간적 오차 허용

• Custom 헬스체크 API 에 rate limiter 적용

  • FastAPI 예시:

    1 2 3 4

    @limiter.limit("5 per minute") @app.get("/healthz") async def health_check(): return {"status": "ok"}

L7 에서 무조건 TLS 종료 (TLS Termination Only at LB)

문제: L7 LB 에서 TLS 를 종료한 후, 내부 서버 간은 평문 HTTP 로 통신 → 보안 문제 발생

해결 방안: TLS 재암호화 및 내부 인증

• TLS Termination 후 백엔드 암호화 구성

flowchart LR
  Client --> LB[Application Load Balancer]
  LB -->|TLS Termination| TLSProxy[TLS Proxy Layer]
  TLSProxy -->|Mutual TLS| App1[Internal App Server]
  TLSProxy -->|Mutual TLS| App2[Internal App Server]

• ALB 는 TLS 종료
• 내부 서비스 간은 mTLS 로 재암호화
• TLSProxy 는 Envoy 또는 Istio 로 구성 가능

적용 예시:

• L7 LB 에서 TLS 종료 후 백엔드로 다시 HTTPS 통신 설정

  • Envoy 또는 NGINX 에서 백엔드 proxy_pass 시 TLS 유지

    1 2 3 4 5

    location /api { proxy_pass https://internal-service; proxy_ssl_verify on; proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt; }

• 서비스 메시 활용 (Istio mTLS):

  • Istio 에 mTLS 정책 설정:

    1 2 3 4 5 6 7

    apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default spec: mtls: mode: STRICT

  • 클러스터 내 모든 Pod 간 통신을 암호화 (Zero Trust 보안)

Kubernetes 기반 YAML 구성 예시:

• TLS Termination + Backend TLS Re-encryption (Istio)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# PeerAuthentication: enforce mTLS between sidecars
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: backend-mtls
  namespace: default
spec:
  selector:
    matchLabels:
      app: backend
  mtls:
    mode: STRICT

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# Gateway for external TLS termination
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: my-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: my-cert
    hosts:
    - "example.com"

메트릭 미수집 (Lack of Observability)

문제: 로드 밸런서 상태와 트래픽 흐름을 실시간으로 파악하지 못해 장애 감지 및 분석 지연

해결 방안: 메트릭 수집 및 시각화 도구

통합 예시:

• Prometheus + Grafana 통합:

  • NGINX 메트릭 수집:

    1 2 3 4 5

    location /metrics { stub_status; allow 127.0.0.1; deny all; }

  • nginx-exporter 또는 envoy-prometheus-exporter 사용

• ALB, ELB 등 클라우드 LB 연동:

  • AWS CloudWatch 에서 RequestCount, TargetResponseTime, HTTPCode_ELB_5XX 등 수집
  • Alarm 설정으로 장애 시 자동 알림 (SNS, Slack 연동)

• 예시 시각화 대시보드 구성 (Grafana):

  • 요청 수, 평균 응답 시간, 연결 수, 활성 타겟 수 등 시각화
  • Alertmanager 와 연동하여 SLA 초과 시 알림 발송

분류 기준에 따른 종류 및 유형

• 레이어 기준 (L4 vs L7): 처리 속도 vs 정교한 라우팅 정책
• 구현 방식 (하드웨어/소프트웨어/클라우드): 비용 및 운용 전략 기준 선택
• 알고리즘: 트래픽 특성과 서버 성능 기반으로 동적 또는 정적 선택
• 세션: 사용자 상태 유지가 필요한 경우 반드시 고려
• Kubernetes 환경: Ingress Controller 또는 서비스 메시 필수 고려

로드 밸런서 아키텍처 유형

각 구성은 다음 상황에 맞춰 선택하면 된다:

Single Layer LB

flowchart LR
  Client --> LB1[L4 or L7 Load Balancer]
  LB1 --> App1[Application Server 1]
  LB1 --> App2[Application Server 2]

📌 단일 LB 로 간단한 트래픽 분산 구성 (예: 소규모 서비스, 단일 AZ)

Multi-Layer LB (L7 + L4)

flowchart LR
  Client --> L7["L7 Load Balancer (HTTPS)"]
  L7 --> L4["L4 Load Balancer (TCP)"]
  L4 --> App1[App Instance 1]
  L4 --> App2[App Instance 2]

📌 L7 은 인증, 라우팅, WAF 처리 / L4 는 내부 서비스로 TCP 기반 분산.
예: Cloudflare + NGINX → 내부 Redis, GRPC 서버 등

Global + Regional LB

flowchart LR
  Client1[Asia Client] --> GeoDNS
  Client2[US Client] --> GeoDNS
  GeoDNS --> LB-Asia[🇰🇷 Regional LB - Asia]
  GeoDNS --> LB-US[🇺🇸 Regional LB - US]
  LB-Asia --> App-KR1[KR App 1]
  LB-Asia --> App-KR2[KR App 2]
  LB-US --> App-US1[US App 1]
  LB-US --> App-US2[US App 2]

📌 지역별 로드 밸런서로 트래픽을 분산.
예: AWS Route53 GeoDNS + 각 리전 ALB

Hybrid LB (클라우드 + 온프레미스 연동)

flowchart LR
  Client --> LB-Cloud[Cloud L7 Load Balancer]
  LB-Cloud --> App-Cloud[Cloud App Service]
  LB-Cloud --> LB-OnPrem[On-Prem L4 Load Balancer]
  LB-OnPrem --> App-OnPrem1[Legacy App 1]
  LB-OnPrem --> App-OnPrem2[Legacy App 2]

📌 일부 트래픽은 클라우드로, 일부는 온프레미스로 전달.
예: Gradual Migration, Disaster Recovery

로드 밸런서 vs. 관련 컴포넌트 비교

요약:

• 로드 밸런서는 분산 중심
• API 게이트웨이는 기능 중심 (API 관리)
• 서비스 메쉬는 내부 마이크로서비스 간 제어

API Gateway vs. Load Balancer

로드 밸런서와 서비스 메시의 통합 전략

서비스 메시는 마이크로서비스 간의 통신을 관리하는 인프라 계층으로, 로드 밸런서와 함께 사용하여 트래픽 관리, 보안, 관찰 가능성 등을 향상시킬 수 있다.

예를 들어, Istio 와 같은 서비스 메시를 사용하면 로드 밸런서를 통해 외부 트래픽을 클러스터로 전달하고, 클러스터 내에서는 서비스 메시가 트래픽을 세밀하게 제어한다. 이를 통해 트래픽 분할, A/B 테스트, 회로 차단기 등의 고급 트래픽 관리 기능을 구현할 수 있다.

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

• 고가용성을 위해 이중화와 멀티 리전 구성은 필수
• 세션 관리는 상태 유지 시스템에서 성능·일관성·확장성을 균형 있게 고려
• 보안 강화는 TLS 종료 전략 + 프록시 인증·WAF 연동으로 계층화
• 운영 자동화는 IaC, 모니터링, 인증서 관리 자동화를 통합적으로 설계

마이그레이션 시 고려사항

실무적 관점에서 로드 밸런서 구성 전략

• 인터넷 입구에서는 WAF + L7 Load Balancer를 통해 보안 강화와 콘텐츠 기반 고도 분산 구성
• 내부 마이크로서비스 간 통신에서는 Envoy + Istio Service Mesh를 통해 보안, 관찰 가능성, 장애 격리 수준을 강화

외부 트래픽 처리 전략 (L7 중심)

1

Client ──→ DNS ──→ WAF ──→ L7 Load Balancer ──→ Application Layer

• 핵심 역할
  • WAF: 애플리케이션 계층 공격 차단 (XSS, SQLi 등)
  • L7 Load Balancer: TLS 종료, 콘텐츠 기반 라우팅, 세션 지속성, 리다이렉션 등
  • Application Layer: 실제 API/웹 서비스 처리
• 활용 기술: Cloudflare, AWS ALB, NGINX
• 고려 사항: TLS 종료, Rate Limit, Geo Routing
• 구현 예시
  • Cloudflare + Origin 서버
    Cloudflare 의 WAF 기능 후, L7 로드밸런서에서 TLS 종료 → 후방 서버로 HTTPS 재암호화 가능
  • AWS 구성 (ALB + WAF)
    API 요청은 DNS → AWS WAF → Application Load Balancer → 대상 그룹으로 라우팅.
    ALB 에서 TLS 종료, 콘텐츠 기반 라우팅, WAF 연동
  • 온프레미스 / NGINX + ModSecurity
    NGINX 에서 TLS 종료 후 ModSecurity 기반 WAF 통과 → 백엔드로 전송.
    HAProxy + Cloudflare 조합 예시에서 “Flexible SSL” 모드로 TLS 재설정도 가능

내부 마이크로서비스 간 통신 전략 (L4 + 메쉬)

1

Service A ──→ Sidecar (Envoy) ──→ Istio Mesh ──→ Sidecar (Service B)

• 핵심 역할
  • Envoy Sidecars: 모든 서비스 호출을 프록시하며 TLS 종료, 라우팅, 리트라이, 장애 차단 처리
  • Istio Control Plane: mTLS 인증 설정, 트래픽 정책, 관찰 가능성 및 보안 제어

• Service Mesh: 트래픽 암호화, 정책 기반 통신 통제, 장애 격리

• 활용 기술: Envoy Proxy + Istio Control Plane
• 고려 사항: 정책 기반 라우팅, mTLS, 장애 격리
• 구현 예시

  • Istio Sidecar 모드
    각 Pod 에 Envoy 사이드카 추가하여 트래픽을 모두 제어.
    Control Plane 에서 mTLS 적용 (Strict, Permissive 등 설정)

  • mTLS 설정 예시 (Strict mode)

    1 2 3 4 5 6 7 8

    apiVersion: security.istio.io/v1 kind: PeerAuthentication metadata: name: default namespace: foo spec: mtls: mode: STRICT

    적용 후 클라이언트 사이드카가 없는 요청은 차단됨.

  • Envoy 기능
    사이드카는 L4/L7 기능 모두 제공하며, 라우팅, 재시도, 장애 차단, 메트릭 수집 등 다양한 기능 수행

로드 밸런서 기반 블루 - 그린 배포 및 카나리 배포 전략

블루 - 그린 배포는 두 개의 환경 (블루와 그린) 을 유지하면서 새로운 버전을 배포하고, 트래픽을 새로운 환경으로 전환하는 방식이다.
카나리 배포는 새로운 버전을 소수의 사용자에게 먼저 배포하여 문제가 없는지 확인한 후 전체 사용자에게 확장하는 방식이다.

로드 밸런서를 사용하면 트래픽을 특정 버전의 서비스로 분산시켜 이러한 배포 전략을 구현할 수 있다.

로드 밸런서 자동화

**Infrastructure as Code (IaC)**와 GitOps를 활용하여 로드 밸런서 구성을 자동화할 수 있다.

예를 들어, Terraform 을 사용하여 AWS 의 Application Load Balancer(ALB) 를 정의하고, Argo CD 를 통해 Git 리포지토리의 변경 사항을 자동으로 클러스터에 적용할 수 있다.
이를 통해 인프라 변경의 추적 가능성과 일관성을 확보할 수 있다.

기술 적용 예시

• Terraform: AWS ALB, Target Group, Listener 설정
• Helm: K8s Ingress Controller 자동 배포
• Ansible: NGINX 설정 자동화 및 롤링 재시작

Terraform 예시 (AWS ALB 설정):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

resource "aws_lb" "app" {
  name               = "my-app-lb"
  internal           = false
  load_balancer_type = "application"
  subnets            = var.public_subnets
  security_groups    = [aws_security_group.lb.id]
}

resource "aws_lb_target_group" "app_tg" {
  name     = "app-target-group"
  port     = 80
  protocol = "HTTP"
  vpc_id   = var.vpc_id
}

최적화하기 위한 고려사항 및 주의할 점

로드 밸런서와 CDN 연계 아키텍처 설계

CDN (Content Delivery Network) 은 정적 콘텐츠를 전 세계 엣지 서버에 캐싱하여 사용자에게 빠르게 전달한다.
로드 밸런서와 함께 사용할 경우, 다음과 같은 방식으로 협력한다:

1. CDN → Load Balancer → Backend
2. CDN 은 정적 콘텐츠 처리
3. LB 는 동적 콘텐츠 및 세션 기반 요청 처리

아키텍처 설계 예시

flowchart LR
    User --> EdgeCDN[Cloudflare CDN / Akamai / AWS CloudFront]
    EdgeCDN --> LB["Load Balancer (ALB/Nginx)"]
    LB --> App1[Web App Server]
    LB --> App2[API Server]

구성 전략

실무 팁

• CDN 의 IP Range 만 허용한 WAF 설정 필요
• 동적 API 요청은 CDN 캐시 무효화 적용
• Cache-Control 헤더 정책에 따라 성능 차이 큼

멀티 클라우드 환경에서의 글로벌 로드 밸런서 설계

멀티 클라우드 (Global) 환경에서 로드 밸런싱은 Region 간 트래픽 분산 + DR (Disaster Recovery) 전략을 포함해야 한다.
핵심 요소는:

1. DNS 기반 지리 라우팅 (Geo DNS)
2. Anycast 기반 글로벌 LB
3. Cross-region HA 구성

예시 아키텍처: AWS-GCP 혼합 환경

flowchart TD
    User --> GeoDNS
    GeoDNS --> AWS_GL[AWS Global Accelerator]
    GeoDNS --> GCP_LB[GCP Global HTTP LB]

    AWS_GL --> AWS_App1[us-east-1 App]
    GCP_LB --> GCP_App2[asia-east1 App]

주요 구성 요소 및 전략

실무 팁

• DNS TTL 을 낮게 유지해야 신속한 전환 가능
• Cloudflare Tunnel, Akamai EdgeWorkers 등 글로벌 연동도 고려
• 상태 기반 전환 로직 (BGP, DNS Failover) 테스트 중요

실무 사용 예시

• **L7 기반 (HTTP, API, CDN)**은 트래픽 특성에 따라 경로 기반, 헤더 기반, 지역 기반 분산에 강점
• **L4 기반 (TCP, UDP, DB)**은 레이어 낮은 수준에서 지연 최소화, 세션 유지, 내부 서비스 분산에 적합
• 멀티 클라우드 / 하이브리드 환경에서는 벤더 중립적 LB와 재해 복구 구성이 중요
• Kubernetes 기반에서는 Ingress + Gateway + Service Mesh 조합이 표준 아키텍처로 정착
• 서버리스 및 이벤트 기반 구조에서는 LB 와 API Gateway 를 조합해 비용 최적화 + 비동기 트리거를 달성

활용 사례

사례 1: API 서비스 기반 L7 Load Balancer 활용

구성: 외부 클라이언트 → L7 Load Balancer → REST API 서버 3 대

Workflow:

1. Client 가 HTTP 요청 → L7 Load Balancer 가 요청 경로/쿠키 등 분석
2. Health Check 통과 서버만을 대상으로 분산
3. 스티키 세션 (flask_login 등) 필요 시 쿠키 기반 할당
4. 서버 장애시 자동 제외, 응답시간 모니터링

flowchart TD
    Client-->|HTTP 요청| LB[L7 Load Balancer]
    LB-->|분산| API1[API Server1]
    LB-->|분산| API2[API Server2]
    LB-->|분산| API3[API Server3]
    API1-->|응답| LB
    API2-->|응답| LB
    API3-->|응답| LB
    LB-->|최종 응답| Client

LB 적용 vs 미적용 차이:

• 적용: 서버 증설·장애시 무중단 대응, 응답 속도 향상
• 미적용: 특정 서버에 트래픽 집중, 서버 장애 시 서비스 불가

사례 2: SaaS 플랫폼의 글로벌 트래픽 분산 및 API 서비스 가용성 확보

flowchart LR
  subgraph Users
    U1["User A (Asia)"]
    U2["User B (EU)"]
  end
  DNS[DNS / GSLB]
  subgraph Region Asia
    NLB1["TCP LB (NLB)"]
    ALB1["App LB (ALB)"]
    AppA1[Service A]
    AppA2[Service A]
  end
  subgraph Region EU
    NLB2[TCP LB]
    ALB2[App LB]
    AppB1[Service A]
    AppB2[Service A]
  end

  U1 --> DNS
  U2 --> DNS

  DNS --> NLB1
  DNS --> NLB2

  NLB1 --> ALB1
  NLB2 --> ALB2

  ALB1 --> AppA1 & AppA2
  ALB2 --> AppB1 & AppB2

Workflow:

1. 글로벌 유저 요청 → GSLB 기반 각 지역 NLB 로 라우팅
2. L7 LB(ALB) 통해 API 핸들링, TLS 처리, 쿠키/헤더 기반 라우팅 수행
3. 헬스 체크 실패 시 자동 리전 장애 전환
4. 모니터링 지표 기반 용량 예측 및 오토스케일 운영

사례 3: 모바일 뱅킹 서비스

시나리오: 모바일 뱅킹 앱에서 사용자가 로그인 및 거래를 수행할 때, 고가용성과 세션 유지를 보장해야 한다.

시스템 구성:

• 사용자는 모바일 앱을 통해 인증 요청을 보냄
• 요청은 AWS ALB 로 전달되어 Nginx L7 Proxy 로 분산
• 인증 서버는 Redis 기반 세션 저장소와 연결됨

graph TD
    Client(Mobile App)
    LB[AWS ALB]
    Proxy[Nginx L7 Proxy]
    Auth1[Auth Server 1]
    Auth2[Auth Server 2]
    Redis["Session Store (Redis)"]

    Client --> LB --> Proxy
    Proxy --> Auth1
    Proxy --> Auth2
    Auth1 --> Redis
    Auth2 --> Redis

Workflow:

• 사용자가 로그인 → ALB 라우팅 → Nginx Proxy → Auth Server
• 세션은 Redis 에 저장되어 서버 간 공유됨
• 장애 시 헬스체크 통해 자동 우회

역할:

• ALB: 트래픽 분산 및 HTTPS 종료
• Nginx: 세션 유지, 라우팅
• Redis: 인증 상태 공유 저장소

유무에 따른 차이점:

• 로드 밸런서 없음: 단일 서버 장애 시 전체 서비스 다운
• 로드 밸런서 있음: 유연한 확장 및 장애 회복 가능

구현 예시 (Nginx 설정):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

http {
    upstream auth_backend {
        server auth1.internal:8080;
        server auth2.internal:8080;
    }

    server {
        listen 443 ssl;
        server_name bank.example.com;

        location /login {
            proxy_pass http://auth_backend;
            proxy_set_header Host $host;
            proxy_cookie_path / "/; HttpOnly; Secure";
        }
    }
}

사례 4: E-commerce 플랫폼의 로드 밸런싱 구현

시스템 구성:

• 프론트엔드: React.js 기반 SPA
• 로드 밸런서: AWS Application Load Balancer (L7)
• 백엔드: Node.js 서버 클러스터 (Auto Scaling Group)
• 데이터베이스: MySQL 마스터 - 슬레이브 구성

graph TB
    subgraph "사용자"
        A[웹 브라우저]
        B[모바일 앱]
    end
    
    subgraph "AWS Cloud"
        C[Route 53 DNS]
        D[CloudFront CDN]
        E[Application Load Balancer]
        
        subgraph "Auto Scaling Group"
            F[웹 서버 1]
            G[웹 서버 2]
            H[웹 서버 3]
        end
        
        I[RDS MySQL Master]
        J[RDS MySQL Read Replica]
    end
    
    A --> C
    B --> C
    C --> D
    D --> E
    E --> F
    E --> G
    E --> H
    F --> I
    G --> I
    H --> I
    F --> J
    G --> J
    H --> J

Workflow:

1. DNS 해석: Route 53 을 통한 도메인 해석
2. CDN 처리: CloudFront 에서 정적 콘텐츠 서빙
3. 로드 밸런싱: ALB 에서 동적 콘텐츠 요청을 서버 클러스터로 분산
4. 오토 스케일링: 트래픽 증가 시 자동으로 서버 인스턴스 추가
5. 데이터베이스 분산: 읽기 요청은 Read Replica 로, 쓰기 요청은 Master 로 분산

로드 밸런서의 역할:

• 트래픽 분산: 들어오는 HTTP/HTTPS 요청을 3 개 서버에 균등 분배
• Health Check: 각 서버의 /health 엔드포인트를 주기적으로 확인
• SSL 터미네이션: SSL 인증서 관리 및 HTTPS 트래픽 처리
• 세션 관리: 쿠키 기반 세션 스티키니스 제공

로드 밸런서 유무에 따른 차이점:

• 로드 밸런서 있는 경우:
  • 트래픽 분산으로 서버당 부하 33% 분배
  • 한 서버 장애 시에도 서비스 지속 (66% 용량 유지)
  • 자동 확장으로 피크 시간 대응 가능
  • SSL 중앙 관리로 보안 강화
• 로드 밸런서 없는 경우:
  • 단일 서버에 모든 트래픽 집중
  • 서버 장애 시 전체 서비스 중단
  • 수동 확장으로 인한 확장성 제한
  • 각 서버별 SSL 인증서 관리 필요

구현 예시:

• Python 을 이용한 간단한 HTTP 로드 밸런서

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278

  import asyncio import aiohttp from aiohttp import web import json import time from typing import List, Dict, Any import logging # 로깅 설정 logging.basicConfig(level=logging.INFO) logger = logging.getLogger(__name__) class HealthChecker: """서버 상태 검사 클래스""" def __init__(self, check_interval: int = 30): self.check_interval = check_interval self.healthy_servers = set() async def check_server_health(self, server_url: str) -> bool: """개별 서버 상태 검사""" try: async with aiohttp.ClientSession() as session: async with session.get(f"{server_url}/health", timeout=5) as response: return response.status == 200 except Exception as e: logger.warning(f"Health check failed for {server_url}: {e}") return False async def monitor_servers(self, servers: List[str]): """모든 서버 상태 지속 모니터링""" while True: healthy = set() for server in servers: if await self.check_server_health(server): healthy.add(server) self.healthy_servers = healthy logger.info(f"Healthy servers: {self.healthy_servers}") await asyncio.sleep(self.check_interval) class LoadBalancingAlgorithm: """로드 밸런싱 알고리즘 클래스""" def __init__(self): self.round_robin_index = 0 self.server_connections = {} def round_robin(self, servers: List[str]) -> str: """라운드 로빈 알고리즘""" if not servers: raise Exception("No healthy servers available") server = servers[self.round_robin_index % len(servers)] self.round_robin_index += 1 return server def least_connections(self, servers: List[str]) -> str: """최소 연결 수 알고리즘""" if not servers: raise Exception("No healthy servers available") # 연결 수 초기화 for server in servers: if server not in self.server_connections: self.server_connections[server] = 0 # 최소 연결 수 서버 선택 min_connections = min(self.server_connections[s] for s in servers) for server in servers: if self.server_connections[server] == min_connections: return server def increment_connection(self, server: str): """서버 연결 수 증가""" self.server_connections[server] = self.server_connections.get(server, 0) + 1 def decrement_connection(self, server: str): """서버 연결 수 감소""" if server in self.server_connections: self.server_connections[server] = max(0, self.server_connections[server] - 1) class HTTPLoadBalancer: """HTTP 로드 밸런서 메인 클래스""" def __init__(self, servers: List[str], algorithm: str = "round_robin"): self.servers = servers self.algorithm = algorithm self.health_checker = HealthChecker() self.lb_algorithm = LoadBalancingAlgorithm() self.session_store = {} # 세션 스티키니스용 # 통계 정보 self.stats = { 'total_requests': 0, 'successful_requests': 0, 'failed_requests': 0, 'server_stats': {server: 0 for server in servers} } async def start_health_monitoring(self): """Health Check 모니터링 시작""" asyncio.create_task(self.health_checker.monitor_servers(self.servers)) def select_server(self) -> str: """로드 밸런싱 알고리즘에 따른 서버 선택""" healthy_servers = list(self.health_checker.healthy_servers) if self.algorithm == "round_robin": return self.lb_algorithm.round_robin(healthy_servers) elif self.algorithm == "least_connections": return self.lb_algorithm.least_connections(healthy_servers) else: raise ValueError(f"Unknown algorithm: {self.algorithm}") async def forward_request(self, request: web.Request) -> web.Response: """클라이언트 요청을 백엔드 서버로 전달""" try: # 통계 업데이트 self.stats['total_requests'] += 1 # 서버 선택 target_server = self.select_server() self.lb_algorithm.increment_connection(target_server) # 요청 URL 구성 target_url = f"{target_server}{request.path_qs}" # 헤더 준비 (Host 헤더 수정) headers = dict(request.headers) headers['Host'] = target_server.replace('http://', '').replace('https://', '') logger.info(f"Forwarding {request.method} {request.path} to {target_server}") # 백엔드 서버로 요청 전달 async with aiohttp.ClientSession() as session: async with session.request( method=request.method, url=target_url, headers=headers, data=await request.read(), timeout=30 ) as response: # 응답 헤더 복사 response_headers = {} for key, value in response.headers.items(): if key.lower() not in ['content-encoding', 'transfer-encoding']: response_headers[key] = value # 응답 본문 읽기 response_body = await response.read() # 통계 업데이트 self.stats['successful_requests'] += 1 self.stats['server_stats'][target_server] += 1 # 연결 수 감소 self.lb_algorithm.decrement_connection(target_server) return web.Response( body=response_body, status=response.status, headers=response_headers ) except Exception as e: self.stats['failed_requests'] += 1 logger.error(f"Request forwarding failed: {e}") # 에러 시에도 연결 수 감소 if 'target_server' in locals(): self.lb_algorithm.decrement_connection(target_server) return web.Response( text=f"Service Unavailable: {str(e)}", status=503 ) async def health_endpoint(self, request: web.Request) -> web.Response: """로드 밸런서 상태 확인 엔드포인트""" health_status = { 'status': 'healthy', 'healthy_servers': list(self.health_checker.healthy_servers), 'total_servers': len(self.servers), 'algorithm': self.algorithm, 'stats': self.stats } return web.json_response(health_status) async def stats_endpoint(self, request: web.Request) -> web.Response: """통계 정보 엔드포인트""" return web.json_response(self.stats) # 로드 밸런서 설정 및 실행 async def create_load_balancer(): """로드 밸런서 애플리케이션 생성""" # 백엔드 서버 목록 backend_servers = [ "http://localhost:8001", "http://localhost:8002", "http://localhost:8003" ] # 로드 밸런서 인스턴스 생성 lb = HTTPLoadBalancer(backend_servers, algorithm="least_connections") # Health Check 모니터링 시작 await lb.start_health_monitoring() # 웹 애플리케이션 설정 app = web.Application() # 라우트 설정 app.router.add_route('*', '/health', lb.health_endpoint) app.router.add_route('*', '/stats', lb.stats_endpoint) app.router.add_route('*', '/{path:.*}', lb.forward_request) return app # 데모용 백엔드 서버 async def create_backend_server(port: int): """데모용 백엔드 서버 생성""" async def hello_handler(request): return web.json_response({ 'server': f'Server-{port}', 'message': 'Hello from backend server!', 'timestamp': time.time() }) async def health_handler(request): return web.json_response({'status': 'healthy', 'server': f'Server-{port}'}) app = web.Application() app.router.add_get('/', hello_handler) app.router.add_get('/health', health_handler) app.router.add_get('/api/data', hello_handler) return app # 실행 함수 async def main(): """메인 실행 함수""" # 백엔드 서버들 시작 backend_ports = [8001, 8002, 8003] for port in backend_ports: app = await create_backend_server(port) runner = web.AppRunner(app) await runner.setup() site = web.TCPSite(runner, 'localhost', port) await site.start() logger.info(f"Backend server started on port {port}") # 로드 밸런서 시작 lb_app = await create_load_balancer() lb_runner = web.AppRunner(lb_app) await lb_runner.setup() lb_site = web.TCPSite(lb_runner, 'localhost', 8080) await lb_site.start() logger.info("Load Balancer started on port 8080") logger.info("Available endpoints:") logger.info(" - http://localhost:8080/ (forwarded to backends)") logger.info(" - http://localhost:8080/health (load balancer health)") logger.info(" - http://localhost:8080/stats (statistics)") # 서버 계속 실행 try: await asyncio.Future() # 무한 대기 except KeyboardInterrupt: logger.info("Shutting down...") if __name__ == "__main__": asyncio.run(main())

• 사용 방법:

  1 2 3 4 5 6 7 8 9 10

  # 1. 로드 밸런서 실행 python load_balancer.py # 2. 다른 터미널에서 테스트 curl http://localhost:8080/ curl http://localhost:8080/health curl http://localhost:8080/stats # 3. 부하 테스트 for i in {1..10}; do curl http://localhost:8080/api/data; echo; done

  • 이 구현 예시는 실제 운영 환경에서 사용되는 로드 밸런서의 핵심 기능들을 포함하고 있다:
    • Health Check: 백엔드 서버 상태 모니터링
    • 로드 밸런싱 알고리즘: Round Robin, Least Connections
    • 통계 수집: 요청 처리 통계 및 서버별 분산 현황
    • 에러 처리: 장애 상황에 대한 적절한 대응

로드 밸런서 관련 최신 기술 동향

주목할 내용

반드시 학습해야할 내용

용어 정리

참고 및 출처

확장성 & 로드 밸런서 개념

• Scalability for Dummies by cs.fyi
• Load Balancing Fundamentals | NGINX

NGINX 기반 로드 밸런서 설계

• Inside NGINX: How We Designed for Performance & Scale
• Load Balancing with NGINX and NGINX Plus, Part 1
• Load Balancing with NGINX and NGINX Plus, Part 2
• Choosing an NGINX Plus Load‑Balancing Technique
• TCP/UDP Load Balancing with NGINX

AWS Elastic Load Balancing & Kubernetes 연동

• Elastic Load Balancing | AWS 공식 문서
• Application Load Balancer | AWS
• AWS Load Balancer Controller (EKS용)

GSLB & 글로벌 PoP 구성

• Global Server Load Balancing with NS1 + NGINX Plus

NGINX 일반 정보

• Nginx 위키백과