[Spring] Spring Event로 트랜잭션, 의존성 분리하기

0. Application Events

스프링에서 지원하는 이벤트로, 내부에서 데이터를 전달하는 방법 중 하나이다.

 

Spring Event를 통해 이벤트 기반 아키텍처(Event-Driven Architecture)를 구현할 수 있다.

 

1. 사용 이유

한 예시를 알아보자.

@Service
public class UserService {

    private final UserRepository userRepository;
    private final EmailService emailService;

    @Transactional
    public void registerUser(User user) {

        userRepository.save(user); //사용자 저장

        emailService.sendEmail(user.getEmail());

    }
}

 

한 새로운 사용자가 가입하면, 사용자한테 가입 축하 메일을 전송하는 로직이 있다고 해보자.

 

 

의존성 분리

새로운 UserService와 EmailService는 서로 의존하고 있다.

 

위의 예시가 아니더라도, 다른 서비스와의 로직과 겹치게 되면 여러 컴포넌트와의 결합도가 강해진다.

 

이는 코드의 재사용성과 유지보수성을 떨어트린다.

 

해당 로직을 이벤트 발행 방식으로 변경한다면 의존성을 완전히 분리할 수 있다.

 

 

단일책임원칙(SRP; Single Responsibility Principle)

 

해당 클래스는 사용자 관련 조작에 대한 책임을 가지고 있다.

 

이메일 전송과 한 트랜잭션으로 묶여 같은 책임으로 동작하게 된다면 이는 단일책임원칙을 위배하게 된다.

 

 

 

트랜잭션 분리

 

이메일 전송 로직과 사용자 저장은 한 트랜잭션으로 묶이게 된다.

 

만약 이메일 전송에서 예외가 일어나면, 트랜잭션 전체가 실패하게 된다.

 

이메일 전송에 실패하더라도, 사용자 저장은 성공해야 한다.

 

 

2. 적용

이제 Spring Event를 이용해서 적용하여 Pub/Sub 구조로 만들어 보겠다.

 

 

 

Event

먼저 이벤트 전달용 클래스가 필요하다.

@Getter
@RequiredArgsConstructor
public class UserRegisteredEvent {
    private final String email;
    
}

 

필드값 내용이 바뀔 일은 없기 때문에, final로 지정하면 되겠다.

 

 

 

Publish

@RequiredArgsConstructor
@Service
public class UserService {

    private final UserRepository userRepository;
    
    private final ApplicationEventPublisher eventPublisher;

    public void registerUser(User user) {

        userRepository.save(User user); //사용자 저장

        // 이벤트 발행
        eventPublisher.publishEvent(new UserRegisteredEvent(user.getEmail()));
    }
}

 

ApplicationEventListner는 결국 ApplicationContext가 구현하지만, 인터페이스 분리 원칙(ISP)에 맞게

 

ApplicationEventPublisher  인터페이스를 주입받아 사용하면 된다.

 

 

 

Subscribe

@Service
public class EmailEventHandler {

    @EventListener
    public void handleUserRegisteredEvent(UserRegisteredEvent event) {
        //이벤트 발생 로직
    }
}

 

구독은 ApplicationListener 인터페이스를 구현하거나 @EventListener를 통해 받을 수 있다.

 

ApplicationListener를 상속받아 직접 구현하는 방법은 번거롭기 때문에 @EventListner로 구현하는 것이 훨씬 낫다.

 

 

속성

 

- 클래스 지정

@Service
public class EmailEventHandler {

    @EventListener(classes = UserRegisteredEvent.class) 
    public void handleUserRegisteredEvent(UserRegisteredEvent event) {
        //이벤트 발생 로직
    }
}

 

- 여러 클래스 지정

@EventListener(classes = {UserRegisteredEvent.class, UserDeletedEvent.class})
public void handleUserEvents(ApplicationEvent event) {
    if (event instanceof UserRegisteredEvent) {
    	// 사용자 가입 로직
    } else if (event instanceof UserDeletedEvent) {
        // 사용자 삭제 로직
    }
}

 

- 특정 조건 정의

