비동기 처리로 이메일 발송 성능 개선하기 (feat. 모듈 분리)

개요

현재 저희 Subport에서는 구독 결제일이 다가오면 이메일로 알림을 발송하는 기능을 제공하고 있습니다. 알림 설정은 ON/OFF가 가능하고 결제 1일 전 또는 3일 전을 선택할 수 있습니다.

 

메일 발송 로직은 다음과 같습니다.

1. 스케줄러를 통해 매일 오전 6시 30분에 오늘이 발송일인 구독 정보를 조회하여 이메일 발송용 객체 생성
2. 해당 객체를 기반으로 오전 7시에 이메일 발송

@Transactional(readOnly = true)
public void send(LocalDateTime now) {
	List<EmailNotification> emailNotifications = getEmailNotifications(now, SendingStatus.PENDING);

	log.info("이메일 발송 시작 - 대상 건수: {}", emailNotifications.size());

	Map<String, List<EmailNotification>> groupedEmailNotifications = emailNotifications.stream()
		.collect(Collectors.groupingBy(EmailNotification::getRecipientEmail));

	for (Map.Entry<String, List<EmailNotification>> entry : groupedEmailNotifications.entrySet()) {
		emailSender.send(entry.getValue(), false, now); // 동기 호출
	}

	log.info("이메일 발송 요청 완료 - 수신자 수: {}", groupedEmailNotifications.size());
}

 

그런데 모든 이메일 객체를 조회한 뒤 동기로 처리하다 보니 처리 시간이 꽤 길었습니다. 물론 실시간 알림이 아닌 만큼 서비스 운영에는 큰 영향이 없지만, 그만큼 스레드가 불필요하게 오래 점유되고 프리티어 인스턴스 환경에서는 이것이 부담될 수 있다고 판단했습니다.

 

참고)
실제로 수백, 수천 건의 메일을 발송하는 것은 OCI의 월 3,000건 제한과 스팸 처리 위험이 있어 불가능했습니다. 그래서 10여 건의 발송으로 평균 소요 시간을 측정한 뒤, 해당 값을 고정하여 시뮬레이션 방식으로 테스트를 진행했습니다.

 

비동기 적용

우선 메일 발송 로직을 동기에서 비동기로 전환했습니다. 메일 발송 메서드를 별도의 클래스로 분리하고 @Async 어노테이션을 적용했습니다.

그 결과 처리 시간이 크게 단축되었으며, 1,000건 기준으로 발송 요청 처리가 약 1분 정도 만에 완료되었습니다.

 

그런데 여기서 확인해야 할 부분이 있습니다.

 

비동기 스레드 풀 기본 설정은 어떻게 돼 있을까?

'@Async를 사용할 때 별도의 스레드 풀 설정을 하지 않으면 SimpleAsyncTaskExecutor를 사용한다.'라는 정보를 흔히 접할 수 있고 저 역시 그렇게 알고 있었습니다. 하지만 스프링 부트에서 이는 정확하지 않은 설명입니다.

스프링 부트에서는 TaskExecutionAutoConfiguration 클래스를 통해 스레드 풀이 자동으로 설정됩니다.

 

TaskExecutorConfigurations 클래스 내부를 살펴보면 다음과 같습니다.

즉, 플랫폼 스레드를 사용하는 경우엔 ThreadPoolTaskExecutor, 가상 스레드를 사용하는 경우엔 SimpleAsyncTaskExecutor가 기본 Executor로 등록됩니다.

그래서 별도의 설정을 하지 않았다면 일반적으로 플랫폼 스레드 환경일 것이고, 이 경우 기본 Executor로 ThreadPoolTaskExecutor가 사용됩니다.

 

플랫폼 스레드와 가상 스레드 (+ 캐리어 스레드)
플랫폼 스레드는 OS가 관리하는 전통적인 자바 스레드로, Java가 OS의 기능을 활용해 생성합니다. 상대적으로 많은 리소스를 소비하며 스레드 수는 시스템 리소스에 의해 제한됩니다.
가상 스레드는 Java 21에서 정식 도입된 경량 스레드로, JVM 위에서 생성 및 실행됩니다. 플랫폼 스레드보다 훨씬 가볍고 적은 리소스를 사용하며, 고정된 스택 크기 없이 사용량에 따라 유동적으로 크기가 조절됩니다. 가상 스레드는 캐리어 스레드 위에서 실행되는데, 캐리어 스레드는 실제 CPU 실행 시간을 제공하는 플랫폼 스레드로, 여러 가상 스레드를 시분할 방식으로 스케줄링합니다. 덕분에 OS 스레드 수의 제한 없이 대량의 동시 작업을 효율적으로 처리할 수 있습니다.

 

