[Spring] Spring Retry

Spring Retry

• Spring의 재시도 기능은 스프링 배치에 포함되어 있다가 2.2.0 버전부터 제외되어 현재는 Spring Retry 라이브러리에 포함되어 있다.
• Spring Retry는 동작이 실패하더라도 몇 번 더 시도하면 성공할 수 있는 작업을 자동으로 다시 시도할 수 있는 기능을 제공한다.
• Spring에서 재시도 기능을 사용하기 위해서는 Resilience4j, Spring Retry 라이브러리를 보통 많이 사용한다.
• Resilience4j는 재시도(Retry) 기능만 사용하는 경우는 거의 없고, 대부분 서킷 브레이커와 같이 사용하게 된다.
• 에러를 다시 처리해야할 경우 Spring에서 제공하는 Spring Retry를 유용하게 사용할 수 있다.
• 재시도 기능을 자바 코드로 구현하여 사용할 수 있지만, 비지니스 로직에 집중이 가능하도록 스프링에서 제공하는  Spring Retry 라이브러리를 사용했을 때 코드를 간결하고 유지보수하기 쉽다는 장점이 있다.

 

 

재처리를 할 때 고려해야할 점

 

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

 

Spring Retry 를 사용하는 방법

• Retry Template : 프로그래밍 방식 
• Retry Annotation : 선언적 방식 

 

1. RetryTemplate

gradle에 아래와 같이 의존성을 추가해주고 관련 retryTemplate 인터페이스를 사용한다.

 

implementation 'org.springframework.retry:spring-retry'

 

Spring Retry에는 작업에 대한 재시도를 자동화하기 위한 인터페이스인 RetryOperations가 있다.
아래는 RetryOperations인터페이스 코드이며, execute() 메소드가 존재하는데 매개변수인 RetryCallback은 실패 시 재시도해야 하는 비즈니스 로직 삽입을 허용하는 인터페이스 이다.

 

public interface RetryOperations {
	<T, E extends Throwable> T execute(RetryCallback<T, E> retryCallback) throws E;
    ...
}

 

아래는 RetryCallback 인터페이스이며, RetryCallback은 doWithRetry라는 메소드를 하나 가지고 있는 간단한 인터페이스이다.
doWithRetry 메소드에는 재시도를 할 비즈니스 로직이 들어간다.

public interface RetryCallback<T, E extends Throwable> {
	T doWithRetry(RetryContext context) throws E;
}

콜백이 실패하면 재시도 정책에 따라서 특정 횟수 혹은 특정 시간동안 재시도를 할 것이다.

 

RetryTemplate은 RetryOperations의 구현체이다.
@Configuration 클래스에서 RetryTemplate Bean을 구성해서 사용할것이다.

 

1-1) RetryTemplate 사용

implementation 'org.springframework.retry:spring-retry'

@Configuration
public class RetryTemplateConfig {

    @Bean
    public RetryTemplate retryTemplate() {
        FixedBackOffPolicy backOffPolicy = new FixedBackOffPolicy();
        backOffPolicy.setBackOffPeriod(1000L); //지정한 시간만큼 대기후 재시도 한다.
        // ExponentialBackOffPolicy backOffPolicy = new ExponentialBackOffPolicy();
        // backOffPolicy.setInitialInterval(100L); //millisecond
        // backOffPolicy.setMultiplier(2); //interval * N 만큼 대기후 재시도 한다.

        SimpleRetryPolicy retryPolicy = new SimpleRetryPolicy(); // 고정된 횟수만큼 재 시도 하는데 사용   
        retryPolicy.setMaxAttempts(2); //retry max count

        RetryTemplate retryTemplate = new RetryTemplate();
        retryTemplate.setBackOffPolicy(backOffPolicy);
        retryTemplate.setRetryPolicy(retryPolicy);
        return retryTemplate;
    }
}

@Service
public class SomeClass {
    
    @Autowired
    private RetryTemplate retryTemplate;   

    public String apply() {
        String result = retryTemplate.execute(context -> someFunction());
        return result;
    }
}

위와 같이 사용할 수 있으며, 재시도 정책 및 그외에 기능에 대해 알아보자.

 

1-1-1) Recovery Callback

 

재시도가 전부 실패하면, RetryOperations는 RecoveryCallback을 호출한다.
이 기능을 사용하려면 execute 메소드를 호출할 때 RecoveryCallback 객체를 전달해주어야 한다.

// 익명 클래스 
String result = retryTemplate.execute(new RetryCallback<String, Throwable>() {
            @Override
            public String doWithRetry(RetryContext context) throws Throwable {
                return "retry logic";
            }
        }, new RecoveryCallback<String>() {
            @Override
            public String recover(RetryContext context) throws Exception {
                return "recovery logic";
            }
        });

람다로 변경하면 아래와 같이 변경이 가능하다.

// 람다식 
String result = retryTemplate.execute(
                (RetryCallback<String, Throwable>) 
                        context -> "retry logic", 
                context -> "recovery logic");

모든 재시도가 실패하고 더 이상 재시도할 수 없는 경우, RecoveryCallback 메소드를 호출한다.
RecoveryCallback의 recover 메소드에서는 재시도가 전부 실패한 경우에 대한 대체 로직을 수행한다.

 

1-1-2) Backoff Policies

 

오류가 발생하여 재시도를 할 때 재시도를 하기전에 잠깐 기다리는 것이 유용할 때가 많다.
일반적으로 오류는 잠깐 동안 기다리기만 해도 해결되는 경우가 많다.

BackOffPolicy는 재시도 간의 일정 시간 간격을 두고 retry 제어하는데 사용된다.

public interface BackOffPolicy {

	BackOffContext start(RetryContext context);

