Skip to Content
Suffering builds character

7.MVC, WebFlux 비교

일반적으로 MVC는 Blocking IO 방식으로 동작하며, WebFlux는 Non-Blocking IO 방식으로 동작함

각 방식들의 차이를 비교하면 다음과 같음

1-1. MVC 기반의 Blocking IO

먼저 MVC 기반의 Blocking IO 방식에서는, 스레드가 작업을 처리하는 과정 중에 DB IO를 포함하여 외부 API 호출와 같은 IO 작업이 포함되어 있을 경우, 해당 시간만큼 스레드가 차단되는 방식으로 동작함

만약 클라이언트가 Commerce 서비스를 통해 자신이 구매한 상품에 대한 배송 정보를 확인하기 위해서는 Commerce 서비스로 배송 정보 조회 요청을 전송해야 하며,

2번 이상의 배송 정보 조회 요청을 하나의 스레드에서 모두 처리한다고 가정할 경우,

첫 번째 요청이 모두 완료되어야 두 번째 요청 처리가 시작되기 때문에 각 요청마다 스레드가 차단된 시간만큼 전체 처리 시간이 지연됨

💡
Tip

실제 상황에서는 각 요청들은 스레드 풀 내에 할당된 서로 다른 스레드들로 할당되어 처리되기 때문에 다음의 시나리오만큼 지연되진 않으며,

여기서는 Blocking/Non-blocking IO의 차이를 비교하기 위한 시나리오임을 참고

1-1. WebFlux 기반의 Non-Blocking IO

반대로 WebFlux 기반의 Non-Blocking IO에서는 외부 API인 Delivery 서비스에 요청을 전송하더라도, 스레드가 차단되지 않고 바로 응답되기 때문에

스레드는 첫 번째 요청에 대한 Delivery 서비스의 응답을 기다리지 않고도 다음 두 번째 요청을 바로 전송할 수 있음

이후 세 번째 요청과 같은 후속 요청 처리들도 마찬가지

Delivery 서비스는 Commerce 서비스로부터 받은 각 요청에 대해 처리가 완료되면 Commerce 서비스에게 비동기적으로 응답 결과를 전송하여 남은 처리를 수행함

결과적으로 이 방식에서는 새로운 요청이 전송되어도 스레드가 차단되지 않기 때문에, 전체 처리 시간이 그만큼 줄어듦

💡
Tip

EventLoop

Spring WebFlux에서는 이벤트 루핑 기법을 통해 하나의 스레드당 더 많은 사용자의 요청을 처리할 수 있으며, 결과적으로 블로킹 방식에 비해 메모리 자원 소모 비용을 더 절약할 수 있음

DB 및 네트워크 작업과 같은 CPU 집약적인 작업의 콜백과 요청을 포함해서 이벤트 루프에서는 모든 것들이 이벤트로 처리됨

비용이 드는 작업이 필요할 때 이벤트 루프는 해당 작업의 콜백을 등록해서 병행으로 수행되게 하고, 다른 이벤트 처리로 넘어가게 되며, 작업이 완료될 때 역시 요청과 동일하게 이벤트로 처리됨

결과적으로 비동기 웹 프레임워크는 적은 수의 스레드로 많은 요청을 처리할 수 있어서 스레드를 관리해야 하는 부담이 줄어들고 확장성 또한 용이해졌다고 볼 수 있음

Last updated on