[Java] 가상 스레드 (Virtual Thread) 훑어보기

Java의 Thread를 보면 늘상 고민이었던 부분이 있었습니다. Java의 Thread API는 운영체제의 스레드와 1:1로 매핑되어 있어 쓸 때마다 컨텍스트 스위칭으로 인한 비용 문제가 걸림돌이고, 서버를 개발하는 입장에서 대용량 트래픽의 발생을 고려해야 한다면 스케일 아웃을 해야할지 리액티브 프로그래밍(Reactive Programming)을 해야할지 선택의 고민에 휩싸이게 됩니다.

 

개발자 입장에서 가장 쉽게 생각한다면 스케일 아웃일 것입니다. 요새는 쿠버네티스(k8s)와 같은 컨테이너 오케스트레이션 시스템 내지 클라우드에서 오토 스케일링 기능을 잘 지원하고 있어 트래픽이 대량으로 발생해도 자동으로 스케일 아웃하여 트래픽 발생을 조절해주니 가장 편한 방법이지요. 하지만 이는 여전히 내가 운영하는 서비스의 하드웨어를 적절히 사용하지 못한다는 문제가 남아 있게 됩니다. 

 

그러면 리액티브 프로그래밍은 어떨까? 리액티브 프로그래밍은 Thread가 가진 한 요청당 한 스레드(Thread per request) 문제를 해결하는 요소긴 하지만 그를 위해서는 여러 가지 고민해야 할 부분이 많이 있습니다.

 

• 함수 색 문제 (Colored Function Problem)
• 복잡한 코드 스타일
• 기존 스타일과 다른 프로그래밍 테크닉

한 번 쯤 리액티브 프로그래밍을 해봤다면 아시겠지만 리액티브 프로그래밍을 하려면 기존의 스레드 스타일과는 다른 프로그래밍 문법을 사용해야 하고, 내가 사용하는 라이브러리가 리액티브하게 동작하는 함수들이어야 하며 그렇지 않으면 이를 리액티브 스타일로 리팩토링하여 사용하는 등의 번거로움이 많아집니다. 

 

뿐만 아니라 리액티브 프로그래밍은 기존의 자바 스레드 스타일처럼 순차적인 프로그래밍 테크닉을 사용하지 않고, 체인을 이용하여 이리저리 비동기 처리하고, 보내고, 하는 등의 작업을 반복하게 되기 때문에 리액티브 프로그래밍을 처음한다면 그만큼 배워야하는 기술이 많아지고 코드 정리도 어려워집니다.

 

 

 

Virtual Thread

그러던 중 저는 OpenJDK 내에서 진행되는 동시성 처리 관련 프로젝트를 보게 되었습니다. 이름은 Project Loom이었고, JDK 19에서 처음 등장하여 구조적 동시성, 가상 스레드, 지정 범위 값이라는 세 가지 개선 방안을 제안합니다.

 

Project Loom

기존의 Thread API가 운영체제의 스레드를 그대로 사용하는 것에 대해 현대 프로그래밍적으로 리소스가 많이 소모된다 판단하여 최적화 진행을 위해 시작된 Java 내 프로젝트로 Java 21 버전에서 가상 스레드 구현체가 최초로 등장함.

 

Java 21이 등장한 지금, 가상 스레드는 Preview가 아닌 공식 기능으로 등장하게 됩니다. 가상 스레드는 위에서 언급했다시피 기존의 스레드의 성능을 개선하기 위한 자바의 새로운 API이며 이 기능의 목적은 다음과 같습니다.

 

• 요청당 스레드 한 개를 사용하는 서버 애플리케이션 최적화
• 기존 Thread API를 최소한의 변경만으로 마이그레이션
• 기존 JDK 도구로 가상 스레드 디버깅, 프로파일링 가능

위 목적은 JEP425: Virtual Threads 에서 참고하였으며 이를 보아 가상 스레드는 요청 한 개당 스레드 하나를 사용하는 기존 Thread API를 대체하기 위해 고안한 것으로 이벤트 루프를 사용한 비동기 프로그래밍 언어에 대응하기 위해 나온 것으로 보입니다.

 

그렇다면 기존 Thread와 Virtual Thread는 어떠한 차이가 있는 것일까요?

 

 

 

Virtual Thread vs Platform Thread

Java 21에서는 스레드 개념이 두 가지 등장하면서 기존의 스레드를 플랫폼 스레드(Platform Thread), 가상 스레드(Virtual Thread)로 명명하였습니다. 따라서 이 글에서도 가상 스레드와 플랫폼 스레드라는 용어로 구분하여 사용할 것이며 비교를 위해 먼저 플랫폼 스레드가 어떻게 동작했는지 보도록 하겠습니다.

 

 

