[MSA] #3 Circuit Breaker

[MSA] #1 Monolithic Architecture 란?

[MSA] #2 Microservice Architecture 란?

[MSA] #3 Circuit Breaker

[MSA] #4 API Gateway

[MSA] #5 Service Discovery

[MSA] #6 Spring Cloud Netflix

Circuit Breaker란? 에너지가 있는 도선과 중립 도선 사이의 전류 균형이 깨졌을 때, 전류를 차단하는 장치

학생 때 포기한 물리수업에서 나올 법한 말들이 나오네요. 한국어로는 누전 차단기입니다. (두꺼비집)

누전으로 인해 집이 다 불타버리는 것보다는 이상 징후가 있을 때 전류를 차단하여 잠깐 불편한 것이 훨씬 낫습니다. 

이렇게 접근하면 Circuit Breaker를 좀 더 쉽게 이해할 수 있습니다.

앞에서 MSA의 장점 중 하나가 한 서비스는 다른 서비스에 영향을 안 끼친다고 했습니다. 그럼 만약 한 서비스가 다른 서비스에 디펜던시를 가지고 있어도 영향을 끼치지 않을까요??

온라인 서점 서비스를 통해 이야기해보겠습니다. 책 리스트를 호출하는 API가 있습니다. 그런데 기획팀에서 리스트의 최상단에는 고객이 구입할만한 책을 보여주기를 요구했습니다. 우리는 간단하게 개인화 서비스의 API를 통하여 고객에게 맞는 상품을 가져온 뒤 리스트 첫 번째 항목에 넣을 것입니다. 

그런데 아래처럼 개인화 서비스 모두가 과도한 트래픽이나 서버 문제 등 다양한 이유로 마비가 되면 어떻게 될까요?

개인화 서비스의 장애가 그대로 책 서비스에도 전파되어, 책 서비스 또한 장애를 일으키게 됩니다. 이를 장애 전파라합니다.

과도한 트래픽에 의한 장애를 좀 더 생각해보겠습니다. 서비스는 감당할 수 있는 Request의 수를 정해놓고 그 이상의 Request가 오게 되면 큐에 쌓이게 되고 순차적으로 처리가 됩니다. (tomcat의 max-thread)

현재 개인화 서비스는 과도한 트래픽으로 인해 큐에 많은 수의 Request가 쌓여있는 상태고 책 서비스가 개인화 서비스를 호출하게 되면 큐가 다 비워질 때까지 기다려야 되는 끔찍한 상황이 오게 됩니다. 하지만 우리는 이것을 대비하여 timeout을 설정해 두곤합니다. 그래서 책 서비스가 개인화 서비스를 호출했을 때, 설정한 timeout을 넘어가게 되면 에러를 발생시켜 무작정 기다리는 것을 방지할 수 있습니다. 그러나 또 한편으로는 문제가 생길 때마다 설정한 timeout 만큼 기다려야 합니다.

MSA로 변경하면서 서비스 간에 영향을 안 끼칠 것을 기대했지만, 기대와 달리 서비스 간에 의존을 하고 있으면 강하게 영향을 끼치게 됩니다. 

Circuit Breaker는 이러한 문제를 해결할 수 있게 도와줍니다.

개인화 서비스가 정상적으로 동작할 때는 Circuit Breaker는 타 서비스로 잘 흘려보내줍니다.

<일반적인 경우>

그런데 개인화 서비스가 비정상적일 경우에는 Circuit Breaker는 이를 감지하여 개인화 서비스로 보내지 않고, 책 서비스에 다시 되돌려 줍니다. 

Circuit Breaker 구현체마다 에러를 핸들링 할 여러 가지 방식이 있는데, 대표적으로는 Default 값을 설정하는 것입니다. 가령, 개인화 서비스의 추천 책 API가 문제가 될 것을 방지해  Default로 스테디셀러 책을 두는 것입니다. 그렇게 되면 개인화 서비스가 마비됨에도 불구하고 에러 없이 자연스러운 연출이 가능하게 됩니다.

더불어 설정한 timeout 만큼 기다릴 필요도 없게 됩니다. 왜냐하면 Circuit Breaker가 문제를 감지하게 되면 그 즉시 대응을 하기 때문입니다.

<문제가 생긴 경우>