서킷브레이커는 MSA 에서 마이크로서비스 간 호출 실패 감지
와 전체적인 안정성 유지
의 역할을 하는 패턴이다.
빠른 실패를 도출하여 장애를 격리해 다른 서비스에 나쁜 영향을 끼치지않게 한다.
완벽한 소프트웨어는 없기 때문에 언제든 실패상황을 겪을 수 있고 이를 예방할 필요가 있다.
서킷 브레이커 라이브러리로는 Resilience4j가 있다.
위에서 언급했듯이 서비스 간의 호출 실패를 감지하고 시스템의 안정성을 유지한다.
아래의 세가지 서킷 브레이커 상태를 통해 호출 실패를 관리한다.
- 클로즈드(Closed) 🌑
default 상태로, 모든 요청을 통과시킨다. (closed라고 다 막아버리는 상태가 아님)
클로즈드 상태에서호출실패 시
실패 카운터가 증가한다.
실패 카운터가 증가하며 실패율이 증가하게 되고 실패율이 설정된 값을 초과하면 오픈상태로 전환된다.
- 오픈(Open) 🌕
오픈 상태로 전환 시 모든 요청을즉시 실패
처리한다.
설정된 대기 상태 시간 이후하프오픈
상태로 전환된다.
- 하프오픈(Half-Open) 🌗
하프 오픈 상태에서는 제한된 수의 요청(테스트)을 허용하고 시스템이 정상복구되었는지 확인한다.
요청 성공 시클로즈드
상태로 전환된다.
요청 실패 시 다시 '오픈' 상태로 전환된다.
호출 실패 상황에서 다른 대체 로직
을 제공하여 시스템 안정성을 확보하는 과정 (대안)
Fallback의 경우 생각보다 중요한 수단이다.
나도 간혹 어떤 웹사이트를 보다보면 원래 로직상 나타나야할 부분이 나오지 않고 white label을 보여주는 사이트들이 있다.
이런 경우 white label 페이지나 실패 페이지를 사용자에게 직접적으로 보여주기보다는 fallback 처리를 하고 alert를 띄워줌으로써 사용자에게 조금 더 나은 사용자 경험을 줄 수 있을 것 같다.
더 나은 사용자 경험은 서비스에 대해
신뢰
를 높이고 사용률이나 안정성을 높일 수 있다.
Prometheus와 Grafana를 이용해 서킷 브레이커의 상태를 모니터링 할 수 있다.
우선 GateWay라는 말은 무슨 뜻일까 ?
게이트웨이
란 서로 다른 통신망이나 프로토콜 규율을 사용하는 네트워크 간에 통신을 가능하게 해주는 컴퓨터나 SW를 지칭한다.
여기에 api가 붙은 API GateWay의 경우 client의 요청을 받아 백앤드 서비스로 라우팅
을 해주고, 다양한 부가 기능을 제공하는 중간 서버
를 말한다.
대표적인 API GateWay로는 SpringCloudGateWay가 있는데 MSA 환경에서 자주 사용된다.
라우팅이나 다양한 필터링 기능을 제공한다.
MSA 구조 특성 상 각각의 서비스들은 서로 다른 애플리케이션으로 구현되어있다.
만일 이런 구조에서 사용자가 각각의 서비스에서 정보를 얻기 원할 때는 Payment, Order, Cart에 각각 요청을 보내야한다.
그렇다면 A/Payment, B/Order, C/Cart 처럼 각각의 호스트가 달라질 것이다.
이때, 호스트를 통일 시킬 수 있는 방법이 바로 API GateWay이다.
위 그림처럼 클라이언트 애플리케이션과 각 서비스 애플리케이션 사이에 API GateWay라는 애플리케이션을 두고 GateWay에 요청을 보내면 호스트를 통일시킬 수 있다.
GateWay 애플리케이션 단에서 인증, 인가 로직을 포함시킬 수도 있다.
Case A) Login하지 않은 사용자가 Payment 애플리케이션을 들어가야하는 요청이 들어온 경우
해당 case의 경우 GateWay단에서 로그인되지않은 사용자(인증되지 않은 사용자)임을 인지하고 Login page로 연결시킬 수 있다.
또한 해당 과정에서 count 등을 사용해 로그인되지 않은 사용자의 내부 애플리케이션(예시에서는 Payment) 접근 횟수 등을 얻을 수 있다. (Logging)
바로 앞에서 언급한 Case A 처럼 필터가 필요한 경우 필터링을 사용하면 된다.
Global Filter(모든 요청), Gateway Filter(특정 라우터)
필터 기능을 사용하기위해서는 GlobalFilter나 GatewayFilter 인터페이스를 구현하고, filter 메소드를 오버라이드해서 사용 가능하다.
Pre 필터
요청 처린 전
실행 -> 요청을 가로채고 필요한 작업을 모두 수행 후 다음 요청을 전달하는 방식
Post 필터
요청 처리 후
응답 반환 전 실행
Pre필터의 경우 Post 필터와 다르게 필터로써의 역할 이후 추가적인 비동기 작업이 필요없으므로 then 메소드가 필요하지 않지만, Post필터의 경우 필터 완료 후 추가적인 작업을 해야하하므로 then 메소드를 통해 정의해준다.
필터가 여러개 존재할경우 getOrder 메소드를 오버라이드해서
우선순위
를 지정해 줄 수 있다.
Spring Boot2 에서는 Zuul을 사용한다. (같은 Gateway로써 비슷한 기능을 제공함)