스프링에서 @Async를 사용할때 주의점

개요

비동기 프로그래밍은 오늘날의 소프트웨어 개발에서 매우 중요한 개념입니다. 대용량 데이터 처리, 느린 I/O 작업, 복잡한 계산 등 다양한 작업을 병렬로 처리하면서 시스템의 응답 시간을 개선하고, 리소스를 효율적으로 사용하는데 도움이 되기 때문입니다.

스프링에서는 @Async 어노테이션을 통해 이러한 비동기 메서드를 간단하게 실행할 수 있는데, 이러한 @Async 어노테이션을 사용할 때 주의해야 할 여러 가지 사항에 대해서 정리해 보겠습니다.
 

 

주의점

1. Exception Handling
2. 메서드 호출
3. 리턴 타입
4. 트랜잭션 관리
5. Execution

 

 

Exception Handling

기본적으로 @Async 메서드에서 발생하는 예외는 호출자에게 전파가 되지 않습니다. 이는 @Async 어노테이션이 붙은 메서드가 별도의 스레드에서 실행되므로 메인 스레드에서 캐치를 할 수 없기 때문입니다. 예외를 처리하기 위해서는 AsyncUncaughtExceptionHandler를 사용하여 예외를 적절히 처리해야 합니다.

AsyncConfigurerSupport를 상속받는 클래스

@Configuration
@EnableAsync
public class AsyncConfig extends AsyncConfigurerSupport {

    @Override
    public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() {
        return new MyAsyncUncaughtExceptionHandler();
    }
}

AsyncUncaughtExceptionHandler를 구현하는 클래스

public class MyAsyncUncaughtExceptionHandler implements AsyncUncaughtExceptionHandler {
    @Override
    public void handleUncaughtException(Throwable throwable, Method method, Object... obj) {
        System.out.println("Exception message - " + throwable.getMessage());
        System.out.println("Method name - " + method.getName());
        for (Object param : obj) {
            System.out.println("Parameter value - " + param);
        }
    }
}

위와 같이 AsyncConfigurerSupport를 상속받고, getAsyncUncaughtExceptionHandler()를 오버라이딩하여 사용자가 정한 예외 핸들러를 사용할 수 있습니다.
 

 

메서드 호출

@Service
public class xxxService {
    public void internalCall() {
        this.asyncMethod(); // 동기적으로 실행됨
    }
    
    @Async
    public void asyncMethod() {
        // 비동기로 처리되어야 하는 로직
    }
}

위 코드처럼 스프링에서 @Async 어노테이션이 붙은 메서드는 같은 클래스 내부에서 직접 호출할 경우, 별도의 스레드에서 실행되지 않습니다. 이는 스프링의 AOP가 프록시 기반으로 동작하기 때문입니다.

이 문제를 해결하기 위해서는 별도의 빈을 생성하거나, 다른 클래스에서 호출해야 하며 같은 클래스에서 호출하려면 아래처럼 self reference를 사용해야 합니다.

@Service
public class SelfInvocationService {
    @Autowired
    private SelfInvocationService self;

    public void method() {
        self.asyncMethod(); // self-invocation으로 비동기적으로 실행됨
    }
    
    @Async
    public void asyncMethod() {
        // 비동기로 처리되어야 하는 로직
    }
}

위 코드에서 method()는 self.asyncMethod();를 통해 비동기 메서드를 호출하고 있습니다. self는 SelfInvocationService의 인스턴스로, 스프링 컨테이너에 의해 프록시가 주입됩니다. 이렇게 되면 asyncMethod()가 비동기적으로 실행됩니다.

 

 

리턴 타입

@Async 어노테이션이 붙은 메서드는 void, Future, CompletableFuture 이 중 하나의 반환 타입을 가져야 합니다. 만약 Future를 반환하는 경우, 비동기 작업의 결과를 반환하고, 해당 작업의 완료를 대기할 수 있습니다. 아래 코드는 이를 보여주는 예시입니다.

