일단 지난 포스팅에서 얘기하지 않았던 Mono와 Flux를 알아볼 겸?
사실상 Spring WebFlux를 알아야 이해가 가능하기 때문에 Spring WebFlux를 공부하도록 하겠다.
Spring WebFlux
Spring WebFlux에 대해 조금 더 알고 가야 한다.
https://inpa.tistory.com/entry/👩💻-동기비동기-블로킹논블로킹-개념-정리 [Inpa Dev 👨💻:티스토리]
위 블로그에서 자세하게 나와있는 것 같다.
먼저 Spring WebFlux를 한 문장으로 정의하면
Spring WebFlux 는 비동기 + 논블로킹 + 반응형 기반의 웹 프레임워크
라고 정의할 수 있는데... 벌써부터 어질하다.
또한 기존의 Spring MVC는 동기 + 블로킹I/O 기반으로 되어있다면
Spring WebFlux는 비동기 + 논블로킹 기반으로 되어있다는 특징이 존재한다.
| 항목 | Spring MVC (Blocking) | Spring WebFlux (Non-blocking) |
|---|---|---|
| 처리 방식 | Thread-per-request (요청마다 스레드 할당) | Event-driven + Reactor 기반 |
| 동작 방식 | 요청이 완료될 때까지 스레드가 대기 | 요청 후 바로 반환, 데이터가 준비되면 이벤트 기반 처리 |
| I/O 처리 | Blocking I/O (동기) | Non-blocking I/O (비동기) |
| 반환 타입 | User, List<User> | Mono<User>, Flux<User> |
| 성능 | 동시 요청이 많아지면 스레드 부족 | 적은 스레드로 더 많은 요청 처리 가능 |
표로 요약해보면 다음과 같이 나온다.
기존 Spring MVC의 동기(Blocking I/O) 모델
Spring MVC는 서블릿(Servlet) 기반의 프레임워크로, 내부적으로 동기(Blocking) 방식의 I/O 처리를 사용한다.
Spring MVC의 주요 특징
- Thread-per-request 모델
- 요청이 들어오면 스레드를 할당하고, 응답이 끝날 때까지 해당 스레드가 차단됨.
- 요청 수가 많아지면 스레드가 부족해지고, 성능이 저하됨.
- Blocking I/O (동기 방식)
- 데이터베이스 쿼리, API 호출 등의 작업이 끝날 때까지 스레드가 대기(Block)함.
- CPU 리소스를 비효율적으로 사용하게 됨.
Spring WebFlux와 비동기(Non-blocking) I/O
Spring WebFlux는 Reactor 기반의 비동기 논블로킹(Non-blocking) 방식을 사용한다.
즉, 요청이 들어와도 스레드가 대기하지 않고, 이벤트가 발생하면 비동기적으로 처리한다.
###Spring WebFlux의 주요 특징
1. Event Loop 모델
- 요청을 스레드 하나에서 여러 개 처리 가능
- 기존의 스레드 차단 방식(Blocking I/O) 대신 비동기 이벤트 기반(Non-blocking I/O) 사용
2.Reactor 기반의 Reactive Streams 지원 - Mono(01개) 또는 Flux(0N개)를 반환
- 데이터가 준비되면 이벤트 기반으로 Subscriber가 데이터를 받음
- 기존 Blocking 코드보다 더 많은 동시 요청 처리 가능
비동기
비동기는 다들 알듯이 프로그래밍에서 비동기는 작업이 독립적으로 실행되며, 작업이 시작되면 해당 작업이 완료될 때까지 기다리지 않고 다음 코드를 실행할 수 있다는 것을 의미한다.
논 블로킹
논블록킹은 단어에서 알 수 있듯이 다른 요청의 작업을 처리하기 위해 현재 작업을 block(차단, 대기) 하냐 안하냐의 유무를 나타내는 프로세스의 실행 방식이다.
Reactor
Reactor는 Spring WebFlux에서 비동기 스트림을 처리하기 위해 사용하는 라이브러리
- Reactive Streams 표준을 구현한 라이브러리이며, Publisher-Subscriber 패턴을 기반으로 동작한다.
- Mono 와 Flux라는 두 가지 기본 데이터 타입을 제공한다.
Reactive Streams
Reactive Streams는 비동기 + 논블로킹 + 백프레셔 지원을 위한 표준 스펙으로
데이터 스트림을 효율적으로 처리할 수 있도록 설계된 비동기 데이터 흐름 표준
Reactive Streams가 필요한 이유
위에서 잠깐 얘기했듯이 기존의 Spring MVC 즉, 블로킹 방식에서는 데이터의 소비 속도보다
공급 속도가 빠르면 성능 저하 및 메모리 과부하가 발생한다.
이쯤에서 Reactor는 잠깐 끊어야겠다.
당연히 Spring WebFlux가 Reactor 기반이니까 계속 공부하는게 나을 수 있지만
지금은 어떤 특성을 가지고 있는지 알고만 가는게 맞다고 생각된다.
여튼 요약하자면 Spring WebFlux 는 대용량의 데이터와 대규모 트래픽을 유연하고 안정적으로 처리할 수 있는 라이브러리 기반으로 제작된 프레임워크라는 것이다.
Mono & Flux (Reactive Streams 구현체)
Spring WebFlux에서는 Reactor 라이브러리를 사용하며, Reactor는 Reactive Streams를 구현하고 있다.
Mono와 Flux는 Reactive Streams 인터페이스를 구현한 Reactive 타입이다.
| 타입 | 설명 |
|---|---|
Mono<T> | 0~1개의 데이터 처리 |
Flux<T> | 0~N개의 데이터 스트림 처리 |
Mono와 Flux는 각각 위와 같은 특성을 가지고 있는데 지금까지 작성했던 내용을 보고
지난 포스팅에서의 반환 타입이 Mono인 것을 보면 왜 Mono를 사용했는지 알 수 있다.
왜 Mono였을까?
-
MSA의 가장 큰 특징은 각 서비스(컴포넌트)가 이벤트를 비동기적으로 송수신 하며 자신의 업무를 계속해나간다.
-
Spring WebFlux 는 비동기 + 논블로킹 + 반응형 기반의 웹 프레임워크이며,
Spring WebFlux의 filter() 메서드는 논블로킹 방식으로 작동해야 한다.
( Spring WebFlux는 비동기 + 논블로킹 기반의 프레임워크이므로, 내부에서 실행되는 모든 필터(WebFilter) 역시 논블로킹 방식으로 동작해야 성능을 극대화할 수 있다. ) -
JWT 필터에서 단일 인증 객체를 처리하기 때문이다. (0~1개의 데이터 처리)
이러한 3가지 이유로 Filter에서 Mono를 통해 인증 객체를 전달하는 것이다.
Exchange
대충 하면 안되겠지만 이만하면 겉핥기정도는 된 것 같다.
그래서 다음 내용으로 Exchage에 관한 내용을 짧막하게 적고 가겠다.
Exchange가 어디서 나왔냐면... SecurityConfig나 JwtFilter에 모두 나왔다.
일단 Spring WebFlux가 Netty기반으로 되어있다.
기존의 Spring MVC 에서는 Tomcat 기반이었고, Tomcat은 Servlet기반의 블로킹 형태의 WAS다.
그렇다면 Spring WebFlux는 Netty 기반이고, Netty는 논블로킹 형태의 WAS다.
| 항목 | HttpServletRequest | ServerWebExchange |
|---|---|---|
| 동기/비동기 | 동기 (Blocking) | 비동기 (Non-blocking) |
| 요청 읽기 방식 | InputStream을 사용 (한 번만 읽기 가능) | exchange.getRequest().getBody() (다중 읽기 가능) |
| 반응형 지원 | 지원하지 않음 | 지원 |
이러한 특징으로 Spring Webflux를 사용하는 MSA에서 ServerWebExchange를 사용한다.
(exchange는 Request + Response를 한 번에 관리할 수 있기 때문에 WebFlux에서 사용된다.)
