Spring Boot 의 다중 유저 요청 처리 방법 (Tomcat)

1. Thread

스레드의 개념은 다음과 같다.

실행중인 한 프로그램(프로세스) 내에서 구분지어진 실행 단위

 

하나의 프로세스에서 작업을 처리하기 위한 단위로 생각하면 된다.

 

실생활 예를 들면, 은행은 은행이라는 프로세스 내에서 여러 고객의 동시 거래 요청 작업을 처리해야한다.

이때 은행이 병렬적으로 동시 거래 요청 작업을 처리하는데, 해당 작업이 이루어지는 단위가 스레드인 것이다.

 

컴퓨터의 CPU는 스레드 단위로 작업을 처리한다. CPU는 여러 스레드를 번갈아가며 실행해서 다중 작업을 처리한다. CPU를 엄청 짧은 시간으로 시분할해서 사용하기 때문에 우리 눈에는 동시에 처리되는 것처럼 보이지만, 사실은 여러 스레드를 번갈아가면서 작업을 실행하는 것이다.

 

 

 

❓ Thread가 많으면 많을수록 좋을까?

1. Thread는 생성 시 메모리를 소모한다. 

스레드가 생성되면, 해당 스레드는 실행에 필요한 메모리를 할당받는다. 따라서 생성 시 메모리를 소모하게 된다.

스레드가 많아지면 각 스레드가 차지하는 메모리가 커져서 메모리가 부족해질 수 있다.

 

 

2. Thread가 많아지면 CPU의 자원 경합이 발생할 수 있다.

스레드가 많아지면 CPU 자원을 경합하는 경우가 발생할 수 있다. 하나 이상의 스레드가 데이터를 기록하려고 할 때 다른 스레드가 해당 데이터를 읽으려고 하는 경우를 말한다. 이렇게 경합이 발생하면 애플리케이션에 예상치 못한 동작이 발생할 수 있다.

 

 

3. Thread가 많아지면 컨텍스트 스위칭 비용이 커진다.

컨텍스트 스위칭이란, CPU에서 실행중이던 스레드가 다른 스레드로 바뀌는 것을 의미한다. 스레드가 다른 스레드로 바뀌면서, 바뀐 스레드의 정보를 변경해야 하는데 이때 CPU가 해당 컨텍스트 스위칭을 수행하여 CPU의 시간을 소모한다.

 

따라서, 컨텍스트 스위칭이 일어나면 CPU의 시간을 소모하게 된다. 스레드가 많으면 많을수록 스레드 간의 전환이 빈번해질 것이고, 이에 따라서 컨텍스트 스위칭 비용이 커질 것이므로 CPU의 시간을 소모하게 되고 더 나아가서는 CPU에 오버헤드가 발생하여 성능이 저하할 수 있다.

 

 

 

 

 

 

 

 

 

 

2. Spring Boot와 Tomcat

스프링과 스프링부트의 주요한 차이점 중 하나는, 스프링 부트에선 내장 서블릿 컨테이너(Tomcat)을 지원한다는 것이다. 따라서 application.yml 파일에 설정을 주는 것만으로 간편하게 Tomcat의 설정을 바꿀 수 있다. 

 

 

아래는 서버(Tomcat)의 설정을 바꿔주는 예시이다. 

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 # 서버를 띄울 포트번호

 

만약 설정을 주지 않는다면, 디폴트값을 주입하게 된다. 해당 디폴트 값은 ServerProperties 클래스에서 확인할 수 있다. 

 

 

 

 

 

 

 

 

3. Thread Pool

스레드 풀이란

Thread Pool은 프로그램 실행에 필요한 Thread들을 미리 생성해놓는다는 개념이다.(Thread는 cpu의 자원을 이용하여 코드를 실행하는 하나의 단위임).

 

Tomcat 3.2 이전 버전에서는, 유저의 요청이 들어올 때 마다 Servlet을 실행할 Thread를 하나씩 생성했고 요청이 끝나면 destory했다고 한다.

 

하지만 모든 요청에 대해 스레드를 생성하고 소멸하는 것은 OS와 JVM에 대해 많은 부담을 안겨준다. 동시에 일정 이상의 다수 요청이 들어올 경우 리소스(CPU와 메모리 자원) 소모에 대한 억제가 어렵다. 즉 동시다발적인 요청을 처리하지 못할 가능성이 높다.

 

이런 문제를 해결하기 위해, 톰캣은 Thread Pool(스레드 풀)을 활용한다.

 

스레드풀의 기본 플로우는 다음과 같다.

• 첫 작업이 들어오면, core size만큼의 스레드를 생성
• 유저 요청(Connection, Server socket에서 accept한 소캣 객체)이 들어올 때마다 작업 큐(queue)에 담아둠
• core size의 스레드 중, 유휴상태(idle)인 스레드가 있다면 작업 큐에서 작업을 꺼내 스레드에 작업을 할당하여 작업을 처리
  • 만약 유휴상태인 스레드가 없다면, 작업은 작업 큐에서 대기
  • 그 상태가 지속되어 작업 큐가 꽉 찬다면, 스레드를 새로 생성
  • 3번과정을 반복하다 스레드 최대 사이즈 에 도달하고 작업큐도 꽉 차게 되면, 추가 요청에 대해선 connection-refused 오류를 반환
