Project Loom's virtual threads

모지리 개발자·2023년 1월 18일
3
post-thumbnail


전혀 관련 없는 사진입니다. 생각나서 넣었습니다.

Intro

몇달전부터 Project Loom에 관한 이야기를 건너건너 듣게되었고 최근에 관련한 자료를 많이 접하게 되어 Project Loom이 무엇이고 이에 대해 정리해보기 위해 이 글을 작성하였습니다.

Project Loom 이란

the primary goal of Project Loom is to support a high-throughput, lightweight concurrency model in Java.

Project Loom에 대한 Baeldung글에서 가져온 내용입니다.
해석해보면 다음과 같습니다.

Project Loom의 주요 목표는 JAVA에서 처리량이 많고 가벼운 동시성 모델을 지원하는 것입니다.

이는 os관리하에 있었던 커널 스레드 모델에서 가상머신이 관리하는 경량 스레드 모델로의 전환으로 이루어지게 됩니다. 구체적인 내용은 프로젝트 룸이란 무엇인가?에서 확인해보시면 좋습니다.

리엑티브 프로그래밍 너는 죽었다

자바 병렬 프로그래밍 서적으로 유명한 브라이언 게츠는 이렇게 말했습니다.
Project Loom이 나오면 리액티브 프로그래밍을 죽일 것이다.
왜 이렇게 말했을까요?

spring mvc로 개발을 하게되면 thread pool에 설정한 만큼의(tomcat의 default 쓰레드 수 : 200)thread가 pool에 담겨서 하나의 thread는 하나의 요청을 처리하게 됩니다.

하지만 이때의 Thread 생성 및 전환시 발생하는 컨텍스트 스위칭 비용은 매우커서 저희는 비동기-논블로킹을 사용하여 최소한의 쓰레드로 최대한 많은 일을 하고 그에 따른 코드의 난해함이 부작용이 발생해서 리액티브 프로그래밍, 코루틴과 같은 기술을 사용합니다.

동기 프로그래밍, 비동기 프로그래밍의 장단점을 이해하면 브라이언 게츠가 왜 이렇게 말했는지 이해하기 쉽습니다.

동기 프로그래밍은 설계가 매우 간단하고 직관적이지만 결과가 주어질 때까지 아무것도 못하고 대기해야하는 단점이 있습니다.

비동기 프로그래밍은 동기보다 복잡하지만 결과가 주어지는데 시간이 걸리더라도 그 시간동안 다른 작업을 할 수 있으므로 자원을 효율적으로 사용할 수 있는 장점이 있습니다.

Project Loom을 사용하게 된다면 동기 프로그래밍에서의 단점이었던 결과가 주어질 때까지 아무것도 못하고 대기해야한다는 단점이 무색해지게 됩니다. 또 개발하는 입장에서 설계가 매우 간단하고 직관적이다는 장점을 가져가게 되죠.

이유는 Kt.Academy의 Running Kotlin coroutines on Project Loom's virtual threads
글을 해석해보면서 설명해보도록 하겠습니다.

Project Loom의 가상 스레드에서 Kotlin 코루틴 실행하기

JAVA 19에서 새롭게 등장한 기능입니다. 그러므로 Project Loom을 사용하기 위해서는 JDK 19 이상의 버전을 사용하여야 합니다.

Kotlin에서 비동기 또는 논블로킹 코드를 실행하게 위해서는 CoroutineScope 내부에서 실행시키거나 suspendCancellableCoroutine callback을 처리하기 위해서는 suspend 함수로 변환해야합니다.

Running Kotlin coroutines on Project Loom's virtual threads 글에 따르면

100만개 코루틴을 만들고 개당 1초씩 스레드 슬립을 줬을때 수행시간이 아래와 같습니다

Dispatchers.IO(스레드 64개) : 4시간 20분
Dispatchers.IO(스레드 5000개) : 3분 20초
Dispatchers.LOOM(버츄얼 스레드 100만개) : 1초

Dispatchers.LOOM을 사용하게 되면 성능이 압도적으로 좋은 것을 알 수 있습니다.

Dispatcher.IO의 경우에는 대부분의 경우 CPU소비가 거의 0인 반면 Dispatchers.LOOM을 사용하면 스레드 수는 상대적으로 낮게 유지되지만 CPU 사용량이 최대화 되는 것도 확인해볼 수 있습니다.

결론

처음 webflux를 이용하여 개발을 하면서 굉장히 어려웠었습니다. 특히 콜백으로 계속 chaining하면서 작성해야했던 reactor는 처음 배울 때 굉장히 어렵게 느껴졌습니다. 또 reactor로 코드를 작성하다가 coroutine으로 코드를 작성하게 되면 굉장히 직관적이고 편하게 작성할 수 있다는 느낌을 받았었습니다.
확실히 mvc로 개발했을 때보다 default thread수가 적은 상태로 (cpu 코어 개수에 따라 정해짐) 많은 요청을 처리할 수 있다보니 성능상으로도 확실히 이점이 있었습니다.

하지만 Project Loom이 등장하면서 직관적인 코드로 개발을 하고 그냥 많은 요청이 들어오면 많은 쓰레드를 만들어내도 큰 문제가 없다면 굳이 비동기로 개발을 해야하나라는 의문이 생겼고 이러한 이유 때문에 브라이언 게츠는 Project Loom이 나오면 리액티브 프로그래밍을 죽일 것이다.와 같이 말한 것 같습니다.

개인적으로도...한 1~2년 뒤면 다 Project Loom을 쓰지 않을까..라는 생각이 들었습니다.

profile
항상 부족하다 생각하며 발전하겠습니다.

0개의 댓글