🥅

스프링 이벤트와 동작원리

생성일

2023/04/30

태그

Spring

Event

Transaction

Refactoring

배경

현재 저희 서비스에서 투표/약속잡기 등을 생성하면 슬랙으로 알림을 보내주는 로직이 있습니다. 이러한 알림 로직을 위해 투표/약속잡기 서비스 계층에서는 알림 서비스 계층을 의존하고, 생성 시 알림을 보내는 로직까지 포함되어 있습니다. 즉 투표/약속잡기 생성, 슬랙 알림이 하나의 비즈니스 로직 내에 있는 것이죠. 이는 바꿔말하면 의존도가 높다고 할 수 있습니다. 현재의 로직에서 발생할 수 있는 문제점과 해결 방법으로 사용한 스프링 이벤트 방식의 동작 원리를 알아보겠습니다.

문제점

현재 투표의 생성 로직을 단순화하면 다음과 같습니다.

@Transactional
public PollResponse createPoll(String teamCode, Long memberId, PollCreateRequest request) {
        Poll poll = request.toPoll(teamCode, memberId, systemTime.now());
        Poll savedPoll = pollRepository.save(poll);
				notificationService.notifyPollOpen(teamCode);
        return PollResponse.from(memberId, savedPoll);
    }
Java
복사

투표 생성 save(poll)과 알림notifyPollOpen(teamCode)이 하나의 로직으로 묶여있는데요, 이렇게 다른 컨텍스트가 서로 의존되어 있는 상황을 강하게 결합되어 있다고 할 수 있고 결합도가 높은 위의 로직은 크게 세 가지의 문제점을 가집니다.

유지, 보수에 어려움

알림 서비스의 네이밍이나 시그니쳐가 바뀌면 투표 서비스, 약속잡기 서비스 등에서 함께 변경이 발생하게 됩니다. 투표 서비스 입장에서는 투표 생성이라는 주 관심사가 아닌 알림 서비스 호출 로직이 존재하기때문에 가독성 측면에서도 불편함이 있습니다.

얽혀있는 트랜잭션

알림 서비스에서 예외가 발생하게 되었을 때, 알림 서비스의 트랜잭션이 REQUIRED 라면 잘 생성된 투표에 대해서도 롤백이 되는 상황이 발생합니다.

이를 피하기 위해 알림 로직에서 REQUIRES_NEW 로 설정하여 알림 서비스에서 예외 전파가 되지 않도록 로직을 구성하는 방법이 있긴 하지만, REQUIRES_NEW 는 커넥션을 새로 가져와 트랜잭션을 새로 생성해야 하기때문에, 요청 처리 시간이 길어질 수밖에 없습니다.

만약 알림에서 실패할 시에 투표 생성도 실패해야 한다는 비즈니스 정책이 있다면 두 로직은 동일한 트랜잭션을 타야하지만, 저희는 투표 생성과 알림은 개념상 다른 기능이라고 판단하여 두 기능 사이 트랜잭션이 얽혀있지 않고 독립된 두 개의 트랜잭션이 구성되어야 한다고 판단하였습니다.

불필요한 대기

예외가 발생하지 않는다고 하더라도, 스프링에서 요청은 기본적으로 단일 쓰레드에서 동작하게 되고 하나의 쓰레드 내부의 코드는 동기적으로 처리됩니다. 현재 코드는 투표 생성 로직과 알림 로직이 모두 완료가 되어야 응답합니다. 이 때 알림 로직이 무거워 오래 걸린다면, 투표 생성과 별개인 로직으로 인해 핵심 로직에 대한 응답이 대기하게 되는 상황이 발생합니다.

생각해본 대안

스프링 배치

•

장점 

앞서 언급한 문제점들을 모두 해결할 수 있습니다. 알림에 대한 모든 로직은 배치 로직으로 돌아가기때문에, 투표 생성 로직에서 알림에 대한 물리적, 논리적 의존성을 모두 떼어낼 수 있습니다. 이에 따라 투표 생성 로직에서는 핵심 로직만 처리하여 불필요한 대기를 줄일 수 있으며 두 로직은 완전히 독립된 트랜잭션에서 동작하게 됩니다. 이러한 장점과 더불어 배치만의 장점이 있는데요, 완전히 독립된 로직으로 구성되어 있기때문에 알림에서 발생하는 예외에 대해 안정적으로 처리할 수 있고, 실패한 알림에 대해 추후 재처리가 가능하다는 점입니다.

