Phase 5레슨 24
Circuit Breaker (심화)
Closed/Open/Half-Open, Hystrix, Resilience4j, Fallback — 장애 전파 차단
💡ELI5·
전자차단기와 Circuit Breaker
Closed (정상) 요청 → 서비스 → 응답 실패 카운트 증가 ↓ 실패율 ≥ 50% (최소 20개 요청 후) Open (차단) 요청 → 즉시 Fallback (서비스 호출 안 함) ↓ 60초 후 Half-Open (테스트) 제한적 요청 (3개) → 서비스 성공 → Closed 실패 → Open
💡 비유 — 전자차단기(두꺼비집). 과부하가 걸리면 스스로 차단(Open)되어 화재를 막는다. 수동으로 재연결(Half-Open)해서 테스트하고, 정상이면 다시 사용(Closed). 소프트웨어도 같은 원리로 장애 전파를 막는다.
🔬Deep Dive·
상태 전환 상세
| 상태 | 동작 | 전환 조건 |
|---|---|---|
| Closed | 모든 요청 통과, 성공/실패 카운트 | 실패율 ≥ 임계값 → Open |
| Open | 모든 요청 즉시 Fallback | 대기 시간 경과 → Half-Open |
| Half-Open | 제한적 요청 테스트 | 테스트 성공 → Closed, 실패 → Open |
💻Code·
Resilience4j 예시 (Java)
CircuitBreakerConfig config = CircuitBreakerConfig.custom()
.failureRateThreshold(50) // 실패율 50% → Open
.slowCallRateThreshold(50) // 느린 호출 50% → Open
.slowCallDurationThreshold(Duration.ofSeconds(2))
.minimumNumberOfCalls(20) // 최소 20개 호출 후 판단
.waitDurationInOpenState(Duration.ofSeconds(60)) // 60초 후 Half-Open
.permittedNumberOfCallsInHalfOpenState(3) // Half-Open에서 3개 테스트
.slidingWindowSize(10) // 최근 10개 호출 기준
.build();
CircuitBreaker cb = CircuitBreaker.of("payment", config);
// Fallback과 함께 사용
String result = cb.executeSupplier(() -> paymentService.charge(amount),
() -> "결제 일시 실패. 주문은 보류됩니다.");🔬Deep Dive·
Fallback 설계 원칙
| 상황 | 좋은 Fallback | 나쁜 Fallback |
|---|---|---|
| 추천 서비스 장애 | 인기 상품 목록 반환 | null 반환 |
| 사용자 프로필 장애 | 캐시된 프로필 | 에러 페이지 |
| 결제 서비스 장애 | 주문 보류 + 나중에 결제 안내 | 결제 무시하고 주문 완료 |
| 검색 서비스 장애 | 캐시된 인기 검색어 | 빈 결과 |
Fallback은 '사용자가 이해할 수 있는 대안'이어야 한다. null이나 에러는 사용자 경험을 망친다.
⚖️Trade-off·
Circuit Breaker의 Trade-off
| 이점 | 대가 |
|---|---|
| 장애 전파 차단 | 임계값 튜닝 어려움 |
| 빠른 실패로 자원 보호 | 정상 요청도 일시적 차단 가능 |
| 자동 복구 (Half-Open) | Fallback 로직 설계 부담 |
| 사용자 경험 보호 (Fallback) | 복잡한 상태 관리 |
❓ 체크포인트 질문
- 1.Circuit Breaker의 세 상태는?
- 2.Open 상태에서 '빠른 실패'가 왜 중요한가?
- 3.Fallback이 무엇이고 좋은 예는?
- 4.Hystrix가 왜 deprecated 되었는가?
- 5.Circuit Breaker의 임계값 설정은 어떻게 해야 하는가?