또한 @Conditional(OnExecutorCondition.class)이 적용되어 있어 조건부로 동작합니다.
OnExecutorCondition은 다음과 같습니다.

Executor 타입의 빈이 등록되어 있지 않다면 기본 스레드 풀 생성을 진행합니다.

 

ThreadPoolTaskExecutor에 적용되는 설정값은 TaskExecutionProperties 클래스에서 확인할 수 있으며, 기본값은 다음과 같습니다.

한 가지 주의할 점은 큐 사이즈가 Integer.MAX_VALUE로 설정되어 있다는 것입니다. ThreadPoolTaskExecutor는 큐가 가득 찼을 때 비로소 maxSize까지 스레드를 늘리는데, 사실상 큐가 가득 찰 일이 없으므로 스레드 수는 coreSize인 8을 넘지 않습니다.

 

그렇다면 SimpleAsyncTaskExecutor는 언제 사용되는 걸까?

AsyncExecutionInterceptor 클래스의 getDefaultExecutor()에서 확인할 수 있습니다.

super.getDefaultExecutor(), 즉 부모 클래스인 AsyncExecutionAspectSupport의 getDefaultExecutor()가 null을 반환할 때 SimpleAsyncTaskExecutor가 사용됩니다.

 

"그럼 언제 null이 반환될까?"

 

이를 확인하기 위해 AsyncExecutionAspectSupport 클래스의 getDefaultExecutor()를 살펴보겠습니다.

1. TaskExecutor.class 타입의 빈을 조회합니다.
2. 동일 타입의 빈이 2개 이상이면 NoUniqueBeanDefinitionException이 발생하고, taskExecutor라는 이름의 빈을 추가로 조회합니다.
3. 빈이 아예 없으면 NoSuchBeanDefinitionException이 발생하고, 마찬가지로 taskExecutor라는 이름의 빈을 추가로 조회합니다.
4. 이 두 번째 조회에서도 빈을 찾지 못하면 null을 반환합니다.

 

결국 SimpleAsyncTaskExecutor가 사용되는 케이스는 다음과 같습니다.

• TaskExecutor 타입의 빈이 2개 이상 등록되어 있고
• 그중 이름이 taskExecutor인 빈도 없으며
• @Primary로 지정된 빈도 없고
• @Async에서 사용할 빈을 명시하지 않은 경우

 

"이제 전체 흐름을 정리해 보자"

 

1️⃣ AsyncExecutionInterceptor의 invoke() 호출

내부에서 determineAsyncExecutor()를 통해 실제로 사용할 AsyncTaskExecutor를 결정합니다.

 

2️⃣ AsyncExecutionAspectSupport의 determineAsyncExecutor() 동작

qualifier 지정 여부를 확인합니다. 예를 들어 @Async("emailExecutor")와 같이 이름이 명시돼 있으면 해당 이름으로 빈을 조회하고, 그렇지 않으면 defaultExecutor를 사용합니다.

 

3️⃣ defaultExecutor 결정

AsyncExecutionAspectSupport의 생성자에서 SingletonSupplier를 통해 getDefaultExecutor()를 등록해 둡니다. (SingletonSupplier는 @Async 메서드가 최초로 호출되는 시점에 지연 호출을 하여 getDefaultExecutor()를 실행합니다.)

getDefaultExecutor()는 AsyncExecutionInterceptor에서 오버라이딩된 버전이 동작합니다.

 

최종 요약

1. @Async 메서드 호출
2. AsyncExecutionInterceptor.invoke()
3. determineAsyncExecutor()
4. qualifier 지정 여부 확인
   • 지정된 경우 ➡ 해당 이름으로 빈 조회
   • 미지정인 경우 ➡ defaultExecutor 사용
5. getDefaultExecutor() 호출 (최초 호출 시 SingletonSupplier가 지연 실행)
   • TaskExecutor 빈이 하나 ➡ 해당 빈 사용
   • 2개 이상 & taskExecutor 이름 있음 ➡ 해당 빈 사용
   • 2개 이상 & taskExecutor 이름 없음 ➡ null
     • new SimpleAsyncTaskExecutor() 사용

 

