CompletableFuture를 활용해 외부 API 호출을 비동기 처리, 응답 시간 1분 → 14초로 단축

문제 상황

프로젝트 QA시, 주간 리포트 기능의 응답 시간이 사용자 1명당 최악의 경우 2분 이상, 대체로 평균 1분 이상 소요되는 문제가 있었습니다.

주간 리포트 기능의 QA결과

 

이 문제를 분석한 결과, DB 쿼리는 실행 계획상 eq_ref 와 ref로 빠르게 처리되고 있었습니다.

응답 시간이 길어진 주요 원인은 비즈니스 로직에서 최대 7번의 외부 API 호출을 동기적으로 처리하고 있기 때문이었습니다.

 

아래 코드처럼, stream() 내부에서 연속적인 외부 API 호출을 처리하면서 일일 서비스와 Clova AI가 동기적으로 요청과 응답을 주고받는 구조로 동작하고 있었고, 이를 개선하고자 했습니다.

Map<외부 API 결과, List<Value>> valuesByKey = map.values().stream()  <<-- 외부 API 응답 collect
                .collect(Collectors.toMap(
                        values -> 외부 API 호출,                     <<-- 외부 API 호출
                        values -> values));

3 가지 대안 방안

문제를 해결하기 위해 3 가지 대안을 고려했습니다.

1. parallel()을 사용하여 스트림을 내부적으로 병렬 처리한다.
2. 외부 API 호출을 @Async / CompletableFuture 를 활용해 비동기적으로 처리한다.
3. 외부 API 호출 방식을 Non-Blocking I/O로 변경한다.
   • 현재 사용 중인 OpenFeign 대신 Spring WebFlux의 WebClient로 교체하는 등 새로운 라이브러리를 도입한다.

이 중 2번, @Async / CompletableFuture 를 활용한 비동기 호출 방식을 선택한 이유와 다른 대안을 배제한 이유는 다음과 같습니다.

 

1번인 parallel() 을 사용한 병렬 처리를 배제한 이유

parallel() 을 사용하여 스트림을 병렬로 처리하지 않은 이유는 paralle(병렬 스트림)의 동작 방식은 CPU 작업에 효율적이며, I/O 작업(I/O-bound)에 적합하지 않기 때문입니다.

 

• parallel() 을 사용하면 자바는 포크/조인 프레임워크를 활용해 스트림을 재귀적으로 분할하고(fork), 각각의 쓰레드에서 분할한 스트림을 작업하여 결과를 만들어 냅니다. 이 후, 이 결과들을 합치게 됩니다.(join)
• 이 때, 스트림의 작업을 수행할 쓰레드들은 ForkJoinPool 통해 생성하며 ForkJoinPool 은 JVM이 사용할 수 있는 CPU 코어 수에 맞춰 쓰레드를 생성합니다.

int threads = Runtime.getRuntime().availableProcessors();

• 그리고, 각각의 쓰레드들은 분할된 stream() 에서 자신의 연산을 마쳐서 결과를 만들어 냈다면 작업 훔치기(Work Stealing) 를 통해 다른 스레드의 작업을 "훔쳐서" 처리합니다. 이를 통해 CPU 사용률을 극대화하려고 합니다.

반면 I/O 작업은 쓰레드가 Blocking 상태로 인해 스레드가 대기하는 시간이 많아, 작업을 나눌 여지가 적습니다. 즉, 작업을 "훔쳐오는" 것이 큰 의미를 갖지 못하게 됩니다.

 

그래서, "모던 자바 인 액션"에서도 제 문제 상황처럼 모든 작업이 I/O 작업일 경우, 비동기 API를 활용하는 모습을 볼 수 있었습니다.

(이러한 이유로 ForkJoinPool의 Work Stealing 에 대한 소개를 보자마자 해당 방식은 맞지 않구나를 알 수 있게 되었습니다. Work Stealing 과 포크/조인 프레임워크는 다음번에 공부하는 걸로..) 

 

3번인 Non-Blocking I/O(WebClient)로의 교체를 배제한 이유

즉각적인 적용 어려움

• WebClient의 동작 방식을 완전히 학습해야 하며, 이는 현재 성능 개선이 긴급히 요구되는 상황에서 프로젝트를 지연시킬 수 있습니다

팀원의 학습 비용 증가

