Offcanvas

How To / 개발자 / 애플리케이션

'프로젝트 룸' 최신 자바 동시성 모델 따라잡기

2022.03.14 Matthew Tyson   |  InfoWorld
룸(Loom)은 (오픈JDK에 의해 호스팅되는) 자바/JVM 생태계에서 비교적 새로운 프로젝트다., 전통적인 동시성 모델(concurrency models)이 가진 한계를 극복하려는 시도다. 특히 룸은 자바 스레드(Java threads)를 대체할 경량의 대안이고, 이들을 관리할 새 언어 구조를 가지고 있다. 이와 관련해 앞으로 일어날 중요한 변화를 개략적으로 살펴본다.

파이버: 자바 가상 스레드 
리스팅 1에서 볼 수 있듯이 전통적인 자바 동시성은 스레드(Thread) 및 러너블(Runnable) 클래스에 의해 관리된다 (새 명칭의 스레드를 시작하고 해당 명칭을 출력). 

리스팅 1. 전통적인 자바로 스레드를 시작하기



이 모델은 꽤 이해하기 쉽다. 그리고 자바는 이를 처리함에 있어 여러 풍부한 지원을 제공하고 있다.

단점은 자바 스레드가 운영체제 내의 스레드에 직접 매핑 된다는 점이다. 이러한 매핑은 동시 실행되는 자바 앱의 확장성을 심하게 제한한다. 이는 앱 스레드와 운영체제 스레드 사이의 1대1 관계를 의미할 뿐 아니라 스레드를 최적으로 정돈할 메커니즘이 전혀 없음을 의미하기도 한다. 예를 들어 서로 밀접하게 연계된 스레드들이 상이한 프로세스를 공유할 수 있고, 그렇다면 동일 프로세스 상에서 힙 메모리를 공유하는 데 따른 혜택이 없어진다.

룸이 얼마나 야심적인 변화를 지향하는 지를 쉽게 시사하는 숫자가 있다. 현재의 자바 스레딩은 심지어 육중한 서버에서조차 스레드 수가 많아 봐야 수천 개이다. 룸은 이 한계를 수백만 개로 확대하려 한다. 이게 자바 서버 확장성에 있어서 갖는 함의는 지극히 파격적이다. 표준적인 요청 처리는 스레드 수와 연계되기 때문이다. 

해법은 일종의 가상 스레딩을 도입하는 것이다. 여기서는 자바 스레드가 기저의 OS 스레드로부터 분리되고, JVM(Java Virtual Machine)은 두 스레드의 관계를 한층 효과적으로 관리할 수 있다. 프로젝트 룸은 애당초 파이버(fiber)라는 새로운 가상 스레드를 도입해 이같이 하기 위해 시작되었다. 

프로젝트 룸 제안서는 아래와 같이 언급한다. 
 

지속 객체(continuations)를 구현하는 데 있어, 그리고 이 전체 프로젝트의, 대표적인 기술적 임무는 커널 스레드의 일부로서가 아니라 콜스택(callstacks)을 포착하고 저장하고 재개하는 능력을 핫스팟(HotSpot) 엔진에 추가하는 것이다. 


바이트코드 조작을 통한 경량의 스레딩을 자바에 가져온 퀘이사(Quasar)를 접해본 적이 있는가? 있다면 이의 기술 리더인 론 프레슬러가 오라클을 위해 룸을 지휘하고 있다는 사실에 주목할 것이다.

파이버의 대안들 
룸의 해법을 자세히 살펴보기 전에 동시성을 처리하기 위해 다양한 접근법이 제안되었음을 밝혀두는 게 좋을 듯하다. 대개 이들은 비동기 프로그래밍 모델(asynchronous programming models)이다.  컴플리트테이블퓨처스(CompletetableFutures), 논-블로킹 IO(Non-Blocking IO) 등의 몇몇 접근법은 스레드 이용 효율을 개선하면서 간접적으로 문제에 대처한다. 자바RX(JavaRX) 등의 접근법은 전면적인 비동기 대안이다.

자바RX는 동시성을 위한 위력적이면서 잠재적으로 고성능의 접근법이지만 결점이 없지 않다. 특히 이는 자바 개발자가 전통적으로 이용해온 정신 구조와 매우 다르다. 또한 자바RX는 가상 머신 계층에서 가상 스레드를 관리함으로써 달성할 수 있는 이론적 성능을 따라잡을 수 없다.

파이버는 자바스크립트의 비동기/대기(async/await) 문법의 동시적 코드 흐름 등을 허용하도록 설계됐고, 한편으로 JVM에서 성능을 압박하는 미들웨어의 대부분을 숨긴다. 

자바 파이버의 작용 
위에서 말한 것처럼 새 파이버 클래스는 가상 스레드를 나타낸다. 하부에서는 비동기 곡예가 펼쳐진다. 언어 수준에서 리액티브X(ReactiveX) 같은 것을 도입하면 되는데 굳이 이렇게 번거로울 필요가 있을까? 개발자가 기존의 코드의 세계를 이해하는 일을 더 쉽게 하고 이동시키는 일을 더 쉽게 하기 위해서이다. 예를 들어 데이터 저장 드라이버는 새 모델로 더 쉽게 이동될 수 있다.

