[Architecture] 서킷브레이커 (Resilience4j)

서킷브레이커 개념

• 문제가 있는 외부/하위 시스템의 호출을 계속 시도해서 시스템 전체에 장애가 전파되는 것을 막는 보호장치
• 전기 차단기처럼 일정 기준 이상으로 실패하거나 지연이 쌓이면 회로를 끊고(open) 잠시 뒤에 탐색(half-open) 후 정상(closed) 으로 되돌립니다
• 상태변화 : closed → open → half-open

Resilience4j

• 서킷 브레이커 라이브러리
• 서킷 브레이커의 기능 / Fallback / 모니터링등 다양한 도구 제공
• closed / open / half-open 상태를 통해 호출 실패 관리

closed

• 기본 상태로 모든 요청을 통과시킵니다
• 해당 상태에서 호출 실패시 실패 카운트가 증가합니다
• 실패율이 임계값을 초과하면 open 상태가 됩니다

open

• 모든 요청을 즉시 실패로 처리합니다
• 모든 요청은 처리되지 않고 즉시 에러 응답을 반환합니다
• 대기 시간이 지난 후 half-open 상태로 전환됩니다

half-open

• 제한된 수의 요청을 처리/허용하며 시스템이 정상적으로 동작하는지 확인합니다
• 이 때 요청 성공 시 closed 상태가 됩니다
• 만약 요청 실패 시 다시 open 상태가 됩니다

SpringBoot 에서의 Resilience4j

• SpringBoot Starter 에서는 Resilience4j 를 의존성으로 제공해주긴 하지만 이는 추상화된 모델이다
• 즉 구현체가 없으며 구현을 직접 하거나 혹은 다른 라이브러리를 통해 구현해주어야 한다
  • io.github.resilience4j:resilience4j-spring-boot3:2.2.0 의존성은 구현체를 제공한다

COUNT_BASED 서킷 브레이커 테스트

적용한 슬라이딩 윈도우 알고리즘

• 호출 수 누적
• COUNT_BASED 윈도우 / windowSize : 5
• 최소 5건 누적 후 통계 집계
• open 조건
  1. 실패율 >= 50%
  2. 느린 호출 비율 >= 100%
     • 느린 호출 == "60초를 초과하는 호출"
     • slowCallRate 가 "100" 이므로 최근 5건 전부가 60초 초과일 경우 느린 호출로 간주
• open 유지시간 : 20초
• half-open 에서 허용되는 탐색 호출 건 : 3건

각 상태에 따른 시나리오

Closed → Open 시나리오

1. 실패율에 따른 Open
   • 윈도우 사이즈가 5개로 설정되어 있으므로 최소 3/5 실패 (60%) 이어야함 → >= 50%
   • 최근 호출이 4건 이하일 때는 통계 정보를 수집하지 않으므로 그대로 Closed
2. 느린 호출(60초 초과)에 따른 Open
   • 최근 5건이 모두 60초를 초과한 호출

Open → Half-Open (탐색전환) 시나리오

• Open 이후 20초가 지난 뒤 다음 들어오는 요청에서 Half-Open 전환
  • 최대 3건만 통과시킨후 상태를 시험

Half-Open → Closed (정상 복귀) 시나리오

• 모든 조건을 만족하면 Closed
  • 실패율 < 50% (3건 중 0 or 1만 실패)
  • 느린 호출 비율 < 100% (3건 전부가 60초 초과면 안됨)

Half-Open → Open (재오픈) 시나리오

• 아래 중 하나라도 만족하면 다시 Open
  • 실패율 >= 50% (3건 중 2건 실패)
  • 느린 호출 비율 >= 100% (3건 전부 60초 초과)

테스트 코드

• https://github.com/leeMK09/MemoMemo/tree/main/Playground/circuitBreaker_Resilience4j