• 협업 프로젝트에서 OpenFeign을 주로 사용 중이었기 때문에, WebClient로 교체할 경우 팀원들이 WebClient의 동작 방식을 익히는 데 추가적인 학습 시간이 필요합니다.

 

2번인 '@Async / CompletableFuture 를 활용한 비동기 처리' 선택한 이유

빠른 적용 가능

• 팀원 모두가 같은 코드스쿼드 수료생이었으며, 해당 교육 기관에서 CompletableFuture 를 활용한 경험이 있습니다.
• 비동기에 대해 기본적인 지식을 모두 가지고 있었습니다.

물론, 2번도 고려할 점이 있습니다. 비동기를 위해 쓰레드 풀을 사용하게 되는데, 동시 요청이 많을 경우 스레드 풀의 큐 용량이 가득 차면서 클라이언트가 대기해야 하는 상황이 발생할 수 있습니다. 이러한 상황에서는 병목 현상이 @Async의 스레드 풀 때문인지, 다른 지점에서 발생했는지를 파악해야 합니다. 이를 위해 기존에 구축한 Prometheus와 Grafana를 활용해 문제를 모니터링하고 분석할 계획에 있습니다.

 

2번 방법 쓰레드 풀 설정 과정

먼저 코드를 보여드리고, 그에 대한 설명을 이어나가겠습니다.

 

먼저, 쓰레드 풀 설정 코드입니다.

@EnableAsync
@Configuration
public class AsyncConfig {

    @Bean
    public Executor clovaExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(16);
        executor.setMaxPoolSize(32);
        executor.setQueueCapacity(100);
        executor.setKeepAliveSeconds(60); // 기본 값 60 이지만, 명시적으로 알기 위함
        executor.setThreadNamePrefix("clova-async-");
        executor.setAwaitTerminationSeconds(60);
        executor.setWaitForTasksToCompleteOnShutdown(true);
        executor.setRejectedExecutionHandler(new CallerRunsPolicy());
        executor.initialize();
    }
}

 

@EnableAsync 설명

@EnableAsync는 Spring에서 비동기 작업을 활성화하기 위해 사용되는 어노테이션입니다. Spring은 비동기 메서드 실행 시 이를 처리할 스레드 풀을 다음과 같은 순서로 검색합니다.

• 스프링 컨텍스트에 유일한 org.springframework.core.task.TaskExecutor 빈이 있거나, java.util.concurrent.Executor 빈의 이름이 "taskExecutor"라면 이를 사용합니다.

• 만약 위의 두 가지 조건에 해당하는 빈이 없으면, Spring은 org.springframework.core.task.SimpleAsyncTaskExecutor를 사용해 비동기를 처리합니다.
  • SimpleAsyncTaskExecutor 는 비동기 작업 요청을 처리할 때마다 쓰레드를 생성하므로 주의가 필요합니다.

-- @EnableAsync 의 Javadoc 일부
By default, Spring will be searching for an associated thread pool definition: either a unique org.springframework.core.task.TaskExecutor bean in the context, or an java.util.concurrent.Executor bean named "taskExecutor" otherwise. If neither of the two is resolvable, a org.springframework.core.task.SimpleAsyncTaskExecutor will be used to process async method invocations. Besides, annotated methods having a void return type cannot transmit any exception back to the caller. By default, such uncaught exceptions are only logged.

 

Spring Boot 와 @EnableAsync

하지만 Spring Boot 와 함께 @EnableAsync 사용 시, 쓰레드 풀 설정을 따로하지 않아도 SimpleAsyncTaskExecutor 대신 Auto configuration 에 의해 빈으로 등록된 쓰레드 풀이 쓰입니다.

Spring Boot 2.1 부터 자동 구성에 의해 org.springframework.boot.autoconfigure.task의 TaskExecutionProperties 가 적용됩니다. 이 설정의 기본값은 다음과 같습니다.

• 기본 쓰레드 수: 8
• 최대 쓰레드: INTEGER.MAX_VALUE
• 큐 용량: INTEGER.MAX_VALUE
• 최대 쓰레드의 살아있는 시간: 60초

그러나, 이 설정은 서버 스펙과 맞지 않을 수 있으므로, 서버 스펙에 맞게 커스터마이징하는 것이 중요합니다.

 

또한, 스프링 부트도 아래 코드처럼 쓰레드 풀을 2개 이상 설정 시, @Async 어노테이션에 어떤 쓰레드 풀을 사용할 건지 정의하지 않으면 @Async 처리하는데 SimpleAsyncTaskExecutor 를 사용하게 되니 주의해야 할 필요가 있습니다.