파이버의 매우 단순한 이용 예제는 리스팅 2에 제시된다. 파이버가 기존의 스레드 코드와 매우 유사하다는 점에 유의하라(코드 스니펫은 오라클 블로그 게시물에서 나왔다). 

리스팅 2. 가상 스레드 생성 



이 매우 단순한 예제를 넘어 스케줄링에 대해 광범위한 고려가 있다. 이들 메커니즘은 아직까지 정립되지 않았고, 룸 제안서는 연관 아이디어들을 적절히 개관한다. 

룸 파이버에 관해 유의해야 할 중요한 사항은 전체 자바 시스템에 어떻게 변경되더라도 이들이 기존의 코드를 파괴하지 않는다는 점이다. 시간이 지나면서 기존의 스레딩 코드는 완전히 호환될 것이다. 파이버를 사용할 수 있지만 필수적이지는 않다. 예상했겠지만 이는 매우 힘든 작업이고, 룸에 관해 작업하는 사람은 여기서 대부분의 시간을 소비할 것이다.

지속 객체와의 저수준 비동기 
이제 파이버를 살펴보았기 때문에 지속 객체를 살펴볼 차례이다. 룸은 파이버를 지지하기 위해, 그리고 개발자가 애플리케이션에서 사용하기 위한 퍼블릭 API로서 파이버를 노출시키기 위해 지속 객체를 구현한다. 그렇다면 지속 객체란 무엇인가?

높은 수준에서 지속 객체는 실행 흐름을 코드로 표현한 것이다. 다시 말해 지속 객체는 개발자가 함수를 호출하며 실행 흐름을 조작할 수 있도록 허용한다. 룸 문서는 리스팅 3에 나온 예제를 제시하면서 지속 객체의 작용을 쉽게 파악할 수 있도록 돕는다.

리스팅 3. 지속 객체 예제 



실행 흐름을 다음 번호별로 고려해본다.

(0) 푸(foo) 함수에서 시작해 한 지속 객체가 생성됨 
(1) 지속 객체의 진입점으로 통제권을 이전 
(2) 다음 중단 지점, 다시 말해 (3)까지 실행 
(3) 통제권을 원래의 출처로 반환
(4) 이제 실행함. 실행 흐름은 (5)에서 중단되었던 지점으로 복귀 

이런 종류의 통제는, 함수들이 쉽게 참조되고, 나아가 실행 흐름을 지정하기 위해 마음대로 호출할 수 있는 자바스크립트 같은 언어에서 어렵지 않다

테일 콜 제거 
룸의 또 하나의 명시적 목표는 테일-콜 제거(Tail-call elimination 또는 tail-call optimization)이다. 이는 제안된 시스템에서 상당히 난해한 요소이다. 핵심 아이디어는 가급적 어디서든 지속 객체를 위해 새 스택을 할당하는 일을 피할 수 있을 것이라는 점이다. 

이 경우 지속 객체를 실행하는데 필요한 메모리 용량이 일정하게 유지된다. 프로세스의 각 단계에서 이전 스택이 저장되고 콜 스택 작용 시 이용될 수 있도록 요구함에 따라 메모리 용량이 계속 증가하는 것과 다르다. 

룸, 그리고 자바의 미래 
일반적으로 룸과 자바는 주로 웹 애플리케이션 제작에 특화되어 있다. 분명히 자바는 여러 다른 영역에서도 사용되고, 룸에 도입된 아이디어들은 이들 애플리케이션에 유익할 것이다. 스레드 효율이 크게 증가하고, 여러 경쟁하는 니즈를 처리하기 위한 자원 요건이 극적으로 줄어든다면 당연히 서버의 처리량이 증가한다. 요청과 응답을 한층 효과적으로 처리한다면 이는 기존 및 미래의 자바 애플리케이션에 근본적으로 유익하다.

여느 의욕적인 신규 프로젝트와 마찬가지로 룸도 난제가 있다. 스레드의 정교한 인터리빙(interleaving)은 가상이든 또는 다른 경우이든 언제나 까다로운 문제이고, 이에 대처하기 위해 정확히 어떤 라이브러리 지원과 설계 패턴이 출현하는지 지켜봐야 한다.

프로젝트 룸이 보편화될 때 현실 이용에 대응해 진화해가는 모습을 지켜보는 것은 환상적일 것이다. 이 상황이 펼쳐지면서, 그리고 새 시스템에 내재된 이점이 개발자가 의존하는 인프라로 도입됨에 따라 (예를 들어 제티(Jetty), 톰캣(Tomcat) 등의 자바 앱 서버) 자바 생태계의 커다란 지각 변동을 목격할 수 있을 것이다.

이미 자바와 대표적인 자바의 서버 측 경쟁자인 노드닷제이에스(Node.js)는 성능 격차가 거의 없다. 전형적인 웹 앱 이용 사례에서 자바 성능을 배가시키는 일은 앞으로 몇 해 동안 이 형세를 변화시킬 것이다. 


* Matthew Tyson은 다크호스 그룹의 설립자다. ciokr@idg.co.kr
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.