이건 또 왜 이럴까? 🤬
나는 Spring Cloud Gateway를 이용하여 글로벌 필터를 만들려고 하고 있었다.
Global Filter 코드를 작성하는데 이상하게 오늘따라 문제가 생기는 거였다.
AbstractGatewayFilterFactory, GatewayFilter 해당 부분에 어떤 문제가 있지 하면서 기존에 강의를 들으면서 따라한 코드를 보았다.
원인을 찾을려고 했지만, 내가 이상한지 별다른 특이점은 없었다고 느껴 GPT에게 물어보았다.
GPT가 문제의 원인을 쉽게 찾아 주었다.
원인은 바로 MVC에 있었다고 한다.
문제 발생의 범인 발견! 🕵
문제의 원인을 찾았다. 그런데 왜 MVC가 문제의 원인이 되었을까?
AbstractGatewayFilterFactory와 GatewayFilter는 WebFlux 전용이라고 한다.
Spring Cloud Gateway는 설계 당시 WebFlux를 기반으로 만들었기 때문이다. WebFlux는 논블로킹 방식으로 요청을 처리하는데 해당 방식이 아닌 MVC에는 해당 클래스를 사용이 불가능 했기 때문에 문제가 발생했던 것이다.
발생한 문제에 대한 원인가 이유를 알았다.
그런데 WebFlux는 정확하게 무엇이며, 어떤 차이점을 갖고 있는가?
🧐 WebFlux와 MVC에 대하여
비동기와 동기
동기(Synchronous) : 호출과 응답이 동시적으로 일어나는 것, 함수를 호출 시 해당 위치에서 바로 응답을 받는다.
비동기(Asynchronous) : 호출과 응답이 동시적으로 일어나지 않는 것, 함수 호출 시 처리과정을 거친 이후 불특정 시점에서 호출에 대한 응답을 받는다.
블리킹과 논블로킹
blocking : 특정 함수 호출 시 해당 응답을 받기위해 멈춰있는 것을 의미한다. 예를 들면 특정 함수 호출 시 해당 함수에 대한 응답을 받고 다음 동작으로 넘어간다.
Non-blocking : 특정 함수 호출 시 응답을 받기위해 멈추는 것이 아닌 바로 다음 동작으로 넘어간다. 예를 들면 특정 함수를 호출하여 동작을 시키고 바로 다음 동작으로 넘어간다.
WebFlux
WebFlux는 Spring 5.0에서 비동기적으로 동작하는 논블로킹(Non-blocking), Reactive 프로그래밍 기반의 웹 프레임워크다.
Spring WebFlux는 비동기 논블로킹으로 동작하며, Netty, Undertow같은 논블로킹 런타임에서 실행이 가능하다. 또한 동시 처리에 대한 성능이 우수하며, 요청에 대한 쓰레드 점유가 짧아 고성능이 요구되는 환경에서 상당히 유리하다.
MVC
Spring MVC는 Servlet API를 기반으로 동작하는 동기식 블로킹 웹 프레임워이다. 요청이 들어오면 서블릿 컨테이너(Tomcat, Jetty 등)가 요청을 처리하고, 결과를 반환하기 전까지 스레드가 요청에 묶여 있습니다.
이렇기 떄문에 동시에 많은 요청이 들어오면 처리하지 못하는 문제가 발생된다.
| 특징 | Spring MVC | Spring WebFlux |
|---|---|---|
| 기반 아키텍처 | Servlet API 기반 | Reactive Streams 기반 |
| 동작 방식 | 동기식(블로킹) | 비동기식(논블로킹) |
| 기본 서버 | Tomcat, Jetty 등 서블릿 컨테이너 | Netty, Undertow, Tomcat 등 지원 |
| 성능 | 요청이 많아질수록 스레드 풀 제한 발생 | 더 많은 요청을 동시에 처리 가능 |
| 적용 대상 | 전통적인 REST API, 템플릿 기반 웹 애플리케이션 | 고성능 API 서버, 스트림 처리 등 |
| 병렬 처리 | 스레드당 요청 처리 | 이벤트 기반 논블로킹 처리 |