@Bean
public Executor asyncExecutor1() {
    ThreadPoolTaskExecutor executor1 = new ThreadPoolTaskExecutor();
    return executor1;
}

@Bean
public Executor asyncExecutor2() {
    ThreadPoolTaskExecutor executor2 = new ThreadPoolTaskExecutor();
    return executor2;
}

...
@Async // asyncExecutor1 과 aysncExecutor2 중 어떤 쓰레드 풀을 사용할 것인지 명시해야 한다.
public void doAsync()...

 

우아한 종료를 위한 ThreadPoolTaskExecutor 사용

비동기 작업을 처리하기 위해 Spring의 ThreadPoolTaskExecutor를 사용했습니다. 이는 Java의 ThreadPoolExecutor를 Spring 생명주기에 맞게 확장한 구현체로, 우아한 종료(graceful shutdown)를 지원합니다. 

 

ThreadPoolTaskExecutor는 쓰레드 풀 종료 메서드인 shutdown()을 Spring의 라이프사이클과 관련지어 추상화하여 제공함으로써, 쓰레드 풀의 우아한 종료를 스프링 라이프사이클에 맞춰 쉽게 설정할 수 있습니다.

 

우아한 종료란?

• 서버 종료 시, 스레드 풀의 작업 중인 스레드와 대기 중인 큐의 작업이 모두 완료될 때까지 스레드 풀의 종료를 지연시키는 것을 의미합니다.
• 만약 서버가 종료 중에 스레드 풀이 강제로 종료된다면 I/O 작업 중이던 스레드가 작업을 완료하지 못하거나, 큐에 대기 중이던 작업이 처리되지 못할 수 있습니다.
• 이를 방지하기 위해 스레드와 큐의 모든 작업이 완료될 때까지 기다린 후 종료하는 것이 중요합니다.

다만, 우아한 종료 과정에서 작업의 종료 시간이 지나치게 길어질 경우 서비스가 종료되지 못하는 문제가 생길 수 있습니다. 이를 방지하기 위해, 작업 완료를 기다리는 최대 시간을 설정해서 대기 시간이 초과되면 스레드 풀이 강제로 종료되도록 했습니다.

threadPoolTaskExecutor.setWaitForTasksToCompleteOnShutdown(true);
threadPoolTaskExecutor.setAwaitTerminationSeconds(60);

(++처음에는 분명히 우아한 종료를 지원해주는 메서드가 있을텐데 하며 ThreadPoolTaskExecutor의 Javadoc 을 해석하며 시간을 많이 소비하고, 정리할 엄두가 안났었는데 우아한 종료를 어떻게 지원해주는지, 정리가 잘 된 글을 찾아 공유합니다. ThreadPoolTaskExecutor의 waitForTasksToCompleteOnShutdown 속성 알아보기)

 

I/O bound 에 맞게 쓰레드 풀의 쓰레드 설정

일반적으로 I/O 작업이 많은 경우, 쓰레드 풀의 coreSize는 코어의 2~3배로 설정할 수 있습니다.([Youtube] 쉬운 코드 - 스레드 풀 설정)

하지만, 정확한 값은 아래 공식을 계산해야 합니다. 다만, 저는 아래 공식을 어떤 상황에서의 CPU활용 비율을 측정해야 하는지, 대기시간과 계산시간을 언제 측정해야 하는지에 대해 아직 학습이 필요합니다.

그래서, 공식을 사용하지 않고 간단하게 coreSize 를 2배로 설정했습니다.

-- 출처: 모던 자바 인 액션
사용 가능한 코어 수 * 0과 1 사이의 값을 갖는 CPU활용 비율 * (1+ 대기시간/계산시간)

 

ThreadPoolTaskExecutor의 BlockingQueue

ThreadPoolTaskExecutor의 큐는 어떤 BlockingQueue 로 구현되어있는지 알아봤습니다.

양수면 LinkedBlockingQueue, 다른 값은 SynchronousQueue 로 구현됨을 알 수 있었습니다.

ThreadPoolTaskExecutor의 setQueueCapacity 메서드

 

해당 구현체 및 주요 BlockingQueue 구현체에 대해 간단히 설명하겠습니다.

• LinkedBlockingQueue
  • 크기가 무한하거나 고정된 FIFO 형태의 큐 띈다.
