node 등장 이전의 spring은 Multi-thread를 사용하여 다중요청을 동시에 처리하였다.
한개의 thread가 하나의 요청 담당하여 응답까지 책임지고 반환하고 요청이 들어오면 바로 결과를 반환해주는 동기방식을 사용하고 연산이 완료되는 동안 기다리는 blocking 방식을 사용하고 있다.
여기서 문제가 발생합니다. 위 사진은 https://siyoon210.tistory.com/164 이분의 블로그를 참고하였는데 이분이 음식점으로 예를 들었으니 마찬가지로 음식점으로 예를 들어보겠습니다.
현재 이 식당은 3명의 종업원을 고용하였다. 한명의 종업원(Thread)이 주문(requset)을 받아서 주방(CPU)에 전달하면 주방에서 음식을 만들고 음식이 완성되면 해당 음식을 가지고 손님(client)에게 음식(response)을 전달해준다. 여기서 종업원(Thread)이 주문을 받고 주방에 전달해주는 시간보다 주방앞에서 하염없이 기다리는 시간(blocking)이 많이지게되면 식당이 효율적으로 운영되지 않는다. 주방앞에서 기다리는 시간에 다른 손님의 주문을 받고 오는것이 더 효율적인 운영방식이기 때문이다.
그러면 사장은 이렇게 비효율적으로 식당을 운영하고 각각의 종업원(각각의 thread에서 요청을 받고 응답을 해주는것에도 자원이 낭비)에게 주는 월급을 생각한다면 식당을 운영하는데 필요없는 지출(자원 낭비)을 하고 있는 상황이기에 이를 효율적으로 운영하기 위해서 node가 등장하였다.
node는 single-thread를 사용하여 한개의 Thread에서 모든 요청을 처리하는 방식을 취하고 있다. 기존의 spring과 달리 요청이 들어오면 바로 결과를 주는 것이 아니라 작업이 완료되는 대로 결과를 넘겨주는 비동기 방식을 취하고 있다. node가 가지고 있는 한개의 Thread는 작업이 진행되는 동안 멈춰있는 것이 아니라 다른 작업을 수행할 수 있는 non-blocking 방식을 사용하고 있다.
한명의 종업원(Thread)이 주방앞에서 기다리는 대신에 다른 손님(clinet)의 주문(request)을 받는다. 그러다 음식이 완성(CPU 연산 완료)되면 주방에서 음식(response)을 받아서 손님(clinet)에게 전달해주면된다. 그러나 갑자기 많은 요청이 들어오게되면(ex) 규모가 커지면 외 등등..) 한명의 종업원이 모든 요청을 처리하기 버거워진다. 즉 손님이 많아지고 요구사항이 복잡(CPU 연산 시간 증가)할 수록 손님이 기다리는 시간이 증가한다(서버가 느려진다.).
spring의 단점을 보완하고자 Spring WebFlux가 spring5부터 도입이 되었다. 이는 spring의 단점과 node의 장점을 가져와서 업그레이드 하였다.
기존의 multi-thread 방식을 유지하면서 각각의 요청에 하나의 thread가 대응 되는 것이 아니라 single-thread 처럼 다수의 요청을 처리하게 하는 구조이다.
복잡한 요구 사항이 많은 경우 스프링을 사용하는 것이 유리하다.
ex) 실시간 게임, 영상처리
간단한 요구사항이 많은 경우 노드를 사용하는 것이 유리하다.
ex) 채팅, crud기반 서비스
동기는 요청과 동시에 그 결과가 일어나는 뜻이다. 즉 함수를 호출 했을 때 이 함수의 결과를 호출한 쪽에서 처리하면 동기
비동기는 요청과 그 결과가 동시에 일어나지 않는 뜻이다. 즉 함수를 호출 했을 때 함수의 결과를 호출한쪽에서 처리하지 않을 수도 있다.
블로킹은 자신의 수행결과가 끝날 때까지 제어권을 갖고 있는 것을 의미한다. 즉 연산이 끝날때까지 다른일을 수행하지 않고 대기하는 방식
자신이 호출되었을 때 제어권을 바로 자신을 호출한 쪽으로 넘기며, 자신을 호출한 쪽에서 다른 일을 할 수 있도록 하는 것을 의미합니다. 즉 연산이 끝날 때 까지 대기하는 것이 아니라 다른일을 바로 수행하는 방식