CircuitBreaker 로 예방하는 장애 전파(1)

📌 들어가며

소프트웨어는 모두 실패한다 - 버너 보겔스(아마존 부사장)

 

 아무리 열심히 설계하여 개발하고 QA를 진행한다 하더라도

대고객 시스템의 경우 혹은 대고객이 아니더라도 예상치 못한 장애를 마주하는 경우가 발생합니다.

 

 여러 개의 작은 독립적인 마이크로서비스로 분할하는 아키텍처 패턴이 많아지는 요즘, 단일 서브 도메인의 장애가

전체 시스템에 영향을 줄 수 있어 예상치 못한 장애 상황이 발생할 수 있습니다.

 

 이렇게만 보면 MSA 아키텍처로 설계하는 것 자체가 잘못된 것은 아닐까 하는 생각이 들 수 있습니다.

하지만 이는 '완벽한 시스템을 만들기보다, 실패에 유연하고 빠르게 대응 가능한 시스템을 설계해야 한다.'  라는 의미로 해석할 수도 있습니다.

 

따라서 MSA 환경에서는 단일 서브 도메인(마이크로서비스)의 장애가 전체시스템에 영향을 미치지 않도록

장애가 발생해도 견딜 수 있는 내결함성(Fault Tolerance) 에 대한 설계가 무엇보다 중요합니다.

 

이를 위해서 다양한 기술과 방법들이 존재하며, 이번 포스팅에서는 그 중에서도 circuit-breaker-pattern 에 대해 알아보고자 합니다.

 

---

📌 케스케이드 장애(Cascading_failure)

 케스케이드 장애는 MSA 환경에서 서비스의 사용량이 많은 경우에 

한 서브 도메인으로 과부하가 걸리거나 다른 사유로 인해 오류가 발생하면 연쇄적으로 오류가 발생하는 것을 의미합니다.

 

예를 들어 '장바구니 도메인'에서 장바구니에 담긴 품목을 계산하는 기능이 동작될 때를 들 수 있습니다.

장바구니에 담긴  해당 품목의 재고를 확인하기 위하여  '업무 지원' 도메인에 재고상태를 물어보거나 

쿠폰할인을 적용하기 위해 '쿠폰 도메인' 에 쿠폰의 유효성을 물어보기 위해 외부통신을 하는 상황에서 만약 두 도메인 중 한 도메인 이라도장애가 발생하여 ReadTimeout 또는 ConnectionTimeout 이 발생한 경우 이는 장바구니 도메인의 품목계산 기능이 정상적으로작동하지 않는 상황으로 이어질 수 있습니다.

 

이러한 결함들이 발생하는 경우 마이너한 버그의 경우 짧은 시간 후에 자체적 수정이나, 재시도(Retry) 패턴꽈

같은 저략으로 해결할 수 있습니다.

 

그러나 예기치 않은 이벤트로 인한 오류가 발생하여 정상 복구 시점까지 오래 걸리는 상황이 발생하게 되면

이러한 오류는 전체 서비스의 실패에 이를 수 있습니다. 이런 상황에서 재시도(Retry)를 하여

타 서브 도메인을 계속 호출하는 것은 무의미 할 수 있으며 (오히려 해당 서브도메인에 의미없는 부하를 계속 가할 수 있다)

실패를 받아들이고 해당 실패를 처리해야 합니다.

 

예를 들어, 서비스를 호출하는 작업은 제한 시간을 걸어두고, 해당 기간내에 응답하지 않을 경우 실패 메시지로 응답하도록 구현이 가능하합니다. 그러나 해당 전략은 제한 시간이 만료될 때까지 동일한 작업에 대한 많은 동시요청을 차단시킬 수 있다. 해당 요청들은 쓰레드와 메모리 및 CPU등의 자원을 점유하게 됩니다.

 

