🔥스파르타 TIL (MSA)

Spring Cloud 란? (1)

승승장규 2025. 2. 8. 14:17

마이크로서비스 개발을 위해 다양한 도구와 서비스를 제공하는 스프링 프레임워크의 확장이며, 마이크로서비스 아키텍처를 쉽게 구현하고 운영할 수 있도록 도와준다.

 

주요 기능 ▼

  • 서비스 등록 및 디스커버리 : Eureka, Consul, Zookeeper
  • 로드 밸런싱 : Ribbon, Spring Cloud LoadBalancer
  • 서킷 브레이커 : Hystrix, Resilience4j
  • API 게이트웨이 : Zuul, Spring Cloud Gateway
  • 구성 관리 : Spring Cloud Config
  • 분산 추적 : Spring Cloud Sleuth, Zipkin
  • 메시징 : Spring Cloud Stream

 

Spring Cloud 주요 모듈

Eureka :
  • 넷플릭스가 개발한 서비스 디스커버리 서버로, 마이크로서비스 아키텍처에서 각 서비스의 위치를 동적으로 관리
  • 서비스 디스커버리 : 각 서비스는 등록 서버에 자신의 위치를 등록하고, 다른 서비스는 이를 조회하여 통신
  • 모든 서비스 인스턴스의 위치를 저장하는 중앙 저장소인 서비스 레지스트리가 있다.
  • 서비스 인스턴스의 상태를 주기적으로 확인하여 가용성을 보장할 수 잇는 헬스 체크가 있다.
Ribbon :
  • 넷플릭스가 개발한 클라이언트 사이드 로드 밸런서로, 서비스 인스턴스 간의 부하를 분산시킨다.
  • Eureka로부터 서비스 인스턴스 리스트를 제공받아 로드 밸런싱에 사용
  • 라운드 로빈, 가중치 기반 등 다양한 로드 밸런싱 알고리즘을 지원한다.
  • 요청 실패 시 다른 인스턴스로 자동 전환되는 Failover가 있다.
Hystrix : 
  • 넷플릭스가 개발한 서킷 브레이커 라이브러리로, 서비스 간의 호출 실패를 감지하고 시스템의 전체적인 안정성을 유지
  • 클로즈드, 오픈, 하프-오픈 상태를 통해 호출 실패를 관리하는 서킷 브레이커 상태
  • 호출 실패 시 대체 로직을 제공하여 시스템 안정성 확보하는 Fallback
  • Hystrix Dashboard를 통해 서킷 브레이커 상태 모니터링
Resilience4j :
  • 자바 기반의 경량 서킷 브레이커 라이브러리로, Hystrix의 대안으로 개발
  • 호출 실패를 감지하고 서킷을 열어 추가적인 호출을 차단하여 시스템의 부하를 줄임 => 서킷 브레이커
  • Fallback
  • 타임아웃을 설정하여 호출의 응답 시간을 설정하여 느린 서비스 호출에 대응할 수 있음
  • 재시도 기능을 지원하여 일시적인 네트워크 문제 등에 대응할 수 있음

 

Spring Cloud 구성 요소의 활용

Zuul : 
  • 넷플릭스가 개발한 API 게이트웨이로, 모든 서비스 요청을 중앙에서 관리
  • 요청 URL에 따라 적절한 서비스로 요청 전달 => 라우팅
  • 요청 전·후에 다양한 작업을 수행할 수 있는 필터 체인 제공
  • 요청 로그 및 메트릭을 통해 서비스 상태 모니터링
Cloud gateway :  
  • Spring Cloud에서 제공하는 API 게이트웨이로, 마이크로서비스 아키텍처에서 필수적인 역할
  • 요청을 받아 특정 서비스로 라우팅하고 필요한 인증 및 권한 부여를 수행하는 루팅 및 필터림
  • 외부 요청으로부터 애플리케이션을 보호하고, 보안 정책을 적용
  • 마이크로서비스 아키텍처에서 필요한 요청 처리 및 분산 환경의 관리를 효율적으로 수행
Spring Cloud Config :
  • 분산된 환경에서 중앙 집중식 설정 관리를 제공
  • 중앙에서 설정 파일을 관리하고 각 서비스에 제공하는 Config 서버
  • Config 서버에서 설정을 받아서 사용하는 Config 클라이언트 서비스
  • 설정 변경 시 서비스 재시작 없이 실시간으로 반영

 

주요 기능과 흐름을 알아보자.

 

Microservices에는 각각 Order, Product, User 애플리케이션이 있다고 가정해보자.

서비스간에 통신은 어떤 User가, 어떤 Product를 주문(Order)했는지 상품을 호출하고 유저를 호출한다.

Order -> Product -> User

 

만약 요청이 많아져서 하나의 애플리케이션으로 관리할 수 없는 상황이 온다면

똑같은 기능을 수행하는 Product를 2개로 나눌 수 있다.

하지만 Order에 요청이 들어왔을때 2개 중에서 어떤 Product 애플리케이션이 응답할 지 모를 수 있다.

이때 Ribbon(FeignClient) 에서 처리해준다.

 

Order에서 어떤 Microservices를 호출할지 알아야하는데,

Service registy에 Eureka 서버를 만들어서 Eureka 서버에 모든 Microservices를 등록해준다.

이렇게 되면 Order에서 Product를 호출할 때 Eureka를 통해 알 수 있다.

Order, Product, User는 Eureka Client가 된다.

 

클라이언트에서 Order, Product, User에 요청을 하려면 각각 다른 호스트를 호출하게 되는데

이때, 하나의 API Gateway를 구축해서 각각 요청에 맞는 애플리케이션으로 요청을 전달할 수 있다.

이때 로그인이 된 사용자만 사용 가능하게 가정을 한다면,

API Gateway에서 처리해서 불필요한 요청을 뒤로 보내지 않을 수 있다.

 

만약 Order에서 User를 먼저 호출해서 에러가 발생했을 때,

Resilience4j 서킷 브레이커를 통해 error를 처리할 수 있다. 

yml, properties 파일이 각각 애플리케이션에 다른 내용으로 저장되어 오류가 발생하는 것을 막기위해

Config Server를 구축하고 필요한 yml, properties를 작성하여

모든 서비스가 Config Server를 가리키게 하여 설정 파일을 관리할 수 있다.

 

Distributed Tracing에서 분산 추적을 통해 어떤 요청이 들어왔을 때 어떤 코드가 호출되는 것인지 확인할 수 있다.

 

 

실제로 코드를 작성하고, 그림을 그려보면 흐름을 이해하기 좋을 것 같다.🖐️