들어가며
이번 시간에는 CircuitBreaker 개념 및 설정 방법과 테스트에 대해 정리한다. 내용이 길어서 4-1에서는 개념에 대해서 정리를 하고 4-2에서 설정방법에 대해서 정리한다.
시리즈 1 - MSA
https://sjparkk-dev1og.tistory.com/151
MSA & Eureka & FeignClient(OpenFeign) & CircuitBreaker(Hystrix & Resilience4J) 차례대로 알아보기 시리즈 (1) - MSA(Mi
들어가며 이 글은 제목에서도 알 수 있듯이 MSA & Eureka & FeignClient(OpenFeign) & CircuitBreaker(Hystrix & Resilience4J) 순으로 개념과 설정방법 그리고 테스트 등의 결과와 해당 기술들을 테스트하며 겪었..
sjparkk-dev1og.tistory.com
시리즈 2 - Eureka
https://sjparkk-dev1og.tistory.com/153
SpringBoot Cloud - MSA & Eureka & FeignClient(OpenFeign) & CircuitBreaker(Hystrix & Resilience4J) 차례대로 알아보기 시
들어가며 이번 시간에는 유레카에 대해서 정리한다. 기본적인 개념 정리와 테스트에 대핸 내용을 정리했다. 시리즈 1 - MSA https://sjparkk-dev1og.tistory.com/151 MSA & Eureka & FeignClient(OpenFeign) & Cir..
sjparkk-dev1og.tistory.com
시리즈 3 - OpenFeign
https://sjparkk-dev1og.tistory.com/155
SpringBoot Cloud - MSA & Eureka & FeignClient(OpenFeign) & CircuitBreaker(Hystrix & Resilience4J) 차례대로 알아보기 시
들어가며 이번 시간에는 OpenFeign 개념 및 설정 방법과 테스트에 대해 정리한다. Feign Client 통신을 위한 OpenFeign 라이브러리를 사용했다. 시리즈 1 - MSA https://sjparkk-dev1og.tistory.com/151 MSA & Eur..
sjparkk-dev1og.tistory.com
Circuit breaker 패턴이 필요한 이유
MSA 환경에서의 서비스에서는 많은 장점도 가지고 있지만 반대로 단점도 존재한다. 그 단점 중에 서비스간 통신 중에 장애가 일어났을때 장애가 난 컴포넌트를 호출하는 종속된 컴포넌트까지 장애가 전파되는 특성이 있다. 예를 들어 서비스A가 서비스B를 호출하는 상황에서 서비스B에 문제가 생겨 응답을 못하거나 아니면 응답 속도가 매우 느린 상황이라고 가정했을때 서비스A는 서비스B에 대한 응답을 받지 못하기 때문에 계속 응답을 기다리는 상태로 잡혀있게 된다. 이러한 상황에서 다른 컴포넌트가 서비스A를 호출하게 되는 상황이 일어난다면 전체 시스템이 장애 상태에 빠질 확률도 존재한다.
Circuit Breaker 패턴
바로 이러한 상황을 해결하는 디자인 패턴이 Circuit Breaker 패턴이다. 기본적인 원리는 서비스A와 서비스B 사이에 써킷브레이커를 두고 서비스B가 정상인 상황에서는 A에서 B로 통하는 트래픽을 아무 문제 없이 byPass한다. 하지만 서비스B에 문제가 생겼을때는 써킷브레이커가 감지하여 서비스B로의 호출을 강제적으로 끊어버려서 서비스A에서 쓰레드들이 더 이상 요청을 기다리지 않도록 해서 장애가 전파되는 것을 방지하는 것이다. 대신 서비스A에서는 이에 대한 장애 처리 로직이 별도로 필요하게 된다.
Fall-back Message
장애 처리 로직이 별도로 필요하게 되면서 나온 것이 Fall-back 메시징인데 써킷브레이커에서 서비스B가 정상적인 응답을 할 수 없을 때 써킷브레이커가 룰에 따라서 다른 메세지를 리턴하게 하는 방법이다.
Hystrix & Resilience4J
Hystrix
- CircuitBreaker 패턴을 자바 기반으로 오픈소스화한 라이브러리
- 넷플릭스에서 개발함
- 2018년 12월부터 EOS(End Of Service - 기능 업그레이드 없고 유지만)
- Spring Cloud 2.4.x 부터 지원 안함
- 따라서 대체되는 다른 Component 들을 사용 권장
Resilience4J
- 넷플릭스의 Hystrix에 영감을 받아 개발된 경량화 라이브러리
- Spring에서 Hystrix 대신 사용을 권장하는 라이브러리
- Hystrix와 마찬가지로 서킷브레이커 패턴에 사용됨
https://spring.io/blog/2018/12/12/spring-cloud-greenwich-rc1-available-now
Spring Cloud Greenwich.RC1 available now
<p>On behalf of the community, I am pleased to announce that the Release Candidate 1 (RC1) of the <a href="https://cloud.spring.io">Spring Cloud Greenwich</a> Release Train is available today. The release can be found in <a href="https://repo.spring.io/mil
spring.io
서킷브레이커의 상태
- 일반적인 상태 3가지와 특수 상태 3가지로 분류된다.
일반적 상태
- CLOSED - 서킷브레이커가 닫혀 있는 상태로 서킷브레이커가 감싼 내부의 프로세스로 요청을 보내고 응답을 받을 수 있다.
- OPEN - 서킷브레이커가 열러 있는 상태로 서킷브레이커는 내부의 프로세스로 요청을 보내지 않는다.
- HALF_OPEN - 서킷브레이커가 열러 있는 상태지만 내부의 프로세스로 요청을 보내고 실패율을 측정해 상태를 CLOSED 혹은 OPEN 상태로 변경한다.
—> 요청의 성공 실패 여부에 따라 상태가 변하며 CLOSED는 OPEN으로, OPEN은 HALF_OPEN으로, 실패율에 따라 CLOSED, OPEN 두 상태 중 하나로 변한다.
특수 상태
특수 상태는 강제로 상태변이를 하지 않으면 될 수 없다.
- DISABLED - 서킷브레이커를 강제로 CLOSED 한 상태이다. 실패율에 따른 상태변화도 없고 이벤트 발행도 발생하지 않는다.
- FORCED_OPEN - 서킷브레이커를 강제로 OPEN 한 상태. DISABLED와 동일하게 상태변화도 없고 이벤트 발행도 하지 않음
- METRICS_ONLY - 서킷브레이커를 강제로 CLOSED한 상태. DISABLED와 동일하게 상태변화는 없지만 이벤트 발행을 하고 내부 프로세스의 metric 수집
다음 4-2에서 설정 방법에 대해서 정리한다.
댓글