[Springboot] Spring Cloud

Spring + Cloud

분산환경에서 Springboot

클라우드 네이티브 환경에서 Spring 애플리케이션을 적용하고 관리할 때 따라오는 여러 애로사항들이 있다.MSA로 구성하여 사용하다 보면 필요한 서비스를 찾아서 호출하거나,동일한 설정을 알맞게 적용하는 등의 시스템을 추가적으로 구축하고 관리해야 하는데 이때 Spring에서 제공하는 훌륭한 도구가 있다.

Spring Cloud의 기능

Spring Cloud는 분산 시스템에서 필요한 여러 기능들을 추상화하여 제공한다.

1. Service Discovery

MSA 환경에서 서비스를 등록,검색,호출 할 수 있도록 도움을 주는 기능으로 Spring Cloud에선 Netflix OSS의 Eureka, Apache ZooKeeper,Consul 등의 서비스 디스커버리 툴들과 통합되어 있다.

2. Distributed Configuration

각 서비스에서 필요한 설정 정보를 중앙에서 관리하고 변경 사항을 런타임 중 적용할 수 있도록 해주는 기능으로 Spring Cloud는 이를 위해 Spring Cloud Config를 제공한다.

3.API Gateway

여러 마이크로서비스에서 제공하는 API를 단일 진입점으로 노출시켜 주는 역할을 하며 Spring Cloud는 Netflix OSS의 Zull,Spring Cloud Gateway 등 다양한 API 게이트웨이를 제공한다.

4.Load Balancing

여러 인스턴스에서 제공된 서비스를 균등하게 분산시켜주는 역할을 하며 Spring Cloud는 Ribbon,Spring Cloud LoadBalancer 을 이용한 로드 밸런싱을 지원한다.

5. Distributed Tracing

분산 시스템에서 트랜젝션을 추적하기 위한 기능으로 Spring Cloud에선 이를 위하여 Spring Cloud Sleuth,Zipkin을 제공한다.

6.Circuit Breaker

마이크로서비스에서 일시적인 문제가 발생하여 인스턴스가 다운되었을 때 이 인스턴스에 대한 요청을 차단하고 대체 인스턴스를 호출하는 기능으로 Spring Cloud는 Netflix OSS의 Hystrix 또는 Resilience4j를 이용하여 기능을 제공한다.

Spring Cloud Config

Spring Cloud 분산 시스템에서 구성 데이터를 효과적으로 관리하고 이를 적용하는 것을 담당하는 컴포넌트이다.

일반적인 모놀리식 Spring Boot 애플리케이션에서는 동작을 할 때 간단히 '설정 파일'을 읽어와서 수행하지만 MSA를 지원할 때는 이러한 정보들을 자유롭게 변경하고 처리 할 수 있어야 한다.이를 위하여 중앙 저장소(Spring Cloud Config Server)에서 모든 설정을 관리하고 개별 인스턴스들이 이 정보들을 요청하여 가져오는 형태로 동작한다.

---

설정 파일을 불러올 때는 

1. 클라이언트에서 최초 구동 시 서비스로 요청
2. 서비스에서 '설정 데이터'를 Config Server로 요청
3. Config Server가 Git Repository에서 설정 데이터를 찾아 반환
4. Config Server가 찾은 설정 데이터를 서비스로 반환

다음과 같은 순서로 진행된다.

---

설정 파일을 '변경'할 때는

1. 사용자가 Git Repository의 설정 파일을 변경
2. Client가 변경 사항의 갱신을 위하여 서비스로 '/actuator/refresh' 요청
3. 서비스를 변경 사항 갱신에 따른 설정 데이터를 Config Server로 요청
4. Config Server가 Git Repository를 통하여 설정 데이터를 찾아 반환
5. Config Server가 최신 설정 데이터를 갱신

다음과 같은 과정을 통하여 진행할 수 있다.

---

단순히 설정 데이터를 적용하고 관리하는 것 뿐 아니라 설정 데이터를 버전 관리 할 수도 있다.이를 위하여 Git,Subversion과 같은 버전 관리 시스템을 사용하며 필요한 경우 이전 설정으로 되돌리는 등의 작업을 수행할 수도 있다.

Spring Cloud Discovery

분산 시스템에서 서비스 간의 서비스를 등록하고 검색할 수 있도록 제공하는 컴포넌트로서 다수의 서비스 인스턴스를 자동으로 등록하고 검색할 수 있어 '통신'을 보다 쉽게 구현할 수 있다.

---

'서비스의 등록'을 위하여 Eureka,Apache Zookeeper,Consul과 같은 다양한 Server Discovery 툴을 지원하며 서비스가 실행되면 자동으로 등록된다.

'서비스의 검색'을 위하여 Discovery Server로 요청하면 

1. 인스턴스의 IP 주소,포트 번호
2. 인스턴스가 등록된 서비스 이름
3. 등록된 서비스의 메타 데이터

이러한 정보를 반환받아 직접 요청을 할 수 있다.

