[Indp] 이벤트와 비동기를 활용한 푸쉬 알림 구현하기

🚀 개요

Indp 프로젝트에서는 메일 푸쉬 알림이 존재한다. 사용자가 음악을 추천하거나 문의 사항을 등록할 경우 관리자의 이메일로 알림을 전송한다. 간단하게 구현한 알림 로직에는 여러 가지 문제를 내재하고 있다. 발생할 수 있는 문제점들을 정의하고 이를 점차 해결해 보자.

🚨 기존 코드

음악 추천 글이 등록되었을 때 실행되는 로직은 다음과 같다.

@Service
public class RecommendationService {

    @Transactional
    public long registerRecommendation(RegisterRecommendationRequest request) {
        Store store = getStore(request);
        
        Recommendation recommendation = new Recommendation(store, request.information(), request.phoneNumber());
        Recommendation persistRecommendation = recommendationRepository.save(recommendation);

        Mail mail = new Mail(to, "[버비] 인디피 서비스에 음악이 추천되었어요!",
            "추천 음악 정보: " + request.information() + "\n" +
            "추천인 연락처: " + request.phoneNumber() + "\n" +
            "매장 이름: " + request.storeName() + "\n" +
            "매장 주소: " + request.storeAddress() + "\n");
        springMailService.sendMail(mail);

        return persistRecommendation.getRecommendationId();
    }

@Service
public class SpringMailService {

    public void sendMail(Mail mail) {
        SimpleMailMessage message = new SimpleMailMessage();

        message.setTo(mail.to());
        message.setSubject(mail.subject());
        message.setText(mail.text());

        mailSender.send(message);
    }
}

이 로직은 문제가 없어 보이지만 많은 문제를 내재하고 있다. 

☠️ 문제점 정의

문제 1: 알림과 음악 추천이 하나의 트랜잭션에 존재

하나의 트랜잭션에서 음악 추천 정보가 저장되고 메일 알림이 전송된다. 이 경우 음악 추천 정보가 데이터베이스에 커밋되지 않았는데 메일 알림이 전송될 수 있고 메일 알림 실패로 인해 예외가 발생될 경우 추천 정보가 커밋되지 않고 롤백이 될 수 있다. 분리가 필요하다.

문제 2: 메일 전송 서비스가 트랜잭션 내부에 존재

제 3자 서비스인 메일 전송 서비스가 트랜잭션 내부에 존재하여 메일 서비스에 장애가 발생하면 한정적인 리소스인 커넥션이 계속 물려 있을 수 있고 시스템 전체의 장애로 이어질 수 있다. 예를 들어 커넥션이 20개인 경우 메일 서비스에 장애가 발생하여 20개의 커넥션이 모두 반환되지 않고 사용 중인 상태로 머물러 있다면 다른 요청들은 커넥션을 획득하지 못해 아무런 동작을 할 수 없게 된다.

문제 3: 동기적인 방식으로 인한 성능 문제

음악 추천과 푸쉬 알림은 동기적으로 처리할 필요가 없는 로직이다. 또한 메일 전송은 성능이 보장되지 않는다. 예를 들어 음악을 추천하는데 100ms, 메일 전송이 5000ms 가 소요된다면 사용자는 음악 추천 요청을 보낸 후 5100ms 후에 응답을 받을 수 있게 된다. 하지만 사용자는 음악을 추천하는 것이 목적이지 관리자에게 메일 알림을 전송하는 것이 목적이 아니다. 이 또한 분리할 필요가 있다.

문제 4: 메일 전송이 실패할 가능성 존재

메일 전송은 제 3자 서비스이고 언제든지 실패할 가능성이 존재한다. 하지만 메일 전송이 실패될 경우 예외가 발생하기만 할 뿐 아무런 동작이 수행되지 않는다. 메일 전송 실패의 경우를 대비한 메카니즘이 필요하다.

✅ 스프링 이벤트 적용

스프링 이벤트는 스프링 프레임 워크를 사용할 때 스프링 빈 간에 데이터를 주고받는 방식 중 하나로 이벤트를 발행하고 이벤트를 수신하여 소비하는 기능이다. 스프링에서 제공하는 리스너에는 EventListener 와 TransactionalEventListener 가 있으며 우리는 이 중 트랜잭션의 상태에 따라 이벤트를 처리해 주는 TransactionalEventListener 를 적용해 볼 것이다. (물론 해당 로직에 음악 추천을 저장하는 save 만 있기 때문에 @Transactional 애노테이션을 떼버리면 커밋 후에 실행되긴 한다. 하지만 영속성 로직이 추가될 가능성이 있기 때문에 이벤트 방식을 선택하였다.)

1. 발행할 이벤트인 MailSendEvent 를 생성한다.

public record SendMailEvent(
    Mail mail
) {
}

2. MailSendEvent 를 수신할 TransactionalEventListener 를 생성한다. 트랜잭션이 정상적으로 커밋이 된 후 실행되도록 phase 옵션을 AFTER_COMMIT 으로 설정한다.

@Service
public class SendMailListener {

