스프링 이벤트 발행과 구독으로 트랜잭션 분리하기

서론

서비스를 만들다 보면 다양한 외부 모듈이나 시스템을 연동해야 하는 상황이 생기게 됩니다. 대표적으로 다음과 같은 상황을 들 수 있습니다.

회원가입 시 메일을 전송하는 예시

코드로는 다음과 같습니다.

@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
public class UserService {
 
    private final MessageService messageService;
    private final UserRepository userRepository;
 
 
    @Transactional
    public void signUp(String email) {
        // 유저 저장
        userRepository.save(new User(email));
        // 메세지 발송(알림, 메세지 등 외부 API 수행)
        messageService.send(email);
    }
}

@Service
@RequiredArgsConstructor
public class MessageService {
 
    /**
     * 메일 전송 로직
     * (실제로는 외부 모듈이 들어감)
     */
    @Async
    public void send(String email) {
        System.out.println(email + "에게 전송 완료");
    }
}

유저를 저장하고, 해당 유저의 이메일로 가입 축하 메일을 보내는 코드입니다. 

 

문제

먼저 흐름을 보면 "회원가입 요청 -> 데이터 베이스에 유저 저장 -> 가입 축하 메일 발송"입니다. 크게 문제가 없어 보이지만 다음과 같은 두 가지의 문제점이 발생할 수 있습니다.

1. 외부 리소스를 수행하는 로직까지 트랜잭션에 묶인다.
2. 문제로 인해 트랜잭션 롤백이 일어났을 때, 유저는 저장되지 않지만 메일은 전송된다.

문제를 하나씩 살펴보겠습니다.

1. 불필요한 로직까지 트랜잭션에 묶인다.

먼저 트랜잭션을 처리하기 위해서는 데이터베이스와 통신하기 위한 커넥션이 필요합니다. 하지만 커넥션 생성을 위해서는 꽤 많은 비용이 소모되는데, 이러한 비용을 절약하기 위해 WAS가 실행될 때 DB 연결을 위해 미리 일정 수의 커넥션 객체를 만들어 풀에 담아뒀다가 클라이언트의 요청이 발생하면 풀에서 생성되어 있는 커넥션 객체를 사용하는 방식을 이용합니다(커넥션 풀에 대한 더 자세한 내용은 이전 글에서 확인 가능합니다).

 

커넥션 풀의 개수는 제한되어 있기 때문에, 동시에 수많은 요청들이 커넥션 풀의 개수 이상으로 오게 된다면, 커넥션을 획득하지 못한 요청들은 다른 요청이 끝나 커넥션이 반납될 때까지 기다리게 되고, 이로 인해 병목현상 즉 지연이 일어나게 됩니다.

그렇다면 이제 이전 코드에서 문제가 되는 부분을 알 수 있습니다.

예시 코드의 트랜잭션 흐름

실질적으로 데이터베이스의 트랜잭션이 필요한 건 검은 화살표이지만, 외부 API인 파란 화살표까지 트랜잭션에 묶여서 데이터베이스 커넥션을 사용하지 않는 시간까지 불필요하게 낭비되고 있는 것을 확인할 수 있습니다.

따라서 외부 서비스의 호출이 실패하거나 지연될 경우 트랜잭션 자체가 실패하거나 지연되는 문제가 발생하게 됩니다.

2. 데이터의 일관성을 보장할 수 없다.

기존의 예시 코드에 로직이 추가된다고 생각해 봅시다.

    @Transactional
    public void signUp(String email) {
        // 유저 저장
        userRepository.save(new User(email));
        // 메세지 발송(알림, 메세지 등 외부 API 수행)
        messageService.send(email);
     	// 또 다른 어떤 서비스 로직을 수행
        xxxService.execute();
    }

위 코드에서 또 다른 어떤 서비스 로직을 수행하다가 에러가 발생하게 되면 트랜잭션 롤백이 일어나게 됩니다. 하지만 메시지 발송 같은 경우는 외부 모듈이기 때문에 트랜잭션 롤백과는 무관하게 이메일을 전송하게 됩니다. 따라서 결과적으로 회원가입이 실패했지만 가입축하 이메일이 전송되게 되는 문제가 발생합니다.

 

해결

해당 문제들은 스프링에서 지원하는 ApplicationEventPublisher를 사용해서 해결할 수 있습니다. 

ApplicationEventPublisher는 Spring Framework에서 이벤트를 발행하는 데 사용되는 인터페이스로 디자인 패턴 중 하나인 옵저버 패턴을 사용하여 구현되어 있습니다. ApplicationEventPublisher는 이벤트 발행자 역할을 하는데, 이벤트를 발행하면 이벤트 이벤트를 구독한 모든 리스너에게 해당 이벤트가 전달되고, 이벤트에 따른 적절한 동작을 실행합니다.

흐름을 살펴보면 "회원 가입 -> 회원 가입 완료 이벤트 발행 -> 회원 가입 이벤트 리스너 동작 -> 메일 서비스 수행"으로 이루어집니다.

코드를 한번 살펴보겠습니다.

UserService

@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
public class UserService {
 
    private final ApplicationEventPublisher applicationEventPublisher;
    private final UserRepository userRepository;
 
 
    @Transactional
    public void signUp(String email) {
        userRepository.save(new User(email));
 
        applicationEventPublisher.publishEvent(new MessageEvent(email));
    }
}

기존에 UserService에서 MessageService를 의존하고 있었던 코드를 ApplicationEventPublisher를 주입받도록 변경했습니다.

ApplicationEventPublisher의 구현체는 스프링이 해주며, 이벤트 발행자는 이벤트를 받아 처리하는 리스너가 누구인지, 어떻게 처리하는지 알 필요가 없습니다. 단지 지금처럼 이벤트를 발행하기만 하면 되며, 이벤트를 받아 처리하는 것은 리스너의 책임입니다.

