Load Balancer

🤔 Load Balancer란??

로드 밸런서(Load Balancer)는 클라이언트로부터 들어오는 요청(트래픽)을 여러 대의 서버에 고르게 분산시켜주는 장비 또는 소프트웨어이다. 서버가 한 대일 경우 트래픽이 몰리면 응답 속도가 느려지거나 장애가 발생할 수 있는데, 로드 밸런서는 여러 대의 서버(서버 풀, Server Pool) 앞단에 위치하여 요청을 분배함으로써 특정 서버에 부하가 집중되지 않도록 조율하는 역할을 한다.

클라이언트 입장에서는 로드 밸런서의 가상 IP(VIP) 하나만 바라보게 되고, 실제로 어떤 서버가 요청을 처리하는지는 알 필요가 없다. 즉 로드 밸런서는 클라이언트와 서버 사이의 중개자(Reverse Proxy) 역할을 하면서, 뒷단 서버들의 구성이 바뀌어도 클라이언트에는 영향을 주지 않는 추상화 계층을 제공한다.

⚙️ 로드 밸런서의 역할

• 🚦 Distribute Traffic (트래픽 분산)
  • Round Robin, Least Connections, IP Hash 등의 알고리즘을 이용해 여러 서버에 요청을 균등하게 분배한다.
  • 특정 서버에만 트래픽이 몰리는 병목 현상을 방지한다.
• 📈 Scale Applications (확장성 제공)
  • 트래픽이 증가하면 서버를 수평으로 확장(Scale-out)하고, 로드 밸런서가 새로 추가된 서버를 자동으로 풀에 포함시켜 트래픽을 분산한다.
  • 반대로 트래픽이 줄어들면 서버를 줄이는 Scale-in도 유연하게 대응할 수 있다.
• ⚡ Improve Performance (성능 향상)
  • 각 서버의 부하를 낮춰 응답 시간을 단축시킨다.
  • SSL Termination(SSL 처리를 로드 밸런서가 대신 수행), 캐싱, 압축 등을 통해 백엔드 서버의 연산 부담을 줄여준다.
• 🛡️ Improve Availability (가용성 향상)
  • Health Check를 통해 각 서버의 상태를 주기적으로 확인하고, 장애가 발생한 서버는 트래픽 분배 대상에서 자동으로 제외한다.
  • 특정 서버가 다운되더라도 나머지 서버가 요청을 처리하므로 서비스 전체의 무중단(High Availability)을 보장할 수 있다.

🧩 로드 밸런서 타입

🖥️ 하드웨어 로드밸런서

• F5 BIG-IP, Citrix ADC(NetScaler) 등 물리 장비 형태로 제공되는 로드 밸런서이다.
• 전용 하드웨어(ASIC)로 트래픽을 처리하기 때문에 매우 높은 처리량과 낮은 지연 시간을 보장한다.
• 사용 시점: 대규모 금융권, 통신사 등 트래픽 양이 매우 많고 초저지연이 요구되며, 초기 도입 비용(CAPEX)을 감당할 수 있는 온프레미스 데이터센터 환경에서 주로 사용한다.

💾 소프트웨어 로드밸런서

• Nginx, HAProxy, Envoy 등 일반 서버(리눅스 등) 위에 설치해서 사용하는 소프트웨어이다.
• 하드웨어 대비 비용이 저렴하고, 설정 변경이나 스케일 조정이 유연하다.
• 사용 시점: 스타트업이나 중소 규모 서비스처럼 비용 효율성과 유연한 커스터마이징(라우팅 규칙, 캐싱 등)이 중요한 경우, 혹은 컨테이너/쿠버네티스 환경에서 Ingress Controller로 사용하는 경우에 적합하다.

☁️ 클라우드 로드밸런서

• AWS ELB(ALB/NLB), GCP Load Balancing, Azure Load Balancer처럼 클라우드 벤더가 관리형 서비스로 제공하는 로드 밸런서이다.
• 인프라 관리(HA 구성, 패치, 장애 대응)를 벤더가 대신 해주며, 트래픽에 따라 자동으로 확장(Auto Scaling)된다.
• 사용 시점: 클라우드 네이티브 환경에서 운영 부담 없이 빠르게 배포하고, 트래픽 변동 폭이 큰 서비스(예: 이벤트성 트래픽 급증)에 자동으로 대응하고 싶을 때 사용한다.

🔌 L4 로드밸런서

• OSI 4계층(Transport Layer)에서 동작하며, IP 주소와 포트 정보만 보고 트래픽을 분산한다.
• 패킷의 내용(HTTP 헤더, URL 등)을 들여다보지 않기 때문에 처리 속도가 빠르고 오버헤드가 적다.
• 사용 시점: HTTP뿐 아니라 TCP/UDP 기반의 다양한 프로토콜(DB 커넥션, 게임 서버 등)을 분산해야 하거나, 최고 수준의 처리 성능이 필요한 경우에 사용한다.

