Thread Pool에 대해서(with Tomcat, Spring Boot)

Thread

Process의 작업은 Thread 단위로 나눌 수 있다. 그리고 CPU Core가 Thread 단위로 작업을 처리하게 된다.
결론적으로 Thread는 CPU Core의 실행 단위이다.

 

Thread를 사용함으로서 하나의 Process에서 두 가지 이상의 작업을 동시에 실행 가능하게 된다.

 

Thread를 단순하게 사용할 때 문제점

새로운 요청이 들어올 때마다 새로운 Thread를 생성한다고 가정하고 문제점을 생각해보자.

생성 비용이 큰 Thread

Thread는 생성 비용이 크다. 따라서 해당 방식으로는 요청에 대한 응답시간이 늘어날 수 밖에 없다.

아래 그림을 보면서 더 자세하게 알아보자.

• Java는 One-to-One Threading-Model로 Thread를 생성한다.
• User Thread(Process의 스레드) 생성시 OS Thread(OS 레벨의 스레드)와 연결한다.
• 새로운 Thread를 생성할 때 마다 OS Kernel의 작업이 필요하다.
• Thread는 생성 비용이 크다.
• 작업 요청이 들어올 때 마다 Thread를 생성하면 최종적인 요청 처리 시간이 증가한다.

 

Thread가 너무 많으면 여러 복합적인 문제 발생

만약 Process의 처리 속도보다 빠르게 요청이 들어오면 새로운 Thread가 무제한적으로 계속 생성될 것이다.
그리고 Thread가 많아 질수록 메모리를 많이 차지하고 Context-Switching이 더 자주 발생한다.
이러한 문제 때문에 메모리 문제가 발생하거나 CPU 오버헤드가 발생할 수 있다.

 

Thread Pool로 문제를 해결해보자

Thread Pool이란 Thread를 허용된 개수 안에서 사용하도록 제한하는 시스템이다.

한번 사용된 Thread는 작업이 끝나고 없어지지 않고 재사용이 가능하다는 특징이 있다.

 

 

스레드 풀은 크게 스레드, 작업 큐 두가지로 이루어져 있다.

간단하게 작업 흐름을 보자.

1. 스레드풀에 작업 처리를 요청
2. 작업 큐에 offer
3. 작업 큐에서 poll하여 각 스레드로 작업을 보내고, 스레드는 작업을 처리함
4. 결과 전달

출처 :nbsp; https://www.baeldung.com/thread-pool-java-and-guava

 

그래서 Thread Pool이 앞서 말했던 단순하게 Thread를 이용했을 때의 문제를 어떻게 해결하는지 알아보자.

 

1. 작업 요청이 들어올 때마다 Thread를 생성함으로써 최종 요청 처리 시간이 증가한다는 문제

-> ✅ 해결: 미리 만들어 둔 Thread를 재사용할 수 있기 때문에 새로운 Thread를 생성하는 비용을 줄일 수 있다.

 

2. 메모리 문제가 발생하거나 CPU 오버헤드가 발생하는 문제

-> ✅ 해결: 사용할 Thread 개수를 제한하기 때문에 무제한적으로 스레드가 생성되지 않으므로 방지 가능하다.

 

따라서, 여러개의 작업을 동시에 처리하면서 안정적으로 처리하고 싶을 때 Thread Pool이 효과적이다.

 

Java의 Thread Pool의 구성

Java는 ThreadPoolExecutor 클래스를 이용해서 Thread Pool을 구현하고 있다.

maximumPoolSize, keepAliveTime, corePoolSize 세가지 특징이 있다.

 

Thread Pool에는 항상 maximumPoolSize값의 최대 개수로 Thread를 만들어 두지 않는다. 왜냐하면 요청이 적을 때는 많은 양의 쓰레드를 가지고 있을 필요가 없기 때문이다.

이를 최적화하는 기능이 들어있다.

 

⭐️ 만약 작업이 없는데 스레드 개수가 최대로 있고 keepAliveTime 이후로도 계속 요청이 없으면 작업 Queue에도 작업이 없는 것이므로 스레드를 corePoolSize 까지만 없앤다.

이러한 Thread Pool이 어울릴 만한 곳은 Web Server를 예로 들 수 있다.

 

Thread Pool을 사용하는 Web Server

동시적인 요청을 동시적으로 처리해야 하므로 많은 웹 서버들이 Thread Pool을 사용한다.

SpringBoot의 내장 Servlet Container 중 하나인 Tomcat을 웹 서버 예시로 들 수 있다.

Tomcat은 Java 기반의 WAS 로서 Java의 Thread Pool 클래스와 매우 유사한 자체 Thread Pool 구현체를 가지고 있다.

 

MaxConnection

