[MSA] Resilience4j 의존성 설정 및 주의할 점들 (부제: io.github에서 제공하는 의존성 사용)

<이전 글>

[TIL] 서킷 브레이커의 상태 변화(Closed -> Open -> Half-Open)와 주의할 점

 

이전 글에서는 서킷 브레이커의 개념과 상태 변화, fallback 매커니즘 등에 대해서 학습했다. 오늘은 Spring Boot에서의 Resilience4j 설정과 주의할 점에 대해 짚고 넘어가보겠다.

▪️ Resilience4j란?
서킷 브레이커 라이브러리로, 서비스 간의 호출 실패를 감지하고 시스템의 안정성을 유지한다. 다양한 서킷 브레이커 기능을 제공하며 장애 격리 및 빠른 실패를 통해 복원력을 높일 수 있다.

 

1. Resilience4j 설정

1-1. 기본 의존성 설정

Resilience4j를 사용하려면 Spring Boot 애플리케이션에 의존성을 추가해야 한다. 이를 위해 Resilience4j 의존성 설정을 구글링해보면, 많은 블로그 글에서 spring-cloud-starter에서 제공하는 의존성을 추가하는 걸 볼 수 있었다.

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

👉 결론부터 말하면 spring-cloud-starter에서 제공하는 의존성을 추가하는 것을 권장하지 않는다.

 

spring-cloud-starter 의존성은 실제로 구현이 안 되어 있는 추상화 계층이기 때문에, 이 의존성을 사용 시 구현체만 들어와서 개발자가 원하는 모든 Resilience4j의 동작을 구현하기에는 무리가 있다.

공식 문서에 명시되어 있는 의존성

공식 문서에도 명시되어 있는 io.github 의존성을 사용해 주자.

 

필자의 환경은 Spring Boot 버전 3를 사용하기 때문에 의존성에서도 boot3를 사용하지만, Spring Boot 버전 2를 사용하는 분들은 숫자만 2로 바꿔서 의존성 추가해주면 된다.

 

[build.gradle 파일 예시]

dependencies {
    implementation 'io.github.resilience4j:resilience4j-spring-boot3:2.2.0'
    implementation 'org.springframework.boot:spring-boot-starter-aop'
}

 

주의점 하나 더 ! aop 의존성 또한 추가해주지 않으면 Resilience4j 동작 안 되는 것 주의 ..ㅎㅎ aop 의존성 추가도 잊지 말기!

▪️정리
1) io.github에서 제공하는 의존성 추가해주자.
2) 의존성 추가할 때 Spring Boot 버전 잘 확인해주자.
3) aop 의존성까지 같이 세트로 추가해주자. (안그러면 동작 안됨)

 

 

1-2. Resilience4j 설정 파일

Resilience4j의 설정은 application.yml 파일 또는 application.properties 파일에서 설정할 수 있다. 필자는 application.yml 파일로 설정 예정!

 

[예시 설정 파일]

resilience4j:
  circuitbreaker:
    configs:
      default:  # 기본 구성 이름
        registerHealthIndicator: true  # 애플리케이션의 헬스 체크에 서킷 브레이커 상태를 추가하여 모니터링 가능
        # 서킷 브레이커가 동작할 때 사용할 슬라이딩 윈도우의 타입을 설정
        # COUNT_BASED: 마지막 N번의 호출 결과를 기반으로 상태를 결정
        # TIME_BASED: 마지막 N초 동안의 호출 결과를 기반으로 상태를 결정
        slidingWindowType: COUNT_BASED  # 슬라이딩 윈도우의 타입을 호출 수 기반(COUNT_BASED)으로 설정
        # 슬라이딩 윈도우의 크기를 설정
        # COUNT_BASED일 경우: 최근 N번의 호출을 저장
        # TIME_BASED일 경우: 최근 N초 동안의 호출을 저장
        slidingWindowSize: 5  # 슬라이딩 윈도우의 크기를 5번의 호출로 설정
        minimumNumberOfCalls: 5  # 서킷 브레이커가 동작하기 위해 필요한 최소한의 호출 수를 5로 설정
        slowCallRateThreshold: 100  # 느린 호출의 비율이 이 임계값(100%)을 초과하면 서킷 브레이커가 동작
        slowCallDurationThreshold: 60000  # 느린 호출의 기준 시간(밀리초)으로, 60초 이상 걸리면 느린 호출로 간주
        failureRateThreshold: 50  # 실패율이 이 임계값(50%)을 초과하면 서킷 브레이커가 동작
        permittedNumberOfCallsInHalfOpenState: 3  # 서킷 브레이커가 Half-open 상태에서 허용하는 최대 호출 수를 3으로 설정
        # 서킷 브레이커가 Open 상태에서 Half-open 상태로 전환되기 전에 기다리는 시간
        waitDurationInOpenState: 20s  # Open 상태에서 Half-open 상태로 전환되기 전에 대기하는 시간을 20초로 설정

 

