[Spring] 톰캣 요청 쓰레드, 내가 조절해보자

 

 

 

📖 개요

---

여태까지 API 서버를 개발하면서 스프링부트를 가장 많이 사용해왔습니다. 병목이 발생할만큼 많은 트래픽을 고려하지 않았기 때문에 API 요청을 처리하는 톰캣 쓰레드 수를 다뤄본 적이 없습니다.

 

그래서!

 

해당 부분을 학습하고 실제로 적용한 값이 예상대로 동작하는지 확인해보려고 합니다.

목차는 다음과 같습니다.

• API 요청부터 톰캣 쓰레드가 실행하기까지
• 톰캣 쓰레드 파라미터
• 톰캣 쓰레드 조절 실습
• 마치며

 

 

 

🛞  API 요청부터 톰캣 쓰레드가 실행하기까지

---

Spring MVC로 프로젝트를 구성하면 요청을 처리하기 위해 서블릿을 사용합니다. 스프링부트로 작성했을 때 기본적으로 서블릿 컨테이너인 톰캣이 내장돼 있습니다. 바로 이 톰캣이 서블릿 컨테이너 역할을 하면서 요청 쓰레드를 생성하고 관리하는데요. 해당 쓰레드를 얼마나 미리 생성해놓을지, 최대 몇 개까지 생성할지 등 스프링 설정 파일을 통해 정할 수 있습니다.

 

각 설정 파라미터의 영향을 알아보기전에 API 요청부터 톰캣 쓰레드 실행까지의 과정을 간단하게 살펴보겠습니다.

 

클라이언트 HTTP 요청

좌측 초록색 원으로, 아직 요청이 들어오기 전입니다.

 

OS TCP 백로그 큐

TCP 연결 요청을 대기하는 포트마다 OS의 TCP 백로그 큐가 할당되는데 톰캣이 당장에 요청을 처리할 수 없다면 백로그 큐에서 대기하게 됩니다. 지정한 사이즈에 따라서 TCP 연결 요청이 큐에서 대기할 수 있고 해당 큐가 가득차면 추가적인 TCP 연결은 클라이언트 측에서 실패하게 됩니다.

 

톰캣 요청 처리 큐

톰캣은 최대 TCP 연결 요청 수를 지정하고 쓰레드 풀에 사용가능한 쓰레드가 없거나 생성하지 못할 경우 해당 큐에서 요청이 대기합니다.

 

HTTP 요청 처리 쓰레드

톰캣의 쓰레드 풀에서 생성된 쓰레드가 요청이 들어왔을 때 처리합니다. 쓰레드 풀에 쓰레드 최소 유지 개수를 지정할 수 있습니다. 또한, 모든 쓰레드가 사용중일 때 새로 쓰레드를 생성하여 요청을 처리하고 최대 생성 개수를 제한할 수 있습니다.

위 예시에서는 쓰레드 풀에서 최소 1개의 쓰레드를 유지하고 최대 2개의 쓰레드를 관리한다고 가정하겠습니다.

 

HTTP 요청(초록색 원)이 들어왔고 백로그 큐와 톰캣 요청 처리큐에서 대기하는 요청이 없기 때문에 쓰레드 풀에 있던 쓰레드(톱니바퀴)가 스프링 앱에서 요청을 처리하기 위해 애플리케이션 로직을 실행합니다.

 

첫 번째 요청이 처리되고 있는 사이에 또 다른 요청이 하나 더 들어왔습니다. 해당 요청도 마찬가지로 백로그 큐와 톰캣 요청 처리 큐에서 대기하는 요청이 없기 때문에 쭉쭉 들어옵니다. 쓰레드 풀에서 쓰레드 1개를 생성한 채로 유지하고 해당 추가 요청이 들어왔을 때 사용 가능한 쓰레드가 없을 경우 쓰레드 하나를 생성하도록 설정했기 때문에 새로 할당받아서 요청을 처리합니다.

 

첫 번째 요청과 두 번째 요청으로 인해서 요청을 처리할 수 있는 쓰레드가 모두 사용중인 상태에서 10개의 요청이 밀려옵니다. 가용한 쓰레드가 없기 때문에 우선 톰캣 요청 처리 큐에 5개의 요청이 대기하게 됩니다. 이후에 들어온 5개의 요청은 톰캣이 수용할 수 있는 대기 요청 큐가 가득 찾기 때문에 OS 레벨의 TCP 백로그 큐에서 대기하게 됩니다.

 