•

단점

아무래도 대규모 처리를 위한 작업이다보니, 스케줄이 자주 돌지 않아 실시간성이 부족합니다. 또한 배치 작업을 위해 컬럼, 테이블 등 부가적인 데이터 정보를 DB 에 저장해야 합니다.

쓰레드 생성

•

장점

쓰레드를 생성하여 다른 자원의 추가 없이 쉽게 적용이 가능합니다.

private void notifyPollOpen(String teamCode) {
        Thread thread = new Thread(() -> notificationService.notifyTeamPollOpen(teamCode));
        thread.start();
    }
Java
복사

또한 비동기적으로 처리가 가능하여 메인 로직인 투표 생성 로직은 불필요한 대기를 줄일 수 있으며, 메인 로직과 다른 쓰레드이기때문에 독립된 트랜잭션으로 로직이 진행됩니다.

•

단점

알림 로직을 직접 쓰레드로 생성하여 진행하다보니, 생성한 쓰레드 내부에서 결국 알림 도메인에 대한 의존성이 생길 수밖에 없습니다. 또한 알림 로직에서 발생하는 예외에 대해 처리가 힘들다는 단점이 있습니다. 서비스 계층 내부에서 새로 생성한 쓰레드이기때문에 디스패처 서블릿을 타지 않아 컨트롤러 어드바이스와 같은 spring 이 제공해주는 예외 처리 기능을 이용할 수 없습니다. 만약 커밋 시점에서 투표 생성 로직이 롤백된다면, 알림 로직도 실행되지 않아야 하는데 이러한 부분에 대해 관리하기가 어렵습니다.

스프링 이벤트 방식

이벤트는 프로그램에 의해 감지되고 처리될 수 있는 동작이나 사건을 말하는데, 일반적으로 이벤트 기반 시스템은 프로그램에서 처리해야 할 외부 활동이 있을 때 사용합니다. 여기서 프로그램에 의해 감지되는 사건은 “투표 생성” 이고, 처리해야 할 외부 활동은 “알림 서비스” 로 볼 수 있습니다. 스프링에서는 스프링 이벤트를 지원하고 있습니다.

•

장점

외부 리소스없이 간편하게 이벤트 방식을 구현할 수 있습니다. 또한 동기/비동기 모두 지원 가능하고 트랜잭션 커밋 성공 여부에 따라 알림 로직 실행 여부를 따질 수 있습니다. 즉 쓰레드를 직접 생성하는 것보다 더 섬세하게 로직을 다룰 수 있습니다.

•

단점

쓰레드 생성과 마찬가지로 예외 발생에 대한 재처리가 힘듭니다. 또한 AOP 등 복잡한 내부 동작 구조를 파악해야 할 필요가 있습니다.

저희는 위의 세 가지 중 스프링 이벤트를 적용하기로 했습니다. 이유는 다음과 같습니다.

스프링 이벤트 선택 이유

실시간성이 보장되어야 한다.

저희 서비스의 비즈니스 정책 상 투표가 생성되면 동시에 슬랙 알림을 보내야 합니다. 이에 따라 배치 방식은 실시간성이 부족하다고 판단하여 배제하였습니다.

원자성이 보장되어야 한다.

투표 생성이 성공하면 슬랙 알림이 보내져야 하고, 투표 생성에 실패하면 슬랙 알림 로직이 호출되지 않아야 합니다. 하지만 쓰레드 생성 방식은 투표 생성 커밋 시점 이전에 슬랙 알림 로직을 실행시키기때문에 원자성이 지켜지지 않을 우려가 있을 것이라고 판단하였습니다.

관심사가 분리되어야 한다.

이벤트 방식을 사용하면 알림 도메인에 대한 물리적 의존성이 분리가 될 수 있습니다. 비록 스프링 이벤트 라는 라이브러리에 의존성이 생기긴 하지만 알림 도메인에 대해 의존성을 분리하면서 가져올 수 있는 유지/보수의 효율이 더 좋을 것이라고 생각하였습니다.

이제 스프링 이벤트의 사용법과 함께, 스프링 이벤트를 적용하는 과정에서 만났던 선택지들과 선택 이유에 대해 알아보겠습니다.

발행

발행은 프로그램에 의해 감지되는 사건이 발생했다는 것을 알려줍니다. 발행할 때 이용하는 클래스로는 대표적으로 ApplicationEventPublisher와 AbstractAggregateRoot 가 있습니다.

