왜 클라이언트 사이드 로드 밸런서인가
대규모 트래픽을 처리하는 시스템에서 로드 밸런서는 필수 구성 요소지만, 외부 로드 밸런서는 그 자체로 네트워크 홉을 추가하고 단일 장애 지점이 될 수 있다. Zalando 엔지니어링팀은 초당 100만 건의 요청을 처리하는 고처리량 API에서 이 문제를 정면으로 마주했다. 외부 LB를 거칠 때마다 발생하는 레이턴시 변동, 인프라 운영 비용, 그리고 장애 발생 시 어느 서비스에서 문제가 시작됐는지 추적하기 어렵다는 세 가지 한계가 구체적인 동기였다.
해결책으로 선택한 것은 인프로세스(In-Process) 클라이언트 사이드 로드 밸런서, 즉 애플리케이션 프로세스 내부에서 직접 부하 분산 로직을 수행하는 방식이다. 이 패턴은 Netflix Ribbon이나 Spring Cloud LoadBalancer처럼 자바 생태계에서 이미 개념 자체는 익숙하지만, Zalando의 사례는 실제 프로덕션 규모에서 이를 어떻게 설계하고 운영했는지를 보여준다는 점에서 가치가 있다.
인프로세스 방식이 가져온 세 가지 실질적 효과
첫째, 레이턴시 예측 가능성이 향상됐다. 외부 LB를 거치지 않으면 네트워크 홉이 줄어드는 것은 물론, 외부 컴포넌트의 큐 상태나 GC 중단 같은 외부 요인에 의한 레이턴시 스파이크를 제거할 수 있다. 요청이 프로세스 안에서 타깃 엔드포인트로 직접 디스패치되기 때문에 P99 레이턴시가 안정적으로 유지된다.
둘째, 인프라 비용이 절감됐다. 고가용성을 위해 이중화해야 하는 외부 LB 인스턴스 자체가 사라지거나 대폭 축소된다. 초당 100만 건 규모에서 LB 인스턴스를 줄이는 것은 직접적인 비용 절감으로 이어진다.
셋째, 장애 가시성이 개선됐다. 클라이언트 사이드에서 라우팅 결정을 내리므로, 어떤 업스트림 인스턴스가 실패를 유발했는지 애플리케이션 로그와 메트릭에 즉시 반영된다. 외부 LB가 중간에 있을 때는 실패 원점이 LB 뒤에 숨어 있어 디버깅이 까다로웠던 문제를 해소한다.
백엔드 개발자가 주목해야 할 설계 포인트
클라이언트 사이드 로드 밸런서를 직접 구현하거나 도입할 때 핵심은 서비스 디스커버리와의 통합이다. 업스트림 인스턴스 목록을 어떻게 최신 상태로 유지하느냐가 전체 안정성을 좌우한다. Kubernetes 환경이라면 엔드포인트 워치나 DNS 기반 디스커버리를 활용할 수 있다.
// 단순화한 라운드로빈 선택 예시
public URI selectTarget(List<URI> endpoints) {
int index = counter.getAndIncrement() % endpoints.size();
return endpoints.get(index);
}
또한 헬스 체크와 서킷 브레이커를 로드 밸런서 로직 안에 녹여야 한다. 특정 인스턴스가 느려지거나 오류를 반환하기 시작하면 즉시 라우팅 가중치를 낮추거나 제외해야 한다. Resilience4j의 CircuitBreaker를 인스턴스별로 적용하는 방식이 자바 백엔드에서 현실적인 선택지다.
CircuitBreaker cb = CircuitBreaker.ofDefaults("instance-" + target.getHost());
Supplier<Response> decorated = CircuitBreaker.decorateSupplier(cb, () -> call(target));
마지막으로 스레드 안전성과 성능을 동시에 고려해야 한다. 인스턴스 목록 갱신과 요청 라우팅이 동시에 발생하므로 CopyOnWriteArrayList나 읽기 잠금 최소화 전략이 필요하다. Zalando의 사례처럼 초당 수십만 건 이상을 처리하는 환경이라면 락 경합이 레이턴시에 직접 영향을 미친다.
정리
- 인프로세스 클라이언트 사이드 로드 밸런서는 네트워크 홉 제거, 비용 절감, 장애 추적 용이성을 동시에 달성하는 아키텍처 패턴이다.
- 서비스 디스커버리 연동, 인스턴스별 헬스 체크·서킷 브레이커, 스레드 안전한 라우팅 로직이 구현의 핵심 세 축이다.
- 초당 수십만 건 이상의 고처리량 자바 백엔드라면 Spring Cloud LoadBalancer 또는 직접 구현을 통해 외부 LB 의존도를 줄이는 방향을 검토할 시점이다.