티스토리 뷰
문제상황
사용자 경로 제공에 있어 Kakao, Naver, Tmap Open API를 사용하였고 Open API에 장애가 발생한 경우 처리에 있어 유연한 처리가 필요함을 느낌
장애가 발생하더라도 지속적으로 [OpenAPI 요청 -> 예외 발생] 이 반복되는 상황
- 다음과 같은 부분이 가장 개선하고 싶었다.
- 지속적으로 네트워크를 활용해 요청하는 부분
- 어차피 데이터를 못 받아오는데, 매번 요청하여 에러를 반환할 때까지 기다리는 부분
- 여러 OpenAPI에 의존하고 있는 이길저길 서비스에서 OpenAPI를 동적으로 호출하지 않도록 제한하면 비용을 많이 아낄 수 있을 것이라 기대했다.
- 이러한 자잘한 문제도 있었다.
- DB를 같이 활용하는 API의 경우 OpenAPI 정보를 제외한 정보는 반환하고 싶은데, DB 정보까지 반환 못하는 부분
(사실 이 부분은 모든 OpenAPI 로직에 try-catch 코드를 넣으면 해결은 가능하다.
- DB를 같이 활용하는 API의 경우 OpenAPI 정보를 제외한 정보는 반환하고 싶은데, DB 정보까지 반환 못하는 부분
접근
- 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로 에러 핸들링하도록 수정
- [부하테스트시] Request Latency 확인
분석
알림 시스템
- Slack 알림으로 Docker Container가 종료되어 알림이 발송되었다.
Resilience4j 모니터링
- 서킷브레이커 1개가 OpenAPI 장애로 Open 돼있고 3개가 Close 돼있는 것을 볼 수 있다.
SpringBoot 서버 모니터링 (JVM 관련 지표)
SpringBoot 서버 모니터링 (요청, 로그 관련 지표)
'프로젝트-탐구 > 이길저길' 카테고리의 다른 글
실시간 통신 기술 상호 비교 및 분석 with 성능테스트 (0) | 2024.06.23 |
---|---|
전략 패턴 기반 테스트 더블을 이용한 단위 테스트 (0) | 2024.03.25 |
Redis Cache 적용과 만료 전략 수립 (0) | 2024.03.25 |
RabbitMQ 비동기 처리와 데드레터 처리 적용기 (0) | 2024.03.25 |
FULL Text Index 적용기 (0) | 2024.03.25 |