[📕 Reactive] Spring WebFlux

Spring WebFlux 개요

Spring 5.0부터 지원하는 리액티브 웹 프레임워크로, 적은 수의 스레드로 대량의 요청을 안정적으로 처리할 수 있는 비동기 Non-Blocking I/O 방식을 사용한다. 

 

 

 

 

Spring WebFlux 기술 스택

 

✳️ Spring MVC와 Spring WebFlux 기술 스택 비교 

https://spring.io/reactive

 

🔷 서버

• Spring MVC
  • 서블릿 기반의 프레임워크
  • Apache Tomcat같은 서블릿 컨테이너에서 Blocking I/O 방식으로 동작
• Spring WebFlux
  • Non-Blocking I/O 방식으로 동작하는 Netty 등의 서버 엔진에서 동작

 

🔷 서버 API

• Spring MVC
  • 서블릿 API 사용
• Spring WebFlux 
  • Jetty나 Undertow 같은 서버 엔진에서 지원하는 리액티브 스트림즈 어댑터를 통해 리액티브 스트림즈 지원

 

🔷 보안

• Spring MVC
  • Spring Security가 서블릿 컨테이너와 통합
• Spring WebFlux 
  • Webfilter를 이용해 Spring Security 사용

 

🔷 데이터 액세스

• Spring MVC
  • Blocking I/O 방식인 Spring Data JDBC, Spring Data JPA, Spring Data MongoDB 같은 기술 사용
• Spring WebFlux 
  •  데이터 액세스 계층까지 완벽하게 Non-Blocking I/O를 지원할 수 있도록 Spring Data R2DBC 및 Non-Blocking I/O를 지원하는 NoSQL 모듈 사용 

 

 

 

 

Spring WebFlux의 요청 처리 흐름

1. 최초에 클라이언트로부터 요청이 들어오면 Netty 등의 서버 엔진을 거쳐 HttpHandler가 들어오는 요청을 전달받음. HttpHandler는 Netty 이외의 다양한 서버 엔진에서 지원하는 서버 API를 사용할 수 있도록 서버 API를 추상화해주는 역할을 함. 
   각 서버 엔진마다 주어지는 ServerHttpRequest와 ServerHttpResponse를 포함하는 ServerWebExchange를 생성한 후, WebFilter 체인으로 전달함.
2. ServerWebExchange는 WebFilter 체인에서 전처리 과정을 거친 후, WebHandler 인터페이스의 구현체인 DispatcherHandler에게 전달됨.
3. DispatcherHandler에서는 클라이언트로부터 오는 Http 요청을 적절한 Handler로 라우팅하고, HandlerMapping List를 원본 Flux의 소스로 전달받음.
4. ServerWebExchange를 처리할 핸들러를 조회
5. 조회한 핸들러의 호출을 HandlerAdapter에게 위임
6. HandlerAdapter는 ServerWebExchange를 처리할 핸들러를 호출함
7. Controller 또는 HandlerFunction 형태의 핸들러에서 요청을 처리한 후, 응답 데이터 리턴
8. 핸들러로부터 리턴받은 응답 데이터를 처리할 HandlerResultHandler를 조회
9. 조회한 HandlerResultHandler가 응답 데이터를 적절하게 처리한 후, response로 리턴

 

 

 

 

Spring WebFlux의 핵심 컴포넌트

✳️ HttpHandler

• 다른 유형의 HTTP 서버 API로 request와 response를 처리하기 위해 추상화된 단 하나의 메서드만 가짐

public interface HttpHandler {
	Mono<Void> handle(ServerHttpRequest request, ServerHttpResponse response);
}

public class HttpWebHandlerAdapter extends WebHandlerDecorator implements HttpHandler {
	...
    ...
    
    @Override
    public Mono<Void> handle(ServerHttpRequest request, ServerHttpResponse response) {
    
    	...
        ...
        ServerWebExchange exchange = createExchange(request, response);
    }
}

👉 ServerHttpRequest와 ServerHttpResponse로 ServerWebExchange를 생성한 후에 WebHandler 호출 

 

 

✳️ WebFilter

• 핸들러가 요청을 처리하기 전에 전처리 작업을 할 수 있도록 함
• 어플리케이션 내에 정의된 모든 핸들러에 공통으로 동작
  👉 어노테이션 기반의 요청 핸들러와 함수형 기반의 요청 핸들러에서 모두 동작 가능
• 주로 보안이나 세션 타임아웃 처리 등 어플리케이션에서 공통으로 필요한 전처리에 사용됨

public interface WebFilter {
	Mono<Void> filter(ServerWebExchange exchange, WebFilterChain chain);
}

