장애 처리와 MS 분산 추적

user service 에서 문제가 발생한것이 아니라 다른 ms를 호출하는 과정에서 다른 ms에서 문제가 발생하는 경우가 있다.

https://tonylim.tistory.com/380

MS간 통신

에 작성된 Feign Client의 에러 처리 법이 존재한다. orders를 에서 제대로된 데이터를 불러 오지 못하는 경우 user-service에서 처리할 수 있는 데이터들만 제대로 json에 담아서 돌려주며 200처리를 하게 된다.

이런 처리 말고 CircuitBreaker를 사용할 수 있다.

중간에 스위치 레이어가 존재하여 다른 ms를 호출할것인지 말것인지를 결정하게 된다.

@Configuration
public class Resilience4JConfig {

    @Bean
    public Customizer<Resilience4JCircuitBreakerFactory> globalCustomConfiguration() {

        CircuitBreakerConfig circuitBreakerConfig = CircuitBreakerConfig.custom()
                .failureRateThreshold(4)
                .waitDurationInOpenState(Duration.ofMillis(1000))
                .slidingWindowType(CircuitBreakerConfig.SlidingWindowType.COUNT_BASED)
                .slidingWindowSize(2)
                .build();

        TimeLimiterConfig timeLimiterConfig = TimeLimiterConfig.custom()
                .timeoutDuration(Duration.ofSeconds(4))
                .build();

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

Resilience4j dependency를 가져오후에 현재 ms에 어떤 서킷브레이커 설정을 가져갈지 bean을 만들어준다.

1초안에 답이 오지 않는다면 내가 구현한대로 임의의 값을 돌려줄것이다.

window에서 가장 최신 return들을 보관하고 이를 통해 failure rate를 계산하고 이를 통해 close 할지 open 할지 결정한다.

CircuitBreaker circuitbreaker = circuitBreakerFactory.create("circuitbreaker");
List<ResponseOrder> ordersList = circuitbreaker.run(() -> orderServiceClient.getOrders(userId), throwable -> new ArrayList<>());
userDto.setOrders(ordersList);

user service에서 서비스 레이어에서 현재 user의 order 정보를 보기위해 order service ms를 호출해보고 실패시 기본 ArrayList를 돌려주게 된다.

 

---

Zipkin , MS 분산 추적

분산환경에서의 시스템 병목 현상 파악을 위한 오픈소스이다.

span = 하나의 요청에 사용되는 작업의 단위 , unique id를 가지고 있다.

Trace = 트리구조로 이뤄진 span SET , 하나의 요청에 대한 같은 Trace ID 발급

Trace 는 하나의 Request 에 대응되는 값이고 , 그 Request안에 여러 ms 를 거치면서 response를 만든다면 거쳐가는 ms마다 span 아이디를 가지게 되는 것이다.

Spring Cloud Sleuth  = trace id , span id를 만들어서 zipkin 서버에게 전달해줘서 시각화를 가능하게 해준다.

 

spring:
  application:
    name: user-service
  zipkin:
    base-url: http://localhost:9411
    enabled: true
  sleuth:
    sampler:
      probability: 1.0

별도의 코드없이 설정만으로 zipkin에서 trace id를 기반으로 어떻게 ms간의 소통이 진행이 되었는지 확인이 가능하다.

보고 싶은 ms에 다 dependency와 application.yml을 수정해줘야한다.

의도적으로 order service에서 Exception을 던졌는데 잘 실패하고 error message인 장애발생과 500 status code를 확인할 수 있다.