[TIL] 클라이언트 사이드 로드밸런싱과 서버 사이드 로드밸런싱

클라이언트 측 로드 밸런싱

작동 방식

• 클라이언트의 책임: 클라이언트는 사용 가능한 서버 목록을 유지하며, 이 목록을 기반으로 어떤 서버로 요청을 보낼지 결정합니다.
• 구현: 클라이언트는 서비스 레지스트리(예: Eureka)에서 서비스 인스턴스 목록을 가져온 후, 특정 알고리즘(예: 라운드 로빈, 랜덤)을 사용하여 인스턴스를 선택합니다.

특징

• 분산된 제어: 각 클라이언트는 독립적으로 서버 선택을 결정합니다.
• 서비스 발견 통합: 서비스 발견 메커니즘과 통합되어 서비스 인스턴스의 최신 목록을 관리합니다.
• 망 효율성: 요청은 클라이언트로부터 직접 선택된 서버로 라우팅되어 병목 현상을 감소시킵니다.

장점

• 지연 시간 감소: 중간자가 없기 때문에 서버와의 통신 지연 시간을 줄일 수 있습니다.
• 고장 허용: 하나의 서버가 실패해도 클라이언트는 다른 사용 가능한 서버로 요청을 자동으로 전환할 수 있습니다.

단점

• 복잡성: 각 클라이언트는 로드 밸런싱 로직과 서비스 발견을 처리해야 하므로 구현이 복잡합니다.

예시: Ribbon

Ribbon은 Netflix에서 개발한 클라이언트 측 로드 밸런서로, 주로 마이크로서비스 간 통신에 사용됩니다. Spring Cloud와 통합되어 마이크로서비스에서 서비스 간 요청을 로드 밸런싱할 수 있습니다.

서버 측 로드 밸런싱

작동 방식

• 로드 밸런서의 책임: 로드 밸런서(하드웨어 또는 소프트웨어)는 클라이언트 요청을 받아 사용 가능한 서버 목록에 따라 요청을 적절한 서버로 라우팅합니다.
• 구현: 로드 밸런서는 요청을 균등하게 분산시키기 위해 특정 로드 밸런싱 알고리즘(예: 라운드 로빈, 최소 연결, IP 해시)을 사용합니다.

특징

• 중앙집중식 제어: 모든 트래픽 분배 결정이 로드 밸런서에 의해 중앙에서 이루어집니다.
• 클라이언트 구성의 단순화: 클라이언트는 로드 밸런서의 주소만 알면 되므로 설정이 간단합니다.
• 신뢰성 및 중복성: 종종 고가용성과 장애 조치 메커니즘을 갖추고 구현됩니다.

장점

• 클라이언트의 단순화: 클라이언트는 로드 밸런싱 로직을 처리할 필요가 없으며, 로드 밸런서가 모든 것을 관리합니다.
• 중앙집중화된 관리: 트래픽, 정책 구현, 장애 조치 전략을 쉽게 관리할 수 있습니다.

단점

• 단일 실패 지점: 로드 밸런서 자체가 병목 현상이나 실패 지점이 될 수 있습니다.
• 추가 지연: 클라이언트와 서버 사이에 추가적인 홉이 생기므로 지연이 발생할 수 있습니다.

예시: NGINX

NGINX는 강력한 웹 서버이자 리버스 프록시 서버로, 많은 조직에서 로드 밸런싱을 위해 사용합니다. NGINX 설정을 통해 여러 백엔드 서버 간에 인바운드 트래픽을 분산할 수 있습니다.