[Spring WebFlux] Spring WebFlux

Spring WebFlux

Spring WebFlux는 기본적으로 Project Reactor 기반으로 동작하며, 서블릿 기반의 Spring MVC와 대비되는 리액티브 기반의 웹 스택이다.Spring MVC와 배타적으로 동작하지만 WebClient, annotation 등 일부 기능은 상호 운용이 가능

단, 내부적으로 Blocking API가 포함되면 성능이 현저하게 낮아질 수 있다.

---

기존 MVC 어노테이션 기반 방식

기존의 Spring MVC에서 사용하던 @Controller, @RestController, @RequestMapping 등의 어노테이션을 그대로 활용할 수 있다.

 

Functional Endpoints 방식

기존 MVC 방식과 다르게 람다 스타일의 Routing 및 Handling 방식을 사용할 수 있다.

---

[Functional Endpoints]

Handler Function

• ServerRequest를 인자로 받아 Mono를 리턴한다.
• 기존 MVC 모델에서 @RequestMapping 메소드의 body와 동일한 역할을 수행한다.
• 요청 바인딩, 핸들러 실행, 핸들러 결과 처리를 담당한다.

Router Function

• ServerRequest를 인자로 받아 Mono을 리턴한다.
• routerFunction이 매칭되면 적절한 Handler Function을 리턴하고, 그렇지 않으면 Mono.empty()를 리턴한다.
• 요청 매핑을 담당하는 역할을 한다.

Mono 기반에서는 AOP 같은 동작을 위해 WebFilter를 활용해야 한다.

---

Reactor Netty

Spring MVC는 기본적으로 Blocking 방식의 동기 처리 모델을 사용한다.
Spring Boot는 서블릿 기반의 Tomcat을 기본 서버로 사용하지만, Spring Boot WebFlux는 Netty, Undertow 등 여러 서버를 지원하며 기본적으로 Netty를 사용한다.

 

Netty란?

• NIO 기반의 서버 프레임워크로, 서버 및 클라이언트에 필요한 네트워크 애플리케이션을 빠르고 쉽게 개발 가능
• 비동기 Event-Driven 방식의 프레임워크
• Event Loop 모델을 사용하여 Work Thread를 생성하고 요청을 처리

 

Spring Boot WebFlux Starter의 기본 서버

기본적으로 WebFlux Starter에 포함된 서버는 Netty이며, 다음과 같은 기본 스레드를 사용한다.

• server
• reactor-http-nio1
• reactor-http-nio2
• reactor-http-nio3

 

서버의 기본 스레드를 제외하고, Netty는 요청 처리를 위해 Work Thread를 생성하여 Event Loop 모델로 동작한다.

---

Spring WebFlux의 스레드 모델

• 이벤트 큐에서 관리되고 순차적으로 처리되는 구조로 동작한다.
• 스레드 풀은 순차적으로 이벤트를 처리하는 Event Loop 방식을 따른다.
• Netty의 스레드 풀 개수는 머신 코어 개수 * 2로 설정된다.

 

높은 처리량이 가능한 이유

• 이벤트 기반으로 동작하여 스레드가 block 되지 않음
• 기존 Spring MVC의 Tomcat은 Thread-per-Request 모델(기본값: 200개 스레드)를 사용하여, 컨텍스트 스위치로 인한 오버헤드가 발생한다.
• 반면 WebFlux는 적은 리소스로 높은 처리량을 처리할 수 있으며, CPU 사용량이 높은 작업이나 Blocking I/O가 포함되면 성능이 저하될 수 있다.