Load Balancing Algorithms

로드 밸런싱 알고리즘의 종류

로드밸런싱 알고리즘은 클라이언트 요청을 여러 서버로 효율적으로 분산시켜 시스템의 부하를 줄이고, 성능과 가용성을 높이기 위한 방식이다. 다음은 대표적인 로드밸런싱 알고리즘의 종류와 특징이다.

1. 라운드 로빈 (Round Robin)

요청:   R1   R2   R3   R4   R5   R6
        ↓    ↓    ↓    ↓    ↓    ↓
서버:   S1 → S2 → S3 → S1 → S2 → S3

• 방식: 요청을 순차적으로 서버에 분산
• 장점: 구현이 간단하고 서버가 동일한 성능일 때 효율적
• 단점: 서버의 처리 능력을 고려하지 않음

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

요청:   R1   R2   R3   R4
        ↓    ↓    ↓    ↓
서버:   S1 → S1 → S2 → S1   *가중치: S1(2), S2(1)

• 방식: 각 서버에 가중치를 부여하여, 가중치가 높은 서버에 더 많은 요청 할당
• 장점: 서버 성능이 다를 때 유용
• 단점: 실시간 부하를 반영하지 못함

3. 최소 연결 수 (Least Connections)

현재 연결 수:
S1: 3   S2: 1   S3: 2

신규 요청 R1
        ↓
      선택된 서버: S2 (최소 연결)

• 방식: 현재 연결 수가 가장 적은 서버에 요청 할당
• 장점: 상태 기반 로드밸런싱, 긴 연결 요청에 유리
• 단점: 서버 상태 추적이 필요하므로 오버헤드 존재

4. 가중 최소 연결 수 (Weighted Least Connections)

서버 상태:
S1 [★★★☆] (75%)  
S2 [★☆☆☆] (50%)

신규 요청 R1
        ↓
      선택된 서버: S2

• 방식: 서버의 가중치와 현재 연결 수를 고려하여 결정
• 장점: 부하 분산에 더 정밀
• 단점: 설정 및 모니터링 복잡성 증가

5. IP 해시 (IP Hashing)

클라이언트 IP → 해시함수 → 고정된 서버

예)
192.168.0.10 → S1  
192.168.0.11 → S2  
192.168.0.12 → S3

• 방식: 클라이언트 IP를 해싱하여 특정 서버에 고정적으로 연결
• 장점: 세션 유지(Sticky Session)에 유리
• 단점: 서버 변경 시 해시 충돌, 불균형 가능성 있음

6. 랜덤 (Random)

요청:   R1   R2   R3
        ↓    ↓    ↓
서버:   S2   S1   S3   (무작위 선택)

• 방식: 서버를 무작위로 선택
• 장점: 단순, 소규모 트래픽에 적합
• 단점: 성능 최적화에 부적합

7. 응답 시간 기반 (Response Time Based)

서버 응답시간:
S1: 150ms  S2: 90ms  S3: 220ms

신규 요청 R1
        ↓
      선택된 서버: S2 (가장 빠름)

• 방식: 가장 빠른 응답 시간을 보이는 서버에 요청 전달
• 장점: 사용자 경험 향상
• 단점: 실시간 모니터링 필요

8. 유휴 시간 기반 (Least Response Time / Idle Time)

현재 시각: 10:00:00

서버 상태:
S1 → 마지막 요청 처리 시각: 09:59:45 (15초 유휴)
S2 → 마지막 요청 처리 시각: 09:59:55 (5초 유휴)
S3 → 마지막 요청 처리 시각: 09:59:30 (30초 유휴)

          [ 요청 R1 도착 ]
                   ↓
     ┌────────────────────────┐
     │ 각 서버의 유휴 시간 측정 │
     └────────────────────────┘
         ↓        ↓        ↓
      S1(15s)  S2(5s)   S3(30s)
                        ↓
          [ 요청 → S3에 할당 ]

• 방식: 가장 오래 유휴 상태였던 서버 선택
• 장점: 자원 효율성 향상
• 단점: 비동기 처리 시스템에선 비효율적일 수 있음

9. 커스텀/하이브리드 알고리즘

• 방식: 트래픽 특성, 서버 성능, 지역 등을 조합한 맞춤형 알고리즘
• 예시: 지역 기반(Geo-based), 애플리케이션 로직 기반, CDN 연동

필요한 환경에 따라 가장 적절한 알고리즘을 선택하거나 여러 알고리즘을 조합하여 사용하기도 한다. 예를 들어, NGINX는 라운드 로빈, 최소 연결, IP 해시 등을 지원하고, AWS ALB는 지연 시간 기반 라우팅을 제공하는 식으로 구성할수도 있다.

---

문제상황별 적절할 로드 밸런싱 알고리즘 선택

다음은 상황별로 문제가 되는 원인을 규명하고 적절한 로드 밸렁신 알고리즘을 선택하는 시나리오를 살펴보는 내용이다. 로드 밸런싱이 균형 있게 되지 않는 경우는 실제 운영 환경에서도 자주 발생하며, 그 원인과 해결책은 다음과 같다.

1. 서버 성능 차이 무시 (Fixed Round Robin 사용 시)

📍문제:

• 모든 서버를 동등하게 취급하지만, 일부 서버가 성능이 낮거나 과부하 상태여서 요청을 감당하지 못함.

✅ 해결책:

• 가중 라운드 로빈 (Weighted Round Robin) 또는
• 가중 최소 연결 (Weighted Least Connection) → 서버의 성능에 따라 가중치를 조정해 요청 분배

