[Spring Framework] 스프링 비동기 처리 방법

✅ 1. 비동기(Asynchronous) 란?

1. 클라이언트 요청
2. 워커 스레드 클라이언트 요청 처리
3. 동작 중 비동기 로직 발견
4. 워커 스레드를 하나 더 만들어서 비동기 로직을 처리
5. 요청 처리 및 비동기 처리 스레드 두개가 돌아가게 됨.
6. 스케줄러의 의해 따로 동시의 동작을하게 됨.

• 어떤 작업을 요청한 후 그 작업의 완료 여부를 기다리지 않고 다음 작업을 바로 수행하는 방식을 의미한다.
• 보통 구현은 요청 하나 스레드에서 분기되어 동시에 다른 작업도 처리하는 과정이라고 볼 수 있음.

---

✅ 2. Spring 에서 비동기(Asynchronous) 처리

✅ @EnableAsync가 하는 일 요약 ( 애너테이션 사용시 내부 동작 )

AsyncAnnotationBeanPostProcessor 등록
→ @Async 애너테이션이 붙은 메서드를 감지해서
→ 해당 메서드를 **프록시(proxy)**로 감싸고, 비동기 실행되도록 설정

TaskExecutor (스레드 풀) 설정
→ @Async 메서드가 실행될 때 사용할 Executor를 결정함
→ TaskExecutor라는 빈이 등록되어 있으면 그것을 사용
→ 없다면, 기본 SimpleAsyncTaskExecutor를 사용 (비추천: 스레드 재사용 X)

비동기 호출 흐름 관리
→ 프록시가 @Async 메서드를 호출할 때,
→ 해당 로직을 다른 스레드에서 실행되도록 분기 처리

• 스프링에서는 기본적으로 비동기 처리를 위한 코드를 제공을 해준다.
• @EnableAsync 애너테이션 설정을 하게 되면, 스프링 내부적으로 비동기 처리에 필요한 핵심 구성요소들을 자동으로 빈으로 등록하고 활성화를 해준다.
• 정의해둔 @Async 애너테이션이 호출이 될 때 마다 해당 메서드를 비동기로 처리를 해준다.
• 즉, 스레드를 새로 만들어서 처리를 해준다는 의미이다.

@Configuration
@EnableAsync
public class AsyncConfig {
    @Bean
    public Executor taskExecutor() { // 스레드 풀 직접 정의하는 메서드
        // 스프링에서 제공하는 스레드 풀 구현체
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(5); // 항상 유지되는 최소 스레드 수
        executor.setMaxPoolSize(10); // 최대 스레드 수 제한
        executor.setQueueCapacity(100); // 비동기 작업 요청 대기 큐 크기
        executor.setThreadNamePrefix("AsyncExecutor-"); // 스레드 이름 prefix 지정
        executor.initialize(); // 스레드 풀 초기화 메서드
        return executor;
    }
}

• Async 설정 파일은 보통 위의 코드와 같이 설정을 하게 된다. 해당 설정 Bean 은 @Async 에서 사용할 스레드 풀(TaskExecutor) 을 직접 정의하는 곳이다.
• setXorePoolSize(5) 메서드는 항상 유지되는 최소 스레드 수를 set 할 수 있는 setter 이다. 쉽게말해, 비동기 작업이 없어도 5개의 스레드를 기본적으로 유지하며, 처음엔 여기까지의 스레드 수만큼만 생성이 된다는 의미이다.
• setMaxPoolSize(10) 메서드는 최대 스레드 수 제한을 의미하며, 큐가 가득 차고 더 많은 요청이 들어오면, corePoolSize 이상으로도 스레드를 확장해서 처리를 한다. 하지만 이것도 최대는 기재해둔 것 까지 가능하다.
• setQueueCapaciry(100) 메서드는 비동기 작업 요청이 들어올 때 대기 할 수 있는 큐의 크기를 의미한다. corePoolSize 만큼 스레드가 다 찼을 때는 이 큐에 작업을 넣어서 대기를 시킨다. 쉽게말해, 기존 스레드의 사용이 다 되고 반납이 되면 여기서 꺼내다가 쓴다는 의미이다. 만약 큐가 꽉차서 한계에 도달하게 되면 이후의 저장은 RejectedExecutionException 예외가 발생하게 된다. 이렇게 되면, 요청을 보냿지만, 아무 일도 안 일어나는 현상이 발생 할 수 있음. 즉, 요청이 증발 할 수 있음.
• initialize() 해당 메서드는 스레드 풀을 초기화하는 메서드로 반드시 호출해야 실제로 사용이 가능하다.

(1) 이후의 흐름 요약 

