Resilience4j 적용과 모니터링까지

문제상황

사용자 경로 제공에 있어 Kakao, Naver, Tmap Open API를 사용하였고 Open API에 장애가 발생한 경우 처리에 있어 유연한 처리가 필요함을 느낌
장애가 발생하더라도 지속적으로 [OpenAPI 요청 -> 예외 발생] 이 반복되는 상황

• 다음과 같은 부분이 가장 개선하고 싶었다.
  • 지속적으로 네트워크를 활용해 요청하는 부분
  • 어차피 데이터를 못 받아오는데, 매번 요청하여 에러를 반환할 때까지 기다리는 부분
• 여러 OpenAPI에 의존하고 있는 이길저길 서비스에서 OpenAPI를 동적으로 호출하지 않도록 제한하면 비용을 많이 아낄 수 있을 것이라 기대했다.
• 이러한 자잘한 문제도 있었다.
  
  • DB를 같이 활용하는 API의 경우 OpenAPI 정보를 제외한 정보는 반환하고 싶은데, DB 정보까지 반환 못하는 부분
    (사실 이 부분은 모든 OpenAPI 로직에 try-catch 코드를 넣으면 해결은 가능하다.

접근

• Resilience4j를 통해 Open API에 장애가 발생한 경우 close - open - half open 단계에 걸쳐 유연한 처리
• 장애시 매번 OpenAPI를 호출하는 네트워크 비용을 절감할 수 있으며 동기처리로 인해 에러를 반환받기까지의 대기 시간 없이 다음 로직을 수행할 수 있다.

설명

• Close
  • Open API에 장애가 발생하지 않은 경우 → 기존과 동일하게 로직 수행
• Open
  • Open API에 장애가 발생 ( Open API의 실패율이 30%에 도달한 경우)
  • 이후 10초간 Open API 요청을 수행하지 않고 Default Failure 처리
    • 1분 간격으로 RateLimit이 초기화되는 OpenAPI가 있었다.
    • 테스트 시 10초 안에 1 ~ 2회의 실패는 다른 에러가 발생하는 경우가 있었지만, 3회부터는 거의 대부분 이 RateLimit 이슈로 발생한 에러였기에, 10초간 30%를 산정하였다.
• Half Open
  • Open API 처리가 정상화된 경우 → Close 상태 변경
  • 정상화되지 않은 경우 → Open 상태 변경

모니터링

• 서킷브레이커의 상태 확인이 필요해 모니터링 시스템을 도입했다.
  • 장애 상황을 빠르게 파악하고자 AlertManager로 슬랙 알림 발송하도록 구성했다.
  • Spring Actuator 중 Prometheus와 Resilience 4J 를 사용하여 모니터링을 수행했다.

 

• Grafana 대시보드로 확인한 메트릭과 사례
  
  • [부하테스트시] Request Latency 확인
    • 개선 작업시 API Latency를 확인하며 성능테스트를 수행하는 경우가 많았다.
  • [운영시] Request Status code, 서킷브레이커 Status별 개수 확인
    • 상태코드를 중점적으로 확인하며 에러 상태코드 발생 부분 확인
    • 시큐리티의 에러를 확인하여 ControllerAdvice로 에러 핸들링하도록 수정

분석

알림 시스템

• Slack 알림으로 Docker Container가 종료되어 알림이 발송되었다.

Resilience4j 모니터링

• 서킷브레이커 1개가 OpenAPI 장애로 Open 돼있고 3개가 Close 돼있는 것을 볼 수 있다.

 

SpringBoot 서버 모니터링 (JVM 관련 지표)

SpringBoot 서버 모니터링 (요청, 로그 관련 지표)