동기vs비동기, 블로킹vs논블로킹
동기(Synchronous)
동시에 일어날 수 있다. 호출과 응답이 동시에 이루어 지는 것을 의미한다.
순차적으로 실행되므로 제어하기 쉬움
호출한 작업이 완료될 때까지 대기하므로 여러 작업을 동시에 처리할 수 없음
함수를 호출한 곳에서 바로 응답을 받는 것으로 비동기와 비교했을때 처리결과를 받는 시점에 대한 차이가 있다.
비동기(Asynchronous)
호출과 응답이 동시에 이루어지지 않는 것을 의미한다.
호출시점과 처리결과에 대한 응답시점이 같지 않아서, 함수를 호출했을때 그에 대한 처리결과를 추후에 처리가 완료된 불특정 시점에 전달받는다.
블로킹(Blocking)
함수를 call했을때 응답을 받기 위해 멈춰있는 상태를 의미한다. 그래서 함수가 종료되야 다음줄을 실행한다.
예를들어 B라는 함수를 만들었다고 하면 B를 호출했을때 함수의 return이 있고나서 함수가 종료된다.
그리고 나서 다음줄의 코드를 실행할 수 있다.
논블로킹(Non-Blocking)
call 했을때 결과를 받기 위해 멈춰있지 않고 바로 다음줄을 실행하는 상태를 의미한다.
예를 들어 B라는 함수를 만들었다고 하면,
B를 호출했을때 함수의 return이 아직 없어도 다음줄의 코드를 실행할 수 있다.
Spring Boot는 동기적으로 동작하고, WebFlux는 비동기적으로 동작한다!
Spring MVC
동기적/블로킹
Spring MVC는 전통적인 서블릿 기반의 웹 프레임워크입니다.
사용자 요청이 들어올때마다 스레드를 생성해서 처리한다는 점이다. 1:1로 요청하기 때문에 트래픽이 몰리면 많은 스레드가 생긴다.스레드가 전환될 때 문맥교환비용이 발생한다. 스레드 풀로 인해 요청이 들어오면 오청을 큐에 쌓아두고, 스레드풀에 미리 만들어둔 스레드를 하나씩 가져와서 사용하는 것이다.
Webflux
비동기/논블로킹
Spring 5에서 새롭게 추가된 Reactive-Stack의 웹 프레임워크이며, 클라이언트/서버에서 리액티브(reactive) 애플리케이션 개발을 위한 논블로킹 리액티브 스트림을 지원합니다.
WebFlux가 생긴 이유는?
1. 적은 양의 스레드와 최소한의 하드웨어 자원으로 동시성을 핸들링 하기 위해 만들어졌다.
2.함수형 프로그래밍 때문이다. Java5에서 RestControllers나 unit test가 만들어지고, Java8에서 함수형 API를 위한 람다식이 추가됐는데 이는 논블로킹(non-blocking)어플리케이션 API의 토대가 되었다.
3.논블로킹으로 동작하는 웹 스택의 필요성 떄문에 등장하게 되었다. 기존 SpringMVC의 Servlet API는 v3.1부터 논블로킹을 위한 API를 제공했었다. 하지만 이외의 동기적으로 처리하는 모듈(Filter, Servlet)과 블로킹 방식의 API(getParameter, getPort)들이 있기에 완벽한 논블로킹 환경의 개발을 할 수 있었으며, 비동기 논블로킹 환경의 서버로 Netty가 부상하고 있었으며 이 Nety와의 연동을 위해 Spring은 새로운 API가 필요했다.
공통점
- @Controller
- Reactive Client
- 실행가능한 서버: Tomcat, Jetty, Unvertow
차이점
| Spring MVC | Webflux |
| 동기(Synchronous)적인 방식 | 비동기(Asynchronous)적인 방식 |
| 불로킹(Blocking)방식 | 논블로킹(Non-Blocking)방식으로 구현 (단, 모든 코드가 논블로킹하게 동작해야만 의미가 있다) |
| 명령형(Imperative)프로그래밍 (Webflux보다 작성하기 쉽고 디버깅하기 쉽다) |
반응형(Reactive) 프로그래밍 |
| JDBC, JPA 네트워킹 지원 | 반응형 라이브러리(Reactor, RxJava) 지원 |
MVC는 '공을 던지고 받는다'
사용자 요청마다 하나씩 동기적으로 처리하기 때문이다.
Webflux는 '공을 기차에 실어보낸다. 기차가 레일을 따라 한 바퀴 돌아서 공을 내려 준다.
이벤트 루프를 가지고 비동기적으로 처리하기 때문에 공을 기차에 실어 보낸다고 표현한 것 같다.
논블로킹 방식이기 때문에 멈추지 않고 레일에서 한바퀴 돌고나서 요청을 받는다
왜 Webflux가 아니라 MVC로 개발했지?
Spring MVC에 적합한 시스템
- 블로킹 방식의 의존성(JDBC, JPA 등)을 사용
- 현재 애플리케이션이 정상적으로 동작하고 있고, 특별한 성능 이슈가 없는 경우
Stoyanchev(Spring 핵심 개발자)의 의견: 현재 애플리케이션이 spring-mvc에서 제대로 실행되고 있고 스택 변경을 요구하는 문제가 없다면 spring-mvc를 유지해야 한다고 제안합니다. 그는 또한 애플리케이션 종속성에 대해 생각하는 것이 좋은 생각이라고 제안합니다. 애플리케이션에 차단 종속성이 있는 경우 Spring MVC 스택을 유지하는 것이 좋습니다.
Spring WebFlux 에 적합한 시스템
- 비동기, non-blocking reactive 개발에 사용하는 경우(실시간 알람, 채팅 서비스, 라이밍 스트리밍)
- 효율적으로 동작하는 고성능 웹어플리케이션 개발에 사용
- 서브스간 호출이 많은 마이크로서비스 아키텍처에 적합(네트워크 I/O병목을 최소화)
WebFlux 문제점은?
WebFlux의 경우, 내부적으로 사용되는 비-데몬(non-daemon) 스레드이다. 모든 비데몬 스레드가 종료되기 전까지 JVM이 종료되지 않아 애플리케이션을 명시적으로 종료해야 한다.
데몬 스레드 → JVM 종료 시 자동 종료 (백그라운드 작업에 적합)
비데몬 스레드 → JVM이 종료될 때까지 실행 (웹 서버에 적합)
'cs > dev' 카테고리의 다른 글
| [운영체제]뮤텍스(mutex), 세마포어(semaphore), 모니터(Monitor) (0) | 2025.11.17 |
|---|---|
| [Spring]JPA N + 1 문제 (0) | 2025.11.09 |
| [Spring]Spring의 3가지 핵심 프로그래밍 모델(AOP, DI, IOC) (0) | 2025.10.22 |
| [CS]MVC패턴 (0) | 2025.10.17 |
| [CS]TDD(테스트 주도 개발) (1) | 2025.10.17 |