[Resilience4J] MSA 환경에서의 장애 방어 전략

1. CircuitBreaker가 필요한 이유

개발을 하다 보면 외부 API를 호출해야 하는 경우가 있다. 특히나 전체적인 시스템 구성이 MSA(Microservice Architecture)로 되어 있다면 다른 서비스를 호출하는 경우가 매우 빈번하다.

 

문제는 서버들에 장애가 발생할 수 있다는 점인데, 호출한 다른 서비스에 장애가 발생했다면 장애가 전파되어, 해당 서비스까지 문제가 발생할 수 있다. 또한 장애가 발생한 서버에 계속 요청을 보내는 것은 장애 복구를 힘들게 만든다.

 

 

 

예를 들어, 사용자의 대시보드에서 한 번의 요청으로 사용자의 여러 정보를 조회해 한 화면에 보여주어야 하는 상황을 생각해보자. 이 대시보드는 아래와 같이 각기 다른 서비스에서 데이터를 가져와야 한다.

1. 사용자 정보 서비스: 사용자 프로필 정보를 반환
2. 주문 내역 서비스: 사용자의 최근 주문 내역을 반환
3. 추천 서비스: 사용자의 관심사에 맞는 추천 상품 목록을 반환

 

만약 이 중 하나의 서비스, 예를 들어 추천 서비스에 장애가 발생했다면, 대시보드 서비스는 추천 데이터를 기다리면서 응답이 지연된다. 이는 대시보드 전체의 응답 속도를 늦추게 될 뿐만 아니라, 최악의 경우 장애가 난 서비스로 인해 전체 대시보드가 응답하지 않는 상황이 발생할 수도 있다.

 

 

 

이를 해결하기 위해서는 장애가 발생한 서비스를 탐지하고, 요청을 보내지 않도록 차단할 필요가 있다. 이때 사용되는 것이 서킷 브레이커이다.

 

 

 

 

 

 

 

 

 

 

 

2. CircuitBreaker란?

 

원래 서킷 브레이커는 해석 그대로 누전 차단기 라는 뜻을 지닌다. 누전 차단기는 전기 회로에서 과부하가 걸리거나 단락으로 인한 피해를 막기 위해 자동으로 회로를 정지시키는 장치이다.

 

서버에서 사용하는 서킷 브레이커도 외부 API 통신의 장애 전파를 막기 위해 장애를 탐지하면 외부와의 통신을 차단하는 역할을 한다.

 

서킷 브레이커가 실행(오픈)되면 fail-fast 함으로써 외부 서비스가 장애가 나더라도 빠르게 에러를 응답 받을 수 있는 장점이 있으며, 개발자가 지정한 행위를 리턴 받을 수도 있다. 

 

 

 

 

 

 

 

 

 

 

 

 

3. CircuitBreaker 동작 원리

 

서킷 브레이커의 3가지 상태

실제 회로를 기준으로 전구가 외부 API 또는 Callee에 해당하고, Power Source가 클라이언트(호출 서버) 또는 Caller에 해당한다. 그리고 회로 차단기에는 크게 CLOSED, OPEN, HALF_OPEN 3가지 상태가 존재하는데, 각각의 상태를 정리하면 다음과 같다.  

 

 

• CLOSED: circuit이 닫힌 상태로, 외부 호출이 정상상태이다.
• OPEN: circuit이 열린 상태로, 오류(실패호출/느린호출)가 발생했을 때 OPEN 상태로 전환된다.
• HALF_OPEN: OPEN 상태가 발생한 이후 일정 시간이 지난 상태이다. 이때 상태가 정상적이라면 CLOSED로, 아니라면 다시 OPEN으로 전환된다.

 

 

서킷 브레이커의 슬라이딩 윈도우

슬라이딩 윈도우는 시간 기반(Time-Based)과 개수 기반(Count-Based)의 2가지 타입을 갖는다.

• Time-Based: 특정 기간(Duration) 의 호출 결과를 저장하는 슬라이딩 윈도우를 제공
• Count-Based: 특정 개수(Count) 의 호출 결과를 저장하는 슬라이딩 윈도우를 제공

 

 

 

서킷 브레이커의 동작 프로세스는 아래와 같다.

 

1. 일반적으로 외부 서버는 정상적으로 실행 중이며, 서킷 브레이커는 닫혀 있어 모든 요청이 전달되고 응답을 받는다.

 

2. 외부 서버에 장애가 발생하여 요청이 실패하기 시작

 

3. 요청 실패가 기준치를 넘어가면 서킷 브레이커가 열리고 모든 요청이 즉시 실패한다.

 

4. 서킷 브레이커가 열린 상태에선 모든 요청이 외부 서버로 전달되지 않고 즉시 에러or응답을 반환한다.

 

5. 외부 서버가 정상적으로 복구된다.

 

6. 서킷 브레이커가 OPEN 상태로 전환된 후 설정한 시간이 지나면 HALF_OPEN 상태로 변경된다. 이 상태에서 일부 요청만 외부 서버로 전달하여 서버가 정상적으로 동작하는지 테스트한다. 

 

