Webflux에 대해서 알아보자
Spring Webflux는 Spring 5에서 새롭게 추가된 모듈이다.
Webflux는 reactive-stack의 웹 프레임워크이다
설명에 따르면 Webflux의 등장 배경은 non-blocking으로 동작하는 web-stack의 필요성이다.
왜 Webflux가 탄생했을까?
후술할 내용이긴 하지만 결론적으로 non blocking web-stack을 통해 적은 수의 쓰레드와 적은 하드웨어 자원으로 동시성을 처리하기 위함이다.
Reactive의 정의에 대해 간단하게 알아보자.
반응에 중점을 두어 만들어진 프로그래밍 모델이다. 여기서 반응이란 변경에 대한 반응이다. 네트워크 컴포넌트는 I/O 이벤트에 대한 반응이고, UI 컨트롤러는 마우스와 같은 이벤트에 반응한다. non-blocking은 동작을 중단하는 대신 명령의 수행, 데이터의 제공과 같은 변경에 대해 반응하는 형식을 취하기 때문에 reactive라고 할 수 있다.
WebFlux를 선택함으로써 얻는 이점.
배달의 민족은 가게노출 시스템에 Webflux를 도입했다. 배달의 민족의 가게노출 시스템은 말 그대로 사용자에게 가게의 정보를 보여주는 시스템이다.
가게노출은 앱 내에서 많은 트래픽을 소화했던 시스템으로 수많은 외부 시스템과 실시간 정보, 데이터를 조합으로 시간과 위치에 따른 실시간 데이터를 제공하는 서비스이다. 이를 위해서
- 어떻게 가장 빠른 응답을 줄 것인가?
- 수많은 요청을 처리하는 과정에서 발생하는 쓰레드 지옥을 어떻게 방지할 것인가?
이를 위해서 비동기적으로 데이터를 처리하는 것이 해결방식으로 제시된다.
Spring MVC는 1:1로 요청을 처리하기 때문에 트래픽이 몰리면 많은 쓰레드가 발생한다. 쓰레드가 전환될 때 발생하는 context switch가 곧 비용이기 때문에, 쓰레드가 많을수록 비용이 커지는 문제가 발생한다.
Spring Webflux는 Event Driven과 non-blocking 처리방식으로 리소스를 효율적으로 사용할 수 있도록 한다.
MVC를 선택한 이유
mvc는 못해도 본전, reactive는 못하면 적용하지도 못한 결과. 트래픽이 높은 서비스가 아니라면 mvc로도 감당할 수 있다.
명령형 프로그래밍은 대부분 blocking방식이기 때문에 작성하고 이해하고 디버깅하기 가장 쉬운 방식이고 라이브러리 선택에 있어서도 선택지가 많다. → 잘 작동 중인 기존 spring mvc 애플리케이션이 있다면 변경할 필요가 없기도 하다.
또한 이번 프로젝트에서 JPA에 대한 경험을 해보고 싶었다. JPA는 blocking persistance api이므로 때문에 Spring MVC를 선택하였다.
