Gun's Dev Log

Project Loom 최신 빌드 얼리 액세스 빌드 제공 ( 2020년 8월 17일) Build 16-loom+105   자바의 동시성 처리 개선을 위해 Ron Pressler의 제안으로 2017년 시작된 Project Loom이 얼마 전 더욱 완성도 높은 형태의 얼리 액세스 빌드로 제공되었다. 개인적으로 관심이 많은 프로젝트이기도 했고 릴리즈가 되면 현재의 비동기 개발 방식에 많은 영향을 미칠 것으로 보이는지라, 올해 개발 세미나 등에서 ( 이전 글- 나는 왜 Reactive streams와 친해지지 않는가? 와 잘 버무려서 )   관련 내용을 다뤄볼까 하는 생각이 있었지만 이놈의 C19 이슈로 거의 모든 개발 세미나가 온라인으로 진행되고 있어 그냥 블로그 글로 남겨본다. 최근 자바 서버 개발에 큰 흐름 중 하나로 등장한 reactive streams라는 어그로(?) 끄는 제목과는 달리 비동기 프로그래밍과 Project Loom 에 대한 글이다. ^^; (물론 여기엔 reactive streams 도 포함된다.) Project Loom 의 동기 Project Loom 제안 Project Loom: Fibers and Continuations for the Java Virtual Machine Project Loom의 동기 자원 사용면에서 효율적이지 못한 스레드 작성하고 디버깅 하기 어려운 비동기 개발 방식 경량 스레드(파이버)를 통한 블로킹 방식의 개발로 이를 해결하기 위함 먼저 Project Loom의 제안  내용 중 프로젝트의 동기 부분만 간단히 살펴 보도록 하자 하나의 서버에서 수백만 개의 소켓을 다룰 수 있지만 OS 스레드를 직접적으로 사용하는 자바에서는 동시에 수천 개 이상의 요청을 효율적으로 다루기 어렵다. 이를 극복하기 위해 최근 수년 간 많은 비동기 라이브러리들이 탄생하였는데 이는 작성하고 이해하고 디버깅하기 편해서가 아니라 단지 자바의 스레드가 성능면에서 효율적이지 못하기 때문 이다. Loom의 목표는 수백만 개를 생성할 수 있는 파이버라고

Reactive stream에 관심을 갖게 된 건 2017년 스프링캠프를 통해서이다.  그 때 나는 비동기 어플리케이션의 추적(Tracing)에 빠져 있어, 스프링캠프에서 관련된 세션을 발표했는데 이 세션에서 언급된 비동기 어플리케이션이 reactive streams를 지칭한 것은 아니었다. (스프링캠프 :  비동기 어플리케이션 모니터링과 밀당하기 ) Reactive stremas와 webflux는 이름 정도만 아는 수준이었는데 스프링캠프의 토비님 세션을 통해 좀 더 알게 되었다. (스프링캠프: Spring Webflux )  지금도 잘 이해하고 있는 것은 아니지만 그 당시에는 그저 비동기 논블로킹을 구현하는 또 다른 스타일 또는 nodejs와 유사한 이벤트 루프 처리와 콜백 헬을 좀 더 우아하게 처리하는 방법인가? 정도로만 생각했고 webflux 공식 버전이 나온것도 아니기에 관심이 오래가지는  않았다.  그러다 관련된 정보들이 점점 많아지고 주변에서도 이를 사용하기 시작하면서 나도 개발중인 시스템에 적용하게 되었다. 특히 사용하는 시스템들이 늘어나다 보니 SCOUTER 에서도 webflux에 대한 추적을 지원할 필요가 있었다. 그런데 webflux로 개발을 하거나 관련 코드를 볼때 뭔가 불편한 이질감을 떨칠 수가 없었고 종종 " 내가 지금 왜 이러고 있나~" 라는 멍타임이 오곤 했는데, 주변 개발자들도 "나도 그렇다!" 라는 얘기들을 하여 이참에 이 이질감의 정체를 밝혀 보려고 한다. 그럼 먼저 개발 관점에서 reactive streams의 몇가지 장점을 한번 짚어보자. 일괄 처리 백프레셔 스트림을 다룰때의 풍성한 표현력 또한 reactive streams는 당연히 비동기 논블로킹 프로그래밍의 장점을 가지고 있다. C10K 문제 해결 비동기 논블로킹 프로그래밍의 장점으로 많이 얘기되는 것이 C10K 문제의 해결, 즉  "만개의 클라이언트를 동시에 처리할 수 있는가?"   이다.  소켓은 동시에 수백만개