Virtual Thread 를 사용할 경우 이점을 살펴보기 위해, 기존 Platform Thread 갯수 이상의 동시요청을 하여 동시요청이 모두 수행되는 시간을 측정 해보았습니다.
또한 수동으로 virtual thread 활성화 설정 및 동시요청 횟수 등의 변수값들을 바꿔보며 Platform Thread 갯수의 몇배의 동시 요청이 발생할 경우 Platform Thread vs Virtual Thread 간 얼마나 차이를 보이는지 확인해보신다면 좋을것 같습니다.
테스트에 사용되는 각 Rest API 들은 각 아래와 같은 간단한 흐름으로 동작합니다.
- GET - 2초간 Thread Sleep -> DB 조회 요청 -> 응답값 반환
- POST - 2초간 Thread Sleep -> DB 생성 요청 -> 응답값 반환
모두 2초간 Thread Sleep 후 간단한 DB 요청 이후 응답하는 간단한 동작이며, 여기서 Thread Sleep 을 통한 TIMED_WAITING 과 DB 요청으로 인한 BLOCKED 상태가 API 요청마다 발생하게 됩니다.
따라서 Thread 가 RUNNABLE 상태가 아닌 WATING 해야 상태에 빠져야 하지만 동시요청이 기존 Platform Thread 갯수 이상만큼 몰리는 상황에서 Platform Thread 에 비하여 Virtual Thread 를 사용했을 경우 병목이 생기지 않는것을 확인할 수 있습니다.
- 가상 스레드 활성화 - application.yml > spring:threads:virtual:enabled > true / false 로 가상스레드 / 플랫폼 스레드 방식 전환
- 동시요청 횟수 - VirtualThreadsTest.kt > requestCount > 해당 변수의 값을 변경하여 API 동시요청 횟수 조정
# 2초간 sleep 후 내장 DB에 조회 / 생성 동작을 하는 GET / POST 엔드포인트에 대한 동시요청 테스트
./gradlew test --tests "io.mango.virtualvmtest.presentation.controller.VirtualThreadsTest"동시요청 횟수를 600 으로 설정하고 가상 스레드를 사용할 경우와 플랫폼 스레드를 사용할 경우 latency 차이 입니다.
위와 같이 가상 스레드를 사용 하도록 application.yml 설정
약 3초 정도의 시간이 소요
위와 같이 플랫폼 스레드를 사용 하도록 application.yml 설정
약 6초 정도의 시간이 소요
예상 하시겠지만 플랫폼 스레드의 경우 기본값 200개의 스레드가 모두 2초간 WAITING 상태에 빠지게 되고 이후 들어온 요청은 이전 요청들이 끝나기까지 기다렸다 실행되기 때문에
600 개의 요청을 다 수행하려면 총 (동시요청 갯수 600개 / 플랫폼 스레드 갯수 200) * Thread Sleep(2초) = 6초 정도의 시간이 소요 되는것을 보실 수 있습니다.
간단한 동작을 하는 API 엔드포인트에 기존 플랫폼스레드 갯수 이상의 동시요청 테스트를 통하여 Virtual Thread 가 왜 이점이 있는지 살펴봤습니다.
물론 단편적인 예이지만 일반적인 서버 어플리케이션 에서는 거의 DB I/O 요청으로 인한 병목이 많기 때문에 Thread Block(해당 테스트는 비슷한 상황 연출을 위해 Thread Sleep(WAITING) 사용) 이 많이 발생하게 되는 상황에서 TPS 200 이상이 발생하는 서비스라면 Virtual Thread 의 사용을 고려 해보는게 좋을것 같습니다.
대게 많은 서비스들이 Spring MVC 로 구축되어 있는데, Pinning 방지와 같은 몇가지 고려사항만 주의 한다면 기존 코드 구조를 크게 바꿀일 없이 전환이 가능 하다는 점에서 Spring Webflux 로 마이그레이션 하지 않고도 위와 같은 문제상황을 해결할 수 있게 됩니다.