그 와중에 또 다른 요청들이 미친듯이 몰려옵니다. 현재 백로그 큐까지 가득찬 상태이기 때문에 클라이언트 측에서는 TCP 연결 실패를 인지하게 되고 클라이언트의 설정에 따라 재시도 혹은 실패처리를 진행합니다.

이후, 스프링에서 요청 처리를 끝낸 쓰레드가 쓰레드 풀로반납되면 톰켓 요청 처리 큐에 쌓인 녀석부터 하나씩 처리합니다.

 

 

톰캣이 관리하는 쓰레드가 요청을 처리하는 흐름을 간단하게 그림으로 확인해봤습니다.

실행 환경의 리소스(CPU, 메모리) 상황에 비해 스레드 개수를 과도하게 늘리면, 컨텍스트 스위칭 비용이 커져 성능이 급격히 저하될 수 있습니다. 반대로 너무 적게 설정하면 사용 가능한 자원이 놀게 되어 처리량이 줄어들 수 있습니다.

또한, 대기 큐(Task Queue) 크기를 지나치게 키우면, 요청이 대기하는 동안 소켓·메모리와 같은 리소스를 점유한 채로 머무르게 됩니다. 특히 HTTP Keep-Alive가 활성화되어 있다면, 의미 없이 연결이 장시간 유지되는 문제가 발생할 수 있습니다.

따라서 서비스의 API 특성과 배포 환경을 고려하여 적절한 부하 테스트를 거친 뒤 스레드 풀과 대기 큐 크기를 조정하는 것이 중요합니다.

 

 

 

⚙️ 톰캣 쓰레드 파라미터

---

앞에서 동작 흐름을 살펴봤는데 그림에서 등장한 요소들을 어떤 파라미터로 어떻게 조절하는지 알아보겠습니다.

톰캣 요청 쓰레드 관련 설정값은 스프링 프로젝트를 세팅한 후 application.properties 혹은 application.yml에 작성하여 적용할 수 있습니다.

 

server.tomcat.threads.min-spare (기본값: 10)

톰캣이 스레드 풀에 유지할 최소 스레드 수입니다.

스레드 생성 오버헤드 없이 요청이 들어오는 대로 바로 처리를 진행할 쓰레드입니다.

 

server.tomcat.threads.max (기본값: 200)

톰캣이 동시에 실행할 수 있는 최대 요청 처리 스레드 수입니다.

min-spare만큼 유지하고 있는 쓰레드가 모두 실행중일 때 쓰레드의 총 개수가 max값이 될 때까지 추가적으로 생성하여 처리할 수 있습니다. 만약 min-spare보다 max값을 더 작게 설정하다면 쓰레드 풀에는 max값만큼 쓰레드가 대기하게되고 추가 생성을 하지 않습니다.

 

server.tomcat.max-connections (기본값: 8192)

톰캣이 동시에 허용할 수 있는 최대 TCP 연결의 수입니다.

현재 실행되고 있는 쓰레드도 TCP 연결을 유지하고 있으므로 당연히 포함되고, 쓰레드를 잡지 못한 요청들은 톰캣이 관리하는 요청 큐에서 대기하게 됩니다. 큐에서 대기하는 요청들도 TCP 연결이 수립된 상태이고 대기 큐의 사이즈는 [max-connections - threads.max]가 됩니다.

 

server.tomcat.accept-count (기본값: 100)

톰캣이 OS에 요청하는 백로그 큐 사이즈입니다.

톰캣의 쓰레드가 모두 사용중이고 요청 대기 큐가 가득 찼을 때 TCP 연결이 수립된 상태로 백로그 큐에서 대기하게 됩니다.

 

 

 

🧪 톰캣 쓰레드 조절 실습

---

위에서 언급한 4개의 파라미터를 조절하면서 예상한대로 동작하는지 확인해보겠습니다.

실습환경은 다음과 같습니다.

• macOS Sequoia 15.5
  로컬환경에서 진행했습니다.
• SpringBoot 3.5.4
  간단하게 쓰레드가 5초 동안 sleep한 후 정상 응답하는 API를 작성했습니다.
• VisualVM 2.1.10
  현재 활성 쓰레드 상태를 확인하기 위해 사용했습니다.
• Jmeter 5.6.3
  설정한 값에 따라서 쓰레드가 얼만큼 사용되고 어떤 응답이 오는지 확인하기 위해 사용했습니다.

 