	void backOff(BackOffContext backOffContext) throws BackOffInterruptedException;
}

BackoffPolicy 인터페이스의 backOff 메소드를 원하는 방식으로 구현하면 된다.
고정된 시간으로 backoff 시키고자 한다면 FixedBackOffPolicy를 사용하면 된다.
하지만, 위에서 언급한 것처럼 똑똑하게 재처리를 하지 않으면 오히려 네트워크 부하를 줄 가능성이 크다.

그래서 조금 더 좋은 방법으로 점진적으로 시간 간격이 늘어나는 ExponentialBackOffPolicy를 사용할 수 있다.
이는 지수에 비례하여 backOff 시간을 조절한다. 예를 들어 첫번째 재시도를 위한 대기 시간은 100ms 두번째 재시도를 위한 대기시간은 200ms, 세번째 재시도를 위한 대기 시간은 400ms 처럼 정해진 배수만큼 늘어나는 방식이다.
아래 코드로 확인해보자.

ExponentialBackOffPolicy backOffPolicy = new ExponentialBackOffPolicy();
backOffPolicy.setInitialInterval(100L); // millisecond
backOffPolicy.setMultiplier(2); //interval * N 만큼 대기후 재시도 한다.

그 외에도 Jitter라는 방식으로 backOff를 지정할 수 있으며, AWS에서도 Retry를 Exponential BackOff And Jitter 함께 사용한다고 한다.

1-1-3) Retry Policies

RetryTemplate에서 재시도 할지 여부는 RetryPolicy에 의해 결정된다.
RetryTemplate은 RetryPolicy의 open 메소드를 통해서 RetryContext 객체를 생성한다.
그리고 RetryCallback의 doWithRetry 메소드 인자로 생성된 RetryContext 객체를 전달한다.
RetryTemplate은 콜백이 실패한 경우 RetryPolicy에게 상태를 업데이트 하도록 요청한다.
그리고, RetryPolicy의 canRetry 메소드를 호출하여, 재시도가 가능한지 여부를 묻는다. 만약 재시도가 불가능한경우 RetryTemplate은 마지막 콜백 실행시 발생한 예외를 던진다.
단, RecoveryCallback이 있는 경우 RecoveryCallback 메소드를 호출한다.

// Set the max attempts including the initial attempt before retrying
// and retry on all exceptions (this is the default):
SimpleRetryPolicy policy = new SimpleRetryPolicy(5, Collections.singletonMap(Exception.class, true));

// Use the policy...
RetryTemplate template = new RetryTemplate();
template.setRetryPolicy(policy);
template.execute(new RetryCallback<Foo>() {
    public Foo doWithRetry(RetryContext context) {
        // business logic here
    }
});

위처럼, 모든 예외를 재시도 하는 것은 비효율적일 수 있다. 따라서 모든 예외에 대해 재시도 하지말고, 재시도 가능할 것 같은 예외에 대해서만 재시도 할 수 있다.

재시도 해도 또 다시 예외가 발생할 것이 확실한 경우에 재시도를 하는 것은 비효율적이기 때문이다.

ExceptionClassifierRetryPolicy라는 보다 유연한 RetryPolicy도 있다.
이는 예외 유형에 따라 다르게 재시도할 수 있도록 해준다. ExceptionClassifierRetryPolicy는 예외 유형에 따라 RetryPolicy를 결정한다.
즉, 콜백 메소드에서 발생하는 예외 유형에 따라 RetryPolicy를 다르게 하고 싶을 때 유용하다.

 

 

 

2. Retry Annotation

 

@EnableRetry 어노테이션을 추가해서 Spring Retry를 활성화할 수도 있다.

 

@EnableRetry
@Configuration
public class RetryTemplateConfig {
    //...
}

 

그 후 @Retryable 어노테이션을 사용하여 메소드에 재시도 기능을 추가하면 된다. 

 

@Service
@RequiredArgsConstructor
public class KakaoAddressSearchService {

    @Retryable(value = {RuntimeException.class})
    public KakaoApiResponseDto requestAddressSearch(String address) {
        // ...
    }

value을 통해 exception 설정이 가능하며 RuntimeException이 발생하면 재시도를 하게 된다.현재는 설정을 default로 주었기 때문에 재시도는 최대 3번, 재시도 딜레이는 1초이다.

maxAttempts(재시도 최대 횟수) 및 backoff (딜레이 초) 매개변수를 사용하여 재시도 동작을 커스텀마이징 할 수 있다.

 

@Service
@RequiredArgsConstructor
public class KakaoAddressSearchService {

    @Retryable(
            value = {RuntimeException.class},   // 여러 exception 선택 가능
            maxAttempts = 2,
            backoff = @Backoff(delay = 3000)
    )
    public KakaoApiResponseDto requestAddressSearch(String address) {
        // ...
    }

위의 코드는 최대 2회 재시도(첫번째 시도 포함)를 하고 재시도 전 3초 지연을 주었다.

 

 

재시도 처리가 모두 실패할시 어떻게 할지 정의하는 FallBack 기능을 사용할려면, @Recover 어노테이션을 사용하면 된다.

@Recover
public KakaoApiResponseDto recover(RuntimeException e, String address) {   
    log.error("All the retries failed. address: {}, error : {}", address, e.getMessage());    
    return null;    
}

즉, 최대 2번 재시도(첫번 째 시도 포함)를 하고, 모두 실패하게 된다면 recover 메서드가 실행된다.

 

여기서 주의할 점은 Recover 메서드의 반환 타입은 반드시 맞춰야 하는데, requestAddressSearch 메서드의 반환타입을 맞춰준다.

 

 

 

 

 

 

 

출처

[Spring] Spring Retry - SW Developer (wonyong-jang.github.io)