서킷 브레이커 패턴은 장애가 발생한 서비스를 감지하고 더 이상 요청을 보내지 않도록 차단하여 장애가 퍼지지 않도록 격리하는 방법이다.
서킷 브레이커는 주로 CLOSED, OPEN, HALF_OPEN 세 가지 상태로 나눠지는데 각각의 상황에 따라 시스템의 요청을 어떻게 처리할지를 결정한다.
서킷 브레이커의 필요성
- 시스템의 안정성 : 장애가 발생한 서비스에 계속 요청을 보내면, 해당 서비스뿐만 아니라 전체 시스템이 다운될 위험이 있다.
- 장애를 조기에 감지하고 대응 : 서킷 브레이커는 장애가 발생했을 때 즉시 요청을 차단하여 문제를 조기에 해결할 수 있는 기회를 제공한다.
- 사용자 경험을 개선 : 장애가 발생했을 때 사용자에게 적절한 피드백을 제공함으로써 불필요한 대기 시간을 줄일 수 있다.
서킷 브레이커의 작동 원리
서킷 브레이커는 요청을 처리하는 과정에서 성공과 실패를 모니터링한다.
기본적으로 CLOSED 상태에서 시작하는데 이 상태에서는 요청이 정상적으로 처리된다.
실패가 발생할 경우 일정한 임계값을 초과하면 OPEN 상태로 전환되어 요청이 차단되고, 일정 시간이 지나면 HALF_OPEN 상태로 전환된다.
이 상태에서는 일부 요청을 허용하여 시스템이 정상적으로 작동하는지 테스트하는데 만약 요청이 성공하면 다시 CLOSED 상태로 돌아가고, 실패하면 다시 OPEN 상태로 돌아간다.
Fallback 메서드
Fallback 메서드는 서킷 브레이커가 OPEN 상태일 때 대체 동작을 수행하는 메서드로, 요청이 실패했을 때 사용자에게 제공할 수 있는 대체 서비스를 정의하는 것이다.
예를 들어 특정 API가 응답하지 않을 경우, 미리 정의된 대체 데이터를 반환하거나 사용자에게 오류 메시지를 제공하는 방식이다.
Fallback 메서드는 서킷 브레이커와 함께 사용되며, 장애가 발생했을 때 사용자에게 더 나은 경험을 제공할 수 있도록 돕는다.
이를 통해 시스템의 신뢰성을 높이고, 사용자에게 불편을 최소화할 수 있다.
Fallback 메서드의 활용 예시
예를 들어 고양이 사진을 요청하는 경우, 사용자가 요청을 보냈지만 서버가 응답하지 않는 상황에서 서킷 브레이커가 OPEN 상태로 전환되면, Fallback 메서드가 호출되어 미리 준비된 고양이 사진을 반환할 수 있다.
이러한 방식으로 시스템은 장애가 발생했을 때도 사용자에게 적절한 서비스를 제공할 수 있고, Gateway와 같은 아키텍처에서 서킷 브레이커와 Fallback 메서드를 함께 사용하면 여러 서비스 간의 통신에서 발생할 수 있는 문제를 효과적으로 관리할 수 있다.
