문제상황
사용자 경로 제공에 있어 Kakao, Naver, Tmap Open API를 사용하였고 Open API에 장애가 발생한 경우 처리에 있어 유연한 처리가 필요함을 느낌
접근
- Resilience4j를 통해 Open API에 장애가 발생한 경우 close - open - half open 단계에 걸쳐 유연한 처리
설명
- Close
- Open API에 장애가 발생하지 않은 경우 → 기존과 동일하게 로직 수행
- Open
- Open API에 장애가 발생 ( Open API의 실패율이 30%에 도달한 경우)
- 이후 10초간 Open API 요청을 수행하지 않고 Default Failure 처리
- Half Open
- Open API 처리가 정상화된 경우 → Close 상태 변경
- 정상화되지 않은 경우 → Open 상태 변경
모니터링
- 서킷브레이커의 상태 확인이 필요해 모니터링 시스템을 도입했다.
- 장애 상황을 빠르게 파악하고자 AlertManager로 슬랙 알림 발송하도록 구성했다.
- Spring Actuator 중 Prometheus와 Resilience 4J 를 사용하여 모니터링을 수행했다.
Grafana 대시보드로 확인한 메트릭과 사례
- [부하테스트시] Request Latency 확인
개선 작업시 API Latency를 확인하며 성능테스트를 수행하는 경우가 많았다. - [운영시] Request Status code, 서킷브레이커 Status별 개수 확인
상태코드를 중점적으로 확인하며 에러 상태코드 발생 부분 확인
시큐리티의 에러를 확인하여 ControllerAdvice로 에러 핸들링하도록 수정
분석
알림 시스템
- ex ) Slack 알림으로 Docker Container가 종료되어 알림이 발송되었다.
Resilience4j 모니터링
- 서킷브레이커 1개가 OpenAPI 장애로 Open 돼있고 3개가 Close 돼있는 것을 볼 수 있다.
SpringBoot 서버 모니터링 (JVM 관련 지표)
SpringBoot 서버 모니터링 (요청, 로그 관련 지표)
Young , Wild , Free