Spring WebFlux

Bloking I/O

Block I/O는 어플리케이션에서 I/O 요청을 한 후, 완료되기 전까지는 Application이 Block 되어 다른 작업을 수행할 수 없습니다. 이는 해당 자원이 효율적으로 사용되지 못하고 있음을 의미합니다.
하지만 실제 어플리케이션들은 Blocking 방식임에도 불구하고 마치 Block이 안 되듯이 동작하는 것처럼 보입니다. 이것은 Single Thread 기반이 아닌 Multi Thread를 기반으로 동작하기 때문입니다. Block 되는 순간 다른 Thread가 동작함으로써 Block의 문제를 해소하였습니다. 그러나 Thread 간 전환에 드는 비용이 존재하므로 여러 개의 I/O를 처리하기 위해 여러 개의 Thread를 사용하는 것은 비효율 적으로 보입니다.

Synchronous Non-Blocking I/O

어플리케이션에서 I/O 요청 후 바로 return 되어 다른 작업을 수행하다가 특정 시간에 데이터가 준비가 되었는지 상태를 확인합니다. 데이터의 준비가 끝날 때까지 틈틈이 확인을 하다가 완료가 되었으면 종료합니다. 여기서 주기적으로 체크하는 방식을 폴링(Polling)이라고 합니다. 그러나 이러한 방식은 작업이 완료되기 전까지 주기적으로 호출하기 때문에 불필요하게 자원을 사용하게 됩니다.

Asynchronous Non-Blocking I/O

I/O 요청을 한 후 Non-Blocking I/O와 마찬가지로 즉시 리턴됩니다. 하지만 데이터 준비가 완료되면 이벤트가 발생하여 알려주거나, 미리 등록해놓은 callback을 통해서 이후 작업이 진행됩니다. 이전 두 I/O의 문제였던 Blocking이나 Polling이 없기 때문에 자원을 보다 더 효율적으로 사용할 수 있습니다.

Spring WebFlux란

Spring WebFlux는 Spring 5에서 새롭게 추가된 모듈입니다. WebFlux는 클라이언트, 서버에서 reactive 스타일의 어플리케이션 개발을 도와주는 모듈이라고 합니다. WebFlux는 reactive-stack web framework이며 non-blocking에 reactive stream을 지원합니다.
WebFlux를 만든 이유는 다음과 같습니다.

1. 적은 양의 스레드와 최소한의 하드웨어 자원으로 동시성을 핸들링하기 위해 만들어졌습니다. 서블릿 3.1이 non-blocking을 지원하지만, 일부분입니다.
2. 함수형 프로그래밍 때문입니다. Java 5에서 RestController나 Unit Test가 만들어지고, Java 8에서는 함수형 API를 위한 Lambda 표현식이 추가되었습니다. 이는 non-blocking 어플리케이션 API의 토대가 되었습니다.

Spring WebFlux의 동작 흐름

1. 웹 서버로 들어온 요청이 HttpHandler에서 전달되면 HttpHandler는 전처리 후, WebHandler에 처리를 위임합니다.
2. WebHandler 내부에서 HandlerMapping, HandlerAdapter, HandlerResultHandler 3개의 컴포넌트가 요청과 응답을 처리합니다.
3. 처리가 끝나면, HttpHandler가 후처리 후 응답을 종료합니다.

Spring WebFlux가 적은 리소스로 많은 트래픽을 감당하는 방법

Spring WebFlux는 사용자들의 요청이 들어오면 Event Loop를 통해서 작업이 처리됩니다. 우리가 일반적으로 아는 구조와의 차이점은 다수의 요청을 적은 Thread로 커버할 수 있다는 점입니다.

https://alwayspr.tistory.com/44