서킷브레이커 패턴의 등장
개발을 하다보면 외부 API를 호출야 하는 경우가 있다. 특히나 MSA환경에서는 매우 빈번하다. 문제는 각각 서버들에 장애가 발생할 수 있다는 점이다. 문제가 생긴 서버를 호출한 다른 서비스들까지 장애가 전파된다!
그래서 장애가 발생한 서비스를 탐지하고, 요청을 보내지 않도록 차단할 필요가 생기게 되었다.
서킷브레이커 패턴이란?
문제가 발생한 지점을 감지하고 실패하는 요청을 계속 보내지 않도록 방지한다. 이를 통해 시스템의 장애 확산을 막고, 장애 복구를 도와주며 사용자는 불필요한 대기하지 않게 된다. 서킷 브레이커 패턴은 클라이언트 측면에서 장애를 방지하기 위한 도구로써, 실패할 수 있는 작업을 계속 시도하지 않도록 방지한다.
서킷브레이커의 3가지 상태
| 구분 | Closed | Open | Half Open |
|---|---|---|---|
| 상황 | 모든 것이 정상인 상황 | 외부(Callee)에 장애가 발생한 상황 | Open 상태가 되고 일정 시간이 지난 상황 |
| 요청 | 정상적으로 요청을 전달 | 외부(Callee)로의 요청을 차단하고 바로 에러를 반환 (Fail-fast) | 외부(Callee)로의 요청을 차단하고 바로 에러를 반환 |
| 상태 전이 | 장애가 일정 임계치를 넘으면 Open 상태로 변경 | 특정 시간이 지나면 Half Open 상태가 됨 | 일부 허용된 요청들이 성공한 경우 Closed 상태로, 실패인 경우 Open 상태로 변경 |
외부에 장애가 발생했는지 판단하는 기준을 크게 2가지가 있는데, 각각의 정해진 임계치가 넘어갈 경우 요청이 차단된다.
- slow call: 기준 시간보다 오래 걸린 요청
- failure call: 실패하거나 오류를 응답받은 요청
서킷 브레이커의 동작 방식
1) 외부 서버가 정상 실행중이라면, 서킷이 닫혀있고 요청이 정상적으로 실행됨.
2) 🚨 외부 서버에서 장애 발생
3) 요청이 계속 실패하고, 회로가 Open 상태가 됨.
4) 이후 요청들은 더 이상 전달되지 않고 빠르게 차단되며, 빠르게 에러 또는 실패 응답을 반환함.
5) 이후에 외부 서버가 정상 복구됨.
6) 회로가 Open 상태가 된지 특정 시간이 지나고, Half Open 상태로 변경됨.
7) 일부 요청들이 외부 서버로 전달되고, 응답이 성공하여 Closed 상태가 됨.
8) 모든 요청들이 정상 요청장애 전파 시나리오
동시에 100명의 사용자가 외부 서비스를 호출하는 기능을 요청한다.그리고 타임아웃은 30초이다
-> 100개의 요청이 30초씩 대기하는 동안 각각이 쓰레드를 붙잡고 있는다. 그런데 만약 서버의 쓰레드 풀이 100개가 최대라면, 그 30초 동안 다른 기능(ex. 상품조회, 로그인)을 요청하지 못하게 된다.
서킷브레이커가 이러한 상황을 빠르게 차단하여 쓰레드가 묶이는 걸 막아주는 것이다.
서킷브레이커가 작동했다. 그런데..?
서킷브레이커 패턴은 장애가 더 이상 전파되지 않도록 막는 것이지 장애 복구의 개념이 아니다.
서버 A가 서버 B에 추천상품을 GET하는 요청을 했는데 서버 B가 장애가 나서 응답을 주지 않는다.
그럼 사용자 입장에선 갑자기 상품이 보이지 않는 상황이니 참으로 황당할 것이다.
만약 마트에서 자주 사던 음료가 품절인데, 점원이 "비슷한 음료인데 이건 어떠세요?" 하거나, "지난번에 사셨던 거 다시 드릴까요?" 라고 하면 어떨까?
우리는 이걸 캐시화해서 저장할 수 있다. 캐시에 있는 값이 엄격한 최근 데이터는 아닐지라도 '완벽한 데이터'보다는 '적당히 좋은 사용자 경험'이 나을 수 있기 때문이다.
