Retry와 Recover

네트워크를 통한 API 호출은 언제 어떻게 실패할지 예측하기 어렵기 때문에 이를 감시할 수 있는 모니터링 기술이 매우 중요하게 평가받고 있다.

분산 시스템에서 서버와 서버간 API 호출 실패에 대한 재시도는 매우 중요한 행위이다. 1번의 네트워크 호출 실패로 서비스의 비즈니스 로직을 모두 실패 처리하거나 fallback 처리하는 것은 몇 번 다시 호출하는 것보다 큰 리소스 낭비가 될 수 있기 때문이다.

🤔 FallBack 처리???

어떤 기능이 약해지거나 제대로 동작하지 않을 때, 이에 대처하는 기능 또는 동작을 말한다. fallback은 API 호출 시 발생하는 예외 처리를 위한 클래스를 정의한다. 실패에 대해서 후처리를 위해 설정해두는 메서드이다.

또한, DNS 서버, 스위치, 로드 밸런스등 수 많은 네트워크 구성 요소들은 요청이 이루어지는 모든 단계에서 오류를 일으킬 수 있다. 네트워크 환경에서는 클라이언트 애플리케이션의 재시도 기술이 애플리케이션의 안정성을 높일 뿐만 아니라 운영 비용을 절감하는 효과도 있다.

따라서, 보통은 특정 API 호출 실패 상황에서는 최대 3번의 호출 재시도를 하는 등의 방법을 많이 사용한다.
대표적인 예로, 명확한 비즈니스 로직의 실패 응답을 받는 상황이 아닌 네트워크의 일시적 장애로 Read Timeout 실패 응답을 받는 경우나 API throttling 문제가 재시도를 해볼만한 상황이다.

하지만 문제는 이런 평범한 재시도 행위 자체가 대부분은 의미 없거나 네트워크에 부담을 더 가중하는 결과로 끝난다는 점에 있다.
대부분의 Read Timeout 상황은 특정 시간동안 네트워크 이슈가 지속되는 경우가 많기 때문에 3회 재시도를 하더라도 모두 실패로 끝날 가능성이 높다.
또한, 재시도 자체를 시간 간격을 두고 하지 않는 경우 문제가 발생한 네트워크에 부담을 줄 가능성이 크다.
따라서 Retry 행위는 똑똑해야 하며, Spring에서 재시도 기능을 사용하기 위해서는 Resilience4j, Spring Retry 라이브러리를 보통 많이 사용한다.

🥕 에러를 다시 처리해야할 경우 Spring Retry를 유용하게 사용할 수 있다.

재처리를 할 때 보통 아래를 고려하게 된다.

재시도를 몇 번 실행할 것인가?
재시도 하기 전에 지연시간을 얼마나 줄 것인가?
재시도를 모두 실패했을 경우 어떻게 처리할 것인가?

비즈니스 로직에 집중이 가능하도록 스프링에서 제공하는 라이브러리를 사용했을 때 코드가 간결하고 유지보수하기 쉽다는 장점이 있습니다.

Reference

https://wonyong-jang.github.io/spring/2021/02/18/Spring-Retry.html
https://velog.io/@sweet_sumin/Fallback

728x90

저작자표시 (새창열림)