    private final SpringMailService springMailService;

    @TransactionalEventListener(phase = AFTER_COMMIT)
    public void handleSendMailEvent(SendMailEvent event) {
        springMailService.sendMail(event.mail());
    }

}

3. 음악 추천 서비스에서 SendMailEvent 를 발행하도록 수정한다.

@Service
public class RecommendationService {
    ...
    private final ApplicationEventPublisher applicationEventPublisher;

    @Transactional
    public long registerRecommendation(RegisterRecommendationRequest request) {
        Store store = getStore(request);
        
        Recommendation recommendation = new Recommendation(store, request.information(), request.phoneNumber());
        Recommendation persistRecommendation = recommendationRepository.save(recommendation);

        Mail mail = new Mail(to, "[버비] 인디피 서비스에 음악이 추천되었어요!",
            "추천 음악 정보: " + request.information() + "\n" +
            "추천인 연락처: " + request.phoneNumber() + "\n" +
            "매장 이름: " + request.storeName() + "\n" +
            "매장 주소: " + request.storeAddress() + "\n");
        applicationEventPublisher.publishEvent(new SendMailEvent(mail));

        return persistRecommendation.getRecommendationId();
    }

이제 ApplicationEventPublisher 를 모킹하여 SendMailEvent 발행 여부를 테스트해 보자.

@Test
@DisplayName("성공: 추천 음악 정보를 저장한다.")
void registerRecommendation() {
    ...

    // then
    verify(applicationEventPublisher, times(1)).publishEvent(any(SendMailEvent.class));
}

테스트를 통과하였지만 확실하게 테스트하기 위해 음악 추천 트랜잭션이 커밋된 후에 이벤트를 소비한 건지 로깅을 통해 확인해 보자.

logging:
  level:
    org:
      springframework:
        orm: DEBUG

로그를 확인해 보면 음악 추천 트랜잭션이 커밋된 후 메일이 전송 로직이 샐 행 되는 것을 확인할 수 있다.

이로써 문제 1: 알림과 음악 추천이 하나의 트랜잭션에 존재는 해결되었다. 하지만 한 가지 궁금한 점이 있다. 

@TransactionalEventListener(phase = AFTER_COMMIT)

커밋된 후에 이벤트를 소비하는 건 알겠는데, 커넥션을 반환하고 소비하는 걸까?

ProxyConnection 의 close() 메서드에 디버그 포인트를 찍어 커넥션을 반환하는 시점을 확인해 보았더니 트랜잭션이 커밋되고 나서 메일이 전송된 직후까지 connection 이 물려있는 것을 확인할 수 있었다.

Spring 공식문서에는 다음과 같은 내용을 확인할 수 있다.

WARNING: if the TransactionPhase is set to AFTER_COMMIT (the default), AFTER_ROLLBACK, or AFTER_COMPLETION, the transaction will have been committed or rolled back already, but the transactional resources might still be active and accessible.

경고: 트랜잭션 단계가 AFTER_COMMIT(기본값), AFTER_ROLLBACK 또는 AFTER_COMPLETION으로 설정된 경우 트랜잭션이 이미 커밋되거나 롤백되었지만 트랜잭션 리소스는 여전히 활성화되어 있고 액세스 할 수 있습니다.

즉, AFTER_COMMIT 이더라도 커넥션이 물려있는 상태로 메일 전송 API 를 호출하는 것이다. 그렇다면 문제 2: 메일 전송 서비스가 트랜잭션 내부에 존재 가 아직 해결되지 않았다.

✅ 비동기 처리

이벤트를 소비하는 스레드를 이벤트를 발생하는 스레드와 비동기적으로 동작하게 하기 위해선 스프링에서 제공하는 @Async 를 사용할 수 있다.

1. AsyncConfig 를 설정한다.

@EnableAsync
@Configuration
public class AsyncConfig {

}

2. 비동기로 동작해야 하는 EventListener 에 @Async 를 적용한다.

@Async
@TransactionalEventListener(phase = AFTER_COMMIT)
public void handleSendMailEvent(SendMailEvent event) {
    springMailService.sendMail(event.mail());
}

현재 스레드의 id 를 로그를 찍어보면 다음과 같이 서로 다른 스레드에서 실행되는 것을 확인할 수 있다.

이제 문제 2: 메일 전송 서비스가 트랜잭션 내부에 존재뿐만 아니라 문제 3: 동기적인 방식으로 인한 성능 문제가 해결되었다.

남은 문제는 문제 4: 메일 전송이 실패할 가능성이 존재다. 메일 전송에 실패할 경우 지정된 횟수만큼 재시도를 하고 같은 문제가 계속 발생하면 ERROR 로그를 남기도록 수정했다.(ERROR 로그 발생 시 slack 으로 알림이 가도록 logback 을 설정한 상태)

private void send(SimpleMailMessage message) {
    for (int count = 0; count < MAX_RETRY_COUNT; count++) {
        try {
            mailSender.send(message);
            return;
        } catch (MailParseException | MailAuthenticationException exception) {
            log.error("메일 전송을 실패하였습니다.", exception);
            return;
        } catch (MailSendException exception) {
            log.warn("메일 전송을 실패하였습니다. 재시도합니다. 재시도 횟수: {}", count);
        }
    }
    log.error("메일 전송에 실패하였습니다. 재시도 횟수: {}", MAX_RETRY_COUNT);
}

⚒️ 추가 리팩토링

앞서 정의한 문제들은 해결했지만 추가적으로 리팩토링 하고 싶은 부분들이 있다.

1. 메일 전송 구현체(SpringMailService)가 변경될 경우 클라이언트 코드를 변경해야 한다.
2. 음악 추천과 푸쉬 알림은 다른 도메인임에도 불구하고 음악 추천 서비스에서 메일 내용을 생성하고 있다. 알림 포맷이 변경될 경우 알림 서비스가 아닌 음악 추천 서비스에서 변경해야 한다. 이건 음악 추천 시비스의 역할이 아닌 것 같다.
3. 음악 추천 서비스에서 알림메일전송이벤트를 발행하고 있다. 알림은 메일뿐만 아니라 FCM, 카카오톡, 문자 메시지 등으로 전송할 수 있다. 다른 알림 방식이 추가될 경우 음악 추천 서비스에 추가적으로 이벤트를 발행하는데 이 부분도 음악 추천 서비스의 역할이 아닌 것 같다.
4. 재시도 메카니즘으로 메일 전송의 정합성을 높였지만 만약 지정한 횟수만큼 재시도를 했음에도 전송이 실패할 경우 해당 알림 데이터가 소실되는 문제가 있다.

🔨 알림 서비스 추상화

MailService 를 인터페이스화 해서 클라이언트가 구현체가 아닌 추상체를 의존하도록 수정한다.

public interface MailService {
    void sendMail(Mail mail);
}

