[Spring WebFlux] 1. Overview

1. Spring Webflux란?

• Reactive Streams와 Reactor 기반
• Non-blocking 방식으로 HTTP 요청을 처리하는 Spring의 Reactive Web Framework
• 비동기 작업을 Operator + Function Chain 형태의 선언형 API 제공
• ⚠️ 기존 Servlet 기반 Web MVC는 기본적으로 Blocking을 허용하는 구조
• ✅ 동시 요청이 많아지면 이를 감당하기 위해 많은 Thread가 필요함
• ➡️ 적은 Thread로 많은 동시 요청을 처리하는 것이 목적

 

2. Define “Reactive”

• Reactive는 변화나 Event가 발생했을 때 반응하는 Programming Model임
• ex) Network I/O 준비 → Event 발생 → Handler 실행

 

Non-Blocking Backpressure

• Backpressure: Consumer의 처리 가능량에 맞춰 Publisher의 데이터 공급량을 조절하는 Non-Blocking 흐름 제어 방식
• ✅ Blocking 방식에서는 Consumer가 처리중이면 호출한 Thread도 기다리기 때문에 자연스럽게 처리 속도가 제한됨
• ✅ Non-Blocking이면 Thread가 기다리지 않고 계속 다른 작업을 수행할 수 있어 Producer가 데이터를 계속 전달할 수 있음
• ⚠️ Producer 속도 > Consumer 처리 속도 → Queue 증가 → Memory 사용 증가 → 시스템 부담 증가
• ➡️ request(n): Consumer가 자신이 처리할 수 있는 양을 Publisher에 전달하여 데이터 생성 및 전달 속도를 조절함

 

3. Programming Models

방식	핵심
Annotated Controllers	@RestController, @GetMapping 등 기존 MVC와 유사
Functional Endpoints	RouterFunction, HandlerFunction을 Lambda 기반으로 직접 구성

 

예제) Annotated Controllers

@GetMapping("/users/{id}")
Mono<User> getUser(@PathVariable Long id) {
    return userService.findById(id);
}

 

예제)

@GetMapping("/users/{id}")
Mono<User> getUser(@PathVariable Long id) {
    return userService.findById(id);
}

 

4. Applicability

• Spring MVC, Spring Webflux 둘중 Application의 I/O 특성과 사용하는 Library에 따라 선택함
• ✅ Spring MVC 적합: Blocking API를 주로 사용하는 경우
• ✅ Spring Webflux 적합: I/O 대기 많음. Non-Blocking Stack을 유지할 수 있을 때
• ex) gateway, streaming, reactive db, 외부 api , 많은 동시 connection

 

5. Servers

• Spring Webflux에선 여러 서버 위에서 동작할 수 있음
• Reactor Netty, Tomcat, Jetty, Servlet Container
• Spring Webflux에선 일반적으로 Reactor Netty에서 동작함

 

6. Performance

• Scalability, Resource Efficiency, Load 상황에서의 안정성
• ➡️ 느린 Network I/O나 많은 동시 요청이 존재할수록 장점이 커짐

 

7. Concurrency Model

• Blocking하지 않는다고 가정함
• ➡️ I/O를 기다릴 때 Thread를 점유하지 않으므로 많은 요청을 적은 Thread가 처리 가능함

 

Invoking a Blocking API

• Blocking API를 써야 하는 경우 EventLoop에서 직접 실행하면 안됨
• ⚠️ Blocking 시 다른 요청들이 지연됨
• ➡️ boundElastic Thread로 분리하기

 

예시) boundElastic Thread

Mono.fromCallable(() -> blockingCall())
    .subscribeOn(Schedulers.boundedElastic());

 

Mutable State

• Reactor Pipeline은 각 단계가 순차적으로 Signal을 처리하도록 구성됨
• ✅ onNext → Operator → Operator → Subscriber
• ✅ 같은 Pipeline 내부 Logic은 동일한 Signal 흐름에서 직렬화됨
• ➡️ 기존 멀티 Thread 코드보다 공유 Mutuable State에 대한 Synchronization 부담을 줄일 수 있음

 

Threading Model

• Reactor Netty 기반 Webflux에서는 소수 reactor-http-nio EventLoop Thread가 HTTP 요청을 처리함
• ✅ WebClient도 EventLoop 방식으로 동작함
• ✅ Server와 Client 모두에서 사용하면 EventLoop Resource를 공유할 수 있음

 

 

출처

• Spring WebFlux - Overview