• SynchronousQueue
  • 데이터를 큐에 저장하지 않는다. 생산자가 데이터를 추가하면 소비자가 그 데이터를 받을 때까지 대기한다. 즉, 중간에 큐 없이 생산자와 소비자간의 직접 거래하는 메커니즘.
• ArrayBlockingQueue
  • 크기가 고정된 블로킹 큐로 공정(fair)모드를 사용할 수 있지만, 성능이 저하될 수 있다.
  • 공정 모드: 특정 큐에 있는 작업을 먼저 대기하고 여러 스레드들 중 특정 스레드로 하여금 처리하게 할 수 있다는 게 특징이다.
• PrioirtyBlockingQueue
  • 우선순위가 높은 요소를 먼저 처리합니다. (그 이상의 설명은 Javadoc을 봐야합니다..)
• DelayQueue
  • 각 요소는 지정된 지연 시간이 지난 후에 소비될 수 있다. 즉, 일정 시간이 지난 후 작업을 처리해야 하는 스케줄링 작업에 사용됩니다.

저 같은 경우는 공정모드, 우선순위, 지연 요소를 고려할 필요가 없다고 판단해서 ThreadPoolTaskExecutor의 기본 구현인 LinkedBlockingQueue 을 그대로 사용하기로 결정했으며 큐의 사이즈를 임의의 값인 100으로 두었습니다.

 

다만, 큐의 용량에 제한을 둔다면 큐의 용량이 가득 찼을 때의 작업을 어떻게 처리할 것인지 거절 정책을 정해야 합니다.

 

CallerRunsPolicy 을 통해 작업 제출 스레드를 활용하기

거절 정책은 작업이 스레드 풀의 최대 크기에 도달하고 큐가 가득 찼을 때 적용됩니다.

• AbortPolicy: 기본 거절 정책으로, 새로운 작업을 제출할 때, RejectedExecutionException 을 발생하며 거절합니다.
• DiscardPolicy: 새로운 작업을 조용히 버립니다.
• CallerRunPolicy: 새로운 작업을 제출한 스레드가 대신해서 직접 작업을 실행합니다.
• 사용자 정의(RejectedExecutionHandler): 개발자가 직접 정의한 로직으로 처리합니다.

저는 CallerRunsPolicy를 선택했습니다. 그 이유는 다음과 같습니다.

 

1. 트래픽이 많은 상황에서의 최소한의 작업 처리

• 작업 제출이 거부되는 상황은 대체로 트래픽이 과도하게 많은 상황일 것이라 예상했습니다. 이 때, CallerRunsPolicy 를 통해 작업을 제출한 스레드에서 작업을 처리하면 최소한의 작업을 처리할 수 있게 됩니다.

2. 어차피 join() 과 allOf() 로 인해 작업 제출 스레드가 대기합니다.

• 아직 설명에 안나왔지만, 저는 @Async 대신 CompletableFuture 를 활용해 7번의 외부 API 호출을 비동기 작업으로 처리한 후, join() 을 통해 작업 제출 스레드가 대기하는 구조입니다.
• 어차피 호출 스레드가 대기 중이라면, CallerRunsPolicy 를 사용해 호출 스레드가 외부 API 호출 작업을 대신 처리하도록 하는 것이 적절하다고 판단했습니다

다만, 이러한 과정은 마치 큐가 꽉 차더라도 호출 스레드가 작업을 실행하면서, 시스템이 정상적으로 동작하는 것처럼 보일 수 있습니다. 이로 인해 개발자가 과도한 트래픽 문제를 즉각 인지하기 어려울 수 있습니다.

 

위 단점을 보완하기 위해, 모니터링 서버에 트래픽 상태를 확인할 수 있는 알림 시스템을 추가해야 한다고 생각합니다.

 

코드 설명: CompletableFuture를 활용한 비동기 처리

시퀀스 다이어그램으로 나타낸 전체 흐름도입니다.

3번이 CompletableFuture 를 활용한 비동기 처리이며, 3번과 4번에 대해 설명하겠습니다.

 

시퀀스 다이어그램의 3번은 아래 코드 3번에 해당합니다.

// FACADE 계층의 코드 중 일부