@Service
public class AsyncService {
    @Async
    public Future<String> asyncMethodWithReturnType() {
        System.out.println("Execute method asynchronously - " + Thread.currentThread().getName());
        try {
            Thread.sleep(5000);
            return new AsyncResult<>("hello world !!!!");
        } catch (final InterruptedException e) {
            //
        }
        return null;
    }
}

위의 메서드는 비동기적으로 실행되며, 작업이 완료될 때까지 기다리지 않고 즉시 Future 객체를 반환합니다. 그리고 이 Future객체를 통해 비동기 작업의 결과를 가져올 수 있습니다.

그러나 Future나 CompletableFuture 객체를 반환받아도, 비동기 연산이 아직 완료되지 않았을 경우  반환값에 실제 값들은 담기지 않았을 수도 있습니다.

@Service
public class xxxService {
    @Autowired
    private AsyncService asyncService;

    public void method() {
        Future<String> future = asyncService.asyncMethodWithReturnType();
        String result = future.get(); // This will block
        System.out.println(result);
    }
}

해결 방법으로는, 위와 같이 Future의 get() 메서드를 통해 비동기 작업이 끝날 때까지(값이 담길 때까지) 현재 스레드를 블로킹하는 방법이 있습니다. 하지만 이는 비동기 메서드를 동기적으로 동작하게 만들어, 원래 비동기로 설계된 코드의 이점을 누리지 못하게 됩니다.

따라서 Future나 CompletableFuture의 결과를 처리할 때는 주의가 필요한데, 가능하면 non-blocking 방식으로 접근하거나, 필요할 경우 콜백을 사용하여 처리하는 것이 좋습니다. 이는 CompletableFuture의 thenApply, thenAccept 등의 메서드를 사용하여 구현할 수 있으며, 이렇게 하면 비동기 연산 결괏값이 담겼을 때 비동기적으로 결과를 처리할 수 있습니다.
 

 

트랜잭션 관리

비동기 메서드에서 트랜잭션을 사용할 때는 주의가 필요합니다. @Async 어노테이션이 붙은 메서드는 호출한 메서드와 독립적인 스레드에서 동작하기 때문에, 비동기 메서드 내에서 생성된 트랜잭션은 호출한 메서드의 트랜잭션과는 별개의 생명주기를 가집니다.

즉, 비동기 메서드 내에서 예외가 발생하여 트랜잭션이 롤백되어야 할 경우에도, 이는 해당 트랜잭션을 생성한 별도의 스레드에서 독립적으로 처리되므로, 원래의 호출 메서드의 트랜잭션에는 영향을 미치지 않습니다.

@Service
public class TransactionalService {
    @Autowired
    private AsyncService asyncService;

    @Transactional
    public void transactionalMethod() {
        asyncService.asyncMethodWithNewTransaction();
    }
}

위 코드에서, transactionalMethod()는 @Transactional 어노테이션이 붙어 트랜잭션 범위 내에서 실행되지만, asyncMethodWithNewTransaction()은 @Async 어노테이션이 붙어 새로운 스레드에서 실행되므로 별도의 트랜잭션을 생성합니다.

따라서 asyncMethodWithNewTransaction()에서 예외가 발생하여 롤백이 필요하더라도, 이는 asyncMethodWithNewTransaction()를 실행하는 별도의 스레드에서 처리되므로 transactionalMethod()의 트랜잭션에는 영향을 미치지 않습니다.

 

 

Executor 

스프링에서 비동기 작업을 수행하려면 보통 @EnableAsync 어노테이션과 @Async를 사용합니다. 그러나 이렇게 설정하면 기본적으로 SimpleAsyncTaskExecutor가 사용되는데, 이는 비동기 작업마다 새로운 스레드를 생성하는 스레드풀입니다. 이로 인해 리소스 낭비, 성능 저하, 스케일링 문제 등이 발생할 수 있습니다.