ApplicationEventPublisher

ApplicationEventPublisher 는 스프링 빈으로 등록되어 있기때문에 객체를 주입받아 사용할 수 있습니다. 일반적으로 서비스 계층에서 해당 객체를 주입받은 뒤, publishEvent(event) 메서드를 통해 이벤트를 발행합니다.

@RequiredArgsConstructor
@Service
public class PollService {
    
		private final ApplicationEventPublisher applicationEventPublisher;

    @Transactional
		public PollResponse createPoll(String teamCode, Long memberId, PollCreateRequest request) {
        Poll poll = request.toPoll(teamCode, memberId, systemTime.now());
        Poll savedPoll = pollRepository.save(poll);
				applicationEventPublisher.publishEvent(PollEvent.from(teamCode));
        return PollResponse.from(memberId, savedPoll);
    }
Java
복사

인자로 보내지는 PollEvent 객체는 POJO 객체이고, Dto 처럼 알림 로직에서 사용할 변수를 객체에 태워 보내면 이를 처리하는 로직에서 받아 사용합니다.

AbstractAggregateRoot

클래스명에 Abstract 가 있지만 추상 클래스는 아니고, 도메인에서 이벤트를 간단하게 처리하기 위한 템플릿으로 볼 수 있습니다. 도메인 주도 관점에서 보았을 때, 루트 도메인에서 해당 클래스를 상속받고 해당 클래스의 protected 메서드인 registerEvent(event) 를 통해 이벤트를 등록합니다.

public class Poll extends AbstractAggregateRoot<Poll> {
		// ...
    Poll(Long id, String teamCode) {
				// ...
        registerEvent(PollEvent.from(teamCode));
    }
}
Java
복사

하지만 registerEvent는 이벤트를 등록만 할 뿐, 발행하지는 않습니다. 대신 발행하는 작업은 AOP 방식으로 발행하는데요, Spring Data JPA Repository의 save, saveAll, delete, deleteAll이 호출될 때 엔티티에 쌓여 있는 이벤트를 모두 발행합니다.

@RequiredArgsConstructor
@Service
public class PollService {

    @Transactional
		public PollResponse createPoll(String teamCode, Long memberId, PollCreateRequest request) {
        Poll poll = request.toPoll(teamCode, memberId, systemTime.now());
        return PollResponse.from(memberId, pollRepository.save(poll));
    }
Java
복사

저희는 ApplicationEventPublisher 를 주입받는 대신 AbstractAggregateRoot 를 상속받아 사용하는 것으로 결정하였습니다.

둘의 차이를 관심사 측면에서 생각해볼 수 있습니다. ‘투표 생성’ 이라는 사건이 발생한 것은 도메인에서 생성된 것이기에 도메인에서 관리해야 하는 관심사입니다. 즉 ‘투표 생성’ 이라는 이벤트는 서비스 계층 투표 생성 로직의 관심사는 아니라고 생각했습니다. 서비스 계층 투표 생성 로직의 관심사는 그저 요청 파라미터를 투표 POJO 객체로 바꾼 뒤 이를 저장하는 것 뿐입니다. 이에 따라 ‘투표 생성 시’에 무언가를 한다면 이는 투표 도메인 객체의 관심사이기에 이벤트 발행 로직을 도메인 객체에 넣는게 적절하다고 판단하였습니다.

발행 동작 원리

AbstractAggregateRoot 의 발행하는 과정을 조금 더 자세히 들여다 보겠습니다. Spring Data JPA repository 의 메서드 중 save, saveAll, delete, deleteAll 이 호출되면 AOP 로 등록된 인터셉터 중 EventPublishingMethodInterceptor 에서 이벤트 관련 로직을 수행합니다.

class EventPublishingMethodInterceptor implements MethodInterceptor {

		@Override
		@Nullable
		public Object invoke(MethodInvocation invocation) throws Throwable {

			Object result = invocation.proceed();

			if (!isEventPublishingMethod(invocation.getMethod())) {
				return result;
			}
			// ...
			eventMethod.publishEventsFrom(arguments[0], publisher);

			return result;
		}

		private static boolean isEventPublishingMethod(Method method) {
				return method.getParameterCount() == 1 //
						&& (isSaveMethod(method.getName()) || isDeleteMethod(method.getName()));
		}
	
