# 로드 밸런서 (Load Balancer)

## 1. 개요
로드 밸런서(Load Balancer)는 네트워크 트래픽을 여러 대의 백엔드 서버로 효율적으로 분산시켜 시스템의 가용성을 높이고 응답 시간을 단축하는 장치 또는 소프트웨어를 말한다.

단일 서버로 서비스를 운영할 경우, 트래픽 급증 시 서버 과부하로 인한 성능 저하가 발생하며, 서버 장애 시 서비스 전체가 중단되는 **단일 장애점(SPOF, Single Point of Failure)** 문제가 발생한다. 로드 밸런서는 이러한 위험을 방지하기 위해 트래픽을 분산함으로써 시스템의 확장성(Scalability)과 신뢰성(Reliability)을 확보하는 핵심적인 역할을 수행한다.

## 2. 동작 원리 및 구조
로드 밸런서는 클라이언트와 서버 사이의 중개자(Proxy) 역할을 수행한다. 클라이언트가 서비스 주소로 요청을 보내면, 로드 밸런서가 미리 정의된 알고리즘에 따라 가용한 서버를 선택하여 요청을 전달하고, 서버로부터 받은 응답을 다시 클라이언트에게 반환한다.

### [표 1] 단일 서버 구조 vs 로드 밸런싱 적용 구조 비교

| 구분 | 단일 서버 구조 (Single Server) | 로드 밸런싱 구조 (Load Balanced) |
| :--- | :--- | :--- |
| **트래픽 처리** | 모든 요청이 하나의 서버로 집중 | 여러 서버로 트래픽 분산 처리 |
| **가용성** | 서버 장애 시 서비스 전체 중단 | 일부 서버 장애 시 타 서버가 대체 처리 |
| **확장성** | 수직 확장(Scale-up)만 가능 | 수평 확장(Scale-out) 가능 |
| **응답 속도** | 부하 증가 시 응답 시간 급증 | 부하 분산을 통해 일정한 응답 속도 유지 |

**주의: 로드 밸런서 자체의 SPOF 문제**
로드 밸런서가 모든 트래픽의 단일 진입점이 되므로, 로드 밸런서 자체가 장애가 나면 전체 시스템이 중단되는 새로운 SPOF가 될 수 있다. 이를 해결하기 위해 두 대 이상의 로드 밸런서를 **Active-Passive**(한 대는 대기) 또는 **Active-Active**(모두 작동) 구조로 구성하여 고가용성(HA, High Availability)을 확보해야 한다.

## 3. 로드 밸런싱 알고리즘
로드 밸런서는 어떤 서버에 요청을 보낼지 결정하기 위해 다양한 알고리즘을 사용한다.

### 주요 알고리즘 특징
*   **라운드 로빈 (Round Robin):** 모든 서버에 순차적으로 요청을 배분하는 방식이다. 서버들의 사양이 동일할 때 적합하다.
*   **가중치 라운드 로빈 (Weighted Round Robin):** 서버마다 가중치를 부여하여 성능이 좋은 서버에 더 많은 요청을 보내는 방식이다.
*   **최소 연결 (Least Connection):** 현재 연결된 세션 수가 가장 적은 서버로 요청을 보내는 방식이다. 처리 시간이 긴 요청이 많을 때 효율적이다.
*   **IP 해시 (IP Hash):** 클라이언트의 IP 주소를 해싱하여 특정 서버에 매핑하는 방식이다. 동일 사용자가 항상 동일한 서버에 접속해야 하는 경우에 사용한다.

### [표 2] 알고리즘별 장단점 및 선택 기준

| 알고리즘 | 장점 | 단점 | 적합한 사례 |
| :--- | :--- | :--- | :--- |
| **라운드 로빈** | 구현이 매우 단순함 | 서버 성능 차이를 반영 못 함 | 서버 사양이 동일한 환경 |
| **가중치 RR** | 서버 성능 차이 반영 가능 | 가중치 설정의 수동 관리 필요 | 서버 사양이 서로 다른 환경 |
| **최소 연결** | 동적 부하 분산 가능 | 연결 상태를 계속 추적해야 함 | 세션 유지 시간이 긴 서비스 |
| **IP 해시** | 세션 일관성 유지 가능 | 특정 서버에 부하가 쏠릴 수 있음 | 상태 저장(Stateful) 서비스 |

