Node.js(Express.js) VS. Spring

📣 들어가기에 앞서, Node.js는 Runtime 환경이고, Spring과 Spring boot는 Framework이므로 둘을 비교하는 것은 맞지 않을 수 있으나, 프로젝트를 진행하며 생긴 순수한 궁금증으로 둘을 비교해보고자 한다.

(만일 옳지 않은 정보가 있거나 더 알려주고 싶은 정보가 있으시다면 댓글 달아주시면 감사하겠습니다. 🙇‍♀️)

인용처리 되어있는 글들은 설명 중에 나오는 개념들을 정리해둔 것입니다.

Runtime 환경

• Runtime: 해당 프로그램이 필요한 시스템 자원(RAM, 시스템 변수, 환경변수 등)을 할당받고 실제로 시스템 자원을 사용해서 어떠한 처리를 하고 있는 상태
• Runtime 환경: Runtime이 일어나기 위해(해당 프로그램이 시스템 자원을 사용하기 위해) 시스템 자원에 엑세스 할 수 있도록 해주는 실행 환경
  • 운영체제 자체에 속하는 경우도 있고, 운영체제에서 작동하는 소프트웨어를 뜻할 수도 있음

→ Runtime 환경은 코드가 동작하는 환경을 갖춘 것, Framework는 코드를 어떻게 수정하고 작성할지에 대한 일련의 규칙과 구조

엄연히 둘을 제대로(?) 비교하기 위해서는 Node.js의 사실상의 표준 서버 프레임워크로 불리는 Express.js로 적는 것이 옳다고 생각하지만, 대다수의 자료에서 둘을 혼재하여 (Node.js + Express.js) 사용하므로 본인은 편의성을 위해 Node.js로 통일하여 사용

Thread의 차이

• Node.js : Single Thread 이벤트 루프 모델을 기반
• Spring : JVM의 Multi Thread (JVM이 뭐였더라?)

위와 같은 Node.js의 특징은 단점이자 장점이 될 수 있다. (일단, 명확히 짚고 넘어갈 것은 저러한 Node.js의 환경은 Spring Thread에 비해 작고 느리다는 것)

• Node.js의 특징으로 써놓은 'Single Thread 이벤트 루프 모델을 기반'을 간단히 말하자면, Single Thread '서버처럼' 작동한다는 것이다.
• 즉, 모든 요청을 하나의 Thread로 처리한다는 의미이고, 이는 여러 개의 요청을 동시에 처리할 수 있는 (Http 요청을 별도의 Thread에서 처리함) Spring과 비교하여 서버의 응답성이 떨어진다는 것을 나타낸다.
  • ex) 특정 요청에 대한 처리가 5초라면, Spring 서버는 새로운 Thread를 만들어 바로 다른 요청을 처리할 수 있지만, Node.js 서버는 새로운 요청을 처리하기까지 5초를 기다려야 한다.

• 유사 Single Thread 구조를 가진 Node.js는 CPU 코어 수가 아무리 많아도 이벤트 루프가 Single Thread이므로 강력한 서버에 설치되었더라도 서버의 성능을 100% 활용할 수 없다.
  
  • 동일 처리 시, 수행 시간을 비교한 그래프. CPU 연산이 많을수록 Node.js의 처리 수행 시간이 급격히 증가하는 것을 확인할 수 있다.

Thread

• 프로세스(실행 중인 프로그램. 디스크로부터 메모리에 적재되어 CPU의 할당을 받을 수 있는 것)의 실행 단위
• 한 프로세스 내에서 동작되는 여러 실행의 흐름
  • 프로세스 내의 코드, 데이터, 파일과 같은 운영체제 자원 공유 가능
• 구성요소 : Thread ID, register set(PC 포함), 스택
  • PC(Program Counter) : Thread가 명령어의 어디까지 수행하였는지 나타냄. Thread는 CPU를 할당 받았다가 스케줄러에 의해 다시 선점당하기 때문에 명령어가 연속적으로 수행되지 못하고, 어느 부분까지 수행했는지 기억해야할 필요가 있음.
  • 스택 : 함수 호출 시 전달되는 인자, 되돌아갈 주소값 및 함수 내에서 선언하는 변수 등을 저장하기 위해 사용되는 메모리 공간
    • 스택 메모리 공간이 독립적이라는 것은 독립적인 함수 호출이 가능하다는 것 → 독립적인 실행 흐름 → Thread의 정의에 따라 독립적인 실행 흐름을 추가하기 위한 최소 조건으로 독립된 스택을 할당함.

