Web on Reactive Stack (spring.io)
Spring 공식 문서의 Web on Reactive Stack Spring WebFlux를 번역합니다.
모든 저작권은 docs.Spring.io 에 있습니다. All copyrights are in docs.spring.io
들어가며
최근 node.js를 공부하고 있다. 깊게 공부하진 못하고 in action 수준으로 하고 있다. 주로 작업하는 스프링 환경에서 벗어나니 새로운 기분이다. 시야가 넓어진다. 재밌다(?)
Single Thread, asynchronous와 Promise. 반응형, 동시성 프로그래밍을 접하며 의문이 들었다.
스프링은 이거 왜 안하지?
구글로 서칭했고 당연하게도 스프링은 asynchronous 비동기 프로그래밍을 지원한다. Spring WebFlux가 그것이다.
Spring 5부터 웹 애플리케이션의 반응형 프로그래밍을 지원하는 Spring WebFlux가 제공되었다.
그래서 WebFlux란 무엇인가.
Spring 공식 문서의 Web on Reactive Stack - Spring WebFlux를 읽고 정리하며 알아보자.
Spring Weflux
Spring Framework가 지원하는 기존 웹 프레임워크인 Spring Web MVC는 Servlet API 및 Servlet 컨테이너를 위해 제작되었다.
WebFlux는 Spring의 reactive-stack 웹 프레임워크이다. Spring 5부터 지원되었고, Netty, Undertow, Servlet 3.1 버전 이상에서 지원된다.
Spring WebFlux는 non-blocking에 *reactive streams을 지원하며, 기존 Spring MVC에 대안으로 여겨진다.
결론부터 말하자면 스프링으로 비동기 프로그래밍을 하겠다는 것이다.
출처: https://spring.io/reactive
두 웹 프레임워크 모드 소스 모듈(Spring-WebMVC와 Spring-WebFlux)의 이름을 반영하며 스프링 프레임워크에 동시에 존재한다. 각 모듈은 선택사항이다.
애플리케이션은 하나 또는 다른 모듈을 사용할 수 있다. 예를 들어 Spring WebMVC와 reactive 반응형 WebClient를 함께 사용할 수 있다.
Spring WebFlux는 내부적으로 프로젝트 반응자 Project Reactor와 그것을 구현한 *Flux(0..N)와 Mono(0..1)를 사용한다.
이들은 *두개의 프로그래밍 모델을 지원한다.
-
Annotaion 기반 반응형 컴포넌트
-
함수형 라우팅과 핸들링
*(reactive streams와 Flux와 Mono 그리고 두개의 프로그래밍에 대해서는 나중에 이야기 하겠다.)
Spring WebFlux 등장 배경
Spring WebFlux는 왜 등장했는가?
적은 스레드로 동시성을 처리하고 더 적은 하드웨어 리소스로 확장 가능한 non-blocking 웹 기술에 대한 요구가 있었다.
Servlet 3.1부터 non-blocking I/O를 위한 API를 제공하기 시작했다.
그러나 이는 Synchronous 동기화(Filter, Servlet) 또는 blocking 차단 (getParameter, getPart) 하도록 약속된 많은 기존 레거시 Servlet API와는 거리가 있었다.
그래서 Spring WebFlux는 SpringMVC와 달리 Servlet과는 전혀 관계없이 만들어졌으며, 더이상 WAS가 필요하지 않았다.
asynchronous 비동기 non-blocking 비차단 영역에 최적화된 서버 Netty를 기반으로 하지만 별도 설정을 통해 다른 Servlet 3.1 스펙을 준수하는 WAS 엔진(Tomcat, Jetty) 등을 사용할 수는 있다. 하지만 Netty 권장. 또한 Project Reactor를 통해 Reactive Programming을 지원한다. (Project Reactor에 대해선 나중에 이야기하겠다.)*
또 다른 측면에선 함수형 프로그래밍이 있었다. Java 5에서 annotation을 지원하며 새로운 장이 열린 것처럼(Rest Controller, or Unit Test) Java 8에서 lambda 람다를 지원하며 Java에서 함수형 프로그래밍에 대한 가능성을 보여주었다.
비동기 로직의 선언적 구성을 허용하는 non-blocking 애플리케이션과 연속 스타일의 API의 장점이 그것이다. 프로그래밍 모델 측면에서 Java 8은 Spring WebFlux가 annotated controller와 함께 기능적인 웹 엔드포인트를 제공하게 해주었다.
Reactive 반응성 정의
non-blocking과 functional은 알겠다. 그렇다면 반응적 reactive이라는 말은 무슨 뜻일까.
reactive 반응적, 반응형 이라는 용어는 I/O 이벤트에 반응하는 네트워크 구성 요소, 마우스 이벤트에 반응하는 UI 컨트롤러 등 변화에 반응하는 것을 중심으로 구축된 프로그래밍 모델을 말한다.
그런 의미에서 non-blocking은 반응적이다. block되는 대신 작업이 완료되거나 데이터를 사용할 수 있게 되면 알림에 반응하는 모드에 있기 때문이다.
Spring에서 반응성과 연관시키는 또 다른 중요한 매커니즘이 있는데, 그것은 non-blocking back pressure 배압이다. 동기식 명령형 코드에서 blocking call 차단 호출은 호출자가 대기하도록 하는 자연스러운 형태의 back pressure 역할을 한다. 비차단 non-blocking 코드에서는 빠른 생산자가 대상을 압도하지 않도록 이벤트 속도를 제어하는 것이 중요하다.
Reactive Stream은 back pressure가 있는 비동기 구성 요소 간의 상호 작용을 하는 small spec이다.
예를 들어 데이터 저장소(Publisher 역할) 은 HTTP 서버(Subscriber 역할)가 쓸 수 있는 데이터를 생성할 수 있다.
Reactive Streams의 주요 목적은 구독자가 ‘게시자가 데이터를 생성하는 속도’를 제어할 수 있도록 하는것이다.
Reactive API 반응형 API
Reactive Stream은 상호 운용성에 중요한 역할을 한다. 라이브러리와 인프라 컴포넌트에는 유용하지만 성능이 낮아 애플리케이션 API로는 비효율적이다. 애플리케이션에는 Java 8 Stream API와 유사하지만 컬렉션용뿐만 아니라 비동기 로직을 구성하기 위해 더 높은 성능의 기능성 API가 필요한데, 이것이 반응형 라이브러리의 역할이다.
Reactor는 Spring WebFlux를 위해 선택된 반응형 라이브러리이다. Mono와 Flux를 지원한다.
Reactor는 Reactive Streams 라이브러리이며 결과적으로 Reactor의 모든 연산자는 non-blocking back pressure를 지원한다.
Reactor는 server-side Java를 매우 중요시하며, Spring과 긴밀히 협력하여 개발하였다.
WebFlux는 Reactor를 핵심 dependency로 두지만 Reactive Streams를 통해 다른 상호 운용을 가진다.
일반적으로, WebFlux API는 순수한 Publisher를 입력으로 받고, 내부적으로 이를 Reactor 유형에 맞게 조정한 다음 이를 사용하여 Flux 또는 Mono를 출력으로 반환한다.
따라서 모든 Publisher를 입력으로 받을 수 있으며 출력에 연산을 적용할 수 있지만, 다른 반응형 라이브러리를 사용하기 위해 출력을 조정해야 한다. WebFlux는 가능한 경우(ex: annotated controllers) RxJava 또는 다른 반응형 라이브러리의 사용에 투명하게 적응합니다. 자세한 내용은 reactive library 항목에서 찾아볼 수 있다.
Programming Models 프로그래밍 모델
Spring-web 모듈은 HTTP 추상화, 지원되는 서버, 코덱, 그리고 Servlet API와 비슷하지만 non-blocking 작업을 지원하는 핵심 WebHandler API 들을 위한 Reactive Streams adapter, 반응성 기반을 포함하고 있다.
이 기반을 바탕으로 Spring WebFlux는 두 가지 프로그래밍 모델을 선택할 수 있다.
Annotated Controllers: Spring MVC와 일치하며 스프링 웹 모듈의 동일한 annotation들을 기반으로한다. Spring MVC와 WebFlux 컨트롤러 모두 반응형(Reactor 및 RxJava) 반환 유형을 지원하므로 결과적으로 이를 떼어놓고 얘기하기는 쉽지않다. 한 가지 주목할만한 차이는 WebFlux는 반응형 @RequestBody 요소 또한 지원한다는 것이다.
Functional Endspoints: 람다 기반의 가벼운 항수형 프로그래밍 모델이다. 애플리케이션이 요청을 라우팅하고 처리하는 데 사용할 수 있는 작은 라이브러리, 혹은 유틸리티 세트라고 생각할 수 있다.
annotated controller과의 차이는 애플리케이션이 처음부터 끝까지 요청 처리를 담당하는 것(annotated controller)과 주석을 통해 의도를 선언하고 called back이 된다는 것(functional endspoints)이 둘 사이의 가장 큰 차이이다.
Applicability 유용성
그래서, Spring MVC? 아님 WebFlux?
당연한 질문이지만 둘 중 하나만 선택할 순 없다.
실제로, 두 가지 모두 사용 가능한 옵션의 범위를 확장하기 위해 협력하고 있다.
이 두 가지는 서로 연송성과 일관성을 유지하도록 설계되었고, 함께 사용할 수 있으며, 양측의 피드백이 서로에게 좋은 영향을 미치고 있다.
다음 다이어그램은 두 가지가 어떤 관련성을 가지고, 공통으로, 또는 독립적으로 지원하는 내용을 보여준다.
당신이 다음 몇 가지를 고려했으면 한다.
Spring WebMVC 애플리케이션이 정상적으로 작동하는 경우 변경할 필요가 없다. 명령형 프로그래밍은 코드를 쓰고, 이해하고, 디버깅하는 가장 쉬운 방법이다.
역사적으로 대부분의 라이브러리가 blocking 형태이기 때문에 라이브러리를 최대한 선택할 수 있다.
이미 non-blocking 웹 스택을 사용하고 있는 경우 Srping WebFlux는 해당 분야의 다른 제품과 동일한 실행 모델의 이점을 제공하며, 서버(Netty, Tomcat, Jetty, Underow 및 Servlet 3.1+ 컨테이너), 프로그래밍 모델(주목되지 않은 컨트롤러 및 기능적인 웹 엔드포인트)와 반응형 라이브러리(Reactor, RxJava 또는 기타) 선택할 수 있다.
(번역중)
REFERENCE