🌐 L7 로드밸런서

• OSI 7계층(Application Layer)에서 동작하며, HTTP 헤더, URL 경로, 쿠키 등 애플리케이션 데이터를 기반으로 라우팅한다.
• /api는 API 서버로, /static은 정적 파일 서버로 보내는 등 콘텐츠 기반 라우팅이 가능하다.
• 사용 시점: 마이크로서비스 아키텍처처럼 URL 경로나 헤더에 따라 다른 백엔드로 요청을 분기해야 하거나, SSL Termination·쿠키 기반 세션 유지(Sticky Session) 같은 애플리케이션 레벨 기능이 필요한 경우에 사용한다.

🌍 Global Server Load Balancer (GSLB)

• 단일 데이터센터가 아닌, 지리적으로 분산된 여러 데이터센터/리전에 걸쳐 트래픽을 분산하는 로드 밸런서이다.
• DNS 기반으로 동작하며, 사용자의 위치에서 가장 가까운(혹은 가장 응답이 빠른) 리전으로 트래픽을 라우팅한다.
• 사용 시점: 글로벌 서비스에서 사용자와 지리적으로 가까운 서버로 연결해 지연 시간을 줄이거나, 한 리전 전체에 장애가 발생했을 때 다른 리전으로 트래픽을 우회시켜 재해 복구(DR)를 수행해야 하는 경우에 사용한다.

🔀 Load Balancing Algorithms

1️⃣ Round Robin

• 동작 방식: 서버 목록을 순서대로 돌아가며 요청을 하나씩 배분한다. 예를 들어 서버가 A, B, C 세 대라면 요청은 A → B → C → A → B → C 순서로 전달된다.
• 적용 상황: 모든 서버의 스펙(CPU, 메모리 등)이 동일하고, 요청을 처리하는 데 걸리는 시간도 비슷한 경우에 적합하다. 구현이 단순해서 가장 기본적으로 많이 쓰인다.

2️⃣ Sticky Round Robin

• 동작 방식: 기본적인 Round Robin 방식으로 서버를 배분하되, 한 번 특정 클라이언트가 특정 서버에 연결되면 이후 요청도 계속 같은 서버로 보낸다(세션 유지, Session Affinity). 보통 쿠키나 클라이언트 정보를 이용해 매핑을 기억한다.
• 적용 상황: 로그인 세션 정보나 장바구니 데이터처럼 서버의 로컬 메모리(인메모리 세션)에 상태를 저장하는 애플리케이션에서, 같은 사용자의 요청이 항상 같은 서버로 가야 할 때 사용한다. 다만 특정 서버에 특정 사용자들이 몰릴 경우 부하가 불균등해질 수 있다는 단점이 있다.

3️⃣ Weighted Round Robin

• 동작 방식: 각 서버에 가중치(Weight)를 부여하고, 가중치가 높은 서버일수록 더 많은 요청을 받도록 분배한다. 예를 들어 A 서버의 가중치가 3, B 서버가 1이라면 A는 B보다 3배 많은 요청을 받는다.
• 적용 상황: 서버 스펙이 서로 다른 경우(예: 고성능 서버와 저성능 서버가 혼재된 환경)에 성능에 비례해 트래픽을 배분하고 싶을 때 사용한다. 신규 서버를 점진적으로 트래픽에 노출시키는 카나리 배포 상황에서도 활용된다.

4️⃣ IP/URL Hash

• 동작 방식: 클라이언트의 IP 주소나 요청 URL을 해시 함수에 입력해 나온 값을 기준으로 항상 동일한 서버로 라우팅한다. 같은 입력값이면 항상 같은 해시 결과가 나오므로 동일 서버로 고정된다.
• 적용 상황: Sticky Round Robin과 유사하게 세션 유지가 필요할 때 사용하며, 특히 별도의 쿠키 저장 없이도 클라이언트 IP만으로 세션 친화성을 보장하고 싶은 경우에 적합하다. 또한 URL Hash는 캐싱 서버 앞단에서 동일한 콘텐츠 요청을 항상 같은 캐시 서버로 보내 캐시 적중률(Cache Hit Ratio)을 높이고 싶을 때 사용한다.

5️⃣ Least Connections

• 동작 방식: 현재 활성 커넥션(진행 중인 요청) 수가 가장 적은 서버로 요청을 우선 전달한다.
• 적용 상황: 요청마다 처리 시간의 편차가 큰 경우(어떤 요청은 금방 끝나고 어떤 요청은 오래 걸리는 경우)에 적합하다. Round Robin은 순서대로만 배분하기 때문에 특정 서버에 오래 걸리는 요청이 몰릴 수 있는데, Least Connections는 실시간 부하 상태를 반영해 더 균형 잡힌 분배가 가능하다.

6️⃣ Least Time (Least Response Time)

