TIL - 서킷브레이커(Circuit Breaker)의 외부 모니터링과 서비스 특성에 맞는 상태 전환 정책 설정

서킷브레이커(Circuit Breaker)에 대해 공부하다 궁금증이 생겼다. 

1. 서킷 브레이커의 외부 모니터링 설계 이유와 실시간 대응 방법

서킷 브레이커는 시스템 장애를 감지하고 호출을 차단하여 복구 가능성을 테스트한다. 이를 외부에서 모니터링할 수 있도록 설계하는 이유는 개발자나 운영자가 장애 상태를 실시간으로 파악하기 어려울 수 있기 때문이다. 예를 들어, 서킷 브레이커가 Open 상태로 전환되면 호출이 차단되지만, 내부 로직만으로는 이 상태를 즉시 감지하기 어렵다.

 

서킷 브레이커는 기본적으로 장애 상태를 자체적으로 관리하고, 시스템 내부에서 특정 실패 조건(예: 실패율 초과, 응답 시간 지연 등)을 감지하여 Open 상태로 전환한다. 그러나 이 상태가 실제로 발생했다고 해서 자동으로 외부에 알림이 가지 않는 이상, 개발자는 코드 내에서 서킷 브레이커의 상태를 수동으로 추적하거나 로그를 통해 확인해야 한다..

 

그래서 이를 해결하기 위해 외부 모니터링 도구를 사용해 서킷 브레이커 상태를 실시간으로 추적하고 정애 상태를 자동으로 감지할 수 있도록 설계한 것이다. 외부 모니터링 도구인 Prometheus와 Grafana를 사용해 서킷 브레이커의 상태를 실시간으로 확인하고, 문제가 발생하면 Slack이나 Email 알림을 통해 빠르게 대응할 수 있으며, Grafana에서 대시보드로 이를 시각화할 수도 있다.  

 

2. 서킷브레이커의 상태 전환 정책과 서비스 특성 고려는 어떻게 해야할까?

서킷브레이커의 상태 전환 정책에 있어 서비스의 주용도, 성능 요구 사항, 트래픽 패턴, 실패율 처리 등 다양한 고려사항이 있지만 그 중에서도 핵심은 서비스의 중요도와 성능 요구 사항이다. 

 

주문 관리 비즈니스를 예로 들면, 주문 처리 서비스는 핵심 서비스로, 고객의 주문이 실시간으로 처리되고, 주문이 정확히 이행되어야 한다. 이 서비스에서 장애가 발생하면 고객의 경험과 비즈니스의 신뢰성이 크게 영향을 받으므로, 서킷 브레이커의 실시간 반응이 중요하다.

 

반면, 결제 알림 발송 서비스는 보조 서비스로, 결제가 성공적으로 이루어졌다는 알림을 고객에게 보내는 기능이다. 이 서비스는 잠시 장애가 발생하더라도 주문 처리에는 큰 영향을 미치지 않으므로, 서킷 브레이커의 반응 속도를 덜 민감하게 설정할 수 있다.

 

또한, 성능 요구 사항을 고려한 서킷 브레이커 설정이 필요하다. 예를 들어, 실시간 주문 처리에서는 빠른 응답 시간이 중요하므로 서킷 브레이커가 느리게 반응하지 않도록 해야 한다. 반면, 주문 내역 조회 서비스는 사용자 경험에 큰 영향을 미치지 않지만, 트래픽이 많을 수 있어 서킷 브레이커가 과도한 호출 차단을 하지 않도록 설정해야 한다.

 

결론 

각 서비스의 중요도와 성능 요구 사항을 정확히 파악하고 서킷 브레이커를 적절하게 설정해야만, 시스템 전반의 안정성과 효율성을 보장할 수 있다.