@Async 이메일 전송 고도화: 재시도, 예외 처리, 테스트

인증 이메일 전송 시, 간혹 네트워크 오류로 인해 메일이 정상적으로 전송되지 않는 경우가 발생합니다.

이러한 상황에서 사용자에게 즉시 오류를 알리는 대신, 재시도 로직을 통해 이메일 전송 성공 가능성을 높이는 것이 사용자 경험을 향상하는 중요한 요소라고 판단했습니다.

 

그래서, 재시도 추가 시 고려한 것들을 다음과 같은 목차로 소개합니다.

• 재시도(@Retryable) 조건 설정
• 재시도 예외와 쓰레드 풀 예외를 구분해서 처리하기
• 재시도 및 복구가 잘 되었는지 테스트하기

* 비동기에서 재시도 로직 구현을 위해 Baeldung(async-retry)를 참고했습니다.

 

재시도(@Retryable) 조건 설정

먼저, 이메일 전송에 재시도 조건을 설정하기 위해 Spring Mail 관련 예외를 소개합니다.

• MailAuthenticationException : 인증 실패 시 발생하는 예외
• MailException : 메일 전송과 관련된 모든 예외의 기본 클래스로 구체적인 오류에 따라 세부 예외들이 이 클래스를 상속합니다.
• MailParseException : 잘못된 메시지 속성이 발견될 경우 발생하는 예외
• MailPreparationException : 사용자 코드에서 메일 준비 중 오류가 발생했을 때 던져지는 예외
• MailSendException : 메일 전송 오류 발생 시 던져지는 예외

만약 최상위 예외인 MailException을 재시도 조건으로 설정한다면, 인증 실패나 메시지 구문 오류가 발생해도 이를 인식하지 못하고 계속해서 재시도를 반복하게 됩니다. 그리고, MailSendException을 제외한 다른 예외들은 설정 오류나 메일 내용과 관련된 문제로, 재시도가 아닌 설정 수정이나 메일 내용을 고치는 것이 필요합니다.

 

따라서, 네트워크 오류로 인한 MailSendException 발생 시에만 재시도가 이루어지도록 제한을 두었고, 이 예외가 발생할 경우 1초의 딜레이 후 최대 3회 재시도하도록 설정했습니다. (기본 재시도 횟수는 3회입니다)

 

재시도 예외와 쓰레드 풀 예외를 구분해서 처리하기

운영 환경에서는 로그를 통해 문제를 빠르게 파악할 수 있어야 한다는 것이 중요하다고 생각합니다.

그래서, @Async와 @Retryable이 적용된 sendAsyncAuthenticationMail 메서드에서 두 가지 유형의 예외를 구분하여 처리했습니다. 

• 재시도가 모두 실패해서 발생한 예외
• 비동기 쓰레드에서 발생한 예외

1. 재시도가 모두 실패해서 발생한 예외 처리하기

javaMailSender.send() 메서드 호출 시 발생할 수 있는 MailSendException 외에도, 신원 인증 실패 시 MailAuthenticationException이 발생할 수 있습니다.

 

이때, 재시도 실패 시 복구하는 @Recover 메서드가 MailSendException만 처리하도록 설정되어 있다면, MailAuthenticationException이 발생할 경우, org.springframework.retry.ExhaustedRetryException: Cannot locate recovery method 에러가 발생하며 실제 원인인 MailAuthenticationException이 로그에 드러나지 않아 관련 에러를 해결하는데 시간이 더 오래 걸리는 경험을 했습니다.

 

따라서 최상위 예외인 MailException을 @Recover에 파라미터로 주입하여, 다형성을 이용해 모든 메일 관련 예외들을 처리하여 재시도가 실패한 원인을 로그 빠르게 남기어서 빠르게 대응할 수 있게 했습니다. 그렇지만, 재시도(@Retryable)는 MailSendException인 네트워크 오류가 발생했을 때만, 재시도를 하도록 했습니다.

 

2. 비동기 쓰레드에서 발생한 예외

제 @Async메서드(sendAsyncAuthenticationMail)는 반환 타입이 void이므로, 비동기 스레드에서 발생한 예외가 상위 스레드로 전파되지 않습니다.

비동기 메서드의 반환 타입을 CompletableFuture로 설정하면 상위 스레드로 예외를 전달할 수 있지만, 메일 전송 실패 예외가 중요하지 않아 void로 설정했습니다.

 

그렇지만, void 반환타입인 @Async에서 발생한 예외를 처리하지 않으면 예외가 전파되지 않기 때문에, 예외 발생 시 치명적입니다.

이를 방지하기 위해, 비동기 처리를 위한 스레드 풀 설정에서 AsyncUncaughtExceptionHandler를 오버라이드하여 비동기 스레드에서 발생한 예외를 로그로 출력하도록 설정했습니다.(해당 Config 코드)

 

재시도 및 복구가 잘 적용 됬는지 테스트하기

재시도 및 복구가 의도대로 작동하는지 테스트하여 확인했습니다. 주요 테스트 포인트는 다음과 같습니다.

• 재시도가 총 3회 시도되는지: 코드의 verify()와 times()로 검증
• 재시도 실패 후 @Recover로 정상 흐름으로 전환되는지: 코드의 assertThatCode()로 확인

추가로, 처음에는 재시도 횟수(3번) 확인 테스트와 @Recover로 예외가 복구되는지 확인하는 테스트를 각각 작성했는데, 중복된 로직이 많아 코드 가독성이 떨어졌고, 두 테스트가 하나의 메서드를 검증하는지 다른 사람에게는 명확하지 않을 수 있었습니다. 이에 따라 DynamicTest를 활용하여 시나리오 테스트로 작성하고 중복 로직을 개선하여 가독성을 높였습니다.

 

전체 테스트 코드입니다.

@DisplayName("이메일 전송 실패 시 재시도 및 복구 시나리오")
@TestFactory
Collection<DynamicTest> sendAsyncAuthenticationMail() {
    // given
    String email = "test@naver.com";
    String authenticationCode = "authCode";

    # MockBean을 사용해 메일 요청을 보냈다고 가정
    willThrow(MailSendException.class)   
            .given(javaMailSender)
            .send(any(SimpleMailMessage.class));

    // when then
    return List.of(
           dynamicTest(
                "재시도가 모두 실패해도 @Recover에 의해 예외는 발생하지 않는다", () ->
                    assertThatCode(() -> 
                        mailClient.sendAsyncAuthenticationMail(email, authenticationCode))
                            .doesNotThrowAnyException())
            ),
            dynamicTest("인증 이메일 보내기에 실패하면 총 3번의 시도를 한다", () -> {
                Thread.sleep(5000); # 메인 스레드가 재시도 하는 비동기 쓰레드보다 먼저 종료되지 않기 위함
                verify(javaMailSender, times(3)).send(any(SimpleMailMessage.class));
            })
    );
}

 

 

마무리하며

최근에 운영에서는 무엇이 중요할까? 에 대한 고민이 많아지면서 예외 처리와 로그 관리의 중요성을 실감하고 있습니다. 이와 관련된 요소까지 고려하며 개발하다 보니, 비동기 처리나 메일 관련 문서를 더 깊이 읽고 이해할 수 있게 되어 개발 이해도도 높아지는 장점을 느끼고 있습니다. 앞으로 장애 발생 시 신속하게 대응할 수 있는 운영 단계의 방법들에 대해 더 공부하려 합니다. 이와 관련해 추천할 만한 레퍼런스가 있다면 댓글로 알려주시면 감사하겠습니다. 읽어 주셔서 감사합니다!