• 리소스 낭비: 각 비동기 작업마다 새로운 스레드를 생성하므로, 동시에 많은 비동기 작업이 요청되면 매번 많은 스레드가 생성된다. 따라서 CPU와 메모리 리소스의 사용량이 과도하게 증가하는 문제가 발생할 수 있다.
• 성능 저하: 스레드를 생성하고 소멸시키는 데는 많은 시간과 리소스가 소요된다. 각 작업마다 스레드를 생성하면 이런 오버헤드가 계속 발생하게 되고, 전체적인 시스템 성능에 영향을 끼칠 수 있다.
• 스케일링 문제: SimpleAsyncTaskExecutor는 스레드 수에 대한 제한이 없다. 따라서 동시에 많은 요청이 들어올 경우 스레드 수가 무한정으로 제어할 수 없는 수준으로 증가할 수 있으며, 이는 곧 OutOfMemoryError 등의 문제를 일으킬 수 있다.

이러한 이유로, 특별한 경우가 아니라면 SimpleAsyncTaskExecutor 보다는 ThreadPoolTaskExecutor 같은 제한된 리소스를 사용하는 스레드풀을 사용하는 것이 좋습니다.

ThreadPoolTaskExecutor는 Java의 ThreadPoolExecutor를 Wrapping 한 것으로, 스프링에서 제공하는 TaskExecutor 인터페이스의 구현체입니다. Executor를 정의하는 방법에는 아래의 두 가지 방법이 있습니다.

• Bean으로 정의
• AsyncConfigurerSupport를 상속받아 getAsyncExecutor()를 재정의

1. 직접 Bean으로 Executor를 정의

@Configuration
@EnableAsync
public class AsyncConfig {

    @Bean(name = "threadPoolTaskExecutor")
    public Executor getAsyncExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(2);
        executor.setMaxPoolSize(10);
        executor.setQueueCapacity(500);
        executor.setThreadNamePrefix("Executor-");
        executor.initialize();
        return executor;
    }
}

각각의 옵션 설정에 대한 설명은 다음과 같습니다.

• setCorePoolSize
  • 스레드 풀이 실행을 시작할 때 생성되는 스레드의 수를 정의하며, 스레드 풀의 기본 사이즈를 설정합니다.
  • 스레드 풀은 작업이 들어오기 시작하면 즉시 corePoolSize만큼의 스레드를 생성하고, 스레드들은 스레드 풀이 작업을 받을 때까지 대기 상태로 유지됩니다. 만약 모든 core 스레드가 작업을 처리하고 있고 추가 작업이 들어온 경우, 작업은 큐에 배치되거나 maxPoolSize까지 스레드가 추가로 생성됩니다.
• setMaxPoolSize
  • 스레드 풀이 확장될 수 있는 스레드의 상한선을 설정하며, 스레드 풀이 관리할 수 있는 최대 스레드 수를 정의합니다. 만약 corePoolSize를 초과하는 작업이 들어올 경우, 이러한 추가 작업들은 먼저 큐에 배치됩니다. 그러나 대기열이 가득 차면 스레드 풀은 maxPoolSize에 도달할 때까지 추가 스레드를 생성하여 작업을 처리합니다.
  • maxPoolSize에 도달하면 스레드 풀은 새 작업을 받아들이지 않으며, 대신 정책에 따라 거부하거나 다른 방법으로 처리합니다.
• setQueueCapacity
  • corePoolSize가 가득 찬 상태에서 추가 작업을 처리할 수 없을 때 대기하는 작업의 최대 개수를 정의하며, 스레드 풀의 작업 대기열 크기를 설정합니다.
  • 작업 대기열은 corePoolSize에 있는 스레드들이 모두 사용 중일 때 추가 작업을 임시 저장하는 공간입니다. 대기열의 크기가 꽉 차면, 스레드 풀은 maxPoolSize까지 스레드를 생성하여 대기열에 있는 작업을 처리하기 시작합니다. 대기열이 가득 차고 maxPoolSize에 도달하면 스레드 풀은 새로운 작업을 어떻게 처리할지 결정해야 하며, 일반적으로 거부 정책(RejectedExecutionHandler)을 사용하여 추가 작업을 처리합니다.
