Load Balancer 스키마

🚦 Spring Cloud Gateway에서 lb:// 스키마 완전 정복

— Service Discovery와 Client-side Load Balancing의 연결 고리

MSA 환경에서 API Gateway는 단순한 프록시가 아닙니다.
요청을 어디로, 어떤 기준으로, 어떻게 보낼지를 결정하는 지능형 라우터입니다.

그 중심에 있는 것이 바로 lb:// 스키마입니다.
이 챕터에서는 Spring Cloud Gateway(SCG)에서
lb://가 어떻게 동작하는지, 내부적으로 어떤 컴포넌트들이 관여하는지를 분석해보겠습니다 🔍

🧠 1. lb:// 스키마의 본질 — “주소가 아닌 이름으로 라우팅하라”

일반적인 라우팅은 다음과 같습니다.

http://10.0.1.5:8081

하지만 lb://는 완전히 다릅니다.

lb://USER-SERVICE

✨ 핵심 차이

구분	http://	lb://
기준	물리적 주소(IP/도메인)	논리적 서비스 이름
결합도	높음	매우 낮음
확장성	제한적	수평 확장에 최적

📌 lb://의 의미

“이 서비스 이름을 가진 살아있는 인스턴스 중 하나를 골라서 보내라”

즉, Gateway는 더 이상 IP를 알 필요가 없고
👉 Service Discovery + LoadBalancer에게 결정을 위임합니다.

⚙️ 2. 내부 동작 메커니즘 (Under the Hood)

lb://는 단순한 URI가 아니라,
Spring Cloud LoadBalancer와 결합된 동적 라우팅 트리거입니다.

전체 흐름 한눈에 보기 👇

🔍 ① ReactiveLoadBalancerClientFilter

“아, 이 요청은 lb://구나?”

SCG에는 lb:// 스키마를 감지하는 전용 글로벌 필터가 있습니다.

✔ ReactiveLoadBalancerClientFilter의 역할

1️⃣ Route URI가 lb://로 시작하는지 검사
2️⃣ lb://USER-SERVICE/profile → USER-SERVICE 추출
3️⃣ 로드밸런서 선택을 LoadBalancerClientFactory에 위임

📌 이 필터는 모든 요청에 공통 적용되며
SCG의 비동기(WebFlux) 필터 체인 안에서 동작합니다 ⚡

🔄 ② Service Instance 선택 과정

“어느 인스턴스를 쓸까?”

여기서 Spring Cloud LoadBalancer가 등장합니다.

📦 핵심 컴포넌트

• ServiceInstanceListSupplier
• ReactiveLoadBalancer

🔁 기본 동작

1️⃣ 서비스 디스커버리에서 인스턴스 목록 조회
2️⃣ 로드밸런싱 알고리즘 적용
3️⃣ 하나의 인스턴스 선택

🎯 기본 알고리즘

• ✅ Round Robin (기본값)
• 🔀 Random
• ⚖️ Weighted (가중치 기반)

📌 모든 과정은 Mono / Flux 기반 비동기 처리
→ Gateway 스레드 블로킹 ❌

🧩 ③ URI 재작성 (URI Reconstruction)

선택된 인스턴스가 다음과 같다면 👇

10.0.1.5:8081

Gateway는 내부적으로 URI를 이렇게 바꿉니다.

lb://USER-SERVICE/profile
⬇
http://10.0.1.5:8081/profile

📌 중요 포인트

• 클라이언트는 이 변화를 전혀 인지하지 못함
• Gateway 내부에서만 변환 발생

🚀 3. 고급 설정 & 실무 최적화 전략

🛠 커스텀 로드밸런싱 전략

특정 서비스만 별도 전략을 쓰고 싶다면?

@Configuration
@LoadBalancerClient(
  name = "user-service",
  configuration = MyCustomLoadBalancerConfig.class
)
public class GatewayConfig {}

✔ 서비스 단위로 알고리즘 분리 가능
✔ 트래픽 특성에 맞춘 정밀 제어 🎯

💾 캐싱 & 헬스 체크

🧠 캐싱

spring:
  cloud:
    loadbalancer:
      cache:
        enabled: true

• 매 요청마다 디스커버리 호출 ❌
• 로컬 메모리 캐시 사용 ⭕

❤️ 헬스 체크

• HealthCheckServiceInstanceListSupplier
• 비정상 인스턴스 자동 제외 🚑

🌍 Zone 기반 라우팅 (AZ 최적화)

AWS 같은 환경에서는
👉 같은 AZ의 인스턴스를 우선 선택

✔ 네트워크 비용 절감
✔ 레이턴시 감소
✔ 장애 전파 최소화

🧱 4. 왜 Client-side Load Balancing 인가?

항목	서버 사이드(L4/L7)	SCG lb://
장애 지점	LB가 SPOF 가능	분산 구조
유연성	네트워크 설정 의존	코드/설정으로 제어
비용	고가 장비	소프트웨어 기반
확장성	제한적	MSA 친화적

📌 lb://는 단순한 스키마가 아니라
👉 MSA 철학을 구현한 설계 결정입니다.

🧠 마무리 정리

🔥 lb://는

• Service Discovery
• Client-side Load Balancing
• Reactive Gateway 아키텍처

이 세 가지를 자연스럽게 결합한 추상화 레이어입니다.

Gateway가 똑똑해질수록
👉 마이크로서비스는 더 자유로워집니다 🚀