기본값 설정과 임의로 조정한 값으로 실습을 진행해보곘습니다.

 

기본값

server:
  port: 8080             
  tomcat:
    threads:
      max: 200           
      min-spare: 10      
    max-connections: 8192
    accept-count: 100

application.yml을 위와 같이 작성하고 실행하였습니다. 모두 기본값이며, 따로 설정하지 않아도 기본값으로 설정됩니다.

설정값에 따르면, 톰캣은 max-connections 설정에 따라 동시에 최대 8,192개의 TCP 연결을 유지할 수 있습니다. 이 중 max 값만큼 실제 요청을 처리하며, 나머지 연결은 톰캣의 요청 처리 큐(TaskQueue)에서 대기하게 됩니다. 만약 max-connections 한도까지 연결이 유지되고 있다면, 추가로 들어오는 연결은 OS 커널의 백로그 큐(accept queue)에서 accept-count 개수만큼 대기할 수 있습니다.

 

스프링 앱을 실행시키고 VisualVM에서 Threads 탭을 확인합니다.

설정한 값에 맞춰 최소 10개의 쓰레드가 대기중임을 확인할 수 있습니다.

 

테스트를 위해 jmeter에서 쓰레드 그룹을 생성하고 한 번에 100개의 쓰레드가 GET 요청을 보냅니다.

jmeter 쓰레드 입장에서 TCP 연결에 실패할 경우 즉시 실패 처리되도록 Connect timeout을 1ms로 설정하였습니다.

 

스프링부트 설정에 따라서 각 요청은 5초가 걸리는 작업이고 한 번에 200개의 쓰레드가 활성화될 수 있으니 Error 0%, 쓰레드 생성과 컨텍스트 스위칭 비용을 고려하여 Throughput 20/sec 보다 조금 작을 것으로 예상할 수 있습니다.

 

jmeter 실행결과입니다.

예상했던대로 Error 0%, Throughput 20/sec보다 작은 16.7/sec로 측정되었습니다.

 

 

임의 설정값

server:
  port: 8080             
  tomcat:
    threads:
      max: 20           
      min-spare: 5      
    max-connections: 50
    accept-count: 30

이번엔 조금 더 제한적인 값으로 설정해보겠습니다.

 

VisualVM에서 Threads 탭을 확인합니다.

설정한 값에 맞춰 최소 5개의 쓰레드가 대기중임을 확인할 수 있습니다.

 

처음과 같은 jmeter 쓰레드 그룹을 사용하여 테스트 해보겠습니다.

각 요청은 5초가 걸리는 작업이고 한 번에 20개의 쓰레드가 활성화될 수 있습니다. 또한 max 값만큼 쓰레드가 활성 상태라면 max-connections: 50에서 20개를 제외한 30개가 톰캣 요청 처리 큐에서 대기할 수 있습니다. 추가적으로 accept-count: 30만큼 대기할 수 있습니다.

한 번에 100개의 요청이 들어갔을 때 20개는 즉시 처리, 30개는 톰캣 내부 큐에 대기하여 이후 처리, 30개는 백로그 큐에서 대기후에 처리, 나머지는 20개의 요청은 jmeter 측에서 TCP 연결 실패 처리될 것으로 예상됩니다. 결과적으로 Error 20%, Throughput 5/sec 보다 작은 값이 예상됩니다.

 

jmeter 실행결과입니다.

예상했던대로 Error 20%, Throughput 5/sec보다 작은 4.9/sec로 측정되었습니다.

 

 

 

👋🏻 마치며

---

이번 기회에 쓰레드 수를 조절하는 파라미터를 이해하고 운영체제의 백로그 큐에서도 대기를 한다는 새로운 사실을 알게되었습니다.

백로그 큐의 대기 상황을 조회할 수 있는지 확인하기 위해 netstat과 watch라는 툴을 사용해봤었는데 Recv-Q에 요청별로 조회가 아닌 바이트 단위로 기록되고 있어서 명확하게 몇 개의 요청이 백로그 큐에 있는지 확인하기는 쉽지 않았습니다. 한 번의 HTTP 요청에 대한 메시지 사이즈를 정확하게 안다면 몇 개의 요청이 대기하고 있는지도 실시간으로 조회할 수 있을 것으로 보입니다.

 

읽어주셔서 감사합니다.

궁금한 점에 대한 질문 환영합니다!

부족한, 잘못된 설명이 있다면 알려주시면 감사하겠습니다 🙏🏻