> For the complete documentation index, see [llms.txt](https://atomoh.gitbook.io/kubernetes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atomoh.gitbook.io/kubernetes/service-mesh/istio/traffic-management/06-load-balancing.md).

# 로드 밸런싱

Istio는 Envoy를 통해 다양한 로드 밸런싱 알고리즘을 제공하여 트래픽을 효율적으로 분산시킵니다.

## 목차

1. [Why Load Balancing?](#why-load-balancing)
2. [로드 밸런싱 개요](#로드-밸런싱-개요)
3. [로드 밸런싱 알고리즘](#로드-밸런싱-알고리즘)
4. [Consistent Hash 상세](#consistent-hash-상세)
5. [Locality 기반 로드 밸런싱](#locality-기반-로드-밸런싱)
6. [Connection Pool 설정](#connection-pool-설정)
7. [실전 예제](#실전-예제)
8. [알고리즘 선택 가이드](#알고리즘-선택-가이드)
9. [모범 사례](#모범-사례)
10. [문제 해결](#문제-해결)

## Why Load Balancing?

### 효율적인 리소스 활용

로드 밸런싱은 트래픽을 여러 인스턴스에 분산시켜 시스템 전체의 처리량과 안정성을 향상시킵니다.

```mermaid
flowchart TB
    subgraph Without["로드 밸런싱 없이"]
        C1[모든 요청] -->|과부하| S1[서비스 1<br/>100% 부하]
        S2[서비스 2<br/>0% 부하]
        S3[서비스 3<br/>0% 부하]
    end

    subgraph With["로드 밸런싱 사용"]
        C2[요청 분산] --> LB[로드 밸런서]
        LB -->|33%| S4[서비스 1<br/>33% 부하]
        LB -->|33%| S5[서비스 2<br/>33% 부하]
        LB -->|34%| S6[서비스 3<br/>34% 부하]
    end

    %% 스타일 정의
    classDef overload fill:#FF6B6B,stroke:#333,stroke-width:1px,color:white;
    classDef idle fill:#95A5A6,stroke:#333,stroke-width:1px,color:white;
    classDef balanced fill:#00C7B7,stroke:#333,stroke-width:1px,color:white;
    classDef lb fill:#326CE5,stroke:#333,stroke-width:1px,color:white;
    classDef client fill:#f9f9f9,stroke:#333,stroke-width:1px,color:black;

    %% 클래스 적용
    class C1,C2 client;
    class S1 overload;
    class S2,S3 idle;
    class LB lb;
    class S4,S5,S6 balanced;
```

### 주요 이점

| 문제         | 로드 밸런싱 없이       | 로드 밸런싱 사용  |
| ---------- | --------------- | ---------- |
| **가용성**    | 단일 장애점 (SPOF)   | 장애 시 자동 우회 |
| **성능**     | 특정 인스턴스 과부하     | 균등한 부하 분산  |
| **확장성**    | 수평 확장 어려움       | 쉬운 스케일 아웃  |
| **응답 시간**  | 불균일 (0-1000ms+) | 일관된 응답 시간  |
| **리소스 활용** | 비효율 (일부만 사용)    | 효율적 리소스 활용 |

## 로드 밸런싱 개요

```mermaid
flowchart TB
    Client[클라이언트 요청]
    
    subgraph LB["Load Balancer"]
        Algorithm[로드 밸런싱<br/>알고리즘]
    end
    
    subgraph Pods["파드"]
        Pod1[Pod 1<br/>부하: 30%]
        Pod2[Pod 2<br/>부하: 50%]
        Pod3[Pod 3<br/>부하: 20%]
    end
    
    Client --> Algorithm
    Algorithm -->|Round Robin| Pod1
    Algorithm -->|Least Request| Pod3
    Algorithm -->|Random| Pod2
    
    %% 스타일 정의
    classDef client fill:#f9f9f9,stroke:#333,stroke-width:1px,color:black;
    classDef lb fill:#326CE5,stroke:#333,stroke-width:1px,color:white;
    classDef pod fill:#00C7B7,stroke:#333,stroke-width:1px,color:white;
    
    %% 클래스 적용
    class Client client;
    class Algorithm lb;
    class Pod1,Pod2,Pod3 pod;
```

## 로드 밸런싱 알고리즘

Istio는 다음과 같은 로드 밸런싱 알고리즘을 제공합니다.

### 알고리즘 비교

| 알고리즘                 | 설명           | 사용 시나리오          | 장점        | 단점        |
| -------------------- | ------------ | ---------------- | --------- | --------- |
| **ROUND\_ROBIN**     | 순차적 분배 (기본값) | 스테이트리스 서비스       | 간단, 공평    | 부하 불균형 가능 |
| **LEAST\_REQUEST**   | 최소 활성 요청     | 고성능 API, DB 연결   | 부하 균등화    | 약간의 오버헤드  |
| **RANDOM**           | 무작위 분배       | 대량 트래픽           | 간단, 빠름    | 단기 불균형 가능 |
| **PASSTHROUGH**      | 원본 목적지       | TCP 프록시, SNI 라우팅 | 유연성       | 제한적 제어    |
| **CONSISTENT\_HASH** | 해시 기반 고정     | 세션 유지, 캐시        | Sticky 세션 | 불균형 가능    |

### 1. ROUND\_ROBIN (기본값)

요청을 순차적으로 각 엔드포인트에 분배합니다.

```mermaid
sequenceDiagram
    autonumber
    participant Client
    participant LB as Load Balancer<br/>(ROUND_ROBIN)
    participant Pod1 as Pod 1
    participant Pod2 as Pod 2
    participant Pod3 as Pod 3

    Client->>LB: Request 1
    LB->>Pod1: Route
    Pod1-->>Client: Response

    Client->>LB: Request 2
    LB->>Pod2: Route
    Pod2-->>Client: Response

    Client->>LB: Request 3
    LB->>Pod3: Route
    Pod3-->>Client: Response

    Client->>LB: Request 4
    LB->>Pod1: Route (순환)
    Pod1-->>Client: Response
```

**설정 예제:**

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews-round-robin
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
```

**사용 사례:**

* 스테이트리스 REST API
* 동일한 성능을 가진 파드
* 기본 설정으로 충분한 경우

**장점:**

* 구현이 간단하고 예측 가능
* 공평한 분배

**단점:**

* 파드별 부하 차이를 고려하지 않음
* 긴 요청이 있으면 불균형 발생 가능

### 2. LEAST\_REQUEST

가장 적은 활성 요청을 처리 중인 엔드포인트로 라우팅합니다.

```mermaid
flowchart LR
    Client[클라이언트<br/>새 요청]
    LB[Load Balancer<br/>LEAST_REQUEST]

    subgraph Pods[파드 상태]
        Pod1[Pod 1<br/>활성 요청: 5개]
        Pod2[Pod 2<br/>활성 요청: 2개 ✅]
        Pod3[Pod 3<br/>활성 요청: 8개]
    end

    Client --> LB
    LB -.->|검사| Pod1
    LB -.->|검사| Pod2
    LB -.->|검사| Pod3
    LB -->|최소 부하로<br/>라우팅| Pod2

    %% 스타일 정의
    classDef client fill:#f9f9f9,stroke:#333,stroke-width:1px,color:black;
    classDef lb fill:#326CE5,stroke:#333,stroke-width:1px,color:white;
    classDef pod fill:#00C7B7,stroke:#333,stroke-width:1px,color:white;
    classDef selected fill:#F8B52A,stroke:#333,stroke-width:2px,color:black;

    %% 클래스 적용
    class Client client;
    class LB lb;
    class Pod1,Pod3 pod;
    class Pod2 selected;
```

**설정 예제:**

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: api-least-request
spec:
  host: api-service
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
      warmupDurationSecs: 60  # 60초 워밍업 (선택)
```

**고급 설정:**

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: api-least-request-advanced
spec:
  host: api-service
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
      warmupDurationSecs: 120  # 새 파드 워밍업
    connectionPool:
      http:
        http2MaxRequests: 100
        maxRequestsPerConnection: 10
```

**사용 사례:**

* 응답 시간이 불균일한 API
* 데이터베이스 연결 풀
* 무거운 처리를 하는 서비스
* 실시간 부하 균형이 중요한 경우

**장점:**

* 실시간 부하에 따라 적응
* 응답 시간 일관성 향상
* 파드별 성능 차이 흡수

**단점:**

* 약간의 오버헤드 (활성 요청 추적)

### 3. RANDOM

무작위로 엔드포인트를 선택합니다.

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews-random
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: RANDOM
```

**사용 사례:**

* 대량의 트래픽 (통계적으로 균등)
* 간단하고 빠른 선택이 필요한 경우
* 파드 성능이 동일한 경우

**장점:**

* 매우 빠른 선택
* 구현이 간단
* 대규모에서 통계적으로 균등

**단점:**

* 단기적으로 불균형 가능
* 예측 불가능

### 4. PASSTHROUGH

클라이언트가 지정한 원본 목적지로 직접 연결합니다.

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: tcp-passthrough
spec:
  host: "*.external-service.com"
  trafficPolicy:
    loadBalancer:
      simple: PASSTHROUGH
```

**사용 사례:**

* TCP 프록시
* SNI 기반 라우팅
* 외부 서비스 직접 연결
* TLS PASSTHROUGH 모드

**장점:**

* 원본 목적지 주소 유지
* 유연한 라우팅

**단점:**

* 로드 밸런싱 제어 제한적

### 5. LEAST\_CONN (Deprecated → LEAST\_REQUEST)

**주의**: `LEAST_CONN`은 **deprecated**되었으며, `LEAST_REQUEST`로 대체되었습니다.

**마이그레이션:**

```yaml
# ❌ 구버전 (deprecated)
trafficPolicy:
  loadBalancer:
    simple: LEAST_CONN

# ✅ 신규 버전
trafficPolicy:
  loadBalancer:
    simple: LEAST_REQUEST
```

## Consistent Hash 상세

Consistent Hash는 특정 속성을 기반으로 항상 같은 엔드포인트로 라우팅하여 세션 유지를 보장합니다.

### Consistent Hash 동작 원리

```mermaid
flowchart TD
    subgraph Requests[요청]
        R1[User A<br/>Cookie: abc123]
        R2[User B<br/>Cookie: def456]
        R3[User A<br/>Cookie: abc123]
    end

    subgraph Hash[해시 계산]
        H1[Hash abc123<br/>→ 0x1A2B]
        H2[Hash def456<br/>→ 0x7C8D]
        H3[Hash abc123<br/>→ 0x1A2B]
    end

    subgraph Ring[Consistent Hash Ring]
        P1[Pod 1<br/>0x0000-0x4FFF]
        P2[Pod 2<br/>0x5000-0x9FFF]
        P3[Pod 3<br/>0xA000-0xFFFF]
    end

    R1 -->|1| H1
    H1 -->|2| P1
    R2 -->|1| H2
    H2 -->|2| P2
    R3 -->|1| H3
    H3 -->|2| P1

    %% 스타일 정의
    classDef request fill:#f9f9f9,stroke:#333,stroke-width:1px,color:black;
    classDef hash fill:#326CE5,stroke:#333,stroke-width:1px,color:white;
    classDef pod fill:#00C7B7,stroke:#333,stroke-width:1px,color:white;

    %% 클래스 적용
    class R1,R2,R3 request;
    class H1,H2,H3 hash;
    class P1,P2,P3 pod;
```

### 1. HTTP Header 기반

특정 HTTP 헤더 값으로 해시를 계산합니다.

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: user-hash
spec:
  host: api-service
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: "x-user-id"
```

**사용 사례:**

* 사용자별 세션 유지
* API 키 기반 라우팅
* 테넌트별 격리

### 2. HTTP Cookie 기반

쿠키 값으로 해시를 계산하며, 쿠키가 없으면 자동 생성합니다.

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: cookie-hash
spec:
  host: web-service
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpCookie:
          name: "user-session"
          ttl: 3600s  # 1시간 TTL
```

**사용 사례:**

* 웹 애플리케이션 세션 유지
* 쇼핑 카트 유지
* 사용자 경험 일관성

### 3. Source IP 기반

클라이언트의 소스 IP 주소로 해시를 계산합니다.

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: source-ip-hash
spec:
  host: api-service
  trafficPolicy:
    loadBalancer:
      consistentHash:
        useSourceIp: true
```

**사용 사례:**

* IP 기반 세션 유지
* Rate limiting (IP별)
* 지역별 캐시

**주의사항:**

* NAT 뒤에 있는 클라이언트는 같은 파드로 라우팅될 수 있음
* 프록시 사용 시 실제 클라이언트 IP를 확인해야 함

### 4. HTTP Query Parameter 기반

쿼리 파라미터 값으로 해시를 계산합니다.

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: query-param-hash
spec:
  host: api-service
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpQueryParameterName: "user_id"
```

**사용 사례:**

* RESTful API에서 리소스 ID 기반 라우팅
* 캐시 친화적 라우팅
* 샤딩 전략

### 5. Minimum Ring Size 설정

Consistent Hash Ring의 최소 크기를 설정하여 재분배를 최소화합니다.

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: hash-with-ring-size
spec:
  host: cache-service
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: "x-cache-key"
        minimumRingSize: 1024  # 기본값: 1024
```

**설명:**

* Ring size가 클수록 더 균등한 분배
* 파드 추가/제거 시 재분배되는 키의 비율 감소
* 메모리 사용량 약간 증가

**권장값:**

* 소규모 (< 10 파드): 1024 (기본값)
* 중규모 (10-50 파드): 2048
* 대규모 (50+ 파드): 4096

### Consistent Hash 조합 예제

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: advanced-consistent-hash
spec:
  host: api-service
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpCookie:
          name: "session-id"
          path: "/api"
          ttl: 7200s  # 2시간
        minimumRingSize: 2048
    connectionPool:
      http:
        maxRequestsPerConnection: 100
        idleTimeout: 300s
```

### Consistent Hash 주의사항

#### 1. 불균형 위험

```mermaid
flowchart LR
    subgraph Problem[문제 상황]
        Users[1000명 사용자]
        P1[Pod 1<br/>800명 ⚠️]
        P2[Pod 2<br/>150명]
        P3[Pod 3<br/>50명]
    end

    Users -->|80%| P1
    Users -->|15%| P2
    Users -->|5%| P3

    %% 스타일 정의
    classDef user fill:#f9f9f9,stroke:#333,stroke-width:1px,color:black;
    classDef overload fill:#FF6B6B,stroke:#333,stroke-width:1px,color:white;
    classDef normal fill:#00C7B7,stroke:#333,stroke-width:1px,color:white;

    %% 클래스 적용
    class Users user;
    class P1 overload;
    class P2,P3 normal;
```

**원인**: 특정 해시 값에 트래픽이 집중되는 경우

**해결책:**

* `minimumRingSize` 증가
* 여러 해시 키 조합 사용
* Bounded Load 알고리즘 고려 (Envoy 미지원)

#### 2. 파드 추가/제거 시 재분배

```yaml
# 파드 스케일 아웃 시
# - 기존: Pod 1, Pod 2, Pod 3
# - 신규: Pod 1, Pod 2, Pod 3, Pod 4
# - 결과: ~25%의 세션이 다른 파드로 재분배됨
```

**대응 방안:**

* Graceful shutdown 활용
* 세션 외부 저장소 사용 (Redis, Memcached)
* 서서히 스케일 조정

## Locality 기반 로드 밸런싱

Locality-based Load Balancing은 지리적으로 가까운 엔드포인트를 우선적으로 사용합니다.

### 기본 Locality 설정

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: locality-lb
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      localityLbSetting:
        enabled: true
```

### Locality 분배 비율 설정

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: locality-distribute
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      localityLbSetting:
        enabled: true
        distribute:
        - from: us-west/zone-1/*
          to:
            "us-west/zone-1/*": 80  # 80%는 같은 zone
            "us-west/zone-2/*": 20  # 20%는 다른 zone
```

### Locality Failover

한 지역이 실패하면 다른 지역으로 자동 전환합니다.

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: locality-failover
spec:
  host: api-service
  trafficPolicy:
    loadBalancer:
      localityLbSetting:
        enabled: true
        failover:
        - from: us-west
          to: us-east
```

### Multi-Region 예제

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: global-service-locality
spec:
  host: global-api
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
      localityLbSetting:
        enabled: true
        distribute:
        # US West 클라이언트
        - from: us-west/*
          to:
            "us-west/*": 90      # 90% 로컬
            "us-east/*": 10      # 10% 원격 (DR)
        # US East 클라이언트
        - from: us-east/*
          to:
            "us-east/*": 90
            "us-west/*": 10
        failover:
        - from: us-west
          to: us-east
        - from: us-east
          to: us-west
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s
```

**사용 사례:**

* Multi-region 배포
* 지연 시간 최소화
* 리전 간 장애 복구
* 비용 최적화 (같은 AZ 통신)

## Connection Pool 설정

로드 밸런싱과 함께 Connection Pool을 설정하여 성능을 최적화합니다.

### HTTP/1.1 Connection Pool

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: http1-connection-pool
spec:
  host: api-service
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
    connectionPool:
      tcp:
        maxConnections: 100        # 최대 연결 수
        connectTimeout: 3s         # 연결 타임아웃
      http:
        http1MaxPendingRequests: 50  # 대기 요청 수
        maxRequestsPerConnection: 100 # 연결당 최대 요청
        idleTimeout: 300s             # 유휴 연결 타임아웃
```

### HTTP/2 Connection Pool

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: http2-connection-pool
spec:
  host: grpc-service
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
    connectionPool:
      tcp:
        maxConnections: 50
      http:
        http2MaxRequests: 1000     # HTTP/2 동시 요청
        maxRequestsPerConnection: 0 # 무제한 (HTTP/2 멀티플렉싱)
        h2UpgradePolicy: UPGRADE    # HTTP/2 업그레이드 허용
```

## 실전 예제

### 예제 1: 고성능 API 서비스

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: api-high-performance
  namespace: production
spec:
  host: api-service
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
      warmupDurationSecs: 60  # 새 파드 워밍업
    connectionPool:
      tcp:
        maxConnections: 200
        connectTimeout: 5s
      http:
        http2MaxRequests: 500
        maxRequestsPerConnection: 100
        idleTimeout: 300s
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s
      maxEjectionPercent: 50
```

**사용 시나리오:**

* 고성능 REST API
* 응답 시간이 불균일한 요청
* 파드별 성능 차이가 있는 환경

### 예제 2: 사용자 세션 기반 라우팅

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: web-session-affinity
spec:
  host: web-frontend
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpCookie:
          name: "session-id"
          ttl: 7200s  # 2시간
        minimumRingSize: 2048
    connectionPool:
      tcp:
        maxConnections: 500
      http:
        http1MaxPendingRequests: 100
        maxRequestsPerConnection: 50
```

**사용 시나리오:**

* 웹 애플리케이션 세션 유지
* 쇼핑 카트 일관성
* 사용자별 캐시 활용

### 예제 3: Multi-Region 글로벌 서비스

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: global-api-multi-region
spec:
  host: global-api
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
      localityLbSetting:
        enabled: true
        distribute:
        # US West
        - from: us-west-1/*
          to:
            "us-west-1/*": 80
            "us-west-2/*": 15
            "us-east-1/*": 5
        # US East
        - from: us-east-1/*
          to:
            "us-east-1/*": 80
            "us-east-2/*": 15
            "us-west-1/*": 5
        # EU
        - from: eu-central-1/*
          to:
            "eu-central-1/*": 90
            "eu-west-1/*": 10
        failover:
        - from: us-west-1
          to: us-west-2
        - from: us-east-1
          to: us-east-2
    connectionPool:
      tcp:
        maxConnections: 1000
      http:
        http2MaxRequests: 2000
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 60s
```

**사용 시나리오:**

* 글로벌 SaaS 서비스
* 지연 시간 최소화
* 리전별 장애 복구
* Cross-AZ 트래픽 비용 절감

### 예제 4: 캐시 서비스 최적화

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: cache-service-optimized
spec:
  host: redis-cache
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: "x-cache-key"
        minimumRingSize: 4096  # 큰 링 사이즈로 재분배 최소화
    connectionPool:
      tcp:
        maxConnections: 100
        connectTimeout: 1s
      http:
        http1MaxPendingRequests: 20
        maxRequestsPerConnection: 1000
        idleTimeout: 600s
    outlierDetection:
      consecutiveErrors: 3
      interval: 10s
      baseEjectionTime: 30s
```

**사용 시나리오:**

* 캐시 히트율 최대화
* 일관된 캐시 키 라우팅
* 샤딩 전략

### 예제 5: 데이터베이스 연결 풀

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: database-connection-pool
spec:
  host: postgres-primary
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
    connectionPool:
      tcp:
        maxConnections: 50  # DB 연결 제한
        connectTimeout: 5s
      http:
        http1MaxPendingRequests: 10
        maxRequestsPerConnection: 100
    outlierDetection:
      consecutiveErrors: 3
      interval: 60s
      baseEjectionTime: 120s
```

**사용 시나리오:**

* 데이터베이스 연결 풀 관리
* 느린 쿼리 분산
* 연결 수 제한

### 예제 6: 대규모 트래픽 처리

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: high-traffic-service
spec:
  host: analytics-ingestion
  trafficPolicy:
    loadBalancer:
      simple: RANDOM  # 빠른 선택으로 오버헤드 최소화
    connectionPool:
      tcp:
        maxConnections: 5000
        connectTimeout: 1s
      http:
        http2MaxRequests: 10000
        maxRequestsPerConnection: 1000
        idleTimeout: 60s
    outlierDetection:
      consecutiveErrors: 10
      interval: 30s
      baseEjectionTime: 30s
      maxEjectionPercent: 20  # 대규모에서는 제한적 ejection
```

**사용 시나리오:**

* 이벤트 수집 (Analytics)
* 로그 수집
* 대용량 데이터 처리

## 알고리즘 선택 가이드

### 결정 트리

```mermaid
flowchart TD
    Start[로드 밸런싱 필요]

    Q1{세션 유지<br/>필요?}
    Q2{트래픽<br/>매우 높음?}
    Q3{응답 시간<br/>불균일?}
    Q4{지리적<br/>분산?}
    Q5{TCP<br/>프록시?}

    R1[CONSISTENT_HASH<br/>httpCookie 또는<br/>httpHeaderName]
    R2[RANDOM]
    R3[LEAST_REQUEST]
    R4[LEAST_REQUEST +<br/>Locality Setting]
    R5[PASSTHROUGH]
    R6[ROUND_ROBIN<br/>기본값]

    Start --> Q1
    Q1 -->|Yes| R1
    Q1 -->|No| Q2
    Q2 -->|Yes| R2
    Q2 -->|No| Q3
    Q3 -->|Yes| Q4
    Q3 -->|No| Q4
    Q4 -->|Yes| R4
    Q4 -->|No| Q5
    Q5 -->|Yes| R5
    Q5 -->|No| R6

    %% 스타일 정의
    classDef question fill:#326CE5,stroke:#333,stroke-width:1px,color:white;
    classDef result fill:#00C7B7,stroke:#333,stroke-width:1px,color:white;
    classDef start fill:#f9f9f9,stroke:#333,stroke-width:1px,color:black;

    %% 클래스 적용
    class Start start;
    class Q1,Q2,Q3,Q4,Q5 question;
    class R1,R2,R3,R4,R5,R6 result;
```

### 서비스 유형별 권장 알고리즘

| 서비스 유형             | 권장 알고리즘                   | 이유         |
| ------------------ | ------------------------- | ---------- |
| **REST API**       | LEAST\_REQUEST            | 응답 시간 일관성  |
| **GraphQL API**    | LEAST\_REQUEST            | 복잡한 쿼리 분산  |
| **gRPC**           | LEAST\_REQUEST            | 스트리밍 부하 균형 |
| **웹 프론트엔드**        | CONSISTENT\_HASH (cookie) | 세션 유지      |
| **WebSocket**      | CONSISTENT\_HASH (header) | 연결 유지      |
| **캐시 서비스**         | CONSISTENT\_HASH (header) | 캐시 히트율     |
| **분석/로그 수집**       | RANDOM                    | 대규모 처리     |
| **데이터베이스**         | LEAST\_REQUEST            | 연결 풀 관리    |
| **Static Content** | ROUND\_ROBIN              | 간단하고 충분    |
| **Message Queue**  | LEAST\_REQUEST            | 큐 부하 균형    |
| **배치 처리**          | LEAST\_REQUEST            | 작업 분산      |

### 트래픽 패턴별 선택

```yaml
# 1. 균일한 작은 요청 (< 10ms)
trafficPolicy:
  loadBalancer:
    simple: ROUND_ROBIN  # 간단하고 효율적

# 2. 불균일한 요청 (10ms ~ 1s+)
trafficPolicy:
  loadBalancer:
    simple: LEAST_REQUEST  # 부하 적응

# 3. 매우 큰 트래픽 (10,000+ RPS)
trafficPolicy:
  loadBalancer:
    simple: RANDOM  # 오버헤드 최소화

# 4. 세션 기반 (사용자 상태)
trafficPolicy:
  loadBalancer:
    consistentHash:
      httpCookie:
        name: "session-id"
        ttl: 3600s

# 5. Multi-region
trafficPolicy:
  loadBalancer:
    simple: LEAST_REQUEST
    localityLbSetting:
      enabled: true
```

## 모범 사례

### 1. 알고리즘 선택 원칙

**✅ 좋은 예:**

```yaml
# 응답 시간이 불균일한 API
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: api-service-best-practice
spec:
  host: api-service
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST  # 부하 적응
      warmupDurationSecs: 60  # 새 파드 워밍업
```

**❌ 나쁜 예:**

```yaml
# 응답 시간이 불균일한데 ROUND_ROBIN 사용
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: api-service-bad-practice
spec:
  host: api-service
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN  # 부하 불균형 발생
```

### 2. Connection Pool 필수 설정

로드 밸런싱과 함께 항상 Connection Pool을 설정하세요:

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: complete-lb-config
spec:
  host: api-service
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
    connectionPool:  # 필수
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 50
        maxRequestsPerConnection: 100
```

### 3. Outlier Detection 조합

Circuit Breaker와 함께 사용하여 장애 파드 제거:

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: lb-with-outlier
spec:
  host: api-service
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
    outlierDetection:  # 필수
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s
```

### 4. Consistent Hash 사용 시 주의

```yaml
# ✅ 좋은 예: 세션 저장소 사용
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: web-with-redis-session
  annotations:
    description: "Uses Redis for session storage"
spec:
  host: web-frontend
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpCookie:
          name: "session-id"
          ttl: 3600s
    # Redis 세션 저장소를 사용하므로
    # 파드 재시작 시에도 세션 유지
```

```yaml
# ⚠️ 주의: 로컬 세션만 사용
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: web-local-session-only
  annotations:
    warning: "No external session storage - sessions lost on pod restart"
spec:
  host: web-frontend
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpCookie:
          name: "session-id"
          ttl: 3600s
    # ⚠️ 문제: 파드 재시작 시 세션 손실
```

### 5. Multi-Region 배포

```yaml
# ✅ 좋은 예: Locality + Failover
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: multi-region-best-practice
spec:
  host: global-service
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
      localityLbSetting:
        enabled: true
        distribute:
        - from: us-west/*
          to:
            "us-west/*": 80
            "us-east/*": 20
        failover:  # 필수
        - from: us-west
          to: us-east
```

### 6. 모니터링 및 메트릭

로드 밸런싱 효과를 모니터링하세요:

```yaml
# Prometheus 쿼리
# 파드별 요청 분포
sum by (destination_workload) (rate(istio_requests_total[5m]))

# 파드별 응답 시간
histogram_quantile(0.95,
  sum by (destination_workload, le) (
    rate(istio_request_duration_milliseconds_bucket[5m])
  )
)

# 활성 연결 수
sum by (destination_workload) (envoy_cluster_upstream_cx_active)
```

### 7. 점진적 적용

```yaml
# 1단계: 기본 ROUND_ROBIN
simple: ROUND_ROBIN

# 2단계: 모니터링 후 LEAST_REQUEST
simple: LEAST_REQUEST

# 3단계: Connection Pool 추가
simple: LEAST_REQUEST
connectionPool: ...

# 4단계: Outlier Detection 추가
simple: LEAST_REQUEST
connectionPool: ...
outlierDetection: ...
```

### 8. 문서화

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: api-service-lb
  annotations:
    # 설정 이유
    purpose: "Distribute load based on active requests"

    # 알고리즘 선택 근거
    algorithm-rationale: |
      - LEAST_REQUEST: Response times vary 10ms-500ms
      - warmupDurationSecs: New pods need 60s to warm up cache

    # 테스트 결과
    test-results: |
      - Load test: 1000 RPS evenly distributed
      - P95 latency: 150ms (improved from 300ms with ROUND_ROBIN)
      - No pod overload observed

    # 모니터링
    monitoring: |
      - Dashboard: grafana.example.com/d/istio-workload
      - Alert: High P95 latency > 500ms
```

## 문제 해결

### 불균형한 부하 분산

**증상:**

```bash
# 파드별 CPU 사용률 확인
kubectl top pods -n production

# 출력:
# NAME                CPU    MEMORY
# api-pod-1           80%    2Gi
# api-pod-2           20%    1Gi
# api-pod-3           15%    1Gi
```

**원인 및 해결:**

```yaml
# 1. ROUND_ROBIN → LEAST_REQUEST로 변경
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: api-service-fix
spec:
  host: api-service
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST  # 변경

# 2. Warmup 추가
      warmupDurationSecs: 60

# 3. Outlier Detection 추가
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s
```

### Consistent Hash 불균형

**증상:**

```bash
# Envoy 메트릭 확인
kubectl exec -it pod-name -c istio-proxy -- \
  curl localhost:15000/stats/prometheus | grep upstream_rq_total

# 특정 파드에 요청 집중
```

**해결:**

```yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: hash-fix
spec:
  host: api-service
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: "x-user-id"
        minimumRingSize: 4096  # 2048 → 4096 증가
```

### Locality 기반 라우팅이 작동하지 않음

**확인 사항:**

```bash
# 1. 파드의 Locality 레이블 확인
kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels.topology\.kubernetes\.io/region}{"\t"}{.metadata.labels.topology\.kubernetes\.io/zone}{"\n"}{end}'

# 2. Istio Proxy 설정 확인
istioctl proxy-config endpoints pod-name | grep locality

# 3. DestinationRule 적용 확인
istioctl proxy-config clusters pod-name --fqdn api-service.default.svc.cluster.local -o json | jq '.[] | .localityLbEndpoints'
```

**수정:**

```yaml
# 노드 레이블 확인 및 추가
apiVersion: v1
kind: Node
metadata:
  labels:
    topology.kubernetes.io/region: us-west
    topology.kubernetes.io/zone: us-west-1
```

## 참고 자료

* [Istio Load Balancing](https://istio.io/latest/docs/reference/config/networking/destination-rule/#LoadBalancerSettings)
* [Envoy Load Balancing](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/load_balancing)
* [Consistent Hashing](https://www.toptal.com/big-data/consistent-hashing)
* [Locality Load Balancing](https://istio.io/latest/docs/tasks/traffic-management/locality-load-balancing/)