		private static boolean isSaveMethod(String methodName) {
				return methodName.startsWith("save");
		}
	
		private static boolean isDeleteMethod(String methodName) {
				return methodName.equals("delete") || methodName.equals("deleteAll") || methodName.equals("deleteInBatch")
						|| methodName.equals("deleteAllInBatch");
		}
}
Java
복사

isEventPublishingMethod 에서 save 또는 delete 인지 확인하여 맞다면 publishEventsFrom 를 호출합니다. publishEventsFrom 메서드 내부에서는 앞서 언급한 ApplicationEventPublisher 의 publishEvent() 를 호출하게 됩니다.

결국 ApplicationEventPublisher 를 주입받아 사용하는 로직이나 AbstractAggregateRoot 에서 AOP 를 활용해 사용하는 로직이 한 곳에서 만나게 되는 것입니다.

그렇다면 발행한 이벤트는 어디에서 보관되어 어떻게 처리될까요?

ApplicationEventPublisher 의 publishEvent 메서드는 AbstractApplicationContext 추상 클래스에 구현되어 있습니다. publishEvent 메서드 내부에서 SimpleApplicationEventMulticaster 를 거쳐 TransactionListener 에 등록을 요청하면 TransactionalApplicationListenerMethodAdapter 의 onApplicationEvent 메서드에서 등록을 합니다.

public class TransactionalApplicationListenerMethodAdapter extends ApplicationListenerMethodAdapter
		implements TransactionalApplicationListener<ApplicationEvent> {

	// ...
	public void onApplicationEvent(ApplicationEvent event) {
		if (TransactionSynchronizationManager.isSynchronizationActive() &&
				TransactionSynchronizationManager.isActualTransactionActive()) {
			TransactionSynchronizationManager.registerSynchronization(
					new TransactionalApplicationListenerSynchronization<>(event, this, this.callbacks));
		}
	}
}
Java
복사

TransactionSynchronizationManager 는 트랜잭션의 동기화를 도와주는 객체인데요, 해당 메서드에 ThreadLocal 의 Set 자료구조로 이루어진 변수에 담기면 발행이 완료됩니다.

Set 자료 구조의 타입은 TransactionSynchronization 인데 해당 객체는 발행시 인자로 보낸 Dto 성격의 객체와 리스너를 함께 담고 있습니다. 여기에 담긴 TransactionSynchronization 객체는 추후에 구독하는 객체에서 가져와 사용하게 되는데요, 이는 다음 챕터에서 알아보도록 하겠습니다.

구독은 어노테이션 방식으로 간단하게 적용이 가능하며@EventListener, @TransactionalEventListener 어노테이션으로 이벤트 구독을 할 수 있습니다.

@EventListener : 이벤트가 발행되었을 때 항상 이를 수신합니다.

@TransactionalEventListener : 이벤트를 발행하는 트랜잭션이 올바르게 수행되었을 때 수신합니다.

@TransactionalEventListener 선택 이유

저희 프로젝트에서는 @EventListener 대신 @TransactionalEventListener 를 사용하였는데요, 그 이유로는 투표 생성 로직이 올바르게 수행되었을 때 슬랙 알림을 보내는 것이 비즈니스 정책이었기 때문입니다. 즉, 만약 투표 생성 시도에 초점을 두어, 이러한 시도가 있을때마다 성공 여부와 관계없이 이를 구독하고 싶다면 @EventListener 를 사용하였을 것입니다. 하지만 투표가 올바르게 생성되었을 때만 이를 구독하고 알림을 보내야 하기때문에 @TransactionalEventListener를 사용하였습니다.

조건 설정

•

condition

현재 저희 모락 서비스 정책 상, 슬랙 알림은 투표를 생성할 때 뿐만 아니라 투표 종료 시에도 보냅니다. 이러한 로직들을 처리하기 위해, 이벤트를 등록할 때 인자로 보내지는 이벤트 POJO 객체에 isClosed 변수를 설정하고 생성된 것인지, 종료한 것인지 알림 로직 내에서 분기 처리하여 확인할 수 있습니다.

@Transactional
public class NotificationService {

		// ...