결과적으로 이러한 리소스가 고갈되어 동일한 리소스를 사용해야 하는 시스템의 관련되지 않은 다른 부분까지 오류가 발생할 수 있습니다. 이러한 상황에선 작업이 즉시 실패하고 성공할 가능성이 있는 경우에만 서비스 호출을 하는 것이 좋습니다.

 

서킷브레이커 패턴(circuit-breaker-pattern)은 장애가 발생한 서비스를 감지하고

더이상 요청을 보내지 않도록 차단하여, 장애가 퍼지지 않도록 격리시킵니다.

 

---

📌 서킷브레이커 (Circuit-breaker)

CircuitBreaker는 직역하면 회로 차단기로,
가정집에서 쉽게 볼 수 있는 누전 차단기가 화재를 막는 것과 비슷하게  웹 애플리케이션이 실패하고 있는 요청 혹은 실패할 가능성이 있는 작업을 반복적으로 실행하려고 시도하는 것을 방지하여 서비스 간의 장애 전파를 막는 역할을 한다고 이해하면 됩니다.

 

이를 통해 시스템의 장애 확산을 막고 장애 복구를 도와주며 유저는 불필요하게 대기하지 않게 됩니다.

 

또한 오류가 오래 지속된다고 판단하는 동안 오류가 수정될 때까지 기다리고,

오류가 해결되었는지 여부를 감지하여 문제가 수정된 것으로 보이면 애플리케이션이 작업 호출을 시도할 수 있습니다.

 

📌 CircuitBreaker의 3 가지 상태

	Closed	Open	Half Open
상황	정상	장애발생	Open 상태가 되고 일정 요청 횟수/시간이 지난 상황. Open과 Closed 중 어떤 상태로 변경할지에 대한 판단이 이루어지는 상황
요청에 대한 처리	요청에 대한 처리를 수행 정해진 횟수/비율만큼 실패할 경우 장애 상황으로 인지하여 Open 상태로 변경하게 된다.	타 서브도메인으로의 외부 요청을 차단하고 에러를 뱉거나 지정한 callback 메서드를 호출하여 현 장애 상황에 대해 대처한다.	요청에 대한 처리를 수행하고 실패시 Open 상태로,  성공시 Closed 상태로 변경한다.

 

❗️ CircuitBreaker에서의 장애 판단의 기준은 아래와 같습니다.

1. slow call : 기준보다 오래 걸린 요청
2. failure call : 실패 혹은 오류 응답을 받은 요청

❗️ 각 상태는 지정한 속성 값을 통해 제어할 수 있으며 Resilience4j를 통한 구현부에서 설명하겠습니다.

 

 

📌 CircuitBreaker의 상태변경

 

 

• Closed 상태에서는 정상 요청 수행
• 실패 임계치(failureRate Threshold or slowCallRateThreshold) 도달시 Closed 에서 Opend 으로 상태 변경
• Open 상태에서 일정시간(waitDurationInOpenState) 소요 시 Half Open 상태로 변경
• Half Open 상태에서의 요청 수행
  • 지정한 횟수(permittedNumberOfCallsInHalfOpenState) 수행 후 성공 시 Half Open 상태에서 Closed로 변경
  • 지정한 횟수(permittedNumberOfCallsInHalfOpenState) 수행 후 실패 시 Half Open 상태에서 Open 상태로 변경

 

 

다음 포스팅에서는 이러한 CircuitBreaker를 실제로 구현하는 방법에 대해서

알아보도록 하겠습니다. 감사합니다.

 

 

출처: 

https://velog.io/@akfls221/resilience4j-%EB%A1%9C-%EC%95%8C%EC%95%84%EB%B3%B4%EB%8A%94-%EC%84%9C%ED%82%B7%EB%B8%8C%EB%A0%88%EC%9D%B4%EC%BB%A4%ED%8C%A8%ED%84%B4CircuitBreaker

https://oliveyoung.tech/blog/2023-08-31/circuitbreaker-inventory-squad/