[SCG] Spring Cloud Gateway는 왜 Netty 기반으로 만들어졌을까? 그리고 WebFlux란?

Blocking I/O를 보완한 Spring Cloud Gateway

자바 진영에서도 Non-blocking 기술이 등장하기 시작하였다. Blocking 기술의 경우 하나의 요청 당 하나의 스레드를 보장한다. 이러한 경우 여러 개의 스레드를 두더라도 딱 그 갯수만큼만의 요청을 처리할 수 있고, 다른 요청들은 모두 Ready queue에서 기다리게 되는 것이다.

대용량 트래픽을 처리하기 위해서는 하나의 스레드 당 여러 요청을 수행할 수 있어야 한다. Spring Cloud Gateway가 비동기 처리를 수행하는 Netty 기반 Reactive Web application으로 구동되는 이유도 동일하다. 전통적인 방식으로 Blocking 방식을 사용하는 Tomcat과 같은 WAS를 사용하게 되면 많은 요청을 처리할 수 없게 된다. 

 

정리하자면, Gateway는 수많은 요청을 큐에 넣어 적합한 서비스로 라우팅해주는 역할을 빠르게 수행하기 위해 Non-blocking I/O가 가능한 Reactive 스타일로 구현되었다.

 

WebFlux에 대해서

여기서 WebFlux를 언급해보자면, Servlet API와 Servlet 컨테이너로 이루어진 스프링 프레임워크에 5 버전부터 Reactive-stack web framework 이며 Non-blocking에 Reactive Stream을 지원하는 WebFlux가 추가되었다.

위에서 설명한 문장에 대해서 조금 더 부연설명 하자면,
 
스프링 프레임워크는 Servlet Stack, Reactive Stack 총 두 가지 스택이 있는데, 대부분의 Java 애플리케이션은 Blocking I/O를 사용하는 고전적인 Servlet Stack을 사용한다. Spring MVC, Spring Data 로 구성되어있으며 Tomcat, Jetty, Servlet Container에서 동작한다. 

반면에, 이벤트 루프, 비차단 실행 모델을 기반으로 하여 적은 하드웨어 리소스로 높은 동시성을 처리할 수 있는 Reactive Stack이 나왔다. Spring WebFlux와 Spring Data Reactive Repositories (반응형 저장소)로 구성되어 있으며 Netty, Undertiw와 같은 Non-blocking 서버 위에서 구동된다.

위에서 언급하였다시피, 추가적인 스레드의 사용을 줄이고 클라이언트 요청에 대한 대기 시간을 줄이기 위해 Non-blocking 서버 위에서 구동되는 Spring WebFlux가 등장하였다고 이해하면 된다.

Reactive라는 용어는 명령의 완료, 혹은 데이터의 제공 등의 알림에 반응하는 등 변경에 대한 반응에 중점을 두어 만들어진 프로그래밍 모델을 일컬어 말한다.

이렇게 기존의 Spring Framework가 가지고 있던 한계를 비동기 프로그래밍으로 보완하여 출시된 것이 WebFlux이고, Spring Cloud Gateway는 이러한 특성을 사용해 클라이언트의 요청을 빠르게 처리하기 위해 WebFlux와 Reactor 프로젝트를 기반으로 하여 만들어진 것이다.