• 동작 방식: 활성 커넥션 수뿐 아니라 각 서버의 평균 응답 시간(Latency)까지 함께 고려해서, 가장 빠르게 응답할 것으로 예상되는 서버로 요청을 전달한다.
• 적용 상황: 서버 간 성능 편차나 네트워크 지연 편차가 있어 단순히 커넥션 수만으로는 최적의 서버를 판단하기 어려운 경우에 사용한다. 실시간으로 응답 속도가 가장 좋은 서버를 선택하므로 사용자 체감 성능(Latency)을 최우선으로 고려해야 하는 서비스에 적합하다.

📊 Key Metrics

로드 밸런서가 제대로 동작하고 있는지, 그리고 그 뒤에 있는 서버들이 건강한 상태인지를 파악하려면 아래와 같은 지표들을 모니터링해야 한다.

🚗 1. Traffic Metrics

• Request Rate: 초당 들어오는 요청 수(RPS/QPS). 현재 시스템에 얼마나 많은 트래픽이 몰리고 있는지, 평소 대비 급증(스파이크)이나 급감이 있는지를 파악할 수 있다. 스케일 아웃/인 시점을 판단하는 핵심 지표다.
• Total Connections: 현재 유지되고 있는 전체 커넥션 수. 커넥션이 비정상적으로 계속 쌓이기만 한다면 서버가 요청을 제때 처리하지 못하고 있다는 신호일 수 있다.

⚡ 2. Performance Metrics

• Response Time: 요청이 들어와서 응답이 나갈 때까지 걸린 전체 시간. 사용자가 체감하는 서비스 속도를 직접적으로 보여준다.
• Latency: 네트워크 왕복이나 처리 대기 등으로 인한 지연 시간. Response Time 중 순수 처리 시간 외적인 지연 요소(네트워크 구간, 큐잉 등)를 분리해서 병목 구간을 찾아낼 수 있다.
• Throughput: 단위 시간당 실제로 처리해낸 데이터량/요청량. 시스템이 실질적으로 얼마나 많은 일을 소화하고 있는지를 보여주며, Request Rate와 비교하면 시스템이 유입 트래픽을 감당하고 있는지(밀리고 있지 않은지) 판단할 수 있다.

💓 3. Health Metrics

• Server Health Checks: 각 백엔드 서버가 정상 응답 중인지 주기적으로 확인한 결과. 어떤 서버가 트래픽을 받을 준비가 되어 있는지 실시간으로 알 수 있다.
• Failed Health Checks: Health Check에 실패한 횟수. 특정 서버가 반복적으로 실패한다면 해당 서버에 장애가 발생했거나 곧 장애로 이어질 가능성이 높다는 조기 경고 신호다.

🚨 4. Error Metrics

• HTTP Error Rates: 4xx, 5xx 같은 에러 응답의 비율. 클라이언트 요청 자체의 문제(4xx)인지 서버/백엔드 문제(5xx)인지 구분해서 장애 원인을 좁혀나갈 수 있다.
• Dropped Connections: 정상적으로 완료되지 못하고 끊긴 커넥션 수. 서버 과부하, 타임아웃, 네트워크 불안정 등으로 사용자 요청이 유실되고 있는지를 알 수 있다.

🏋️ 5. Load Metrics

• CPU Utilization: 백엔드 서버들의 CPU 사용률. 특정 서버에 트래픽이 쏠려 CPU가 과부하 상태인지, 전체적으로 스케일 아웃이 필요한 시점인지를 판단하는 근거가 된다.
• Memory Utilization: 메모리 사용률. 메모리 누수(Leak)나 과도한 캐싱으로 인한 리소스 부족 여부를 파악할 수 있다.
• Load Distribution: 서버별로 트래픽이 얼마나 고르게 분산되고 있는지. 로드 밸런싱 알고리즘이 의도한 대로 균등하게 동작하고 있는지, 특정 서버에 편중이 발생하고 있는지를 확인할 수 있다.

🔒 6. Security Metrics

• TLS Handshake Time: HTTPS 연결 시 TLS 핸드셰이크에 걸리는 시간. 이 값이 커지면 초기 연결 지연의 원인이 될 수 있고, 로드 밸런서나 서버의 암호화 처리 부하를 파악하는 데 사용된다.
• TLS Error Rates: 인증서 만료, 프로토콜 불일치 등으로 인한 TLS 연결 실패 비율. 보안 설정 오류나 인증서 관리 문제를 조기에 발견할 수 있다.

✅ 7. Availability Metrics

• Uptime: 서비스가 정상적으로 가동된 시간의 비율. 시스템의 전반적인 신뢰성과 SLA 충족 여부를 보여주는 대표 지표다.
• Failover Events: 장애 발생 시 트래픽이 다른 서버/리전으로 전환된 이력. 페일오버가 얼마나 자주, 어떤 상황에서 발생하는지를 통해 인프라의 취약 지점을 파악할 수 있다.