webflux를 이제 막 살펴보고 있는데, 길가다 어떤분이 비유해주신 내용 보고 무릎을 탁! 하고 쳤다.
뭔가 신박하면서 명쾌한 설명인것 같아서 한번 알아보려고 한다.
기본 MVC가 벽에다가 공던지고 공받기라면
WebFlux는 공을 기차에 실어보낸다. 기차가 레일을 따라 한 바퀴 돌아서 공을 내려 준다.
용어정리 : 동기vs비동기, 블로킹vs논블로킹
webflux와 spring mvc를 비교하기전에 기본적인 개념부터 정리하고 가야한다.
왜냐면 이 개념이 전부이기 때문이다.....
동기(Synchronous)
동기는 말그대로 동시에 일어날수 있다는 뜻인데, 호출과 응답이 동시에 이루어 지는 것을 의미한다.
그래서 함수를 호출한 곳에서 바로 응답을 받는 것으로 비동기와 비교했을때 처리결과를 받는시점에 대한 차이가 있다.
비동기(Asynchronous)
비동기는 동기와 다르게 호출과 응답이 동시에 이루어지지 않는것을 의미한다.
호출시점과 처리결과에 대한 응답시점이 같지 않아서,
함수를 호출했을때 그에 대한 처리결과를 추후에 처리가 완료된 불특정 시점에 전달받는다.
블로킹(Blocking)
블로킹은 함수를 call 했을때 응답을 받기 위해 멈춰있는 상태를 의미한다. 그래서 함수가 종료되야 다음줄을 실행한다.
예를들어 hello()라는 함수를 만들었다고 하면,
hello()를 호출했을때 함수의 return이 있고나서 함수가 종료된다. 그리고 나서 다음줄의 코드를 실행 할 수 있다.
논블로킹(Non-Blocking)
논블로킹은 블로킹과 다르게 함수를 call 했을때 결과를 받기 위해 멈춰있지 않고 바로 다음줄을 실행하는 상태를 의미한다.
예를들어 hello()라는 함수를 만들었다고 하면,
hello()를 호출했을때 함수의 return이 아직 없어도 다음줄의 코드를 실행 할 수 있다.
여기까지 이해하고보면 결론을 내리면 Spring Boot는 동기적으로 동작하고, Webflux는 비동기적으로 동작한다!
이제 디테일하게 알아보도록 하자.
Spring MVC
Spring MVC는 동기적으로 동작하는 블로킹 방식이다.
- 사용자 요청마다 스레드를 계속 생성해야하는 문제 -> 스레드풀 생성
- 많은 사용자가 동시요청을 보내면 요청을 처리하지 못하는 문제 (Thread Pool Hell 현상) -> 그럼 어떻게?
- 시스템의 트래픽을 측정해서 thread pool size를 잘 조정해야한다.
일반적으로 spring framework와 srping boot를 쓰는 방식이다.
spring MVC의 핵심은 사용자 요청이 들어올때마다 스레드를 생성해서 처리한다는 점이다.
그래서 다수의 사용자 요청이 들어와서 계속 스레드를 생성하는것이 많은 리소스를 사용하게 된다.
이를 방지하기 위해서 어플리케이션이 실행될때 스레드를 생성하면서 thread pool을 만들어두는 것이다.
스레드 풀로 인해 요청이 들어오면 그 요청을 큐에 쌓아두고, 스레드풀에 미리 만들어둔 스레드를 하나씩 가져와서 사용하는 것이다.
하지만, 이 방식은 요청을 계속 처리하지 못하는 Thread Pool Hell 현상이 발생할 수 있다는 한계가 있다.
엄청나게 많은사용자가 동시에 요청을 보낼 경우 풀사이즈를 초과해서 큐에 계속 요청이 쌓이게 되는 것이다.
결국, spring mvc의 경우 해당 시스템의 트래픽을 측정해서 thread pool size를 조정하는 것이 매우 중요하다.
Spring MVC 방식은 많은 사용자의 요청을 대량으로 받아내는데는 한계가 있는데 이를 WebFlux가 해결해줄 수 있다.
WebFlux
Spring WebFlux는 비동기적으로 동작하는 논블로킹 방식이다.
- Reactive programming (반응형 프로그래밍)
- Event loop
- 모든 코드가 non-blocking하게 동작해야만 의미가 있다.
Node.js처럼 이벤트 루프가 돈다. 즉,리액티브 프로그래밍이 가능해진다.
요청이 발생할 경우 그것에 맞는 핸들러에게 처리를 위임하고, 처리가 완료되면 callback 메소드를 통해 응답한다.
비동기적이고 논블로킹 방식으로 동작하기 때문에 성능적으로 효율적이다.
자세한 webflux 동작방식은 여기에서 그림으로 쉽게 이해할 수 있다!! >> https://pearlluck.tistory.com/712
[WebFlux] 💚 Webflux 그림으로 이해하기(Reactive프로그래밍)
아래의 개념정리는 유튜브 메타코딩의 spring boot weblflux강좌를 요약한 내용입니다. webflux에 대한 개념이 1도 잡혀있지 않았는데 강의를 보고 진짜 금방 이해가 되었다. 정말 이해하기 쉽게 설명해
pearlluck.tistory.com
또한, webflux는 kotlin과 함께 사용하는 가볍고 기능적인 웹 프레임워크로 불린다.
Spring boot2부터 도입된 spring5에서 지원되는 스택중에 하나이다.
하지만 webflux가 '항상' 효율적이라고 볼 순 없다.
요청을 처리하는 파이프라인의 요소들이 모두 논블로킹하게 동작해야만 의미가 있는 것이다.
따라서 어떤 특정한 구간에서 블로킹이 발생하는 구간이 있다면
거기에서부턴 mvc처럼 요청을 계속 처리하지 못하는 Thread Pool Hell 현상이 발생할 수 있다는 것이다.
Spring MVC vs WebFlux
그렇다면 마지막으로 공식문서에 나와있는 검색하면 항상 나오는 이 벤다이어그램으로 정리해보려고 한다.
차이점은 위에서 간단하게 설명했으니 공통점을 중심으로 요약하고 끝내야겠다.
공통점
- @Controller
- Reactive Client
- 실행가능한 서버 : Tomcat, Jetty, Unvertow
차이점
| Spring MVC | Webflux |
| 동기(Synchronous)적인 방식 | 비동기(Asynchronous)적인 방식 |
| 블로킹(Blocking) 방식으로 구현 | 논블로킹(Non-Blocking) 방식으로 구현 (단, 모든 코드가 논블로킹하게 동작해야만 의미가 있다) |
| 명령형(Imperative)프로그래밍 (Webflux보다 작성하기 쉽고 디버깅하기 쉽다) |
반응형(Reactive) 프로그래밍 |
| JDBC,JPA 네트워킹 지원 | 반응형 라이브러리(Reactor,RxJava) 지원 |
이제 다시 처음으로 돌아가서 webflux와 mvc를 비교한 비유를 보자.
기본 MVC가 벽에다가 공던지고 공받기라면
WebFlux는 공을 기차에 실어보낸다. 기차가 레일을 따라 한 바퀴 돌아서 공을 내려 준다.
여기에서 '공을 던지고 받는다'라는게 요청을 처리하는 것이라고 볼 수 있을거 같다.
그래서 mvc는 사용자 요청마다 하나씩 동기적으로 처리하기 때문에 벽에다가 공을 던지고 받는다고 표현한 것 같고,
webflux는 이벤트 루프를 가지고 비동기적으로 처리하기 때문에 공을 기차에 실어 보낸다고 표현한 것 같다.
그리고 논블로킹 방식이기 때문에 멈추지 않고 레일에서 한바퀴 돌고나서 요청을 받는다는것을 의미한것 같다.
참고
'Language > Java' 카테고리의 다른 글
| 자바와 코를린에서 Annotation(어노테이션) 정리 (0) | 2022.02.10 |
|---|---|
| [Webflux]💙Mono와 Flux > Reactor > Reactive Streams 이해 (0) | 2022.02.08 |
| [Spring][MVC] RedisTemplate으로 Spring과 Redis와 연동하기 (0) | 2022.02.08 |
| [Webflux](보류)Java기반 Spring webflux 시작하기 - RestController 방식 (0) | 2022.02.01 |
| [Webflux](보류)Java기반 Spring webflux 시작하기 - Handler방식 (0) | 2022.02.01 |
| [Webflux + Kotlin] Intellij에서 gradle로 Kotiln기반 Spring webflux 프로젝트시작하기 (0) | 2022.02.01 |