public 응답값 createWeeklyReport(UUID userId, LocalDate startDate) {
    1. 주간 리포트 생성 여부 확인
    2. 클로바에게 요청을 보낼 1주일치 편지 조회
    3. 일일 리포트를 만들 편지들을 Clova에게 전송       <-- 외부 API 사용 및 비동기 처리
    4. 클로바로부터 받은 일일 리포트의 분석결과들을 저장 <-- 트랜잭션 시작 및 종료
    5. 주간 분석에 필요한 위로 한마디 조회
    6. 주간 리포트 요청                                <-- 외부 API 사용
    7. 주간 리포트 저장                                <-- 트랜잭션 시작 및 종료
    return 주간 리포트 저장 후 반환받은 응답값; 
}

 

외부 API 호출을 담당하는 Clova 서비스에서는 CompletableFuture.supplyAsync() 를 통해 비동기로 외부 API를 호출했으며, 비동기에 필요한 쓰레드는 수동 빈으로 등록한 쓰레드 풀을 사용하도록 구현했습니다.

public class ClovaService {

    private final Executor clovaExecutor;

    public CompletableFuture<ClovaResponseDto> sendAsyncDailyReportRequest(...) {
        return CompletableFuture.supplyAsync(() -> {
            ...로직 생략
            return 외부 API 호출;
        }, clovaExecutor);
    }

 

이렇듯 외부 API 호출을 비동기로 처리하기 위해 CompletableFuture를 활용했습니다. 그리고, thenApply 를 사용하여 응답 값에 대한 콜백을 추가했습니다.

// 3번 로직 중, 일부
Map<CompletableFuture<키>, List<값>> futures = Map.values().stream()
                .collect(Collectors.toMap(
                        값 -> clovaService.sendAsyncDailyReportRequest(letters)
                                .thenApply(~~),
                        값 -> 값
                ));

 

▶ 외부 API 결과 저장하는 로직을 비동기 작업 후 콜백에 추가하지 않은 이유

외부 API 호출의 결과를 저장하는 작업을 콜백으로 처리할 수 있었지만, 그렇게 되면 save 쿼리가 최대 7번 발생하게 되어 saveAll로 처리하는 것보다 속도가 느려졌습니다.

따라서, saveAll을 사용하기 위해 비동기 결과가 모두 완료될 때까지 join() 이나 allOf()로 기다린 후 한 번에 저장하도록 구현했습니다.

 

▶ @Async 어노테이션을 활용하지 않은 이유?

@Async는 기본적으로 Async-nonBlocking 방식으로 동작하여 콜러 스레드에게 제어권을 즉시 넘겨서 콜러가 다음 로직을 실행하게 됩니다. 하지만 저는 saveAll() 을 위해 join() 처리(Blocking)가 필요했습니다. 따라서 반환 타입을 CompletableFuture로 해야 했습니다. 만약, @Async 어노테이션을 활용했다면 CompletableFuture.supplyAsync() 가 아래 코드처럼 CompletableFuture.completedFuture() 로 변할 것입니다.

 

이렇게 될 경우, 비동기를 담당하는 CompletableFuture과 @Async 의 역할이 중복된다고 생각했기 때문에 @Async를 사용하지 않기로 했습니다.

public class ClovaService {

