Spring Webflux란?
Spirng Webflux는 리액티브 웹 애플리케이션 구현을 위해 Spring5.0부터 지원되는 Reactive Web Freamwork
Spring Webflux 탄생 배경
Spring MVC
서블릿기반의 Blocking I/O 방식
요청당 하나의 스레드를 사용, 스레드의 작업이 끝날 때 까지 스레드가 차단됨
Spring MVC의 한계
대용량 요청 트래픽을 Spirng MVC방식이 처리하기엔 한계가 있었다.
트래픽이 많아질수록 스레드도 많이 사용되는데, 스레드풀에 스레드 200개가 defalut로 존재하고, 만약 만명이 동시접근한다면 감당이 안될것이다. 거기에 스레드 스위칭 비용도 그만큼 많이 발생한다.
Spring Webflux를 이용한 극복
대용량 트래픽을 감당하기 위해선, 비동기/논블로킹 방식의 I/O를 사용해야했으며 이 방식이 적용되어, 대용량도 안정적으로 처리할 수 있는 Spring Webflux가 탄생하게 되었다.
MVC와 Webflux 예시
client가 백엔드 서버로 요청을 보내면, 백엔드 서버는 외부 서버로 요청를 보내게 되는데 이때 외부 서버의 동작이 5초 걸린다고 가정하자.
client의 요청은 총 5번 들어왔다.
(예시에서는 스레드 풀이 1개라는 가정하에 설명하는 것임)
MVC의 경우
MVC는 서블릿 기반 동기식 처리를 한다.
외부 서버로 요청을 보낼 때 동기 처리를 하는 RestTemplate을 사용해서 처리를 한다고 했을 때
5번(요청) * 5초(외부 서버의 응답 처리시간) == 총 25초가 걸린다.
외부 서버와 통신할 때 요청처리스레드는 블로킹이 된다.
Webflux의 경우
웹플럭스는 비동기 넌플로킹 방식의 리액티브 프로그래밍을 지원한다.
이때 외부 서버로 요청을 보내면 WebClient를 사용하면
5번의 요청에서 블로킹이 발생하지 않는다.
그러하여 MVC와 비교했을 때 대용량 처리가 필요한 상황에서 아주 빠른 처리를 할 수 있다.
Spring Webflux Stack
- Netty: 기본 서버엔진
- 리액티브 스트림즈 어댑터를 통한 리액티브 스트림즈 지원
- WebFliter (Spring Security 사용)
- NoSQL 모듈 사용 (Spring Data R2DBC, Non-Blocking I/O 지원)
Spring Webflux의 내부 동작 원리
client의 요청이 발생하면 서버엔진의 Netty를 거치게 된다.
1. HttpHandler가 서버 API를 추상화한다.
=> 네티 뿐만 아니라 다양한 서버엔진이 지원된다.
=> ServerWebExchange를 생성한다. 여기에 ServletHttpRequest, ServletHttpResponse가 포함되어 있다
2. WebFilter
=> 필터체인으로 구성된 웹 필터이다.
=> ServerWebExchange의 전처리 과정을 실천한다.
=> 이후 Web handler의 구현체인 Dispather Handler에게 전달된다.
3. DispatchHandler
=> SpringMVC의 Dispatcher Servlet과 유사한역할
4. getHandler
=> ServerWebExchanger를 처리할 핸들러를 조회한다.
5. 핸들러 어댑터에게, ServerWebExchanger를 처리하도록 위임한다.
6. HandlerAdapter
=> 핸들러어댑터는 핸들러를 호출한다.
=> 이때 호출되는 핸들러의 형태는 Controller, Handler Function 형태이며, Mono를 반환한다.
=> 반환받은 응답데이터를 처리할 HandlerResultHandler를 조회한다.
7. HandlerResultHandler
8. 응답 데이터의 적절한 처리 후 return한다.