@EventListener(condition = "#event.userEmail.endsWith('@gmail.com')")
public void handleGmailUserRegistration(UserRegisteredEvent event) {
        // Gmail 사용자 특별 처리 로직
}

 

 

- 식별자 정의

@EventListener(id = "premiumUserRegistrationListener", 
                   condition = "#event.userType == 'PREMIUM'")
public void handlePremiumUserRegistration(UserRegisteredEvent event) {    
	// 프리미엄 사용자 특별 처리 로직
}

 

직접 클래스를 지정하거나, 이벤트 처리 조건 (condition), 식별자(id)를 직접 지정할 수도 있다.

 

 

3. TransactionEventListener

 

스프링 4.2부터 이벤트 구독에 @TransactionalEventListener를 사용할 수 있다.

 

스프링 이벤트는 기본적으로 동기 방식으로 진행되기 때문에, 별도의 설정 없이는 이벤트 발행과 처리가 같은 트랜잭션에 묶이게 된다.

 

이런 기본 동작을 변경하고 트랜잭션 상태에 따라 이벤트 처리를 제어하기 위해 @TransactionalEventListener를 사용할 수 있다.

 

Phase

@Service
public class EmailEventHandler {

    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT) 
    public void handleUserRegisteredEvent(UserRegisteredEvent event) {
        //이벤트 발생 로직
    }
}

 

@TransactionalEventListener에는 Phase를 선택할 수 있는데, 속성은 다음과 같다.

 

• AFTER_COMMIT (default): 트랜잭션이 성공적으로 커밋된 후 실행
• AFTER_ROLLBACK: 트랜잭션이 롤백된 후 실행
• AFTER_COMPLETION: 트랜잭션이 완료(커밋 또는 롤백)된 후 실행
• BEFORE_COMMIT: 트랜잭션 커밋 직전에 실행

이를 통해 데이터 일관성을 유지할 수 있고, 유연한 이벤트 처리가 가능하다.

 

 

FallbackExecution

@Service
public class EmailEventHandler {

    @TransactionalEventListener(fallbackExecution = true) 
    public void handleUserRegisteredEvent(UserRegisteredEvent event) {
        // 트랜잭션 외부에서 실행될 수 있는 이벤트 발생 로직
    }
}

 

fallbackExecution 속성은 트랜잭션 외부에서도 해당 이벤트 로직이 실행될 수 있음을 뜻한다.

 

기본값은 false이며, false일 경우 트랜잭션 외부에서 이벤트가 발생되면 해당 Listener가 실행되지 않는다.

 

true로 설정하면 트랜잭션 외부(트랜잭션이 아니더라도)에서도 실행된다.

 

 

 

4. 비동기처리

 

이벤트 발생 쪽의 로직과 이벤트 실행 로직은 철저하게 분리되어야 한다.

 

성능 향상 / 로직 분리 등의 이유로 비동기 처리를 할 수 있다.

 

이는 트랜잭션이 철저하게 분리됨을 뜻한다.

 

@Configuration
@EnableAsync
public class AsyncConfig {
    @Bean
    public Executor taskExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(2); //스레드 풀 기본 스레드 수
        executor.setMaxPoolSize(5); // 스레드 풀 최대 스레드 수
        executor.setQueueCapacity(500); // 작업 대기열 크기
        executor.setThreadNamePrefix("AsyncThread-"); //스레드 접두사
        executor.initialize();
        return executor;
    }
}

 

애플리케이션에서 @EnableAsync 를 통해 비동기 작업을 실행할 수 있게 설정해야 한다.

 

@Service
public class EmailEventHandler {

    @Async
    @EventListener(classes = UserRegisteredEvent.class) 
    public void handleUserRegisteredEvent(UserRegisteredEvent event) {
        //이벤트 발생 로직
    }
}

 

비동기 처리는 단순하게 이벤트 리스너에 @Async 를 붙여주면 된다.

 

 

 

 

 

 

---

 

스프링 이벤트는 생각보다 유용한 기술이다.

평소 구현의 트랜잭션이 맞는 단위로 구성되어 있었는지, 컴포넌트들 간에 너무 강한 의존성을 가지고 있지 않았는지, 

단일 책임 원칙을 준수했는지 다시 생각해보게 됐다.