		@TransactionalEventListener
    public void notifyPoll(PollEvent event) {
				if (!event.isClosed()) {
						// 투표 생성 알림
						return
				} 
				// 투표 종료 알림
    }
}
Java
복사

하지만 이후에 투표 제목이 수정되었을 때에도 알림을 보내야하는 비즈니스 로직이 추가가 된다면 if 분기문이 추가되어야 합니다. 이렇게 하나의 메서드 내에 계속 분기문이 추가가 된다면 유지/보수에도 좋지 않고 가독성도 떨어지게 됩니다. 그래서 @TransactionalEventListener 는 이러한 문제를 progmmatic 하게 처리할 수 있도록 condition 옵션이 있습니다.

@Transactional
public class NotificationService {

		// ...

		@TransactionalEventListener(condition = "#event.isClosed() == false")
    public void notifyPollOpen(PollEvent event) {
				// 투표 생성 알림
    }

		@TransactionalEventListener(condition = "#event.isClosed() == true")
    public void notifyPollClosed(PollEvent event) {
				// 투표 종료 알림
    }
}
Java
복사

이처럼 condition 으로 로직 실행 조건을 설정하면 메서드 단위로 로직을 나눌 수 있어 앞서 언급한 유지/보수 문제점을 해결할 수 있습니다. condition 을 확인하는 시점은, 커밋 이후 listener(ApplicationListenerMethodAdapter) 의 processEvent 가 호출되는데, 해당 메서드 내부에서 condition 을 꺼내어 확인합니다(해당 로직을 수행하는 소스 코드).

또 한가지 장점이 있는데, 만약 condition 조건 없이 단순히 메서드만 나누고 해당 메서드 내에서 분기문으로 처리한다면 다음과 같이 구성할 수 있습니다.

@Transactional
public class NotificationService {

		// ...

		@TransactionalEventListener
    public void notifyPollOpen(PollEvent event) {
				if (!event.isClosed()) {
				// 투표 생성 알림
				}
    }

		@TransactionalEventListener
    public void notifyPollClosed(PollEvent event) {
				if (event.isClosed()) {
				// 투표 종료 알림
				}
    }
}
Java
복사

이 상태에서는 등록되는 listener 가 두 개(notifyPollOpen, notifyPollClosed)가 되고 두 메서드 모두 실행이 되고 if 구문으로 알림 로직을 처리할지 말지 확인합니다. 이렇게 된다면 두 메서드 모두 트랜잭션을 새로 얻게 됩니다. 즉 투표 생성 시에 투표 생성 알림 로직 의 트랜잭션과 투표 종료 알림 로직 의 트랜잭션이 모두 열리게 되어 불필요한 트랜잭션을 얻어 비효율적입니다. 하지만 condition 으로 처리를 한다면, condition 을 확인하는 로직은 새로운 쓰레드를 열어 알림 로직을 실행하기 전입니다. 이에 따라 불필요한 트랜잭션을 생성하지 않을 수 있습니다.

•

phase

구독하는 이벤트 로직이 언제 처리될 지 정할 수 있는 옵션입니다. 선택할 수 있는 phase 로는 BEFORE_COMMIT, BEFORE_COMPLETION, AFTER_COMMIT, AFTER_COMPLETION 등 총 4개의 phase 가 있습니다. *_COMMIT 은 메인 로직이 커밋이 되었을 때, 즉 status 에 롤백이 발생하지 않았을 때 동작하고, *_COMPLETION 은 커밋/롤백에 상관없이 동작합니다. 기본값은 AFTER_COMMIT 이고, 이에 따라 메인 로직인 투표 생성 로직이 롤백되지 않고 온전히 커밋된 이후에 알림 로직이 동작하게 됩니다.

구독 동작 원리

AbstractPlatformTransactionManager 의 processCommit 메서드는 해당 쓰레드의 트랜잭션 커밋 로직을 수행합니다. 이 때 커밋하기 전과 후에 수행되어야 할 로직들을 수행하는데 phase 의 설정에 따라 이벤트 로직도 커밋 전/후에 수행됩니다. 이 포스팅에서는 커밋 이후의 이벤트 로직 수행에 대해 알아보겠습니다.

processCommit 메서드 내에서 커밋 로직을 수행하고난 뒤, 발행할 때 등록된 TransactionSynchronization 들을 가져온 뒤(소스 코드), TransactionSynchronizationUtils 에서 가져온 synch 들을 반복문을 돌면서 이벤트 로직이 수행됩니다(소스 코드).

여기서 주요하게 다루어지는 TransactionSynchronization 객체는 트랜잭션 커밋 전후에 작업을 실행시키기 위한 인터페이스입니다. 앞서 phase 로 적용할 수 있는 beforeCommit, beforeCompletion, afterCommit, afterCompletion 네가지 메서드를 구현할 수 있습니다. 구현체에 따라 처리 방법이 다르며, @TransactionalEventListener 는 TransactionalApplicationListenerSynchronization 라는 구현체를 사용합니다. 해당 구현체에는 listener(구독 메서드)와 인자로 받은 이벤트 객체가 있고, 구독 메서드를 실행함으로써 구독 로직이 동작하게 됩니다.

AfterCompletion이 왜 거기서 나와…?

소스 코드를 살펴보며 가장 궁금했던 부분은 triggerAfterCompletion 에서 실행된다는 것입니다.

위의 소스 코드를 다시 한번 보겠습니다.

public abstract class TransactionSynchronizationUtils {