## 4. 계층별 분류 (L4 vs L7)
로드 밸런서는 OSI 7계층 모델 중 어느 계층에서 데이터를 처리하느냐에 따라 L4와 L7로 나뉜다.

### L4 로드 밸런서 (Transport Layer)
전송 계층에서 동작하며, **IP 주소와 포트 번호**만을 기준으로 트래픽을 분산한다. 데이터 내용을 확인하지 않으므로 처리 속도가 매우 빠르고 효율적이다. 세션 유지가 필요한 경우 주로 **IP 해시** 방식을 사용하여 특정 클라이언트 IP를 특정 서버로 고정한다.

### L7 로드 밸런서 (Application Layer)
응용 계층에서 동작하며, **HTTP 헤더, 쿠키, URL 경로** 등 실제 데이터 내용을 분석하여 트래픽을 분산한다. 정교한 라우팅이 가능하며, **쿠키(Cookie)**를 활용하여 L4보다 훨씬 정교하고 유연하게 세션을 유지(Sticky Session)할 수 있다.

### [다이어그램] L4 vs L7 동작 차이
*   **L4 동작:** `클라이언트` $\rightarrow$ `[IP/Port 확인]` $\rightarrow$ `백엔드 서버`
*   **L7 동작:** `클라이언트` $\rightarrow$ `[HTTP 헤더/URL/쿠키 분석]` $\rightarrow$ `특정 서비스 서버 (예: /api $\rightarrow$ API 서버)`

### [표 3] L4 로드 밸런서 vs L7 로드 밸런서 상세 비교

| 비교 항목 | L4 로드 밸런서 | L7 로드 밸런서 |
| :--- | :--- | :--- |
| **판단 기준** | IP, TCP/UDP 포트 | URL, HTTP 헤더, 쿠키, 페이로드 |
| **처리 속도** | 매우 빠름 (단순 패킷 전달) | 상대적으로 느림 (콘텐츠 분석 필요) |
| **지능적 라우팅** | 불가능 (단순 분산) | 가능 (예: `/api` → API 서버) |
| **보안 기능** | 기본적 네트워크 필터링 | WAF(웹 방화벽) 연동 및 정교한 제어 |
| **세션 유지 방식** | IP 해시 기반 (단순함) | 쿠키 기반 (정교함) |
| **복잡도** | 낮음 | 높음 |

## 5. 주요 기능 및 고급 설정
*   **헬스 체크 (Health Check):** 로드 밸런서가 주기적으로 백엔드 서버에 신호를 보내 정상 작동 여부를 확인하는 기능이다. 장애가 발생한 서버는 자동으로 분산 대상에서 제외한다.
*   **스티키 세션 (Sticky Session):** 클라이언트의 요청을 처음 처리한 서버가 계속해서 처리하도록 고정하는 기능이다. 세션 정보가 서버 로컬에 저장되어 있을 때 필수적이며, L4에서는 IP 기반으로, L7에서는 쿠키 기반으로 구현된다.
*   **SSL 종단점 (SSL Termination):** 클라이언트와 로드 밸런서 사이의 암호화 통신(HTTPS)을 로드 밸런서에서 복호화하여 백엔드 서버로 전달하는 방식이다. 서버의 암복호화 부하를 줄여준다.

## 6. 장애 조치 (Failover)
**장애 조치(Failover)**란 시스템의 일부 구성 요소에 장애가 발생했을 때, 예비 시스템이나 다른 정상 서버가 그 기능을 즉시 이어받아 서비스 중단을 최소화하는 메커니즘이다.

로드 밸런서 환경에서의 Failover는 다음과 같이 작동한다:
1.  **감지:** 헬스 체크를 통해 특정 서버의 응답 없음 또는 오류를 감지한다.
2.  **격리:** 해당 서버를 'Unhealthy' 상태로 표시하고 트래픽 전송 목록에서 제외한다.
3.  **재배분:** 기존에 해당 서버로 가던 트래픽을 정상 상태인 다른 서버들로 즉시 분산한다.
4.  **복구:** 서버가 다시 정상 상태로 돌아오면 헬스 체크를 통해 이를 확인하고 다시 트래픽 분산 대상에 포함시킨다.

