[TIL,일일 회고] 2024.08.03 - SpringCloud 서킷 브레이커

 

서킷 브레이커의 자세한 설명은 다음 포스팅에서 확인 가능합니다.▼

[Spring Cloud] Resilience4j를 활용한 서킷 브레이커의 상태 변화와 Fallback 메커니즘

 

---

 

마이크로서비스 아키텍처(MSA)는 수많은 독립적인 서비스가 서로 상호작용을 하며 복잡한 시스템을 형성합니다.

위 그림은 amazon과 neflix의 아키텍처 애플리케이션들의 마이크로서비스 간 종속성을 나타낸 그림입니다.

 

이미 TIL과 MSA포스팅에서도 언급했지만, 또다시 등장한 그림입니다.

 

또다시 가져온 이유는, MSA는 확장성, 유연성, 빠른 배포 등 많은 장점이 있지만, 동시에 각 서비스 간의 의존성이 증가하여 시스템의 안정성이 위협받을 수 있습니다.

 

특히, 하나의 서비스가 실패하면 연쇄적으로 다른 서비스에 영향을 미치고, 이로 인해 전체 시스템의 신뢰성이 떨어질 수 있습니다.

 

이러한 문제를 해결하기 위해서 등장한 기능이 바로 "서킷 브레이커"입니다.

 

 

서킷 브레이커를 번역해보면, 회로 차단기입니다.

 

SpringCloud의 서킷 브레이커 역시 회로 차단기와 비슷한 역할을 하는데, 서킷 브레이커는 마이크로 서비스간 호출 실패를 감지하여 시스템의 전체적인 안정성을 유지하고, 장애가 발생했을 때 전체 시스템으로 장애가 확산되는 것을 방지합니다.

 

---

서킷 브레이커의 상태에는 Closed, Open, Half-Open 3가지 상태가 존재합니다.

 

처음에는 닫힘이 부정적인 느낌인줄 알았고, 열림이 긍정적인 느낌으로 생각했지만 반대였습니다. 서킷 브레이커가 닫혀있다는 의미는 장애나 호출 실패가 발생하지 않아 서킷 브레이커가 활성화 안되었다는 의미였습니다.

 

만약 장애가 발생하거나 호출 실패가 발생한다면, 서킷 브레이커는 닫혀있다가 열리게 되고, 이후에 들어오는 요청은 일정시간 동안 전부 차단됩니다.

 

일정시간이 지나면, 서킷 브레이커는 오픈 상태에서 Half-Open상태로 전환되고, 일부 요청을 허용하고 시스템의 복구 여부를 확인합니다.

 

만약 일부 요청이 정상적이면 다시 서킷 브레이커는 닫힘 상태로 바뀌게 됩니다.

 

즉 Half-Open상태는 일종의 "간 보기"상태라고 할 수 있습니다.

 

---

서킷 브레이커를 위해 사용되는 라이브러리에는 Hystrix, Resilience4j가 있습니다.

 

이 중 Resilience4j의 주요 기능에는 Fallback이 있는데, Fallback은 애플리케이션의 장애나 예외 상황을 처리하는 데 도움을 줍니다.

 

즉 장애나 예외 상황이 발생했을 때 장애 전파 방지, 에러 원인 파악, 에러 전파 차단, 일관된 대체 응답 제공 등을 통해 도움을 줍니다.

 

Resilience4j는 Netflix Hystrix로부터 영감을 받은 함수형 프로그래밍으로 설계된 경량의 장애 허용(fault tolerance) 라이브러리

 

구글링을 통해 Resilience4j의 정의를 찾아보았을 때, '경량의 장애 허용'이라는 개념이 처음에는 이해가 어려웠습니다.

 

직접 동작을 확인해 보니 바로 이해할 수 있었습니다. 여기서 '경량의 장애 허용'이란, 시스템이 미리 설정한 임계값을 초과하기 전까지는 장애나 호출 실패를 수용한다는 의미입니다.

 

즉, 설정해놓은 임계점까지는 장애나 호출 실패를 허용하며, 이를 초과하면 시스템이 적절한 대응을 하게 됩니다.