	public static void invokeAfterCommit(@Nullable List<TransactionSynchronization> synchronizations) {
		if (synchronizations != null) {
			for (TransactionSynchronization synchronization : synchronizations) {
				synchronization.afterCommit();
			}
		}
	}

	public static void invokeAfterCompletion(@Nullable List<TransactionSynchronization> synchronizations,
			int completionStatus) {

		if (synchronizations != null) {
			for (TransactionSynchronization synchronization : synchronizations) {
				try {
					synchronization.afterCompletion(completionStatus);
				}
				catch (Throwable ex) {
					logger.debug("TransactionSynchronization.afterCompletion threw exception", ex);
				}
			}
		}
	}
}
Java
복사

@TransactionalEventListener phase 옵션으로 기본값인 after commit 으로 설정하고, triggerAfterCommit 메서드도 존재하는데 왜 after completion 으로 실행이 되었을까요?

사실 trggerCommit 에서는 아무것도 하지 않습니다. 해당 메서드는 구현되어있지 않고 인터페이스의 디폴트 메서드는 비어있는 상태입니다. 그래서 사실 triggerAfterCommit 과 triggerAfterCompletion 로직 둘 다 타는데, 실제 실행은 triggerAfterCompletion 에서만 진행되는 것입니다.

afterCommit 과 afterCompletion 을 둘로 나눈 이유를 알아보기 위해 TransactionSynchronization 인터페이스의 주석을 읽어보았는데요, 기본적인 설명은 메서드명에서 잘 드러납니다. afterCommit 은 커밋 이 진행된 이후, afterCompletion 은 커밋/롤백 상관없이 진행 됩니다.

그런데 사실 현재 로직이 진행되고 있는 시점은 이미 메인 로직의 트랜잭션 로직이 커밋이 된 이후 입니다. 즉 롤백 상태가 있기 힘든 상황입니다. 그렇다면 둘의 실질적인 차이는 무엇일까요?

# afterCommit
Throws:
RuntimeException – in case of errors; will be propagated to the caller (note: do not throw TransactionException subclasses here!)

# afterCompletion
Throws:
RuntimeException – in case of errors; will be logged but not propagated (note: do not throw TransactionException subclasses here!)
Plain Text
복사

주석의 Throws 부분을 보면, afterCommit 은 예외가 호출된 메서드에 전파가 되고, afterCompletion 은 전파가 되지 않습니다. 이에 따라 afterCompletion 은 구현체 로직에서 try/catch 로 감싸져 있고 예외에 대해 DEBUG 로만 로깅하게 됩니다.

하지만 저희 서비스 특성상 알림 로직에서 예외가 발생했을 시, DEBUG 레벨 대신 WARN 레벨 이상의 로깅을 해야 하고, 이에 대해 해결책으로는 afterCommit 을 직접 구현하거나 슬랙 알림 로직에서 try/catch 로 예외를 핸들링할 수도 있습니다. 이 해결책들도 좋지만 아무래도 각각 장단점이 뚜렷해 보입니다. 그래서 앞선 해결책들 대신 비동기를 적용하여 예외 처리에 대한 핸들링이 가능하도록 구성해보았습니다.

비동기 설정

이벤트 발행/구독 방식으로 변경하면서 의존성을 떼어 내고, ‘투표 생성’이라는 메인 로직과 ‘슬랙 알림’ 부가 로직의 트랜잭션을 나누어 알림 로직에서 롤백이 되더라도 투표 생성은 커밋이 되도록 하였고, 투표 생성 로직의 커밋이 잘 이루어졌을때만 알림 로직이 동작하도록 만들어 보았습니다. 하지만 아직 문제점이 남아 있는데요, 현재 동작하는 이벤트 방식의 알림 로직은 동기적으로 실행되어 결국 알림 로직이 모두 완료할 때까지 투표 생성 API 는 대기할 수밖에 없고 이는 응답 latency 를 길게 만들게 됩니다. 주 관심사도 아닌 로직을 굳이 기다리지 않고 클라이언트에게 투표 생성에 대한 응답을 돌려주는 것이 더 자연스럽기에, 비동기가 필요한 상황이라고 판단하여 적용했습니다.

Async 쓰레드 풀 적용하기

비동기 이벤트 처리는 별도의 쓰레드에서 동작합니다. 이 때, 이벤트 처리마다 무한히 쓰레드를 생성하기 보다는 쓰레드 풀을 사용하여 관리하는 방법을 선택할 수 있습니다.

@EnableAsync
@Configuration
public class AsyncConfig implements AsyncConfigurer {