## 7. GSLB (Global Server Load Balancing)
**GSLB**는 지리적으로 서로 다른 데이터 센터(Region)에 분산된 서버들 사이에서 트래픽을 분산하는 기술이다. 일반적인 로드 밸런서가 단일 데이터 센터 내부의 분산을 담당한다면, GSLB는 DNS(Domain Name System) 수준에서 동작하여 전 세계 사용자에게 가장 가까운 데이터 센터의 IP를 응답한다.

*   **지리적 근접성:** 사용자의 위치에 따라 최단 거리의 서버로 유도하여 지연 시간(Latency)을 최소화한다.
*   **재해 복구 (DR):** 특정 지역의 데이터 센터 전체가 마비되었을 때, 다른 지역의 데이터 센터로 트래픽을 완전히 전환하여 서비스 연속성을 보장한다.

## 8. 구현 방식 및 솔루션
로드 밸런서는 구현 형태에 따라 하드웨어 방식과 소프트웨어 방식으로 나뉜다.

### 하드웨어 방식 vs 소프트웨어 방식 비교
| 구분 | 하드웨어 방식 (L4 Switch) | 소프트웨어 방식 (SW LB) |
| :--- | :--- | :--- |
| **특징** | 전용 ASIC 칩을 탑재한 물리 장비 | 일반 서버에 설치하는 애플리케이션 |
| **성능** | 매우 강력한 처리량, 낮은 지연 시간 | 서버 사양 및 OS 최적화에 의존 |
| **비용** | 도입 및 유지보수 비용 매우 높음 | 상대적으로 저렴 (오픈소스 활용 가능) |
| **유연성** | 설정 변경 및 확장이 어려움 | 설정 변경이 자유롭고 배포가 빠름 |
| **예시** | F5 Big-IP, Citrix ADC | Nginx, HAProxy |

*   **클라우드 솔루션:** 클라우드 제공사가 관리형 서비스로 제공하는 방식이다. (예: AWS ELB, Azure Load Balancer, Google Cloud Load Balancing)

### [코드 예제] Nginx를 이용한 업스트림 설정
```nginx
http {
    # 백엔드 서버 그룹 정의 (업스트림)
    upstream my_backend_servers {
        # 가중치 기반 라운드 로빈 설정
        server 10.0.0.1:8080 weight=3; 
        server 10.0.0.2:8080 weight=1;
        server 10.0.0.3:8080 backup; # 메인 서버 장애 시에만 작동
    }

    server {
        listen 80;
        location / {
            # 정의된 업스트림 그룹으로 요청 전달
            proxy_pass http://my_backend_servers;
            
            # 로드 밸런서를 거치면 백엔드 서버는 LB의 IP만 보게 됨.
            # 따라서 클라이언트의 실제 IP를 헤더에 담아 전달하여 서버가 인식하게 함.
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }
    }
}
```

> **Note: 최신 트렌드 (Service Mesh)**
> 최근 마이크로서비스 아키텍처(MSA)에서는 외부 진입점의 로드 밸런서 외에도, 서비스 간(East-West) 통신을 정교하게 제어하기 위해 **서비스 메시(Service Mesh, 예: Istio, Linkerd)**를 도입한다. 이는 사이드카(Sidecar) 프록시를 통해 서비스 내부의 로드 밸런싱, 트래픽 제어, 관찰 가능성을 제공한다.

## 9. 로드 밸런서 선택 가이드 (체크리스트)
서비스 환경에 맞는 로드 밸런서를 선택하기 위해 다음 항목을 검토하십시오.

- [ ] **트래픽의 성격:** 단순 패킷 분산만 필요한가(L4), 아니면 URL/헤더 기반의 정교한 라우팅이 필요한가(L7)?
- [ ] **예산 및 인프라:** 고성능 전용 장비가 필요한가(Hardware), 아니면 유연한 오픈소스/클라우드 환경이 적합한가(Software/Cloud)?
- [ ] **세션 관리:** 사용자의 상태 정보(Session)를 유지해야 하는가? (Sticky Session 필요 여부)
- [ ] **서비스 범위:** 단일 데이터 센터 내의 분산인가, 아니면 글로벌 서비스인가? (GSLB 필요 여부)
- [ ] **보안 요구사항:** SSL 인증서 관리를 로드 밸런서에서 통합 처리할 것인가? (SSL Termination 필요 여부)
- [ ] **확장 계획:** 향후 서버 대수가 급격히 늘어날 가능성이 있는가? (Auto-scaling 연동 여부)