Reactive Programming & Spring Webflux

Reactive Programming

- 등장 배경 : 작은 모바일 디바이스, 모바일 멀티 코어 프로세스까지 너무나 다양한 환경에서 애플리케이션이 배포되며, 이에 따라 사용자는 더욱 더 빠른 처리를 기대함. 

- 데이터 스트림이나 변경에 대해 반응적으로 동작하는 프로그래밍 패러다임

- 함수형 프로그래밍 기법 사용

- 비동기적인 이벤트 중심의 개발을 효과적으로 처리 가능

- Project Reactor / ReactiveX / RxJava와 같은 스트림에서 사용

- non-blocking형식 ( 기존의 블록킹 형식의 리퀘스트는, 워커 스레드가 처리를 하는동안 서블릿 스레드가 응답을 기다려야했음. 반면 논블록킹 리퀘스트는 이벤트 핸들러와 콜백을 모든 요청에 포함하여, 스레드풀에 요청을 위임하고, 다음요청을 처리하는데 바로 사용할 수 있음) 

- 리액티브 스트림을 사용하면, 요청을 비동기적으로, 동시에 보내기 때문에 이 중 가장 긴 요청시간만큼 시간이 소요됨

Spring Webflux

- Reactive Programming모델을 기반으로 하는 웹 프레임워크

- non-blocking형식으로, reactive stream을 지원하며, 기존 Spring MVC에 대한 대안

- 스프링으로 비동기 프로그래밍을 할 때 쓰임

- 적은 양의 스레드와 최소한의 하드웨어 자원으로, 동시성을 핸들링하기 위해 만들어짐.

- 내부적으로 Reactor라는 리액티브 라이브러리를 사용하여 Mono와 Flux를 구현한다. 차이점은 발행하는 데이터 개수이다.

- Flux : ~N개 데이터

- Mono : ~1개 데이터

Spring MVC와 Webflux의 차이

Spring MVC는

- 1 요청당 1 스레드를 사용한다. 

- 스레드 풀을 생성하여, 다량의 요청마다 스레드를 할당해서 사용한다. 

 

반면,

Spring Webflux는 

- 고정된 스레드 수만으로 모든 요청을 처리한다. (싱글 스레드 방식)

- Reactor기반의 Functional API

- 서버는 스레드 한 개로 운영한다. ( CPU 코어 수 개수의 스레드를 가진 워커 풀을 생성하여, 해당 워커 풀 내의 스레드로

모든 요청을 처리한다.) 

 

기존의 Spring MVC는 1:1로 요청을 하기 때문에, 트래픽이 많을 수록 많은 스레드가 생성되며, 콘텍스트 스위칭을 할 수록 비용이 발생하기 때문에, 적절한 쓰레드 개수를 사용해야한다.

이를 해결하기 위해, Spring Webflux를 사용하는 것이다.

 

Spring WebFlux (1) | 토리맘의 한글라이즈 프로젝트 (godekdls.github.io) https://gngsn.tistory.com/223

Spring Webflux를 사용하면 좋은 서비스 

- 대규모 고성능 웹 어플레이션으로, 트래픽이 높은 서비스에 이용하면 좋다. => webflux는 높은 처리량과 낮은 대기시간을 담보하므로!

- MSA환경처럼 여러 API를 호출하여, 각 API에 대하여 요청에 대한 응답시간을 줄여야할 때 

- DB가 RDB가 아닌 서비스 => RDB는 주로 트랜잭션 처리나, 데이터 일관성을 보장하기위해 동기적인 방식으로 디비와 상호작용하기 때문에, Webflux의 비동기 및 논 블록킹 모델과 어울리지 않는다. 

 

아래는 많은 트래픽을 감당해야해서, Webflux를 사용하기 좋은 적절한 예제이다.

https://techblog.woowahan.com/2667/

배달의민족 최전방 시스템! ‘가게노출 시스템’을 소개합니다. | 우아한형제들 기술블로그

 

 

흠 회사에서 몽고 디비 조합으로 로깅 찍을 때 정도 사용하고 있는데, 그 외에는 아직까지 특별히 사용할 일이 없어서,

좀 뭐랄까 완벽하게 감이 안오긴 하는데, 이벤트 드리븐 방식에 대해 공부하면서 더 살펴봐야겠다는 생각이 든다.