    private static final int THREAD_COUNT = 4;

    @Override
    public Executor getAsyncExecutor() {
        return Executors.newFixedThreadPool(THREAD_COUNT);
    }
}
Java
복사

하지만 비동기로 알림 로직을 수행하면 ControllerAdvice 에 잡히지 않습니다. 처음에는 왜 잡히지 않을까 이해할 수 없었는데, 생각해보니 잡히지 않는 것이 당연합니다. 요청에 대한 응답은 DispatcherServlet 의 mvc 방식으로 수행이 되고 핸들링 시에 try catch 로 감싸 예외가 발생하면 이를 잡아 ControllerAdvice 에서 처리를 합니다. 하지만 비동기는 새로운 쓰레드를 생성하여 로직이 수행되기 때문에 DispatcherServlet 에서 수행된 로직이 아니고, 이에 따라 예외가 잡힐 수 없는 구조입니다. 이에 따라 비동기로 수행되는 로직에서 발생하는 예외는 다른 방식으로 핸들링해야 하고 기본적으로 try/catch 구문으로 처리를 할 수 있는데, 이를 전역적으로 도와주는 클래스가 있습니다.

public class AsyncExceptionHandler implements AsyncUncaughtExceptionHandler {

    private static final Logger logger = LoggerFactory.getLogger(AsyncExceptionHandler.class);

    @Override
    public void handleUncaughtException(Throwable ex, Method method, Object... params) {
        logger.warn("비동기 처리중 예외가 발생했습니다\n" +
                "예외 메세지 : " + ex.getMessage() + "\n" +
                "메소드 : " + method.getName() + "\n" +
                "파라미터 : " + Arrays.toString(params));
    }
Java
복사

@EnableAsync
@Configuration
public class AsyncConfig implements AsyncConfigurer {

		// ...

    @Override
    public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() {
        return new AsyncExceptionHandler();
    }
}
Java
복사

AsyncUncaughtExceptionHandler 를 상속받아 비동기 쓰레드에서 발생하는 예외를 전역적으로 처리할 수 있습니다.

개선점

이벤트 방식으로 전환하기 전의 문제점을 모두 해결해보았는데요, 아직 예외 처리에 대한 문제가 남아 있습니다. 현재는 알림 로직의 예외에 대해 로그로만 출력하고 있습니다. 이를 해결할 수 있는 방법으로는, 알림을 발송할 때 배치성 로직을 추가하여 아직 알림을 보내지 않은, 즉 앞서 투표 생성시 예외로 인해 알림을 보내지 못한 레코드에 대해 추가적인 로직을 실행하도록 하는 방법이 있습니다.

public void notifyPollOpen(PollEvent event) {
		// findAllWhereNotnotified();
		// 성공하면 모두 notified = true 업데이트
}
Java
복사

예외로 인해 알림을 보내지 못했던 투표들에 대해 재처리하는 로직은 수행할 수 있습니다. 하지만 이 방법도 결국에는 실시간성이 부족하고, 예외 상황에 대한 추적과 즉각적인 대응을 할 수 없는 방법입니다. 결국은 MSA 와 같이 서비스를 아예 나누어 알림에 대한 새로운 API 를 구성하고, 알림에 대해 요청을 보낼 수 있도록 하여 이에 대한 응답을 따로 관리하는 것이 좋은 방법이 될 것입니다.