플랫폼 스레드는 TaskExecutor 인터페이스를 사용하여 스레드 풀(Thread Pool)을 사용하여 사용한다고 가정했을 때 하나의 태스크당 하나의 스레드를 할당하여 작업하게 됩니다. 아시다시피 플랫폼 스레드는 기존의 Thread API로, 운영체제 스레드를 그대로 사용하기 때문에 많은 비용이 발생합니다.

 

 

가상 스레드에서는 이를 개선하기 위해 플랫폼 스레드를 캐리어 스레드(Carrier Thread)로 정의하여 내부적으로 사용하는 단일 플랫폼 스레드와 그 용어를 분리했습니다. 따라서 VirtualThreadBuilder 객체가 작업을 받았을 때 가상 스레드 객체를 생성하고, 해당 스레드가 가지고 있는 작업은 ForkJoinPool이라는 캐리어 스레드 풀이 받아 각 캐리어 스레드에 할당하는 방식입니다.

 

ForkJoinPool

ExecutorService처럼 Thread Pool을 생성하여 여러 작업을 병렬 처리해주도록 하는 객체로 ExecutorService와는 달리, Task 크기에 따라 분할(Fork)하여 해당 Task의 마지막 부분이 처리되면 이를 합쳐(Join) 리턴하는 분할 정복 알고리즘으로 동작함 가상 스레드 스케줄링을 위해 사용하는 ForkJoinPool은 기존 ForkJoinPool과 약간 다른 형태를 지니고 있음

 

 

이 때 중요한 건 캐리어 스레드는 플랫폼 스레드에서 I/O Blocking 된 작업을 큐에 쌓아 우선순위대로 작업한다는 특징을 가지고 있다는 점입니다. 캐리어 스레드별로 각 리소스에 따라 3~4개 정도 부여하여 플랫폼 스레드 사용 비율과 컨텍스트 스위칭 비용을 낮추면서 성능을 개선합니다.

 

많은 작업을 큐에 넣을 수 없기 때문에 많은 지연시간이 발생하는 곳에서는 오히려 플랫폼 스레드를 사용하는 것보다 성능을 저하시키는 역효과를 내기 때문에 아래의 상황에서는 오히려 좋지 않습니다.

 

• 처리 시간이 오래 걸리는 작업(대용량 데이터 처리)에는 플랫폼 스레드 사용이 적절
• Java Stream API를 대체하고자 하는 작업이 아니므로 해당 코드가 포함된 작업은 플랫폼 스레드 사용이 적절

 

캐리어 스레드에 포함된 작업 큐에 대해 좀 더 설명하자면 해당 작업들은 FIFO 방식으로 스케줄링하며 JVM 내에서 가상 스레드의 갯수는 플랫폼 스레드처럼 제한을 두지 않습니다. 그 이유는 가상 스레드의 생성 비용(1KB)이 플랫폼 스레드 생성 비용(1MB)에 비해 현저히 낮기 때문입니다.

 

가상 스레드 스케줄링을 위한 캐리어 스레드 갯수 관리는 아래의 JVM 파라미터를 통해 관리됩니다.

 

• jdk.virtualThreadScheduler.parallelism
• jdk.virtualThreadScheduler.maxPoolSize
• jdk.virtualThreadScheduler.minRunnable

 

parallelism은 동시 처리 갯수를 의미하며 기본값으로 기기의 최대 가용 코어 갯수를 사용합니다. 이렇게 하면 여러 개의 스레드를 동시에 실행할 수 있는 갯수를 정하게 됩니다. 

 

maxPoolSize는 최대 캐리어 스레드 풀 갯수를 말하며 기본값은 max(parallelism, 256)입니다. 

 

minRunnable은 최소 실행 가능한 갯수를 말하며 기본값은 max(parallelism / 2, 1)입니다. 보편적으로 코어 갯수의 절반 정도를 최소 단위로 실행합니다.

 

 

 

Virtual Thread Scheduling

가상 스레드는 어떻게 I/O blocking 상태를 제어하는 걸까요? 위 글을 살펴봤을 때 스케줄러가 각 작업을 캐리어 스레드로 전달하여 수행한다면 그들이 I/O blocking 상태인지를 가상 스레드나 작업을 통해서 알 수 있어야 할 것입니다. 이번에는 가상 스레드가 어떤식으로 작업을 제어하는지에 대해 알아보겠습니다.

 

 

