MSA 서비스에서 Circuit Breaker 도입하기

이 글은 조대협 님의 글을 통해(https://bcho.tistory.com/1247) 공부한 내용을 담았습니다.

MSA 에서 서비스 간 장애 전파

MSA 패턴을 도입하면서 단일 서비스 컴포넌트는 여러개로 쪼개져 서로 호출하는/호출당하는 관계를 가진다. 이런 경우 먼저 대두되는 문제는 서비스 간 장애 전파 이다.
하나의 서비스 컴포넌트에 장애가 발생하면 그걸 호출하는 또다른 컴포넌트까지 장애를 전파받는다.

Service 1 -- 호출 --> Service 2

위와 같은 관계에 놓였을 때 Service 2 의 응답속도가 매우 느려졌다고 가정해보겠다.
이때 Service 1 의 모든 쓰레드가 2 의 응답을 기다리고만 있다면 다른 요청을 처리할 수 없게 되니 상태는 더 악화된다.

이런 식으로 Service 2 의 상태가 Service 1 에 영향을 주는 경우, 서비스 간 장애가 전파되었다. 고 표현한다.
Service 1 과 같이, 2 를 호출하는 또다른 서비스 컴포넌트가 존재한다면 해당 서비스도 장애 전파가 불가피하다. 이런 상황은 자칫 전체 시스템에 영향을 줄 수도 있다.

Circuit Breaker 패턴

이런 문제를 해결하는 디자인 패턴 중 Circuit Breaker 패턴이 있다.

Service 1 --> |Circuit Breaker| --> Service 2

기본적으로 Service 1 -> Service 2 호출 사이에 Circuit Breaker 를 설치하는 개념이다.
Service 2 로의 모든 호출은 이 Circuit Breaker 를 통하게되고, Service 2 가 정상적인 상황에서는 트래픽이 문제없이 통과한다.

호출한 서비스에서 장애가 감지된다면?

하지만 Circuit Breaker 측에서 Service 2 에 문제가 생김을 감지했다면 무슨 일이 발생할까?

Service 2 로의 호출을 강제로 끊어서 Service 1 의 쓰레드들이 더이상 요청에 대한 응답을 기다리지 않도록, 장애가 전파되는걸 방지한다.
하지만 서킷브레이커가 강제로 호출을 끊는 방식을 채택하고 있기 때문에, Service 1 측에서는 이런 경우에 대한 장애 처리 로직이 구현되어야 한다.

Spring 에서는 이를 조금 발전시킨 방식으로 장애 처리 가능한 기능을 제공한다.

Service 2 가 정상적으로 응답할 수 없을 때, Circuit Breaker 에서는 정해진 룰에 따라서 임시방편이 될만한 메시지(로직) 를 리턴할 수 있다.

이걸 Fall back 메시징 이라고 일컫는데,
위의 상황에서는 Service 2 가 장애 상황일때 Circuit Breaker 가Service 2 가 제공할 default 로직을 응답해서 (to Service 1) 전체 서비스에 영향이 가지 않도록 유도하는 방법이다.

이런 패턴은 Spring 프레임워크를 통해서도 적용이 가능하지만 Netflix java library 인 Hystrix 로도 구현이 되어있으며, 인프라 차원에서 envoy,io 프록시 서버를 이용하여 구축할 수도 있다.

특히 hystrix 는 오픈소스 라이브러리이기 때문에 수월하게 도입할 수 있다는 장점이 있는데, 각 서비스 상태를 대시보드를 통해 안내받을 수 있다고 한다.
(하지만 대시보드를 사용하게 된다면.. 대시보드로 접근가능한 통로를 어떻게 외부로부터 차단할지에 대해서도 생각을 해야하니 복잡하긴 하다..ㅎ)

pom.xml 이나 gradle 에 쉽게 dependency 를 작성하여 사용할 수 있다.