클라이언트 사이드 로드 밸런싱

특징

구현 위치: 클라이언트에서 직접 로드 밸런싱 수행.
작동 방식: 클라이언트가 알고리즘을 사용해 서버를 선택 (예: 라운드 로빈, 랜덤).
기술 예시: Spring Cloud Load Balancer, Netflix Ribbon.

장점

네트워크 부하 감소 (로드 밸런서를 거치지 않음).
단일 장애점(SPoF)이 없음.
알고리즘 변경 및 설정이 유연함.

단점

클라이언트마다 로드 밸런싱 로직 필요 → 복잡성 증가.
서버 목록 관리 부담.
실시간 서버 상태 반영 어려움 → 비효율적 요청 가능.

서버 사이드 로드 밸런싱

특징

구현 위치: 별도 서버(로드 밸런서)에서 수행.
작동 방식:
외부 로드 밸런서(예: NGINX, HAProxy)가 클라이언트 요청을 수신.
서비스 디스커버리와 통합하거나, 고정된 인스턴스 목록을 참조.
알고리즘(라운드 로빈, 최소 연결 등)을 사용해 요청을 인스턴스에 전달.
응답은 로드 밸런서를 통해 클라이언트로 반환.
특징:

트래픽 분산과 상태 확인(Health Check)을 로드 밸런서가 관리.
클라이언트는 로드 밸런서만 호출하며, 인스턴스 정보를 알 필요 없음.

기술 예시: AWS Elastic Load Balancer, HAProxy, Nginx.

장점

중앙 집중 관리 가능 → 서버 상태와 부하를 실시간으로 반영.
클라이언트 간단화 → 로드 밸런싱 신경 필요 없음.
장애 시 자동 트래픽 전환.

단점

단일 장애점 발생 가능 → 이중화로 해결해야 함.
네트워크 홉 추가로 인한 성능 저하 가능.

서버 사이드 vs 클라이언트 사이드

	클라이언트 사이드	서버 사이드
구현 위치	클라이언트에서 수행	서버 측 로드 밸런서에서 수행
장애 처리	클라이언트 직접 처리	로드 밸런서가 자동 처리
관리 복잡성	클라이언트마다 관리 필요	중앙 집중적 관리로 간소화
네트워크 효율성	중간 단계 없음	추가 네트워크 홉 발생 가능
단일 장애점(SPoF)	없음	있음 (이중화 필요)

---