반복 및 복원
언제 어떻게 API 호출이 네트워크를 통해 장애가 발생할지 예측하기 어렵기 때문에 이를 모니터링할 수 있는 모니터링 기술이 매우 높이 평가됩니다.
분산 시스템에서 서버 간의 API 호출 실패 재시도는 매우 중요합니다.
단일 네트워크 호출 실패로 인해 서비스의 전체 비즈니스 로직이 실패하거나 대체되는 것은 여러 번 호출하는 것보다 리소스 낭비가 더 클 수 있기 때문입니다.
FallBack 처리???
어떤 기능이 약해지거나 제대로 동작하지 않을 때, 이에 대처하는 기능 또는 동작Fallback은 API를 호출할 때 발생하는 예외를 처리하기 위한 클래스를 정의한다고 말합니다.
이 방법은 오류 발생 시 사후 처리를 위해 설정됩니다.
또한 DNS 서버, 스위치 및 로드 밸런서와 같은 수많은 네트워크 구성 요소로 인해 요청의 모든 단계에서 오류가 발생할 수 있습니다.
네트워크 환경에서 클라이언트 애플리케이션 재시도 기술은 애플리케이션 안정성을 높일 뿐만 아니라 운영 비용도 줄여줍니다.
따라서 일반적으로 특정 API 호출 오류 상황에서는 최대 3번까지 호출을 반복하는 등의 방법을 많이 사용한다.
일반적인 예는 명확한 비즈니스 로직 오류 응답 대신 일시적인 네트워크 오류로 인해 읽기 시간 초과 오류 응답이 수신되거나 API 조절 문제로 인해 재시도가 필요한 경우입니다.
그러나 문제는 이러한 일상적인 재시도의 대부분이 무의미하거나 네트워크에 추가 부하를 추가한다는 것입니다.
대부분의 읽기 시간 초과 상황에서는 네트워크 문제가 일정 시간 동안 지속되는 경우가 많기 때문에 3번의 재시도 후에도 모두 실패할 가능성이 높습니다.
또한 재시도 자체가 일정한 간격으로 이루어지지 않으면 문제가 발생한 네트워크에 스트레스를 줄 확률이 높다.따라서 Retry 행위는 똑똑해야 하며, Spring에서 재시도 기능을 사용하기 위해서는 Resilience4j, Spring Retry 라이브러리를 보통 많이 사용한다.
Spring Retry는 오류를 재시도해야 할 때 유용할 수 있습니다.
재처리는 일반적으로 다음 사항을 고려합니다.
- 얼마나 많은 담당자를 수행해야 합니까?
- 다시 시도하기 전에 얼마나 기다려야 합니까?
- 모든 재시도가 실패하면 어떻게 해야 합니까?
Spring에서 제공하는 라이브러리를 사용하여 비즈니스 로직에 집중하는 이점은 코드가 깨끗하고 유지 관리하기 쉽다는 것입니다.
참조
https://wonyong-jang.github.io/spring/2021/02/18/Spring-Retry.html
https://velog.io/@sweet_sumin/Fallback