11/20 - TIL : Spring Cloud와 Load Balancer

 

Spring Cloud는 Spring Framework 기반의 클라우드 네이티브 애플리케이션을 개발하기 위한 프로젝트이다. 

• Spring Cloud는 분산 시스템에서 필요한 기능들을 추상화하여 제공하고 있으며, 마이크로서비스 아키텍처를 구현할 때 유용하게 사용된다. 

스프링 클라우드 아키텍처 ❘ 출처 : 스프링 공식 문서

 

주요 기능은 다음과 같다. 

• 서비스 등록 및 디스커버리 
  • 마이크로서비스는 동적으로 확장되거나 축소되기 때문에 고정된 IP 대신 서비스 레지스트리를 통해 위치를 관리한다. 
  • 서비스 등록 : 서비스 인스턴스는 자신의 정보를 서비스 레지스트리에 등록한다. 
  • 서비스 디스커버리 : 다른 서비스가 필요한 서비스의 위치를 동적으로 조회한다. 
  • Spring Cloud에서의 구현 : Spring Cloud Netflix의 Eureka 사용 (Eureka Server - 서비스 레지스트리 역할 | Eureka Client - 서비스 등록 및 조회 역할) 
• 로드 밸런싱 
  • 여러 서비스 인스턴스 간에 트래픽을 균등하게 분배하여 부하를 분산시킨다. 
  • Spring Cloud는 클라이언트 로드 밸런싱(Client-Side Load Balancing) 방식을 사용한다. 
  • Spring Cloud에서의 구현 : Netflix Ribbon이 사용되었지만, 현재는 Spring Cloud LoadBalancer로 대체 (기본적으로 Round Robin) 
• 서킷 브레이커 (Circuit Breaker)  
  • 장애가 발생했을 때, 서비스 간 연쇄 실패를 방지하는 패턴 
  • 서킷 브레이커는 일정한 임계치를 넘어서면 요청을 차단하고, 장애가 복구되었을 때 다시 요청을 허용한다. 
  • Spring Cloud에서의 구현 : Resilience4J(Spring Cloud에서 권장) 또는 Netflix Hystrix (실패 처리, retry, fallback.. 설정 가능 ) 
  • 예시로는 서비스 A가 서비스 B로 요청 시, 서비스 B의 장애로 인해 A까지 영향을 받을 수 있다. 이때, 서킷 브레이커가 감지하고 대체 응답(fallback)을 반환하는 것이 있다. 
• API 게이트웨이 
  • 모든 요청의 단일 진입점 역할을 하는 프록시 서버 
  • 요청을 각 서비스로 라우팅, 인증/인가, 로깅, 필터링, 로드 밸런싱 등을 처리한다. 
  • Spring Cloud에서의 구현 : Spring Cloud Gateway (Zuul의 대체로, 비동기 및 Netty 기반으로 설계되어 더 나은 성능을 제공한다.) 
  • 기능으로는 요청 필터링 및 라우팅, 로드밸런싱과 보안설정, HTTP, WebSocket 지원 
  • 예시) 클라이언트 - Gateway - 서비스 A, B, C로 요청 라우팅
• 구성 관리 
  • 애플리케이션의 설정을 중앙에서 관리하고 동적으로 변경할 수 있도록 지원 
  • 서비스 간 동일한 설정 값을 쉽게 공유하거나, 환경별로 구분 가능 
  • Spring Cloud에서의 구현 : Spring Cloud Config(중앙 집중식 설정 관리 서버, Git, SVN, 파일 시스템을 백엔드로 사용 가능) 
  • 예시) Config Server에 application.properties를 저장 - 서비스가 Config Server로부터 설정 값을 가져온다. - 설정 변경 후, 서비스를 재시작하지 않고도 반영 가능(Spring Cloud Bus로 실시간 반영)
