서킷브레이커가 필요한 상황
마이크로서비스 환경에서 다른 서버에게 이벤트가 아닌 동기 통신(HTTP, gRPC)요청이 실패된다면 어떻게 해결해야할까?
일반적인 방법은 다시 요청해보는 것이다. 상대 서버와 통신 중 네트워크 문제가 발생했을 수도 있고, 상대 서버가 일시적으로 가용하지 못한 경우가 있을 수 있기 때문이다.
만약 다시 요청해서 해결되는 상황이 아니라면? 상대 서버가 처리해야하는 트래픽이 너무 많아서 나의 요청을 처리하지 못하는 것이였다면? 어떻게 해야할까?
이 때 사용할 수 있는게 서킷브레이커이다. 서킷브레이커는 잠시 트래픽을 차단시켜 원래 기능을 대체할 수 있는(fallback)을 실행하도록 도와준다.
이 서킷브레이커를 통해 장애가 전파되는 것을 예방할 수 있다.
Resilience4J
Spring 생태계에서 서킷브레이커를 적용시키기 위해 일반적으로 Resilience4J를 사용하는 것이 권장 사항이다. 앞서 언급했듯이 일반적으로 다른 서버를 호출하는 구문이 실패했을 때 고려해볼 수 있는 사항은 재시도하는 방법이다.
그래서 Resilience4J가 지원하는 여러 기능 중 재시도를 수행할 수 있는 Retry를 간단하게 알아보고 실제 코드로 적용해본다.
Resilience4J - Retry
일반적으로 다른 서버를 호출해야하는 요청이 실패했을 때 재시도를 생각해볼 수 있다. 재시도를 하기 전 고려해야하는 사항은 아래와 같다.
- 몇 번까지 재시도를 할 것인가?
- 재시도 간격은 어떻게 부여할 것인가?
- 어떤 상황(예외)을 재시도를 해야하는 것으로 판단할 것인가?
서킷브레이커가 적합한 상황
간단한 상황을 예시로, 네이버 지도에서 특정 가게의 정보를 보여주는 API가 있을 때, 그 API는 가게 정보 저장소, 가게 리뷰 정보 저장소에게 질의를 하여 사용자에게 보여준다고 가정한다.
이 때 가게 정보를 보여주는 것에는 문제가 없었지만 가게 리뷰 정보를 보여주는 요청에서 실패/속도지연 이 발생한 상황이라면 어떻게될까?
특정 가게의 정보를 제공하는데 가장 중요한 도메인의 정보인 가게 정보는 올바르게 가져왔지만 가게 리뷰를 못가져와 그 요청을 실패로 처리하는 것이 좋은 사용자 경험을 제공하기 어려울 수 있다.
이런 상황에서 서킷브레이커를 도입하면 상대적으로 중요도가 낮은 가게 리뷰정보를 제공하지 못하더라도 가게 정보에 대한 데이터를 제공할 수 있는 차선책을 마련할 수 있다.