CPU 할당

• 프로젝트에 지정되는 시스템의 CPU 리소스 양을 정의하는 데 사용됨.
• 다른 작업 부하에 대한 해당 작업 부하의 상대적 중요성을 정의하는데 사용됨.

이러한 점만 보면 꽤나 규모 있는 작업에서는 Spring을 쓰는게 당연히 느껴질 수 있지만, 오히려 Single Thread 서버처럼 동작하는 것이 MSA(Micro Service Architecture), kubernetes와 같이 최근들어 익히 볼 수 있는 시스템들과 그 합이 매우 좋다.

MSA & kubernetes

• MSA(Micro Service Architecture) : 작은 서비스 여러 개가 모여서 하나의 시스템을 제공하는 아키텍쳐
  • 서비스가 독립적으로 존재하여 클라우드와 컨테이너에 잘 어울림
• kubernetes(k8s) : 컨테이너화된 애플리케이션을 배포, 관리, 확장할 때 수반되는 다수의 수동 프로세스를 자동화하는 오픈소스 컨테이너 오케스트레이션 플랫폼 (컨테이너란?)

• Spring은 JVM 위에서 동작하므로 일반적으로 메모리 사용량이 높다. 반면, Node.js는 JavaScript의 Runtime 환경이므로 상대적으로 더 가벼운 메모리 사용량을 가진다.
  • MSA는 트래픽도 각 서비스에 따라 나뉘게 되므로 트래픽이 많이 몰릴 때에는 Node.js가 적합한 것으로 보인다.
    • 나누는 서비스가 많을 경우, 메모리 낭비를 줄일 수 있다. (양면적인 이야기)
  • kubernetes는 자동화된 관리를 통해 트래픽을 유동적으로 조절하므로 MSA와 같은 이유로 Node.js와 적합성을 보인다.
• 일반적으로 Node.js의 서버 가동 시간이 Spring보다 짧다는 것에서 메모리와 비슷한 양상을 보인다는 것을 알 수 있다.
  • 가동 시간이 짧다는 것은 갑작스러운 트래픽에 즉각적인 반응이 가능하다고 생각할 수 있다.

즉, 서버 수 자체도 늘고, 서버 수가 트래픽에 맞춰 유동적으로 바뀌는 상황이 많아진 최근에는 크고 강력한 한 대의 서버보다는 빠르고 가벼운 서버가 여러 대 있는 것이 유리하게 작용될 수 있다.

JavaScript의 언어적 한계

Java와 달리 자료형을 명확히 규정짓지 않는 JavaScipt는 이러한 이유로 장점과 단점이 꽤나 명확하게 갈리는 언어입니다. 자료형의 이점으로 코드 작성이 용이할 수 있으나, 연산량이 많은 작업에서는 속도가 느릴 수 있습니다.

(하지만, TypeScript 등으로 이러한 단점도 극복되고 있는 중..!)

결론

오랜 기간 현업에서 활용되며 안정성을 충분히 검증받은 Spring 서비스들을 모두 Node.js로 대체하기에는 현실 조건상 다소 무리가 있지만, 개발자(혹은 준비생..?)들은 변화에 유연하게 대처해야므로 적절히 발을 담그고 있어야 한다.

해당 글을 적으면서 컴퓨터 구조, 시스템 프로그래밍의 과목에서 배웠던 몇몇 단어들을 접할 수 있었다. 그렇지만 역시나 나는 시험이 끝나고 머릿속에서 모두 지워버렸나 보다... 기록의 중요성을 다시 한 번 절절히 느끼면서 아자 아자 화이팅!

참고 및 출처

‘Node.js’ VS ‘Java Spring’ by 네이버 파이낸셜 김태우(twkim913)