위와 같은 내용들을 다 기억할 필요는 없고, 읽어보고 원하는 기능이 있다면 선택해서 사용해주면 되겠다. (즉, 상단의 값 중에서 반드시 필요한 값들도 있지만 필요하지 않은 값들도 있다는 말) 만약 옵션 중 작성하지 않은 값이 있다면 그 값은 default 값으로 설정되어 들어간다는 것도 알고 있자 😀

 

👉 (필자는 모든 설정들을 미리 진행하고 넘어가기보단, 최소의 설정을 해서 default 값으로 구성하고, 추후 개발을 더 진행하면서 로직의 성격에 따라 서킷 브레이커 설정을 따로 해주는 것을 추천한다)

👉 (모든 서킷 브레이커가 빠르게 동작하도록 설정하면 가장 좋겠지만, 굳이 그럴 필요가 없는 로직에서 서킷 브레이커 설정을 타이트하게 설정해두면 자원이 많이 드는 문제 등이 발생할 수도 있기 때문)  

▪️정리
먼저 default 설정으로 진행을 해보고, 그 다음에 필요한 설정이 있다면 그때그때 그 설정값을 반영해서 확인해보기 !!

 

 

2. [참고] Resilience4j Dashboard 설정

Resilience4j Dashboard를 사용하여 서킷 브레이커의 상태를 모니터링할 수 있다!

 

[build.gradle 파일 예시]

dependencies {
    implementation 'io.github.resilience4j:resilience4j-micrometer'
    implementation 'io.micrometer:micrometer-registry-prometheus'
    implementation 'org.springframework.boot:spring-boot-starter-actuator'
}

 

[application.yml 설정 파일 예시]

management:
  endpoints:
    web:
      exposure:
        include: prometheus
  prometheus:
    metrics:
      export:
        enabled: true

 

의존성과 설정은 위의 예시와 같이 설정해주면 된다. 

 

http://${hostname}:${port}/actuator/prometheus 에 접속하면 서킷브레이커 항목을 확인할 수 있다. (프로메테우스에서 acuator 항목을 보고 수집해 가는 것)

또한 Prometheus와 Grafana를 통해 Resilience4j 서킷 브레이커의 상태를 실시간으로 모니터링 할 수도 있다. Prometheus를 통해 수집된 메트릭을 Grafana 대시보드에서 시각화하여 보는 것도 가능하다.

 

📌3. 마치며

오늘 학습해 본 내용을 정리해보면?

• io.github에서 제공하는 의존성 추가해주자.
• 의존성 추가할 때 Spring Boot 버전 잘 확인해주자.
• aop 의존성까지 같이 세트로 추가해주자. (안그러면 동작 안됨)
• yml 설정 파일에서는 먼저 default 설정으로 진행을 해보고, 그 다음에 필요한 설정이 있다면 그때그때 그 설정값을 반영하면서 진행해보자.
• 프로메테우스나 그라파나를 통해 서킷 브레이커의 상태를 실시간 모니터링 할 수도 있고, 애플리케이션 메모리나 CPU 사용 등의 항목 또한 볼 수 있다.