👉 WebFilterChain을 통해 필터 체인을 형성하여 원하는 만큼의 WebFilter 추가 가능

 

@Component
public class BookLogFilter implements WebFilter {
	@Override
    public Mono<Void> filter(ServerWebExchange exchange, WebFilterChain chain) {
    	String path = exchange.getRequest().getURI().getPath();
        
        return chain.filter(exchange).doAfterTerminate(() -> {
        	if(path.contains("books")) {
            	System.out.println("path : " + path + ", status : " +
                	exchange.getResponse().getStatusCode());
            }
        });
    }
}

👉 doAfterTerminate() operator를 이용해 종료 이벤트(onComplete, onError) 발생 시, 요청 URI path에 "books"가 포함되어 있다면 Book 리소스에 대한 요청이라고 간주하고 로그 출력

 

 

✳️ HandlerFilterFunction

@FunctionalInterface
public interface HandlerFilterFunction<T extends ServerResponse, R extends ServerResponse> {
	Mono<R> filter(ServerRequest request, HandlerFunction<T> next);
    
    ...
    ...
}

• 함수형 기반의 요청 핸들러에 적용할 수 있는 Filter 👉 WebFilter와 달리 Spring Bean으로 등록되지 않음 

 

✳️ DispatcherHandler

• WebHandler 인터페이스의 구현체로서, 중앙에서 먼저 요청을 전달받은 후에 다른 컴포넌트에 요청 처리 위임 

---

 

🔷 DispatcherHandler 코드 일부 

 

🔹initStrategies(ApplicationContext context)

• BeanFactoryUtils를 이용해 ApplicationContext로부터 HandlerMapping Bean, HandlerAdapter Bean, HandlerResultHandler Bean을 검색한 후에 각각의 List 객체 생성

 

🔹 handle(ServerWebExchange exchange)

• List<HandlerMapping>을 Flux.fromIterable() operator의 원본 데이터 소스로 입력받은 후에 getHandler() 메서드를 통해 매치되는 Handler 중에서 첫 번째 핸들러 사용

• handleRequestWith(ServerWebExchange exchange, Object handler)를 통해 핸들러 호출 위임
• 실제 핸들러 호출은 handleRequestWith() 내부에서 Handler 객체와 매핑되는 HandlerAdapter를 통해서 이루어짐

 

• handleResult(ServerWebExchange exchange, HandlerResult result)를 통해 응답 처리 위임

 

 

✳️ HandlerMapping

• request와 handler object에 대한 매핑을 정의하는 인터페이스

public interface HandlerMapping {
	...
    ...
    Mono<Object> getHandler(ServerWebExchange exchange);
}

 

 

 

✳️ HandlerAdapter

• HandlerMapping을 통해 얻은 핸들러를 직접적으로 호출

public interface HandlerAdapter {
	boolean supports(Obejct handler);
    
    Mono<HandlerResult> handle(ServerWebExchange exchange, Object handler);
}

 

 

 

 

Spring WebFlux의 Non-Blocking 프로세스 구조

• Non-Blocking I/O 방식으로 스레드가 차단되지 않기 때문에 적은 수의 고정된 스레드 풀을 사용해서 더 많은 요청 처리
  👉 요청 처리 방식 = 이벤트 루프 방식 

Non-Blocking 프로세스

 

1. 클라이언트로부터 들어오는 요청을 요청 핸들러가 전달받음
2. 전달받은 요청을 이벤트 루프에 푸시
3. 이벤트 루프는 네트워크, 데이터베이스 연결 작업 등 비용이 드는 작업에 대한 콜백을 등록
4. 작업이 완료되면 완료 이벤트를 이벤트 루프에 푸시
5. 등록한 콜백을 호출해 처리 결과를 전달

 

 

 

Spring WebFlux의 스레드 모델

 

✳️ Reactor Netty의 LoopResource 인터페이스

• Netty에서는 CPU 코어 개수가 4보다 적은 경우 최소 4개의 워커 스레드를 생성하고, 4보다 더 많다면 코어 개수만큼의 스레드를 생성함
• 하지만 서버 측에서 복잡한 연산을 처리하는 등의 CPU 집약적인 작업을 하거나, 클라이언트의 요청부터 응답 처리 전 과정 안에 Blocking 되는 지점이 존재한다면 오히려 성능이 저하됨 
  👉 이러한 성능 저하를 보완하고자 클라이언트의 요청을 처리하기 위해 서버 엔진에서 제공하는 스레드 풀이 아닌 스케줄러를 사용

 

 

 

 

참고 자료

https://github.com/spring-projects/spring-framework/blob/main/spring-webflux/src/main/java/org/springframework/web/reactive/DispatcherHandler.java