스레드 풀 크기 설정

기본 스레드 풀 설정만으로도 처리 시간이 약 10분에서 1분으로 90% 정도 개선되었습니다.

하지만 스레드 수를 늘리면 처리 속도를 더 개선할 수 있습니다.

 

"프리티어 인스턴스 환경이면 코어가 1~2개이지 않나? 스레드 수를 늘려도 의미가 있나? 괜히 컨텍스트 스위칭 오버헤드만 생기는 거 아닌가?"

라고 생각하실 수도 있지만, 이메일 발송 요청은 I/O 바운드 작업입니다. CPU가 직접 연산을 수행하는 것이 아니라 외부 SMTP 서버의 응답을 기다리는 시간이 대부분을 차지하므로, 스레드 수를 늘려 전체 처리량을 높일 수 있습니다.

 

물론 스레드 수를 무작정 늘리는 것이 정답은 아닙니다. 스레드 수가 과하면 컨텍스트 스위칭 비용과 스레드당 메모리 사용량이 문제가 될 수 있습니다. 그래서 1,000건 발송을 기준으로 스레드 수를 변화시키며 처리 시간과 메모리 사용량을 측정했습니다.

스레드 수를 늘릴수록 처리 시간이 계속해서 줄었지만, 50개를 넘어서면서부터는 성능 개선 효율이 급감했는데, 처리 시간 감소 효율이 줄고, (표에는 적지 않았지만) 메모리 사용량 증가 폭도 커졌습니다. 그래서 성능 개선 효율이 가장 좋은 50개가 균형점이라고 판단하여 설정값으로 사용했습니다.

 

결과적으로 1,000건 발송 기준 처리 시간이 598.2초 ➡ 14.5초로, 약 97.6% 개선되었습니다.

 

모듈 분리

기존에는 API 서버와 스케줄링 처리가 하나의 컨테이너에서 동작했습니다. 스케줄링 작업 시간을 피해 배포를 진행한다면 문제없겠지만, 의도치 않게 스케줄링 실행 중에 배포가 겹쳐 작업이 중단되는 상황이 생길 수 있습니다. 이를 방지하기 위해 두 모듈을 분리했습니다.

 

방법은 간단했습니다. 공통 설정과 의존성은 루트의 build.gradle에 두고, api와 batch 모듈 각각에 별도의 build.gradle을 두어 독립적으로 관리했습니다. Dockerfile과 배포 스크립트도 각각 분리하여, 서로의 변경 사항에 영향을 받지 않고 각 모듈의 변경 사항에만 배포가 트리거 되도록 구성했습니다.

 

인스턴스 자체를 분리한 것은 아니기 때문에 성능상의 이점은 없지만, 배포 타이밍으로 인한 스케줄링 오작동을 방지할 수 있게 되었습니다.

 

현재는 DB 인스턴스를 MySQL HeatWave로 이전하면서 여유 인스턴스가 생겼기에 batch 컨테이너를 해당 인스턴스로 이전할 계획을 하고 있습니다. API 요청 없이 순수 스케줄링 용도로만 사용되는 만큼 적절한 분리가 될 거라고 생각합니다.

 

마무리

이메일 발송 로직을 동기 처리에서 비동기 처리로 개선하고, api 모듈과 batch 모듈을 별도 컨테이너로 분리해 보았습니다.

 

사실 구독을 수십 건씩 등록하는 사람은 많지 않을 것이기에, 유저 수가 어느 정도 늘어도 메일 발송 건수는 많지 않을 것으로 예상하고 있습니다. 그럼에도 이번 작업이 오버엔지니어링이라고 생각하지는 않습니다. 처리 시간 단축으로 인한 리소스 절약, 모듈 분리를 통한 배포 안정성 확보로 비용 대비 얻는 것이 충분하다고 판단했습니다.

 

그리고 메일 발송이 I/O 바운드 작업인 만큼 Java 버전을 올려(17 -> 21) 가상 스레드를 도입해 볼까도 생각 중입니다. 다만 별도 인스턴스로의 이전이 완료된 이후에는 추가적 이점이 얼마나 있을지 고민해 봐야 할 거 같습니다🤔