 SpringMailService 이 MailService 인터페이스를 구현하도록 한다.

@Service
@RequiredArgsConstructor
public class SpringMailService implements MailService {

    @Override
    public void sendMail(Mail mail) {
        ...
    }
}

이제 클라이언트인 SendMailListender 가 추상체인 MailService 에 의존하도록 수정해 보자.

@Service
@RequiredArgsConstructor
public class SendMailListener {

    private final MailService mailService;

    public void handleSendMailEvent(SendMailEvent event) {
        mailService.sendMail(event.mail());
    }
}

 

이제 메일 전송 구현체가 변경되어도 클라이언트가 추상화에 의존하기 때문에 클라이언트의 코드를 변경하지 않아도 된다.

🔨  책임 분리

NotificationService 를 생성하여 RecommendationService 에서 갖고 있던 메일 생성과 전송의 책임을 분리하자.

우선 알림의 종류에 따라 데이터가 전송해야 하는 데이터가 다르기 때문에 음악 추천 용 dto 와 이벤트를 생성한다.

public record RecommendationMail(
    String to,
    String information,
    String phoneNumber,
    String storeName,
    String storeAddress
) {
}

public record RecommendationMailEvent(
   RecommendationMail request
) {
}

NotificationService 에서 Mail 을 생성하고 전송하도록 수정한다.

@Service
public class NotificationService {
    ...
    public void sendRecommendationMail(RecommendationMail mail) {
        Mail mail = new Mail("[버비] 문의가 들어왔어요!",
            "문의 내용: " + mail.content() + "\n" +
                "문의자 성함: " + mail.userName() + "\n" +
                "문의자 연락처: " + mail.phoneNumber() + "\n", request.to());
        mailService.sendMail(mail)
    }
}

RecommendationMailListener 에서 NotificationService 를 호출하여 메일은 전송하도록 한다.

@Service
@RequiredArgsConstructor
public class RecommendationMailListener {

