Service Discovery DR 구성 3부 - eurekube-operator의 Zone Failover를 위한 Spring Cloud LoadBalancer 살펴보기

11번가의 Vine 플랫폼은 약 720개 인스턴스, 70여 개 애플리케이션이 운영되는 Spring Cloud 기반 MSA 플랫폼이며, IDC와 AWS를 함께 쓰는 Hybrid Cloud 구조로 확장돼 있다.

eurekube-operator는 IDC의 Client-side Service Discovery와 EKS의 Server-side Service Discovery를 묶어 주는 Kubernetes Operator다. 기존에는 IDC Eureka Server를 중심으로 동작했지만, Eureka 서버를 Multi-Zone으로 구성한 뒤에는 EKS 쪽 Eureka Server를 우선 보게 하고, 장애 시에는 IDC로 자연스럽게 전환하는 Zone Failover가 필요해졌다.

핵심은 Spring Cloud LoadBalancer 위에 failover 로직을 얹는 것이다. 기본 제공되는 ReactorLoadBalancerExchangeFilterFunction은 인스턴스를 골라 요청만 보내며, spring.cloud.loadbalancer.retry.enabled = true를 켜야 RetryableLoadBalancerExchangeFilterFunction을 활용할 수 있다. 로드밸런싱 자체는 ReactiveLoadBalancer와 ServiceInstanceListSupplier가 담당하고, 요청 전후 훅은 LoadBalancerLifecycle로 처리한다.

문제는 eurekube-operator가 Eureka Client가 아니라 WebClient로 직접 요청을 보내기 때문에, Eureka Client가 제공하던 RetryableEurekaHttpClient와 SessionedEurekaHttpClient 같은 Zone 전환과 복귀 메커니즘을 그대로 쓸 수 없다는 점이다. 그래서 별도 구현으로 다음 두 가지를 만족시키도록 설계한다.

• 특정 Zone의 모든 인스턴스 요청이 실패하면 다른 Zone으로 전환한다.
• 일정 시간이 지나면 실패 이력을 지워 원래의 Preferred Zone으로 다시 돌아간다.

이를 위해 Caffeine cache를 두고, 실패한 ServiceInstance를 TTL 동안 저장한다. 예시 설정은 20분 TTL이며, 캐시 미스 시 빈 집합을 반환하도록 구성한다. 이후 ZoneFailoverAwareLoadBalancerLifecycle가 실패 인스턴스를 캐시에 기록하고, ZoneFailoverAwareCachedInstanceSelector가 캐시와 Preferred Zone을 함께 고려해 후보 인스턴스를 다시 계산한다. 마지막으로 ZoneFailoverAwareLoadBalancer가 그 후보들 중 하나를 RoundRobin 방식으로 선택한다.

정리하면, EKS 쪽 Eureka Server가 정상일 때는 그 Zone을 우선 쓰고, 장애나 높은 latency가 발생하면 IDC로 넘어가며, 시간이 지나면 다시 Preferred Zone으로 복귀하는 구조다. Chaos Test에서는 서버 비정상 종료와 네트워크 지연 상황 모두에서 의도한 Zone Failover가 동작함을 확인했다.