장애 및 실패 처리를 위한 서킷 브레이크 패턴

• 다양한 서비스 등록, 탐색 위한 Service registry , Service discovery 패턴
• 서비스 단일 진입을 위한 API 게이트웨이(gateway) 패턴 & BFF(Backend For Frontend) 패턴
• 외부 구성 저장소 패턴
• 마이크로서비스 인증/인가 패턴
• 장애 및 실패 처리를 위한 서킷 브레이크 패턴
• 모니터링과 추적 패턴
• 중앙화된 로그 집계 패턴
• 서비스 매시(Service Mesh) 패턴

장애 및 실패 처리를 위한 서킷 브레이크 패턴

여러 개의 서비스로 이루어진 시스템은 하나의 서비스의 장애 발생 시 다른 서비스가 영향을 받을 수 있다. 이런 장애가 발생된 서비스를 격리하여 유연하게 처리할 수 있는 방법이 필요하다.

이를 위한 방법이 서킷 브레이크 패턴이다. 서비스 수가 많아지면 장점도 존재하지만 단점 역시 존재한다. 예를 들면 사용자가 접하는 프론트의 시스템의 시스템은 정상적인데 특정 서비스를 선택하면 즉각 에러가 발생하지도 않고 한참동안 대기하는 상황이 될 수 있다. 사용자는 장애인지 아닌지 파악도 안되고 그냥 시스템이 느려졌다고 판단할 수도 있다.

이런 상황은 정상적인 서비스가 장애인 서비스에 의존하여 서비스를 제공할 때 발생되는 상황으로 장애가 다른 서비스로 전이된 상태이다. 과부하나 또한 특정 서비스에 문제가 생겼을 때 자연스럽게 다른 정상적인 서비스로 요청 흐름이 변경되게 해야 한다.

그렇게 하기 위해서 서비스 상태는 항상 실시간으로 관리되어 시각화 하고 모니터링 할 수 있어야 하고 특정 서비스에 장애가 감지되면 이러한 장애가 다른 서비스로 전이되지 않도록 하는 방법이 반드시 필요하다. 전기회로 차단기와 비슷하다 하여 서킷브레이크 패턴이라고 한다.

간단히 설명하면 A라는 서비스가 B라는 서비스를 호출하여 자신의 서비스를 제공하는데 B 서비스에 장애가 발생되면 이런 동기 Request의 성격상 A는 계속 기다리게 된다. 이런 상황은 A라는 서비스까지 장애인 것처럼 사용자에게 느끼게 한다. 서킷 브레이크패턴은 이런 경우에 B 서비스 호출에 대한 연속 실패 횟수가 임계 값을 초과하면 회로 차단기가 작동하여 시간 초과 기간 동안 서비스를 호출하려는 모든 시도를 즉시 실패하게 만드는 것이다.

그리고 다음 그림과 같이 대체 처리를 하는 폴백(Fallback) 처리를 지정해 놓으면 폴백 메서드가 자연스러운 처리를 진행하게 된다. 그럼 사용자는 특정 서비스가 장애인지 눈치채지 못하고 시간이 흘러 장애가 복구되었을 때 다시 호출을 정상화시키면 된다.