resilience 4j 발표 내용 정리

resilience 4j 정리

resilience 4j 정의 

• 회복 탄력성
• 장애 내성

일부 서버가 장애가 발생하면 다른 서버로 장애 전파를 방지한다.

 

Hystrix 는 2018 까지 개발되고 더이상 개발은 안되고 운영 유지만 되고 있다. 

이 파트에서는 CircuitBreaker, Retry 에 대한 두 가지 내용을 확인해본다.

 

아래 사진 보는것처럼 트래픽이 너무 몰렸을 때 잠시 트래픽을 차단해야 한다면 CircuitBreaker 을 걸어야 한다. 

서버가 많은 트래픽을 받아서 회복을 목적으로 잠시 트래픽을 차단해야 한다면 -> Fallback 실행 

CircuitBreaker 는 일종에 회로 차단기라고 보면 편하다. 

상태값으로는 3가지로 정리해볼 수 있다. 

Close - 이 상태에서는 시스템이 정상적으로 작동하고 있으며 모든 요청이 네트워크 서비스로 전달

Half_Open -  이 상태에서는 시스템이 에러에서 회복되었는지를 확인하기 위해 제한된 수의 요청만 네트워크 서비스로 전달 

Open - 이 상태에서는 시스템에 문제가 있음을 나타내며, 추가적인 실패를 방지하기 위해 모든 요청을 차단 

결과적으로 특정 시점에 장애 상황이 다른 시스템의 장애 상황으로 퍼지지 않도록 하는데 목적이 있다. 

 

resilience 4j 를 적용하면 적적한 상황

• 몇번 재시도 할지?
• 재시도 간격은 얼마나 할지?
• 어떤 상황을 실패로 간주할지? 

만약 이커머스에서 reslilence 4j 를 적용한다고 가정해보자. 

상품과 리뷰에 대해 조회할 때 리뷰 서버에 대한 조회가 실패한다고 가정하면 상품에 대한 조회 응답속도도 느려질 수밖에 없다. 

설정, 리뷰에 대한 정보가 내려오지 않더라도 상품에 대한 정보만 내려와도 괜찮다면 리뷰 api에 대한 비정상 상태로 가정하면 기능 실행 차단을 할 수 있다. 

 

위와 같은 상황에서 부하가 높아질 때 트래픽 차단 시스템 회복에 도움이 될 수 있다. 

 

resilience4j 실습에 대한 docs 를 확인해보자 !  -  https://github.com/resilience4j/resilience4j

GitHub - resilience4j/resilience4j: Resilience4j is a fault tolerance library designed for Java8 and functional programming

 

@Retry

이번에 직접 코드에서 확인해보자. 

Retry Service 인데 simpleRetryConfig config 이름을 들고 있다. 

retry 어노테이션에 등록해두면 application.yml 에 설정된 simpleRetryConfig 인스턴스 설정 값을 들고 온다. 

참고로 @Retry 은 내부적으로 aop로 구현되어 있어서 프록시를 이용해서 처리하게 된다. 

프록시를 이용하면 추가기능을 제공하는데 도움이 된다.  

 

RetryService 

 

Application.yml

 

 

RetryController

요청 url : http://localhost:8080/api-call?param=abcd

 

 

Retry Configruation 을 직접 구현한다고 하면? 

CircuitBreaker

앞서 언급한 리뷰, 상품 API 응답 중에 

리뷰 저장소에 문제가 생겨도 상품 목록은 정상적으로 보여주어야 한다. 

많은 부하를 받는 리뷰 저장소가 회복될 동안 트래픽을 차단하여 리뷰 저장소 회복에 도움을 줄 수 있다. 

정상적으로 회복되지 못할 경우 아래 처럼 트래픽이 몰릴 수 있다. 

앞에서 얘기했던 3가지 상태에 대해 보면,

Closed - 정상

Open - 차단

Half_Open - 차단 된 상태에서 정상 혹은 닫힘 으로 돌아갈 수 있는 중간 상태

아래 상황을 가정해보면, 

1. 문제 발생 시 closed -> open

2. 시스템이 회복할 수 있는 시간이 흐른후 open -> half_open

3. 차단된 상태에서 정상적인 상태로 갈 수 있는지 점검하는 상태 half_open -> closed, open

자주 open 되면 시스템의 정상적인 운영이 어렵기 때문에 half_open의 상태가 필요함

참고 docs -  

https://resilience4j.readme.io/docs/circuitbreaker

CircuitBreaker

 

circuitbreaker 의 설정값들이다. 

여기서 필요에 따라 waitDurationInOpenState 값을 10s, 100s 변경해 가며 확인해본다. 

호출 url :  http://localhost:8080/api-call?param=abcd

a, b, c 인 경우 케이스가 다른데,

open 으로 변경한 경우  a 에 대한 param으로 여러번 실행해 줬고

open -> half_open은 circuitbreaker 설정값에 따라 대기 시간을 10s 기다린 후 자동으로 변경

그리고 half_open으로 변경 된 후에 open으로 변경될 때는 a 를 param으로 전달했다. 

half_open에서 closed 로 변경할 때는 정상 트래픽을 흘려주

었다. 

open 시에는 트래픽이 몰려도 차단되어 있는 상태