2. 세션 유지 문제 (Sticky Session 미적용)

📍문제:

• 사용자 세션이 분산되어 매 요청마다 다른 서버로 전송됨 → 로그인 유지가 안 되거나 상태가 깨짐.

✅ 해결책:

• IP Hashing 또는 Sticky Session 적용

  • 예: NGINX ip_hash, AWS ALB의 세션 스티키 설정
  • 혹은 Redis, DB 등 세션 클러스터링을 통해 상태 분산 저장

3. 지리적 위치로 인한 지연 (Global 서비스에서)

📍문제:

• 한국 유저가 미국 서버로 연결되는 등, 물리적 거리로 인해 지연 발생

✅ 해결책:

• Geo DNS 기반 로드밸런싱 (예: AWS Route 53, Cloudflare Load Balancer)
• CDN 연동 및 엣지 컴퓨팅 활용

4. 비정상 서버로 라우팅되는 문제 (Health Check 미설정)

📍문제:

• 다운되었거나 장애 난 서버로 계속 요청이 분배됨

✅ 해결책:

• 정기적인 헬스 체크(Health Check) 설정

  • HTTP 상태 코드, 응답 시간 등을 기준으로 판단
  • 대부분의 로드밸런서(L4/L7)는 헬스체크 지원

5. Connection 상태 기반 부하 고려 부족

📍문제:

• 오래 걸리는 연결(WebSocket, 대용량 파일 전송 등)이 계속 특정 서버에 몰림

✅ 해결책:

• Least Connections / Least Response Time 기반 알고리즘 적용
• **커넥션 유지형 트래픽(WebSocket 등)**은 별도의 서버 풀로 분리

6. 캐시/쿠키 기반 라우팅 오류

📍문제:

• 사용자 브라우저에 저장된 DNS 캐시 또는 쿠키 때문에 특정 서버로만 지속적으로 연결

✅ 해결책:

• DNS TTL을 짧게 설정하거나
• 세션 쿠키 전략 개선 / 서버 측 쿠키 무효화 정책 도입

7. 트래픽 쏠림 현상 (예: 특정 시간대, 이벤트 등)

📍문제:

• 대규모 이벤트 시 특정 서버로만 집중 → 응답 지연

✅ 해결책:

• Auto Scaling, Rate Limiting, Circuit Breaker
• Cloud-based LB + WAF로 트래픽 급증 제어

---

결론

🎯 로드밸런싱은 단순한 트래픽 분산이 아니라, 시스템의 성능·안정성·확장성·유지관리성을 좌우하는 핵심 요소이다. 각 알고리즘은 특정 상황에 적합하며, 장단점이 존재하므로 서비스의 특성과 요구사항에 따라 적절한 전략을 선택하는 것이 중요하다.

📌 주요 알고리즘 요약 비교:

알고리즘	특징	적합한 상황
Round Robin	순차적 분산, 구현 간단	서버 성능이 유사할 때
Weighted Round Robin	서버 성능 비례 요청 분산	서버 성능이 다를 때
Least Connections	현재 연결 수 기준 분산	긴 연결이 많은 환경 (예: 채팅, 다운로드)
Weighted Least Conn.	연결 수 + 성능 고려	비동일한 성능 + 장시간 연결 환경
IP Hash	동일 클라이언트는 항상 동일 서버 연결	세션 유지 필요 (로그인 등)
Random	무작위 분산	단순 테스트, 작은 규모
Response Time Based	실시간 응답 시간 기준	성능 최적화 중시
Idle Time Based	가장 오래 쉰 서버로 분산	리소스를 고르게 분산할 때
Geo-based	사용자 지역 기준 분산	글로벌 서비스, 낮은 지연 요구 시

🧠 결론

• 정적 환경에서는 Weighted Round Robin이 일반적이고 안정적이다.
• 실시간 트래픽 상태를 고려해야 하는 환경에서는 Least Connections, Response Time, Idle Time 기반 알고리즘이 더욱 효과적이다.
• 세션 유지, 지연 최소화, 국제화 등 추가 요구가 있다면 IP Hash, Sticky Session, Geo 기반 분산 등을 함께 고려해야 한다.
• 단일 알고리즘만으로는 한계가 있으므로, 실제 환경에서는 보통 여러 알고리즘을 조합하거나 계층적으로 적용한다 (예: L4 + L7).

---

마지막으로, 이상적인 로드밸런싱 전략이란 단순히 “분산”이 아니라 서비스의 형태, 트래픽 패턴, 사용자 경험, 서버 리소스 상황에 맞게 설계된 전략이다. 로드밸런서 자체에 대한 설정뿐만 아니라, 헬스체크, 오토스케일링, 세션 관리, 캐시 설계 등과 함께 종합적으로 고려해야 최고의 효과를 발휘할 수 있다.

🧠 부가 팁: 로깅과 모니터링 도입

문제가 생긴 후 파악하는 것이 아니라, 미리 예측하고 조치하기 위해 다음 도구를 적극 사용하는 것이 좋다.

• Prometheus + Grafana로 CPU/메모리/트래픽 시각화
• **ELK (Elasticsearch + Logstash + Kibana)**로 로그 분석
• AWS CloudWatch, Datadog, New Relic 등 APM 도구

---

참고자료

• Cloudflare. Types of load balancing algorithms
• Kim Jaewook (July 15, 2021). 로드 밸런싱(Load balancing) 종류와 알고리즘
• GeeksforGeeks (November 11, 2024). Load Balancing Algorithms
• AWS. What is load balancing?