MessageEvent

public class MessageEvent {
    private String email;
 
    public MessageEvent(String email) {
        this.email = email;
    }
}

Spring에서는 특정 타입의 이벤트를 전달하면, 그 타입을 파라미터로 받는 이벤트 리스너 메서드가 자동으로 호출됩니다. 즉, 이벤트의 타입이 리스너 메서드를 결정하는 역할을 합니다. 따라서 특정 타입의 이벤트 클래스를 정의하고, 그 클래스의 인스턴스를 이벤트로 전달하는 것이 필요합니다. 여기서는 MessageEvent가 특정 타입의 이벤트가 될 것입니다.

EventListener

@Component
@RequiredArgsConstructor
public class EventListener {
    private final MessageService messageService;
 
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT, fallbackExecution = true)
    public void handleAfterCommitEmailSending(MessageEvent messageEvent) {
        messageService.send(messageEvent.getEmail());
    }
}

이벤트를 받아 처리하는 리스너의 코드입니다. 발행된 이벤트는 ApplicationContext에서 @EventListener 어노테이션이 붙은 Listener handler를 찾아서 인자로 받아들여지고 특정 로직이 수행되게 됩니다.

여기서 @TransactionalEventListener는 Spring Framework에서 제공하는 어노테이션으로, 트랜잭션 경계에서 특정 이벤트를 처리하려는 메서드에 사용됩니다. 즉, 이 어노테이션은 트랜잭션의 생명 주기(ex: 트랜잭션이 커밋 또는 롤백된 후)에 따라 이벤트를 처리하는 데 사용됩니다.

@TransactionalEventListener의 대표적인 속성에는 다음의 네가지가 있습니다.

1. phase
2. classes
3. fallbackExecution
4. condition

phase는 트랜잭션의 어느 시점에 이벤트 핸들러가 호출되어야 하는지를 결정합니다. TransactionPhase 열거형 타입의 값으로 설정되며, 다음 값들을 가질 수 있습니다.

• AFTER_COMMIT : default 값으로써, 트랜잭션이 성공적으로 커밋된 후에 이벤트 핸들러를 실행합니다. 
• AFTER_ROLLBACK: 트랜잭션이 롤백된 후에 이벤트 핸들러를 실행합니다.
• AFTER_COMPLETION: 트랜잭션이 커밋되거나 롤백된 후에 이벤트 핸들러를 실행합니다.
• BEFORE_COMMIT: 트랜잭션이 커밋되기 전에 이벤트 핸들러를 실행합니다.

fallbackExecution는 트랜잭션 컨텍스트가 없을 때 이벤트 핸들러를 실행할지 말지를 결정합니다. default는 false로 트랜잭션이 존재하지 않는 곳에서 이벤트를 발행했을 경우 예외를 던지게 됩니다. true로 설정하면 트랜잭션이 존재하지 않는 경우에도 이벤트 핸들러가 실행되도록 할 수 있지만, 트랜잭션이 없을 경우에는 phase속성이 무시됩니다.

classes는 이벤트 핸들러가 처리할 이벤트의 타입들을 지정합니다. 이 속성을 명시적으로 설정하지 않으면, 이벤트 핸들러 메서드의 첫 번째 파라미터의 타입이 기본적으로 사용됩니다.

condition은 SpEL(Spring Expression Language) 표현식을 사용하여 이벤트 처리를 위한 조건을 제공할 수 있습니다. 이 속성을 이용하면 특정 조건을 만족하는 이벤트만을 처리하도록 할 수 있습니다.

@TransactionalEventListener 사용 시 주의점 이 포스팅도 도움이 되니 한번 읽어보면 좋을 것 같습니다.

 

결론

이벤트 프로그래밍의 주된 장점은 다양한 도메인 간 의존성을 분리하고, 느슨한 결합을 통해 모듈의 재사용성과 확장성을 향상시킬 수 있다는 점입니다. 예를 들어 A 서비스는 B서비스에 대해 전혀 알지 못해도 B서비스의 이벤트를 발행하거나 수신할 수 있습니다. 이렇게 하면 각 서비스는 독립적으로  운영되고 수정될 수 있으므로 서비스 간의 결합도가 낮아집니다. 

이벤트 프로그래밍의 단점은 이벤트를 정의하고, 이벤트 리스너를 생성하고, 이벤트를 발행하는 등의 추가적인 작업이 필요하다는 점입니다. 또한 이벤트를 사용하면 시스템의 전박적인 흐름을 파악하기 어렵게 되어 디버깅과 테스트가 복잡해질 수 있습니다. 이벤트 핸들러의 실행 순서는 보장되지 않기 때문에, 이벤트 순서에 의존하는 로직을 구현하는 것은 복잡하고 어려울 수 있습니다.

따라서 이벤트 프로그래밍은 비동기 처리를 필요로 하는 상황에서 유용합니다.(ex. 알림도 발송하고 메일도 발송하는 경우와 같은 경우) 또한 여러 서비스가 동일한 이벤트에 대해 다르게 반응해야 하는 경우에도 이벤트 프로그래밍이 유용합니다. 예를 들어 주문 이벤트가 발생했을 때 결제 서비스는 결제를 처리하고, 재고 서비스는 재고를 감소시키고, 배송 서비스는 배송을 준비해야 할 수 있습니다. 이런 경우에 각 서비스는 동일한 이벤트에 대해 자신만의 리스너를 구현할 수 있습니다.

 

참고

• https://tecoble.techcourse.co.kr/post/2022-09-20-external-in-transaction/
• https://tecoble.techcourse.co.kr/post/2020-09-30-event-publish/
• https://cheese10yun.github.io/event-transaction/