7. HALF_OPEN 상태에서 요청이 성공하면, 서킷 브레이커는 다시 닫혀 모든 요청이 정상적으로 전달된다. 만약 실패하면 다시 OPEN 상태로 전환된다. 

 

 

 

 

 

 

 

 

 

 

 

 

4. Resilience4J 도입

의존성 추가

// resilience4j
implementation 'org.springframework.cloud:spring-cloud-starter-circuitbreaker-resilience4j'

 

 

 

Resilience4J 설정

@Configuration
@RequiredArgsConstructor
@Slf4j
public class Resilience4jConfig {

    private final RetryRegistry retryRegistry;

    @Bean
    public CircuitBreaker circuitBreaker(CircuitBreakerRegistry circuitBreakerRegistry) {
        CircuitBreaker circuitBreaker = circuitBreakerRegistry.circuitBreaker(
                "customCircuitBreaker",
                CircuitBreakerConfig.custom()
                        .failureRateThreshold(50) // 실패율 기준
                        .slowCallRateThreshold(50) // 느린 호출 실패율
                        .slowCallDurationThreshold(Duration.ofSeconds(3)) // 느린 호출 판단 기준 시간
                        .permittedNumberOfCallsInHalfOpenState(3) // Half-Open 상태에서 허용되는 호출 횟수
                        .maxWaitDurationInHalfOpenState(Duration.ofSeconds(3)) // Half-Open 상태에서 최대 대기 시간
                        .slidingWindowType(COUNT_BASED) // 호출 횟수 기준으로 판단
                        .slidingWindowSize(10) // 최근 10번 호출 기준으로 실패율 계산
                        .minimumNumberOfCalls(5) // 최소 호출 횟수
                        .waitDurationInOpenState(Duration.ofSeconds(60)) // Open 상태에서 대기 시간
                        .build()
        );

        return circuitBreaker;
    }

    @Bean
    public Retry retry() {
        return retryRegistry.retry("customRetry",
                RetryConfig.custom()
                        .maxAttempts(3) // 최대 재시도 횟수
                        .waitDuration(Duration.ofMillis(500)) // 재시도 간 대기 시간
                        .build()
        );
    }
}

 

 

Config로 설정해도 되지만 yml 파일에서 설정해도 된다. 

resilience4j:
  circuitbreaker:
    instances:
      customCircuitBreaker: # Circuit Breaker 이름
        failureRateThreshold: 50 # 실패율 기준
        slowCallRateThreshold: 50 # 느린 호출 실패율
        slowCallDurationThreshold: 3s # 느린 호출 판단 기준 시간
        permittedNumberOfCallsInHalfOpenState: 3 # Half-Open 상태에서 허용되는 호출 횟수
        maxWaitDurationInHalfOpenState: 3s # Half-Open 상태에서 최대 대기 시간
        slidingWindowType: COUNT_BASED # 슬라이딩 윈도우 방식: 호출 횟수 기준
        slidingWindowSize: 10 # 최근 10번 호출 기준으로 실패율 계산
        minimumNumberOfCalls: 5 # 최소 호출 횟수
        waitDurationInOpenState: 60s # Open 상태에서 대기 시간

 

 

 

 

 

나는 Micro Service 중 하나인 member-service를 호출하는 Feign Client에 CircuitBreaker를 적용시켰다. 

@FeignClient(name = "member-server")
public interface MemberServerClient {

    @GetMapping("/member-server/api/v1/members/info")
    @CircuitBreaker(name = "customCircuitBreaker", fallbackMethod = "getMemberFallback")
    MemberInfoResponse getMemberInfo();

    // Fallback 메소드 추가
    default MemberInfoResponse getMemberFallback(Throwable throwable) {
        System.out.println("Fallback executed due to: " + throwable.getMessage());
        return new MemberInfoResponse();
    }
}

 

 

Fallback Method란 Circuit Breaker가 Open 상태일 때 호출되는 대체 메서드이다. 원래 호출하려는 메서드에서 예외가 발생하거나 외부 서비스가 응답하지 않을 때 Fallback 메서드를 호출하여 예외 상황을 처리하고, 예외 발생 시 어떤 값을 반환할 건지에 대해서도 설정할 수 있다.

 

 

 

 

CircuitBreaker Closed 상태

member-server에 예외가 발생하도록 설정하고 요청을 보내보면 아래와 같이 Fallback Method가 호출되는 것을 확인할 수 있다. 

 

 

또한 빈 Response 객체를 반환했기 때문에 응답값에도 null로 찍힌다. 

 

 

 

 

당연하게도 member-server의 로그를 확인해보면 에러가 찍힌다. 

 

 

 

 

 

CircuitBreaker Open 상태일 때 

나는 최소 호출 횟수를 5번으로 잡았기 때문에 5번 연속 보내보면  CircuitBreaker가 열린다.

 

CircuitBreaker가 요청을 차단하기 때문에 member server에선 더이상의 에러 로그는 찍히지 않는다.