Circuit Breaker 서킷 브레이커 이론

Circuit Breaker = 회로 차단기

API 호출에 실패할 때, 실패하는 API를 더 이상 호출하지 않고, 빠르게, fast fail 하게 해주는 것. 

이를 통해 시스템이 점진적으로 실패하는 대신 전체 시스템의 장애로 이어지지 않도록 한다.

 

아마존의 화면을 구성하는데에는 여러개 API 가요청된다. 

만약 그 중 하나라도 실패하면 서비스는 어떻게 될까?

서비스 장애시 단순히 화면이 나온다, 안나온다는 큰 문제가 되지 않는다. 

api 호출시, 실패하는 api 를 호출하면 타임아웃 대기 시간까지 대기해야 한다. -> 전체 퍼포먼스가 떨어진다. 

 

ex) 장바구니, 추천탭은 20ms 걸려 왔는데, 리뷰 api 장애발생으로 300ms(api time out) 대기 한다면 -> 이 페이지 하나를 구성하기 위해 걸리는 시간은 300ms. 리뷰 제외 api는 빨리 도착했는데도 빨리 결과를 보여줄 수 없어진다.

장애가 나면 1스레드가 1초에 3개밖에 처리하지 못한다.

-> 300ms 동안 대기하지 않고 실패시 빨리 리턴. 속도가 다시 20ms로 바뀐다. 이것이 서빗 브레이크의 용도이다.

 

장애 연쇄 반응

• A 서비스가 장애가 날 경우, 여기에 의존하는 B 서비스도 점점 느려진다.
• B 서비스에 의존하는 C,D,E 서비스도 결국 느려진다.

 

필수적인 API 와 필수적이지 않은 API 로 나눌 필요가 있다.

• 서비스 기준에 따라 달라질 수 있다.
• 커머스에서 상품 리스트를 보여줄 수 없다면 큰 문제가 발생함.
  • 그러나 일부 카테고리만 안 보인다면 그냥 넘어가도 되지 않을까?

 

필수적이지 않은 API에서 오류가 발생할 때, 이를 어떻게 처리해야 서비스에 영향을 낮출 수 있을까? 

• Fast Fail Back  정상적이지 않으면 최대한 빨리 실패하자.
  • 정상적이지 않으면, TimeOut등으로 처리량이 줄어들고, 부하가 늘어날수 있다. 
  • 예를 들어, 추천 서비스에 장애 발생시, 기본적으로 미리 정의한 동작을 한다.
    • 추천 서비스 장애 시, 기본적인 순서로 카탈로그 서비스에 나온 정보를 보여준다.  

 

Cricuit Breaker 상태

• Closed
  • 정상적인 API 호출이 되는 상태
  • 20ms 안에 응답이 온다.
• Open 
  • 일정시간 동안 API 호출을 바로 실패하는 상태.
• Half Open
  • open 인 상태에서 일정 시간이 지나면 상태를 다시 확인하기 위해 api호출을 시도해보는 상태
  • half open 에서 성공하면 closed, 실패하면 다시 open으로 이동 

api 호출 성공시, success open. 한 번 실패했다고 바로 open 으로 가는 것이 아닌, 

1,2 회 실패 하더라도 계속 closed 상태를 유지하게 된다. ( threshold가 3미만이라는 전제 하에. 

그동안 api 가 한 번이라도 success 가 된다면, 다시 closed 상태가 되고, threshold 값이 0으로 초기화 된다. 

만약 threshold가 3 이라면, 상태가 open으로 바뀐다. 

서킷이 open 이 되니 api 호출이 들어오면 계속 실패를 리턴한다.

계속 실패를 리턴하다가 타임아웃이 되면 half open 으로 진입해 다시 시도.

성공하면 closed, 실패시 open.

 

 

circuit breaker의 실제 구현은, api server 앞에 wrapper 를 두고, 실패 횟수를 세다가  threshold가 넘어가면 타이머를 걸어두고 계속 실패를 보낸다.