라벨이 webflux 단점인 게시물 표시

나는 왜 Reactive streams와 친해지지 않는가?

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

이 블로그의 인기 게시물

Scouter APM 소소한 시리즈 #1 - 설치하기

Scouter APM 소소한 시리즈 #4 - XLog 활용 - 상세기능

Java의 동시성 개선을 위한 Project Loom은 reactive streams를 대체할 것인가?