• 태스크가 완료되면 스레드는 다시 유휴상태로 돌아감.
  • 4-1. 작업큐가 비어있고 core size이상의 스레드가 생성되어있다면 스레드를 destory

 

 

스레드풀 생성 (ThreadPoolExecutor)

위에 설명한 스레드풀을 자바에서 구현한 구현체가 ThreadPoolExecutor이다. 

 

아까 위헤서 작성했던 application.yml 중 일부이다. 

server:
  tomcat:
    threads:
      max: 200 # 생성할 수 있는 thread의 총 개수
      min-spare: 10 # 항상 활성화 되어있는(idle) thread의 개수
    accept-count: 100 # 작업 큐의 사이즈
    max-connections: 8192 # 연결 가능한 connection의 수

 

threads의 두가지 설정은 스레드 최대 사이즈 및 core size를 변경할 수 있다. 

Spring Boot의 디폴트 값은 각각 200개, 10개 이다. 

 

 

accept-count는 작업큐의 사이즈이다. Tomcat 에선 아무 옵션을 안주면 Integer.MAX, 즉 21억xxx 로 설정된다. 이는 무한 대기열 전략 으로, 아무리 요청이 많이 들어와도 core size를 늘리지 않는다는 정책이다. 

 

max-connections는 동시에 서버가 요청을 처리할 수 있는 Connection 수를 의미한다. 예를 들어 Max-Connection이 10 일때 10개의 요청이 처리중이라면, block되고 작업큐에 들어가게된다. 

 

 

 

 

 

🤔 threads.max 와 max-connection의 차이는 그럼 뭘까??

몇 가지 테스트를 통해 알아보았다.

 

아래는 요청을 보내기 위한 curl 명령어들의 sh 파일이다. 

#!/bin/bash

curl --max-time 15 http://localhost:8080/test &
curl --max-time 15 http://localhost:8080/test &
curl --max-time 15 http://localhost:8080/test &
curl --max-time 15 http://localhost:8080/test &
curl --max-time 15 http://localhost:8080/test &
curl --max-time 15 http://localhost:8080/test &
curl --max-time 15 http://localhost:8080/test &
curl --max-time 15 http://localhost:8080/test &
curl --max-time 15 http://localhost:8080/test &
curl --max-time 15 http://localhost:8080/test &

 

 

Test #1  [max-connections == threads.max]

최대 커넥션 수: 10개

최대 스레드 수: 10개

로 스레드를 설정하고 10번의 요청을 보내보았다.

server:
  tomcat:
    threads:
      max: 10 # 생성할 수 있는 thread의 총 개수
      min-spare: 1 # 항상 활성화 되어있는(idle) thread의 개수
    accept-count: 30 # 작업 큐의 사이즈
    max-connections: 10 # 연결 가능한 connection의 수

 

 

결과는 1초만에 10개의 요청을 다 처리했다. 

 

 

 

 

Test #2  [max connections < thread.max]

최대 커넥션 수: 10개

최대 스레드 수: 5개

로 스레드를 설정하고 10번의 요청을 보내보았다.

server:
  tomcat:
    threads:
      max: 10 # 생성할 수 있는 thread의 총 개수
      min-spare: 1 # 항상 활성화 되어있는(idle) thread의 개수
    accept-count: 30 # 작업 큐의 사이즈
    max-connections: 5 # 연결 가능한 connection의 수

 

 

최대 스레드 수는 10개지만 1 ~ 5 까지 총 5개의 스레드만 생성되고 처리합니다.

따라서 2초에 걸처 요청을 처리했습니다.

 

 

Test #3  [max connections > thread.max]

최대 커넥션 수: 5개

최대 스레드 수: 2개

로 스레드를 설정하고 10번의 요청을 보내보았다.

server:
  tomcat:
    threads:
      max: 2 # 생성할 수 있는 thread의 총 개수
#      min-spare: 1 # 항상 활성화 되어있는(idle) thread의 개수
    accept-count: 30 # 작업 큐의 사이즈
    max-connections: 5 # 연결 가능한 connection의 수

 

 

결과는 max-connection은 5지만 2개의 스레드만 이용 가능하므로 스레드1~2 총 2개의 스레드로 5초에 걸쳐 10개의 요청을 처리했다.

 

 

 

 

 

 

 

 

4. 결론

예전에 스프링을 처음 배우기 시작할 때 강의에서 "스프링은 서버에 스레드 풀이 있고 스레드를 꺼내와 요청을 처리하고 반납한다" 라고 배운 기억이 난다.

 

그땐 스레드의 개념도 잘 모른채로 들었는데, 몇 년이 지나고 궁금해져 찾아보고 정리하게 되었다. 

이젠 톰캣이 어떻게 스레드를 관리하고, 어떻게 값을 바꿀 수 있는지 어느정도 알게 되었지만 조금 더 학습한 후에 각자의 서버에 맞게 튜닝하고 성능 개선까지 해보기엔 싶다. 

 

현재 창업 프로젝트에서 개발 중인 서비스가 있는데, 구현이 완료되고 배포를 앞둔다면 부하 테스트와 모니터링을 통해 톰캣 튜닝을 진행해보고 기록할 생각이다. 

 

 

 

배움엔 끝이 없다..!