서킷 브레이커 패턴의 주요 목적은 장애가 발생한 시스템 혹은 서비스에 대한 요청을 일시적으로 중단시켜, 해당 시스템이나 서비스가 회복될 시간을 제공하고, 시스템의 안정성과 가용성을 유지합니다.
특히나 전체적인 시스템 구성이 MSA 로 되어있다면 다른 서비스를 호출하는 경우가 매우 빈번합니다. 문제는 서버들에게 장애가 발생할 수 있다는 점인데, 호출한 다른 서비스에 장애가 발생했다면 장애가 전파되어, 해당 서비스까지 문제가 발생할 수 있습니다.
또한 장애가 발생한 서버에 계속 요청을 보내게 되면 장애 복구를 힘들게 만듭니다. 그래서 장애가 발생한 서비스를 탐지하고, 요청을 보내지 않도록 차단할 필요가 생기게 되었으며
서킷 브레이커 패턴은 문제가 발생한 지점을 감지하고 실패하는 요청을 계속하지 않도록 방지합니다. 이를 통해 시스템의 장애 확산을 막고, 장애 복구를 도와주며 사용자는 불필요하게 대기하지 않게 됩니다.
전구에 문제가 생겨서 계속하여 전류가 흐르면 위험한 상황이라면 전구에 과부하가 걸려 문제가 생길 수 있습니다.
여기서 등장하는 회로 차단기는 자동으로 회로를 열고 전류가 흐르지 않도록 차단합니다.
한 예로 노트북에 과전압이 들어올 때 회로를 차단하여 보호한다 생각하시면 좋습니다.
보호가 안되면 보드가 고장나고 불이 날겁니다.
이제 우리는 전구와 전원을 다음과 같이 정의하겠습니다.
개방(Closed) | 차단(Open) | 일부 차단(Half Open) | |
상황 | 모든 것이 정상 | 외부(Callee)에 장애가 발생 | Open 상태가 되고 일정 시간이 지남 |
요청 | Open 상태가 되고 일정 시간이 지남 | 외부(Callee) 요청을 차단 후 바로 에러를 받음 | 외부(Callee) 요청을 차단하고 바로 에러를 받음 |
상태 전이 | 외부(Callee) 요청을 차단 바로 에러를 받음 | 특정 시간이 지나면 Half Open 상태가 됨 | 허용 요청에 따라 변경 성공 : Closed 실패 : Open |
그림과 함께 표를 확인해보시면 감이 금방 오실겁니다.
여기서 외부에 장애가 발생했는지 판단하는 기준은 다음과 같습니다.
이를 통해 규칙을 만들어봅시다
자 이제 정리 시간입니다. 위의 내용의 반복입니다. 서킷 브레이커를 회로라고 하겠습니다.
특히나 에러가 나는 것을 API 호출하는 것 또한 서비스에는 부담이 될 수 있는데, 이는 요청하는 서버 또한 대기해야 할 수 있기 때문에 부하를 증가시키는 문제를 야기합니다.
Reslience4J 사용을 권장합니다. 넷플릭스에서 만든 Hystrix 가 있지만 Deprecated 되었습니다.
ganesha 가 있습니다