Webflux와 R2DBC

https://velog.io/@effirin/R2DBC-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0-3.-Webflux%EC%99%80-R2DBC

[R2DBC 알아보기] 3. Webflux와 R2DBC

현업에서 주로 Spring Webflux랑 R2DBC를 같이 사용한다고 하여, 이 참에 블로그에 정리하고자 한다!

본 글은 위에 블로그를 참고하였습니다.

---

Spring MVC와 Spring Webflux의 차이점

- blocking / non-blocking

 

스프링 MVC와 스프링 Webflux간 차이점은 동시성 모델과 블로킹/쓰레드 기본 전략이 다르다.

MVC에서는 애플리케이션이 스레드를 blocking 할 수 있다는 가정 하에 큰 쓰레드 풀을 가지고 있고,

WebFlux는 스레드가 차단되지 않아(non-blocking) 적은 스레드풀을 사용하여 request를 처리한다.

 

Spring MVC 어플리케이션은 Imperative logic(명령형 로직)이다.

스프링 MVC는 블로킹 방식을 사용했기 때문에, 사용할 수 있는 라이브러리가 가장 풍부하다.

 

다른 웹 스택과 같은 실행 환경을 제공하면서도, 다양한 서버(Netty, Tomcat, Jetty, Undertow 등)와 여러 리액티브 라이브러리(리액터, JxJava 등)를 지원하며, 두 가지 프로그래밍 모델(어노테이션을 선언한 컨트롤러와 엔드포인트)를 사용할 수 있다.

 

 

Spring MVC vs Spring Webflux

마이크로 서비스 아키텍처' → 두 프레임워크 조합 가능

 

블로킹 방식의 JPA, JDBC를 쓰고 있을 경우 → Spring MVC
블로킹 방식의 persistence API (JPA, JDBC)나 네트워크 API를 사용하고 있다면 Spring MVC가 최소한 아키텍처를 통일할 수 있으므로 가장 좋은 정책이다

 

비동기, non-blocking 리액티브 서비스 + 마이크로서비스 아키텍처 + Spring → Spring Webflux
비동기, non-blocking 리액티브 서비스를 만들고자 할 때, 특히 서비스 간의 호출이 잦은 마이크로서비스 아키텍처인 상황에서 다른 프레임워크가 아닌 Spring을 계속해서 사용하고 싶다면 Spring Webflux의 도입을 추천한다.

 

 

Webflux와 R2DBC

 R2DBC + Webflux가 높은 동시성때는 좋은 선택이다.

[blocking과 non-blocking을 중심으로 각 기술들의 조합을 비교]

 

(응답 시간 / 처리량 / CPU 사용량 / 메모리 사용량)를 통해 얻은 결론을 각 비교군 별로 요약)

 

• Spring Web MVC + JDBC
  • 낮은 concurrency 에서는 Spring MVC + JDBC가 제일 최선의 선택이다.
• Spring Web MVC + R2DBC
• Spring WebFlux + JDBC
  • WebFlux + JDBC는 동시성 처리에서 최악의 선택. (non-blocking 을 선택할 때 blocking component가 있는지 꼭 체크해야 된다.)
• Spring WebFlux + R2DBC
  • 높은 concurrency에서 좋은 선택 (WebFlux라고 무조건 높은 concurrency를 보장하는건 아니다. R2DBC 덕분에 높은 concurrency 시에 빠른 응답 시간을 가진다.)