    @Async("clovaExecutor")
    public CompletableFuture<ClovaResponseDto> sendAsyncDailyReportRequest(...) {
        
        ...로직 생략
        return CompletableFuture.completedFuture(외부 API 호출);
    }

 

▶ CompletableFuture 를 사용하는데 ForkJoinPool 대신 ThreadPoolTaskExecutor 을 사용한 이유

CompletableFuture는 기본적으로 ForkJoinPool 의 쓰레드를 사용합니다. 그래서, 쓰레드 풀을 설정하지 않더라도 비동기로 작업을 수행할 수 있습니다. 하지만 ForkJoinPool의 쓰레드는 데몬 쓰레드로, I/O 작업이 완료되지 않더라도 JVM이 종료될 수 있습니다. 즉, I/O 작업 중 서버가 종료되고 우아한 종료는 불가하게 때문입니다. 이를 방지하기 위해 ThreadPoolTaskExecutor를 사용하여, CompletableFuture 작업이 데몬 쓰레드가 아닌 사용자 쓰레드에서 실행되도록 설정했습니다

* 이에 대해 정리한 제 글: 왜 내 CompletableFuture 는 Console 에 로그가 없는가? ForkJoinPool 의 데몬 스레드를 알아보자

 

▶ I/O 작업을 비동기로 작업 시, 타임아웃 설정은 어떻게 했는지?

먼저 allOf()를 사용하지 않은 이유는 Map을 사용하게 되면서 코드가 join() 보다 복잡해졌기 때문입니다. 그래서, join()을 stream() 내부에서 join()을 활용해 비동기 작업을 순차적으로 처리하도록 구현했습니다.

 

그러나, stream()은 본질적으로 순차적으로 연산이 진행되므로, 앞선 작업이 완료되지 않으면 뒤의 작업 결과를 받을 수 없습니다. 이를 위해 CompletableFuture 는 비동기 연산이 지정된 시간안에 끝나야하는 orTimeout() 메서드를 지원합니다.

하지만, 제 경우 비동기 작업의 지연 가능성이 외부 API 호출에 한정되었기 때문에 FeignClient 의 timeout 을 10초로 설정하여 stream() 의 순차적인 문제를 보완했습니다.

 

▶ 비동기 처리 중 예외 처리는 어떻게?

CompletableFuture에서 예외가 발생하면, exceptionally()를 통해 예외 발생 시 수행할 행동을 콜백으로 등록하여 기본값을 설정하거나 다른 예외를 던질 수 있습니다.
저는 join()을 사용했고, join() 호출 시 비동기 작업 중 예외가 발생하면 CompletionException 예외가 발생합니다. 이 예외를 @RestControllerAdvice를 활용하여 처리하였고, 다른 예외들과 함께 모듈화했습니다.

join() 의 Javadoc

 

결과: 1분 → 15초

로컬 서버 (논리 코어 16, 메모리 16)

• API 전체 응답 시간
  • 기존 동기 방식: 약 1분
  • 비동기 처리 후: 약 14초

비동기로 실행되는 7번의 외부 API 호출

로컬 서버에서 비동기 적용 후의 전체 API 응답 시간

 

QA 시 사용했던 서버 스펙은 코어 2, 메모리 8 이었습니다. 그리고, 동기 방식의 API 전체 응답 시간은 사용자당 1분 30초 ~ 2분 이상으로 걸렸는데, QA를 진행하고 추후에 업데이트 하도록 하겠습니다.

 

마치며

저는 이전에도 @Async 를 활용해 이메일 전송을 비동기로 처리한 경험이 있었습니다. 하지만, 그 때와 다른점은 고급 자바 강의를 완강을 하기 전과 후로, 현재는 쓰레드 풀을 바라보니 바라보는 시각이 조금은 넓어져서 글이 길어지고, 좀 더 다양한 상황을 고려할 수 있게 되어 즐겁게 개선한 것 같습니다. 또한, 코드스쿼드 교육 당시 비동기로 콘솔에 CompletableFuture 를 활용해 콘솔에 비동기로 카페테리아를 구현한 경험이 도움이 되어서 다행이었습니다. 그러나, 아직 CompletableFuture 가 쓰레드 풀에서 어떤 원리로 join() 하는지, 어떻게 비동기로 처리하는지 코드 레벨의 경험이 부족합니다. 앞으로도 비동기를 공부하며 보완해 나가보려 합니다. 

 

이번 프로젝트에서는 비동기로 성능을 개선했지만, Non-Blocking I/O (WebClient) 방식을 활용해 응답 시간을 줄일 수 있다고 생각이 들기도 합니다. 그래서, 추후 WebClient 를 학습하고 적용해 볼 계획입니다.

 

끝으로, 글을 읽으시면서 부족한 부분이나 개선이 필요한 점이 있다면 피드백 주시면 감사하겠습니다.

 

 

 

@Async 및 CompletableFuture 활용에 도움 주었던 참고 자료들

- 모던 자바 인 액션

- 김영한님 고급 자바 강의

- [Spring] @async 로직 실패 일대기, ThreadPoolTaskExecutor의 awaitTerminate와 Async

- [Youtube] 개발자 장고님 - 자바 비동기 따라하기 4, Spring Async

- Graceful Shutdown in Spring Boot with Sync and Async Tasks

- ThreadPoolTaskExecutor의 waitForTasksToCompleteOnShutdown 속성 알아보기

- 쓰레드 풀과 ForkJoinPool

- [Java] CompletableFuture 사용법

- 재능넷: Spring @Async와 CompletableFuture를 이용한 비동기 처리의 세계로! 

- f-lab: 스프링과 CompletableFuture를 활용한 비동기 처리 방법