Spring Cloud Netflix
Spring Cloud는, Spring boot를 기반으로 MSA 구축에 특화된 라이브러리들의 집합이다.
Spring Cloud에는 Eureka, Hystrix, Ribbon, Zuul 등 많은 넷플릭스 OSS가 통합되어 있다.
지금 알아볼 내용은 넷플릭스 오픈소스 중에서도 Spring Cloud에 속해 있는 Spring Cloud Netflix가 되겠다.
프로젝트 전체 구성
구성 요소에 대해 하나하나 설명해 본다.
원격 시스템이나 서비스를 호출하는 구간을 격리해 관리하고 모니티렁해주는 라이브러리.
히스트릭스 대시보드 서버는
분산 마이크로 서비스에서 수집된 스트림 메시를 일괄 수집한 터빈 서버에서 보내는 터빈 스트림 메시지를 수신할 준비를 한다.
|
서킷 브레이커
|
회로 차단기
(circuit breaker)
|
폴백(fallback) 처리
|
벌크헤드(bulkhead)
|
|
- 격리 패턴 구현체 라이브러리
- 분산 시스템을 위한 Latency 및 Fault Tolerance
- 원격 시스템이나 서비스를 호출하는 구간을 격리해 관리하고 모니터링하는 라이브러리
|
서비스와 소비자 사이에 위치해 서비스 호출을 모니터링한다.
타임아웃을 설정해두고 해당 타임아웃을 넘겨 실패하는 횟수가 충족되면 회로 차단기가 활성화되어 이후의 호출들은 모두 빨리 실패하게 만든다.
|
회로 차단기에 의해 서비스 호출이 빨리 실패할 경우 예외(exception)을 발생시키지 않고 대체 코드를 실행하여 다른 방법으로 작업을 수행한다.
|
선박 건조 개념에서 유래. 배는 격벽(bulkhead)이라는 완전히 격리된 구획으로 나뉜다. 특정 선체에 구멍이 뚫려도 격벽으로 완전 격리되어있어 전체 배의 침수를 방지한다.
소프트웨어에서도 원격호출을 수행할 때 스레드풀로 분리하여 특정 원격호출이 느려질 때 전체 애플리케이션이 다운될 수 있는 위험을 막는다.
|
왜 Hystrix를 사용했나?
RFC 방식으로 호출하는 SAP API(인터페이스)를 사용하는 구간을 모니터링 하고 제어하기 위해서 Hystrix를 사용.
Hystrix를 사용한 더 자세한 이유:
1. Blackbox인 리모트 서비스의 호출 현황을 보고 싶다 :: Hystrix는 대시보드를 통해서 실시간으로 원격 서비스 호출 현황을 보여준다.
2. 최대한 서비스에 부하를 주지 않았으면 좋겠다 :: Hystrix는 추가적인 부하가 거의 없다.
3. 자바 외 기술이나 인프라를 추가로 설치하고 싶지 않다 :: Hystrix는 추가로 데이터저장소 등이 필요 없고 단지 대시보드를 실행할 톰캣만 있으면 된다.
4. 무거운 서비스 호출을 격리하고 싶다 :: Hystrix를 사용하면 각각의 실행 구간을 격리하고, 상황에 따라 실패 처리를 할수가 있다. (커넥션 retry, reject 등등). 실행 시간이 길 때는 몇 십초가 걸려 커넥션을 잡아 두고 있는 상황이 빈번하게 발생하는 상황에서는 매우 유용한 방식이다.
2. 터빈
터빈 서버(Turbine server)는 마이크로서비스에 설치된 히스트릭스 클라이언트 스트림을 통합해 주는 기능을 제공한다. 히스트릭스 클라이언트 스트림은 마이크로서비스에 설치된 히스트릭스 클라이언트에서 마이크로서비스로의 서비스 처리 요청에 대한 결과값을 스트림으로 전달해주는 역할을 하고, 마이크로서비스에 히스트릭스 스트림 메시지는 이후에 설명할 히스트릭스 커맨드 설정을 통해서 적용할 수 있다. 터빈 서버는 각 마이크로서비스에서 생성되는 히스트릭스 클라이언트의 스트림 메시지를 터빈 서버로 모두 수집하는 역할을 한다.
터빈 서버의 'application.yml' 파일의 'appconfig' 속성에 세 개의 마이크로서비스 애플리케이션 이름을 등록하면 등록된 세 개의 애플리케이션에서 발생하는 히스트릭스 클라이언트 스트림 정보를 수집할 수 있다. 이렇게 수집된 스트림정보는 터빈 스트림으로 제공한다.
'http://localhost:9999/turbine.stream'을 조회하면 각각의 마이크로서비스에서 생성되는 스트림 정보를 한꺼번에 확인할 수 있는데, 이렇게 수집된 스트림 정보는 히스트릭스 대시보드 웹페이지를 통해서 확인할 수 있다.
3. 마이크로 서비스
따로 정리.
웹 어플리케이션 서버에서 사용하는 여러용도의 환경 설정값을 일괄적으로 관리하고
서버의 용도별로 적절히 동적으로 적용될 수 있는 기능을 제공.
# 설정 서버 쓰는 이유:
첫째, 마이크로서비스의 어떠한 설정(환경변수값, Spring cloud 설정 등)이 변경되었을때 서버 재시작 없이 동적으로 적용하기 위해서.
둘째, 마이크로서비스가 배포될때 제반 설정값들을 배포 대상 환경(개발계, 검증계, 운영계 등)에 맞게 적용하기 위해
셋째, 마이크로서비스를 Stateless하게 개발하기 위해서입니다. Stateless하게 만들어야 스케일링(마이크로서비스 인스턴스 서버 - 즉, 컨테이너의 증감)과 부담없는 재시작이 가능하기 때문.
# 설정 서버, 어떻게 쓰나?
마이크로서비스에서 설정 파일들을 분리하여, git 또는 File server에서 관리한다.
Spring Cloud config server는 각 마이크로서비스에게 git 또는 File server의 설정값들을 제공한다.
config가 변경되면 각 마이크로서비스는 최신 값을 갖고 오기 위해 POST로 http[s]://{microservice host}/actuator/refresh를 해줘야 한다. 물론 이 작업을 자동화할 수도 있지만, config server가 각 마이크로서비스의 주소를 모두 관리해야 하니 비효율적.
그래서 나온 것이 Spring cloud bus다.
Spring Cloud bus는 1) MQ(Message Queue)에 Publisher(=config server)와 Subscriber(마이크로서비스)를 등록하고, 2) 갱신된 설정 값을 받으면 각 마이크로서비스에 통지해준다.
통지를 받은 각 마이크로서비스는 config server를 통해 갱신된 값을 받아 config를 업데이트하게 된다.
5. Eureka 서비스 관리
MSA 구조에서 서비스들은 동적으로 확장되고 축소되기도 하는데 이때마다 운영자가 일일이 인스턴스 정보를 수정, 관리하기란 쉬운 일이 아니다. 따라서 인스턴스의 상태를 동적으로 관리하는 서버가 필요해졌는데 이를 보통 서비스 디스커버리 서버로 칭하며, 넷플릭스는 Eureka라는 이름으로 공개했다.
중간-계층 서버들에 대한 로드밸런싱과 페일오버(?) 하기 위한 REST 기반 서비스.
6. Zuul 서비스 게이트웨이트
동적 라우팅, 모니터링, 회복성, 보안 등을 제공하는 게이트웨이 서비스.
넥플릭스 스트리밍 애플리케이션의 백엔드에 대한 모든 요청을 담당하는 관문.
Ribbon
Client에 탑재하는 Load Balancer 🎀
Load Balancer
우리가 일반적으로 사용하는 LoadBalancer는 서버사이드 로드밸런싱을 처리하는 L4 Switch와 같은 하드웨어 장비였다. 하지만 MSA에서는 이런 장비보다는 소프트웨어적으로 구현된 클라이언트사이드 로드밸런싱을 주로 이용한다. 이들의 차이를 한번 알아보도록 하자.
server-side load balancing
위는 일반적인 L4 switch 기반의 로드 밸런서다.
Client는 L4의 주소만 알고 있으면되며 모든 로드 밸런싱은 L4에서 처리해 주고 있다.
이런 하드웨어 기반의 서버 사이드 로드 밸런서의 단점은 기본적으로 별도의 스위치 장비가 필요하기 때문에 상대적으로 비용이 많이 소모되게 되며 유연성도 떨어지게 된다. 또한 서버 목록의 추가는 수동으로 보통 이루어진다. 이러한 단점 때문에 클라이이언트 사이드 로드밸런서가 MSA에서는 주로 사용된다. 클라이언트 사이드 로드밸런서를 사용하게 되면 아래와 같이 아키텍처가 형성된다.
client-side load balancing
Ribbon
Spring Cloud에서는 위와 같은 클라이언트 사이드 로드밸런서로 Ribbon을 이용하고 있다.
이 Ribbon의 구성요소로는 Rule, Ping, ServerList가 있는데. 각각은 아래와 같다.
그리고 개인적으로 Ribbon의 가장 중요하다고 생각하는 기능중 하나는 Retry입니다. Retry는 말 그대로 만약 server에게 응답을 받지 못하였을 경우 동일한 서버로 재시도 하거나 다른 서버로 재시도하는 기능이다.
ribbon retry
위의 경우 A_1에게 먼저 요청을 한 후 응답이 존재하지 않아 A_2로 재시도를 하여 성공응답을 받아낸 상황.
'마루아라는 개발쟁이 > MSA' 카테고리의 다른 글
| [API Gateway] API Gateway 란! 그리고 왜 중요한가? (0) | 2023.01.02 |
|---|
