[스프링 msa] 서킷브레이커를 이용한 장애전파 차단

* 문제

• order-service를 끄고 user-service에 요청시 500 error가 발생

* 해결

• 서킷브레이커 도입

@Configuration
public class Resilience4JConfig {

    @Bean
    public Customizer<Resilience4JCircuitBreakerFactory> globalCustomConfiguration() {

        CircuitBreakerConfig circuitBreakerConfig = CircuitBreakerConfig.custom()
                .failureRateThreshold(4) // 4번 이상 실패하면
                .waitDurationInOpenState(Duration.ofMillis(1000)) // 1초 동안
                .slidingWindowType(CircuitBreakerConfig.SlidingWindowType.COUNT_BASED) // 개수 기반
                .slidingWindowSize(2) // 2개
                .build();

        TimeLimiterConfig timeLimiterConfig = TimeLimiterConfig.custom()
                .timeoutDuration(Duration.ofSeconds(4)) // 4초 이상 걸리면 타임아웃
                .build();

        return factory -> factory.configureDefault(id -> new Resilience4JConfigBuilder(id)
                .timeLimiterConfig(timeLimiterConfig)
                .circuitBreakerConfig(circuitBreakerConfig)
                .build());
    }
}

Circuit Breaker 패턴의 전체 설정을 실제 시나리오로 설명

CircuitBreakerConfig circuitBreakerConfig = CircuitBreakerConfig.custom()
    .failureRateThreshold(4)    // 4% 실패율 임계값
    .waitDurationInOpenState(Duration.ofMillis(1000))    // 1초 대기
    .slidingWindowType(CircuitBreakerConfig.SlidingWindowType.COUNT_BASED)    // 개수 기반
    .slidingWindowSize(2)    // 2개 요청 관찰
    .build();

주문 서비스에서 이 설정이 어떻게 동작하는지 시나리오를 통해 살펴보겠습니다:

시나리오 1: 정상 상황

1. 첫 번째 요청: 주문 성공 (200ms 소요)
2. 두 번째 요청: 주문 성공 (300ms 소요)
   - 관찰된 요청 2개 중 실패 0개
   - 실패율 0% < 임계값 4%
   - 서킷 상태: CLOSED (정상 작동)

시나리오 2: 부분 실패

1. 첫 번째 요청: 주문 실패 (네트워크 오류)
2. 두 번째 요청: 주문 성공 (200ms 소요)
   - 관찰된 요청 2개 중 실패 1개
   - 실패율 50% > 임계값 4%
   - 서킷 상태: OPEN (차단 시작)
   - 1초 동안 모든 요청 차단

시나리오 3: 타임아웃

1. 첫 번째 요청: 주문 지연 (5초 소요)
   - 4초 타임아웃 설정으로 인해 실패로 처리
2. 두 번째 요청: 주문 지연 (5초 소요)
   - 역시 타임아웃으로 실패 처리
   - 관찰된 요청 2개 중 실패 2개
   - 실패율 100% > 임계값 4%
   - 서킷 상태: OPEN (차단 시작)

시나리오 4: 복구 과정

1. 서킷 OPEN 상태에서 1초 대기
2. HALF-OPEN 상태로 전환
3. 새로운 요청 시도:
   - 성공하면 → CLOSED 상태로 전환 (정상 운영 재개)
   - 실패하면 → 다시 OPEN 상태로 전환 (1초 대기)

이러한 동작을 통해:

1. 일시적인 장애는 허용하면서도
2. 지속적인 문제가 있을 경우 빠르게 차단하고
3. 시스템이 자동으로 복구를 시도할 수 있습니다.

특히 마이크로서비스 환경에서 이러한 설정은:

• 장애의 연쇄 전파를 방지하고
• 시스템 전체의 안정성을 향상시키며
• 빠른 장애 감지와 복구를 가능하게 합니다.

예를 들어, 결제 서비스에 장애가 발생했을 때:

1. 빠르게 서킷을 열어 추가 요청을 차단하고
2. 대체 결제 수단으로 전환하거나
3. 사용자에게 적절한 오류 메시지를 제공할 수 있습니다.

이렇게 함으로써 전체 시스템의 안정성과 사용자 경험을 모두 개선할 수 있습니다.

 

================================================================

• 서버에는 에러로그가 남지만 응답은 정상적으로 된다.

  

order-service 작동전

order-service 작동후

잠시 kafka 구현은 지워둠