1	클라이언트가 HTTP 요청
2	Controller → Service 계층에서 @Async 메서드 호출
3	Spring이 taskExecutor()로 정의된 스레드 풀에서 워커 스레드 꺼냄
4	비동기 메서드는 이 워커 스레드에서 실행됨
5	기존 요청 스레드는 바로 클라이언트에게 응답

 

(2) Async 실행 순서

🔁 @Async의 실행 순서 (요약)
1. 사용자가 비동기 메서드 호출
2. corePoolSize 만큼 스레드로 실행 (즉시 처리)
3. 그 이상은 queueCapacity만큼 큐에 저장 (대기 상태)
4. 큐도 꽉 차면 → maxPoolSize만큼 스레드를 추가 생성
5. 모든 한계 다 찼을 때 → RejectedExecutionException 발생

---

✅ 3. Async 메모리 기반 Queue의 휘발성 및 작업 누락 문제

• @Async 가 사용하는 ThreadPoolTaskExecutor 내부에는 작업을 보관하는 큐(Queue) 가 존재함.
• 이 큐는 자바 애플리케이션 메모리 안에서만 유지되는 자료구조이다 보니, JVM 프로세스가 종료되거나 재시작 되면 큐 안에 있던 작업 정보가 모두 사라질 수 있다. 즉, 메모리 문제, 서버 장애, 재배포 시에 비동기 작업이 날아갈 위험이 있다는 의미이다.
• 이렇게 된다면 클라이언트의 중요한 요청이 날라가는 문제가 발생 할 수 있게 된다.

(1) 이게 문제인 이유

• 비동기 작업에는 주로 중요한 작업인 이메일 전송, 알림, 결제 후처리 등을 처리 하는데 사용을 하는데, 이 작업이 누락되면 서비스 신뢰성에 직접적인 악영향을 주기 때문이다.

---

✅ 4. Queue의 휘발성 및 작업 누락 문제 해결 방안

(1) 스레드풀 모니터링

• 큐 사이즈를 너무 작게 하면 요청 한계를 벗어날 때 RejectedExecutionException 발생
• 큐 사이즈를 너무 크게 설정하면 메모리 사용량 증가, 작업 지연 가능성이 증가함.
• ThreadPoolWaskExecutor 의 큐 크기, 활성 스레드 수, 완료 작업 수 등 현재 상태를 Spring 의 Actuator 나 JMX, Prometheus + Grafana 같은 실시간 모니터링 도구를 활용해서 모니터링을 할 수 있다.
• 이러한 실시간 모니터링을 통해 큐가 사용자의 증가로 인해 큐가 가득차는 현상을 발견 할 수 있으며, 스레드 수를 늘리거나 서버 자원을 추가함으로써 문제를 해결 할 수 있다.
• 즉, 해결을 위해서는 로그나 모니터링을 통해 큐 크기를 적절한 수준으로 설정하거나 튜닝하는 것이 좋음.

(2) 거절 정책(RejectedExecutionHandler) 설정

• 작업 요청이 너무 많아 큐와 스레드가 다 찼을 때 로그를 남기고 버리는 정책 등 적절한 방어 로직을 두는 방식이다.
• 하지만, 이 방식은 근본적인 문제 해결이라기 보단 증상 완화나 임시 대응에 가까운 방식이다.

(3) MQ(Message Queue) 사용

• MQ 는 비동기 작업이 생성이 되면 해당 작업을 메시지로 보고, Queue 에 저장을 하는 방식이다.
• 해당 MQ 의 종류는 대표적으로 RabbitMQ, Kafka 두 가지가 있다.
• 두 MQ 는 메시지를 디스크 기반 큐에 저장을 하기 때문에, 기존 인메모리 비동기 작업이 사라지는 문제를 해결해준다.
• 메시지가 디스크에 저장되어 서버 장애에도 작업 손실이 없는 내구성을 보장한다.
• 소비자 수 조절로 부하 분산 및 스케일 아웃이 가능 즉, 처리량 조절이 가능하다는 의미이다.
• 외부에 분리된 큐 시스템으로 안정적이고 유연한 비동기 처리를 가능하게 도와줌.
• 실패한 메시지를 별도 큐로 보내 재처리 가능하게 도와줌.
• 여러 서버가 메시지를 나눠 처리가 가능함. 즉, 분산 환경을 지원해준다는 의미임. 매우 좋은 장점인듯..

---

✅ 5. 정리

• @Async는 내부적으로 스레드풀(ThreadPoolTaskExecutor) 을 이용해 비동기 작업을 실행한다.
• 간단하고 작은 규모 내부 비동기 작업이라면 @Async 가 빠르고 간편하지만 안정성, 확장성, 분산처리가 필요하거나 장애 시에도 메시지 유실을 막아야 한다면 MQ를 사용하는게 훨씬 낫다고 판단이 됨.