    private final NotificationService notificationService;

    @Async
    @TransactionalEventListener(phase = AFTER_COMMIT)
    public void handleRecommendationMailEvent(RecommendationMailEvent event) {
        notificationService.sendRecommendationMail(event.request());
    }

}

RecommendationService 에서는 음악 추천 알림 이벤트를 발행해주기만 하면 된다.

@Service
@Transactional(readOnly = true)
public class RecommendationService {
    ...
    @Transactional
    public long registerRecommendation(RegisterRecommendationRequest request) {
        Store store = getStore(request);

        Recommendation recommendation = new Recommendation(store, request.information(), request.phoneNumber());
        recommendationRepository.save(recommendation);

        RecommendationMail recommendationMail = RecommendationMail.of(to, request.information(), request.phoneNumber(), store.getName(), store.getAddress());
        applicationEventPublisher.publishEvent(new RecommendationMailEvent(recommendationMail));

        return persistRecommendation.getRecommendationId();
    }

이제 알림 생성 및 전송의 책임이 NotificationService 로 분리되었다. 알림 포맷이 변경되거나 알림 매체가 추가될 경우 음악 추천 서비스가 아닌 알림 서비스가 변경의 책임을 갖게 된다.

🔨  알림 데이터 저장

알림 데이터 소실을 대비하여 메일 알림 테이블에 데이터를 저장하자. 메일 알림일 경우 제목, 내용, 수신자 이메일 컬럼이 필요하다.

이제 알림 전송 메서드에 알림 데이터를 저장하는 로직을 추가하고 이벤트 비동기를 통해 메일을 전송하도록 수정한다.

@Service
@RequiredArgsConstructor
@Transactional(readOnly = true)
public class NotificationService {

    private final NotificationRepository notificationRepository;
    private final ApplicationEventPublisher applicationEventPublisher;

    @Transactional
    public void sendRecommendationMail(RecommendationMail request) {
        MailNotification mailNotification = new MailNotification("[버비] 인디피 서비스에 음악이 추천되었어요!",
            "추천 음악 정보: " + request.information() + "\n" +
                "추천인 연락처: " + request.phoneNumber() + "\n" +
                "매장 이름: " + request.storeName() + "\n" +
                "매장 주소: " + request.storeAddress() + "\n", request.to());
        MailNotification persistMailNotification = notificationRepository.save(mailNotification);

        Mail mail = Mail.from(persistMailNotification);
        applicationEventPublisher.publishEvent(new SendMailEvent(mail));
    }
}

메일 전송 이벤트를 발행할 때 mail_notification_id 를 추가하여 로깅할 때 추가해 주자.

public record Mail(
    long id,
    String to,
    String subject,
    String text
) {
}

private void send(long id, SimpleMailMessage message) {
    for (int count = 0; count < MAX_RETRY_COUNT; count++) {
        try {
            mailSender.send(message);
            return;
        } catch (MailParseException | MailAuthenticationException exception) {
            log.error("메일 전송을 실패하였습니다. mailNotificationId: {}", id, exception);
            return;
        } catch (MailSendException exception) {
            log.warn("메일 전송을 실패하였습니다. 재시도합니다. mailNotificationId: {} 재시도 횟수: {}", id, count, exception);
        }
    }
    log.error("메일 전송에 실패하였습니다. mailNotificationId: {} 재시도 횟수: {}", id, MAX_RETRY_COUNT);
}

이제 메일 전송 API 에 장애가 발생할 경우 ERROR log 를 통해 slack 으로 알림이 전송되고 개발자는 알림 id 를 통해 영속화된 알림 데이터를 통해 쉽게 대처할 수 있게 되었다.

👏 최종 설계

수정 사항을 정리해보면 다음과 같다.

1. 스프링 이벤트를 사용하여 서비스간의 강한 결합도 감소
2. 비동기 처리를 통한 사용자 경험 개선
3. 추상화와 책임 분리를 통한 확장성과 유지보수성 증가
4. 알림 데이터 영속화를 통한 알림 서비스 안정성 확보