Spring Cloud란?
- Spring Cloud는 마이크로서비스 개발을 위해 다양한 도구와 서비스를 제공하는 스프링 프레임워크의 확장
- 마이크로서비스 아키텍처를 쉽게 구현하고 운영할 수 있도록 도움
주요 기능
- 서비스 등록 및 디스커버리
- Eureka, Consul, Zookeeper
- 서비스 등록 및 검색을 통해 동적으로 서비스의 위치를 관리
- 로드 밸런싱
- Ribbon, Spring Cloud LoadBalancer
- 클라이언트 사이드 로드 밸런서로, 서비스 인스턴스 간의 부하를 분산
- 서킷 브레이커
- Hystrix, Resilience4j
- 서비스 간의 호출 실패를 감지하고 시스템의 전체적인 안정성을 유지
- API 게이트웨이
- Zuul, Spring Cloud Gateway
- 클라이언트 요청을 적절한 서비스로 라우팅
- 인증, 로깅, 요청 필터링과 같은 작업 처리
- 구성 관리
- Spring Cloud Config
- 여러 서비스의 구성 정보를 중앙에서 관리
- 분산 추적
- Spring Cloud Sleuth, Zipkin
- 서비스 간 호출 관계를 추적하고 성능 병목 현상을 분석
- 메시징
- Spring Cloud Stream
- 메시지 브로커(Kafka, RabbitMQ 등)를 사용해 비동기 통신 구현
- 이벤트 기반 마이크로서비스 구축에 활용
그림으로 알아보는 Spring Cloud 주요 기능
상품을 주문하는 앱이 있다고 가정해보자.
주문 요청이 들어오면 우선 주문 정보를 확인하고 처리해야 한다. 또한 상품 정보를 확인해야 한다. 그리고 어떤 유저가 주문했는지도 확인을 해야한다.
주문 요청 -> 주문 확인 - 상품 확인 - 유저 확인
주문(Order), 상품(Product), 유저(User) 이렇게 3개의 어플리케이션이 필요하다. 상품(Product) 앱은 레플리카를 2개로 구성하여 이중화가 되었다.
먼저, 이 어플리케이션을 통해서 주문 요청을 처리하기 위해서 서비스 간의 통신이 필요하다.
Eureka
주문 앱은 상품 앱의 서비스도 호출해야하고 유저 앱의 서비스도 호출해야 한다. 그러면 주문 앱이 모든 앱의 호출 정보를 가지고 있어야 할까?
MSA 환경에서는 앱의 변경이 잦기 때문에 호스트 정보(IP,포트 등) 등이 자주 변경되는데, 각각의 앱들이 직접 관리하기는 어려울 것이다. 그래서 별도의 중앙 저장소가 필요하고 Eureka Server가 바로 그 역할을 한다. (각 앱들은 Eureka Client라고 한다.)
주문 앱은 상품 앱이나 유저 앱의 호스트 정보를 모르더라도 Eureka 서버를 통해 각 서비스의 호스트 정보를 알 수 있다.
Ribbon
주문 앱은 상품을 확인하기 위해 상품 서비스를 호출해야 한다. 그런데 동일한 기능을 하는 상품 앱이 두 개로 이중화가 되어있어 어디로 호출해야할지 모를 것이다. 이 때 Ribbon이 상품#1, 상품#2 중 어디로 호출할지 관리해주는 역할을 한다.
이 기능을 로드 밸런싱이라고 하고, 1번과 2번을 순차적으로 한 번씩 호출하는 것을 라운드 로빈 방식이라고 한다. (다른 알고리즘을 설정할 수도 있다.)
API Gateway
(앱 간의 호출 말고도) 클라이언트에서 요청을 보내려고 할 때, 주문, 상품, 유저 각 앱의 호스트 정보에 맞게 각각 호출하려면 힘들 것이다. 그래서 앞 단에 요청을 받는 역할을 하는 API 게이트웨이 라는 애플리케이션 하나를 띄워놓고 클라이언트는 여기로만 호출하게 한다. API 게이트웨이는 요청을 받아서 어디로 보내줘야 될지 판단을 하고 각 애플리케이션으로 요청을 전달한다. (각 앱으로 바로 호출은 아니고 Eureka를 통한 후에..)
그리고 API 게이트웨이의 필터 기능을 사용해서 로그인 체크 등을 처리할 수 있다.
Resilience4j
주문 요청이 들어왔다. 유저 정보를 먼저 확인 하고 상품 정보 확인을 해야한다고 가정해보자. 주문 앱이 유저 서비스를 호출하는데 유저 서비스에서 오류가 났다면? 굳이 상품 서비스까지 호출하지 않고 바로 오류 응답을 돌려줘야 할 수 있다.
이러한 서비스 오류 상황에 대한 처리를 서킷 브레이커 역할을 하는 Resilience4j를 통해서 관리할 수 있다.
오류를 감지하면 서킷을 열어 실패한 서비스로의 추가 요청을 차단하고, 대체 로직(fallback)을 호출하는 등의 failover 처리를 할 수 있다.
Spring Cloud Config
각각의 서비스 애플리케이션마다 Configuration을 위한 YAML 파일이 있을 것이다.
이 YAML 파일을 각각의 애플리케이션에 넣어주면 수정할 때 어플리케이션을 전부 다 수정해야 될 상황이 생긴다. 이를 방지하기 위해 설정 파일(YAML 파일)을 저장하는 중앙 저장소인 Config 서버를 만들 것이다. 이 Config 서버에 모든 YAML 파일을 저장을 해놓고 각각 모든 서비스가 이 Config 서버를 바라보게 만든다.
그리고 파일이 업데이트됐다는 것만 각 서비스에 알려줄 수 있으면 모든 서비스가 바로 업데이트가 될 것이다.
Zipkin
우리는 각 서비스 간의 호출이 어떻게 이루어지는지 코드 레벨에서 찾아가지 않는 이상 직관적으로 알기 어렵다. 그래서 Zipkin을 이용한 분산 추적(tracing)을 통해서 요청이 들어왔을 때 어떻게 호출이 되는지 알아볼 수 있다.
마무리
강의에서 강사님이 그림을 그리며 설명해주신 부분을 복습하기 위해, 내가 다시 한 땀 한 땀 그려보았다.(간만에 아이패드와 아이펜슬이 제기능을 했다.) 그림이 부족한 부분은 추가해서 그리기도 하고, 내가 이해한대로 설명글을 작성해보면서 스프링 클라우드의 주요 기능들에 대해 간략하지만 어떤 역할을 하는지와 필요성을 정리해볼 수 있었다.