Spring Cloud Routing

네트워크 내부에서 목적지를 찾아가기 위한 기능으로 Spring Cloud Routing에선 Cloud Load Balancer,OpenFeign이 있다.API Gateway가 이곳에서 등장하는데 'Client에서 API로 송신한 요청'을 각각에 서비스로 알맞게 배송해주는 역할을 수행한다.

---

Not Using API Gateway

API Gateway가 필수로 적용되어야 하는 것을 아니기에 소규모 애플리케이션에선 이러한 구조도 사용할 수 있다.

---

API Gateway

API Gateway를 앞에 세우두고 요청에 따라 알맞은 서비스로 라우팅해주게 구성할 수 있다.

---

API Gateway + BFF

Client 측의 모바일 앱,웹 애플리케이션에서 Backend 서비스로 직접 접근하는 것이 아닌 API Gateway와 같은 중간 단계에서 Backend 서비스를 호출하도록 하는 것을 의미하며 별도의 API를 Client에 제공하므로 Client의 유형에 따라 다른 서비스를 호출하도록 하게 할 수 있다.

---

Spring Cloud에선 다양한 API Gateway를 제공하지만 Netflix에서 개발한 Zuul을 예시로 들자면

Zuul?

- Client와 마이크로서비스 같의 인증/라우팅/부하 분산 등의 기능을 제공한다

- Server DIscovery와 연계하여 동작하며 요청/응답에 대한 로깅,성능 측정,인증/인가,헤더 조작 등의 작업을 수행할 수 있다

- Client의 요청을 안전하게 처리함과 동시에 로드밸런싱,트래픽 라우팅 등을 결론적으로 제공한다.

1. 사용자(Client)가 API Gateway로 요청
2. API Gateway가 Discovery Server로 서비스에 대한 위치를 요청
3. 전달받은 위치에 알맞게 요청
4. API Gateway가 응답받은 값을 Client로 반환

기본적으론 다음과 같은 과정을 통하여 동작한다.

---

Spring Cloud Routing은 앞서 조금은 언급되었지만 로드 밸런싱(Load Balancing)을 수행할 수 있다.

Server Side Load Balancing

- 로드 밸런싱을 Server 측에서 수행하는 것을 의미한다

- 로드 밸런서가 Client의 요청을 균등하게 분산하여 처리하는 작업이다

 

Client Side Load Balancing

- 로드 밸런싱을 Client 측에서 수행하는 것을 의미한다

- 로드 밸런서가 여러 대의 Server로 들어가는 요청을 균등하게 분산하여 처리하는 작업이다

 

Client Siad Load Balancing을 Ribbon을 이용하여 구성하면

1. Server를 기준으로 Discovery Server로 서비스 간 호출을 위한 인스턴스를 요청
2. Discovery Server가 Load Balancer로 인스턴스를 요청
3. Load Balancer가 인스턴스를 확인하고 응답
4. 서비스에서 응답받은 인스턴스를 통하여 다른 서비스와 서로 호출

이러한 흐름으로 흘러가게 구성할수도 있다.

Spring Cloud Circuit Breaker

분산 시스템에서 장애 발생 시 '전체 시스템의 장애를 방지'하기 위하여 사용되는 기술을 의미하며 장애가 발생한 서비스에 대한 요청을 빠르게 차단하며 복구될때까지 다른 서비스로의 전파를 막는 역할을 한다.

---

Circuit Breaker에는 3가지 상태가 있다

분류	Closed	Open	Half-Open
상태	동작하지 않고 있는 상태	동작하고 있는 상태	부분적으로 동작하고 있는 상태
동작	모든 요청이 성공,실패 할 때마다 요청 수를 세고 일정 실패 비율 이상일때 발동	일정 시간동안 요청을 차단하고 실패한 요청을 즉시 반환	일부 요청을 처리하며 성공한 요청만큼 상태를 복구
요청	Open 상태가 되고 일정 시간이 지난 상황	외부로의 요청을 차단하고 바로 에러를 수신	외부로의 요청을 사단하고 바로 에러를 수신
상태 전이	외부로의 요청을 차단하고 바로 에러를 수신	특정 시간이 경과하면 Half-Open 상태로 변경	일부 허용된 요청들이 성공한 경우 Close 상태로, 실패한 경우 Open 상태로 변경

---

Neflix에서 개발한 Hystrix나 Java 기반 라이브러리 Resilience4J를 이용하여 간단한 설정으로 구성할 수 있다.

Circuit Breaker: 서비스 호출 실패 시 일시적으로 서비스 호출을 차단
Rate Limiter: 서비스 호출 빈도를 제한
Retry: 서비스 호출 실패 시 지정된 횟수 만큼 재시도
Bulkhead: 서비스 호출 시 동시에 처리되는 요청의 갯수를 제한
Cache: 서비스 호출 결과를 캐싱하여 재사용

다음과 같은 기능들을 제공하며 Server의 부하를 줄이거나 장애의 전파를 방지할 수 있다.