MaxConnection은 Tomcat이 최대로 동시에 처리할 수 있는 Connection 개수를 의미한다. 
Web 요청이 들어오면 Tomcat의 Connector가 Connection을 생성하면서 클라이언트와 커넥션을 연결하게 되는데, 그때 요청된 작업을 Thread Pool에 연결한다. 이때 동시에 커넥션을 연결해서 처리할 수 있는 커넥션의 개수가 MaxConnections이다.

 

AcceptCount

Max-Connections 이상의 요청이 들어왔을 때 사용하는 대기열 Queue의 사이즈를 의미한다.
MAX-Connections와 Accept-Count 이상의 요청이 들어왔을 때 추가적으로 들어오는 요청은 거절될 수 있다.

 

SpringBoot 설정으로 Tomcat Thread Pool 설정

# application.yml (적어놓은 값은 default)
server:
  tomcat:
    threads:
      max: 200 # 생성할 수 있는 thread의 총 개수
      min-spare: 10 # 항상 활성화 되어있는(idle) thread의 개수
    max-connections: 8192 # 수립가능한 connection의 총 개수
    accept-count: 100 # 작업큐의 사이즈
    connection-timeout: 20000 # timeout 판단 기준 시간, 20초
  port: 8080 # 서버를 띄울 포트번호

SpringBoot에서 내장 톰캣 Thread Pool에 대한 설정을 할 수 있다.

 

server.tomcat.threads.max

Thread Pool에서 사용할 최대 스레드 개수이고 기본 값은 200이다.

서버 애플리케이션이 동시에 처리할 수 있는 요청 개수와 관련되어 있다.

요청 수에 비해 너무 많게 설정하면 -> 놀고 있는 스레드가 많아져서 비효율이 발생한다.

너무 적게 설정하면 -> 동시 처리 요청수가 줄어들어 평균응답시간과 TPS가 감소한다.

 

기본적으로 Thread가 많아질수록 CPU 오버헤드와 메모리에서 문제가 생길 수 있다는 것을 고려해야 한다.

 

server.tomcat.threads.min-spare

Thread Pool에서 최소한으로 유지할 Thread 개수, 기본 값은 10이다.

너무 많이 설정하면 -> Thread Pool이 항상 유지해야 할 Thread 수가 너무 많아진다.

적절하게 설정하면 -> 적은 수의 요청에서 새로운 스레드를 만들 필요없이 요청을 효과적으로 처리할 수 있다.

 

잘못 설정했을 경우 사용하지 않는 Thread가 메모리를 차지하면서 비효율을 발생시킨다는 것을 고려해야 한다.

 

server.tomcat.max-connections

동시에 처리할 수 있는 최대 Connection의 개수, 기본 값은 8192이다.

사실상 서버의 실질적인 동시 요청 처리 개수라고 생각할 수 있다.

 

이 부분에서 Tomcat의 Connector 컴포넌트의 작업 방식에 따라 달라질 수 있다.

Blocking I/O 방식에서는 커넥션 하나가 하나의 Thread와 연결되어 작업한다. 따라서, 이 방식에서는 MaxThreadSize와 MaxConnection 개수가 항상 같아야 한다. Tomcat 7 버전까지 적용된 방식이다.

✅ Non-Blocking I/O 방식에서는 Thread 하나에 커넥션이 여러개 연결되어 동시적으로 작업을 처리할 수 있다. MaxThreadSize보다 MaxConnection이 더 많아도 된다. 해당 방식의 경우 Tomcat 8 버전 이후부터 적용되어 있다.

하나의 Thread에 여러가지 커넥션을 연결하여 작업할 수 있으므로 "MaxConnectionSize < = MaxThreadSize" 상황에 비효율이 발생할 수 있다.

 

server.tomcat.accept-count

max-connections 이상의 요청이 들어왔을 때 사용하는 요청 대기열 Queue의 사이즈, 기본 값은 100이다.

너무 크게 설정하면 -> 대기열이 커지면서 메모리 문제를 유발할 수 있다.

너무 작게 설정하면 -> 요청이 몰렸을 때 들어오는 요청들을 거절해 버릴 수 있다.

이 설정을 하는 이유중 하나는 부적절하거나 잘못된 요청이 한번에 너무 많이 들어와 서버에 장애를 발생시키는 것을 방지하기 위함도 있다.

 

결론

Thread Pool은 응답시간과 TPS에 영향을 주는 하나의 요소이다.

따라서, 잘 조정된 Thread Pool은 시스템의 성능을 끌어내고 안정적인 애플리케이션 운용을 가능하게 한다.

부적절하게 설정된 Thread Pool은 병목 현상, CPU 오버헤드, 메모리 문제를 유발할 수 있다.