• 분산 추적 
  • 마이크로서비스 환경에서 요청이 여러 서비스에 걸쳐 수행될 때, 이를 추적하여 성능 병목 지점이나 오류를 파악 
  • 요청마다 고유한 Trace ID와 Span ID를 생성해 요청 흐름을 시각화 
  • Spring Cloud에서의 구현 : Spring Cloud Sleuth(Trace ID와 Span ID를 자동으로 생성하고 로깅), Zipkin(Sleuth에서 수집한 데이터를 기반으로 분산 트랜잭션 시각화)
  • 예시) 서비스 A - B - C로 요청이 이어질 때, Zipkin을 통해 요청의 흐름과 응답 시간을 확인 
• 메시징 
  • 서비스 간 비동기 통신을 지원 
  • 메시지 브로커(Kafka, RabbitMQ 등)를 통해 데이터를 송수신하여 서비스 간 결합도를 낮춘다. 
  • Spring Cloud에서의 구현 : Spring Cloud Stream(메시징 중간 추상화를 제공하여 Kafka, RabbitMQ 등과 쉽게 연동), Spring Cloud Bus(분산 시스템 간 설정 변경 이벤트를 전파)
  • 예시) 서비스 A가 Kafka를 통해 메시지를 게시(Publish)하면, 서비스 B가 이를 구독(Subscribe)하여 처리 

 

Spring Cloud의 Load Balancing은 Client Side Load Balancing이라고 한다. 따라서, 다음과 같이 동작한다고 한다. 

• 클라이언트는 Eureka에서 인스턴스 목록을 가져온다. 
• 로드밸런싱 알고리즘을 통해 적합한 인스턴스를 선택하여 요청을 보낸다. 

 

 

가장 관심있게 보았던 곳은 Load Balancing 부분이었다. 

 

 

나는 이제까지 Server Side Load Balancer 만 다루어봤는데 (LoxiLB, Nginx, AWS ALB, ...) Client Side Load Balancing은 처음 접해본다. 

 

Client Side Load Balancing ? (1줄 요약 : 클라이언트가 서비스 인스턴스의 선택, 요청 분산을 직접 관리하는 로드밸런싱 방법)

Client Side Load Balancing : 클라이언트 애플리케이션이 서버나 서비스 인스턴스의 목록을 유지하고, 요청을 적절히 분산시키는 방식의 로드 밸런싱이다. 

 

클라이언트는 서버의 목록을 가지고 있으며, 이를 바탕으로 로드 밸런싱을 수행한다. 

 

Server Side Load Balancing, Client Side Load Balancing 각각의 차이점을 간단하게 살펴보면 다음과 같다. 

• Server Side Load Balancing
  • 클라이언트 - [로드 밸런서의 IP/도메인으로 요청 보냄] - 로드 밸런서 - [로드밸런서가 적절한 서버 선택] - 서버 
  • 모든 트래픽을 중앙에서 관리하기 때문에 모니터링, 보안, 스케일링에 좋다. 
  • 로드밸런서가 하나의 네트워크 홉 역할을 하기 때문에 약간의 지연이 발생할 수 있다. (이는 다르게 생각하면, 로드밸런서에서 *SPOF이 발생하면 큰일날 수 있다는 것, 따라서 고가용성 구성이 필요) 
• Client Side Load Balancing
  • [서비스 레지스트리] - [레지스트리에서 인스턴스 목록 조회] 클라이언트 - [로드 밸런싱 알고리즘] - 서버
  • 클라이언트가 직접 서버를 선택 
  • 네트워크 홉이 추가되지 않아 성능이 좋으며, 서비스 디스커버리와 통합되어 동적으로 서버 목록을 관리할 수 있다. 
  • 클라이언트에서 로드 밸런싱 로직을 구현해야 하기 때문에 복잡성 증가, 직접 서비스 레지스트리와 통신하므로 네트워크 부하 발생 가능하다. 

 

*SPOF : (Single Poinf of Failure) 단일 장애 지점