가상 스레드도 여타 스레드와 마찬가지로 JVM의 힙(Heap) 영역에 저장됩니다. 힙영역에 저장되었을 때는 작업이 진행 중인 상태로 진행 중에 사용한 함수 호출 정보, 변수 정보 등이 여기에 담기게 되고, I/O blocking이 발생하면 이들은 작업했던 스택 프레임(stack frames)을 별도의 힙 영역에 임시로 복사해뒀다가 캐리어 스레드가 다른 작업 수행시 사용할 수 있도록 합니다. 이러한 작업을 Mount/Unmount 작업이라 합니다. 

 

• Mount: 가상 스레드 내 작업이 캐리어 스레드에서 실행 중인 경우
• Unmount: 가상 스레드 내 작업이 I/O blocking 등 상태로 캐리어 스레드에서 잠시 중단된 경우

이러한 작업이 수행되는 동안 가상 스레드는 상태가 변경되는데, 대표적으로 가상 스레드 작업이 I/O blocking 등에 의해 일시 정지된 경우, PARKED 상태로 전환됩니다.

 

위 코드는 VirtualThread 클래스에서 가져온 실제 가상 스레드가 사용하는 상태값들입니다. NEW ~ PARKED_SUSPEND까지 여러 종류가 있으며 그 중 자주 보이는 상태값은 RUNNABLE, RUNNING, PARKED, PINNED가 있습니다. 이를 통하여 가상 스레드가 생성되어 작업이 종료될 때까지를 일련의 과정으로 보자면 다음과 같습니다.

 

• 하나의 작업을 가상 스레드로 생성 후 캐리어 스레드에 mount 
• 해당 요청 작업에 I/O blocking이 발생하는 경우 스택 프레임을 생성하고 캐리어 스레드에서 unmount
• 위 작업이 RUNNABLE 되는 동안 다른 작업(가상 스레드) 실행
• RUNNABLE 상태가 되면 continue execution 메서드에 나머지 작업 실행
• 작업 종료

위 과정은 가상 스레드를 이용하여 수행한 작업이 성공적으로 수행하여 종료된 경우의 과정입니다. 하지만 스레드 작업 중 도중에 실패하는 경우에는 어떻게 될까요? 

 

 

 

Pinning

가상 스레드가 캐리어 스레드에서 unmount 되지 못하고 있는 상태값이 있습니다. 이를 PINNED 로 정의하였는데, 가령 가상 스레드가 blocking 메서드 호출로 인해 PARKING 상태가 되면 캐리어 스레드는 해당 작업에 대한 스택 프레임을 힙 영역에 저장해놓고 다른 작업을 하는 게 정상적인 방향이지만 이 작업이 제대로 이뤄지지 않는 경우 PINNED 상태가 되며 이를 피닝(PINNING)이라 합니다.

 

그렇다면 피닝은 어떠한 경우에 발생할까요?

 

• 코드 내 synchronized 블록 사용 및 메서드 호출
• native 메서드 혹은 Java 외부 함수(Java 외 다른 언어로 구현된 함수)를 호출

만약 플랫폼 스레드를 사용하여 동시성 처리를 구현했다면 고려해야 할 부분 중에 하나는 하나의 자원을 두고 두 스레드가 동시에 사용하는 경쟁 문제입니다. 이를 위해 Java에서 synchronized 블록을 사용하는 방법이 있습니다. 

 

코드를 예시로 들면 위와 같은 코드를 말하는데, 두 스레드가 서로 업데이트를 함으로써 업데이트 순번이 뒤엉키는 문제가 발생하기 때문에 synchronized 메서드로 업데이트하도록 구현한 예시입니다.

 

하지만 가상 스레드에서는 이러한 메서드를 호출하면 가상 스레드에서 blocking이 발생하는 것이 아닌 캐리어 스레드에서 blocking이 발생하기 때문에 자칫하면 가상 스레드 스케줄러에서 해당 캐리어 스레드를 관리하지 못하게 되는 현상이 발생합니다. 이는 곧 성능 저하로 이어지죠.

 

이럴 때는 동기 블록/메서드를 호출하기보다는 ReentrantLock과 같은 세마포어를 이용하여 캐리어 스레드를 blocking하지 않고 가상 스레드를 PARKED로 유도하는 것을 권장합니다. 이 문제는 버그에 해당하며 Java 21에도 계속 존재하지만 차기 버전에서 이를 수정한다고 합니다.

 

또한 Java에서 C/C++ 계열의 코드를 사용하기 위해 JNI(Java Native Interface)를 이용하는데, 이를 통해 함수를 호출할 때도 피닝이 발생합니다. 다만 JNI에서도 isVirtualThread 메서드를 지원하여 호출하려는 스레드가 플랫폼 스레드인지, 가상 스레드인지에 대한 값을 내려주므로 이를 통해서 개선할 수는 있어 보입니다.

 

 

 