• setThreadNamePrefix
  • 생성되는 스레드의 이름 접두사를 정의합니다. 이를 통해 디버깅이나 로깅에서 어떤 스레드가 작업을 처리하고 있는지 쉽게 식별할 수 있는데, 현재 예시처럼 작성하면 각 스레드의 이름이 Executor-1, Executor-2와 같이 설정됩니다.
• initialize()
  • 스레드 풀을 초기화합니다. initialize()가 호출되면, 설정된 corePoolSize만큼의 스레드가 즉시 생성됩니다.

이렇게 설정한 후, @Async 어노테이션에 아래처럼 Executor의 Bean 이름을 인자로 전달하면 됩니다. 

@Service
public class xxxService {

    @Async("threadPoolTaskExecutor")
    public void asyncMethod() {
        // 비동기로 처리되어야 하는 로직
    }
}

이 방법은 ThreadPoolTaskExecutor를 직접 Bean으로 등록합니다. 따라서 @Async 어노테이션에 Bean 이름을 직접 지정해줄 수 있습니다. 이 방식의 장점은 여러 개의 Executor를 각각 Bean으로 등록하고, 상황에 맞게 적절한 Executor를 선택할 수 있다는 점입니다. 즉, 비동기 작업의 종류나 복잡도에 따라 다른 Executor를 사용할 수 있습니다.

 

예시

@Configuration
@EnableAsync
public class AsyncConfig {

    @Bean(name = "threadPoolTaskExecutor")
    public Executor threadPoolTaskExecutor() {
        //...
    }

    @Bean(name = "anotherExecutor")
    public Executor anotherExecutor() {
        //...
    }
}

@Service
public class xxxService {

    @Async("threadPoolTaskExecutor")
    public void asyncMethod() {
        // 로직
    }

    @Async("anotherExecutor")
    public void anotherAsyncMethod() {
        // 다른 로직
    }
}

 

2. AsyncConfigurerSupport를 상속받아 getAsyncExecutor()를 재정의

@Configuration
@EnableAsync
public class AsyncConfig extends AsyncConfigurerSupport {
    @Override
    public Executor getAsyncExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(2);
        executor.setMaxPoolSize(10);
        executor.setQueueCapacity(500);
        executor.setThreadNamePrefix("Executor-");
        executor.initialize();
        return executor;
    }
}

이 방법은 스프링의 기본 Executor를 재정의하여 사용하는 방법으로, 별도의 이름을 지정하지 않아도 됩니다. 이 방식은 전역적인 Executor 설정에 유용하며, 프로젝트 전체에서 단일 Executor를 사용하려는 경우에 적합합니다.
 

예시

@Configuration
@EnableAsync
public class AsyncConfig extends AsyncConfigurerSupport {

    @Override
    public Executor getAsyncExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        //...
        return executor;
    }
}

@Service
public class xxxService {

    @Async
    public void asyncMethod() {
        // 로직
    }
}

따라서, 어떤 방법을 선택할지는 비즈니스 로직의 요구 사항과 프로젝트의 규모에 따라 결정하면 됩니다.

 

 

결론

비동기 프로그래밍은 시스템의 성능을 향상시키는 데 매우 유용하지만, 주의해야 할 점들이 많습니다. 특히나 스프링에서 @Async 어노테이션을 사용하여 비동기 메서드를 만들 때는 위에서 말한 Execption Handling, 메서드 호출, 리턴 타입, 트랜잭션 관리, Execution 등을 적절히 고려해야 합니다. 
 

 

참고

• https://www.baeldung.com/spring-async
• 토비의 스프링 3.1