Thread Pooling

플랫폼 스레드를 사용할 때는 그 생성 비용이 크기 때문에 스레드를 미리 생성하여 사용할 때마다 빼서 쓰기 위해 풀링(Pooling)을 사용했었습니다. 그렇다면 가상 스레드도 풀링할 수 있을까요?

 

Java 엔지니어들은 가상 스레드를 풀링하지마라(Don't pool virtual threads!)고 합니다. 풀링은 운영체제 스레드와 같은 고가의 비용이 들어가는 곳에서 사용하기 위해 고안된 것인데, 가상 스레드는 그 리소스의 1/10 정도 밖에 되지 않으므로 풀링하지 않아도 된다는 것입니다.

 

하지만 특정 메서드에 사용하는 가상 스레드 갯수를 제한하는 걸 목적으로 하고 있다면 스레드 풀 대신 세마포어 기법으로 접근해 볼 수 있습니다.

 

플랫폼 스레드에서는 위와 같이 ExecutorService의 구현체인 newFixedThreadPool 매개변수로 스레드 갯수를 받아 스레드를 미리 생성하여 상요할 수 있었습니다.

 

피닝 이슈와 마찬가지로 세마포어 기법을 이용하여 특정 메서드에서 가상 스레드 생성 수를 제한해 볼 수 있습니다. 위 코드는 제한된 세마포어를 생성해놓고, 호출마다 카운팅을 하며 호출이 완료되면 다시 그 카운팅을 복구하는 방식입니다.

 

 

 

Scoped Value

가상 스레드에서도 플랫폼 스레드와 마찬가지로 ThreadLocal 변수가 존재합니다. 자바에서 제공하는 스레드 로컬 변수에는 ThreadLocal과 InheritableThreadLocal을 사용할 수 있는데, 가상 스레드는 공식적인 스레드 풀링을 지원하지 않기 때문에 하드웨어 리소스만큼 최대한의 가상 스레드를 사용하게 됩니다. (원하면 1,000,000개 이상까지도...) 

 

하지만 이럴 경우 수많은 가상 스레드들이 공유된 리소스에 접근하기 위해 계속 대기하게 되는데, 만약 InheritableThreadLocal과 같이 비용이 비싼 리소스의 풀링을 수행하게 되면 가상 스레드가 차지하는 메모리의 크기가 더 커지게 됩니다.

 

이러한 문제 때문에 Java 20에서는 JEP 429: Scoped Values (Incubator) 가 고안되었으며 가상 스레드 내 혹은 가상 스레드 간에 공유할 수 있는 불변 데이터 클래스를 통해 ThreadLocal이 가진 문제를 해결하고자 했습니다. 하지만 ThreadLocal을 100% 대체하기 위한 것은 아닙니다.

 

코드 자체에는 큰 차이가 없지만 ThreadLocal은 가변성, ScopedValue는 불변성이라는 점에 차이가 있습니다. 또한 ThreadLocal은 컨테이너 수명과 동일하게 가져가서 remove 메서드를 명시적으로 호출하거나, 새로운 값을 설정하는 방법으로 그 수명을 갱신하지만 ScopedValue는 현재 사용 중인 스레드 수명을 따라가고, 메서드로 값을 할당하지 않고 스코프로 할당한다는 점에서 Python의 yield와 약간 유사합니다.

 

 

 

마치며..

이번 포스트에서는 가상 스레드를 간단하게 보다는 좀 더 깊게 헤짚어보면서 가상 스레드를 사용하기 위해 반드시 알아야 할 부분에 대해 중점적으로 다뤄봤습니다.

 

자바에서 비동기 프로그래밍은 가상 스레드가 나오기 이전에는 굉장히 어려운 패러다임으로 알려져 있습니다. 사용하기 어려운 Callable 방식, 개발자가 비동기 프로그래밍에 대한 많은 지식 요구, 함수 색 문제 등 비동기 처리를 위해 많은 고민을 해야 하고, 그만큼 장벽이 높았지만 가상 스레드의 등장으로 함수 색 문제와 구조적 동시성을 부활시킴으로써 개발자가 좀 더 사용하기 쉽게 해주었죠.

 

아직 국내에서 Java 21 도입이 많이 된 곳은 없지만 가상 스레드를 통해 아직까지 Java 한자리 수 버전에 머물러 계시는 분들도 이번 기회에 큰 변화를 가져보는 것은 어떨까요?

 

 

참고:

Oracle Tech Blog(https://blogs.oracle.com/javamagazine/post/java-loom-virtual-threads-platform-threads)