Node js 의 일반적인 설명, 설치 뭐 이런건 다른 사이트에도 많이 있으니... ㅎㅎ 생략하려고 한다. 다만 최근에 Node 프로젝트를 진행하게 되었는데 업무를 리드해주신 분이 너무 잘하셔서 생각없이 콛이하게 되었다 ( Node 프로젝트를 너무 잘 구조화 해놔서 어떤 코드를 어디에 짜야하지? 라는 고민을 안하게 된다는 의미이다. )
그런데 막상 Node 프로젝트는 진행하는데 왜 Node 이여야 하고, Node 의 장/단은 무엇인지 모르는것 같아 서적을 읽고 검색도 하고 해서 그 내용들을 여기에 정리해 보려고 한다. 사실 나도 Node 를 처음 알게 되었던것은 2012 년으로 기억한다. 당시 대용량 Traffic 을 어떻게 관리할 것인가하는 이슈에서
Single Thread 기반
그런데 Event call back 을 이용한 우리의 멋진(?) Node 는 기존의 WAS 와는 다르게 시간이 오래 걸리는 File, Network I/O 에 대해 Non-block 되도록 비동기로 처리하고 오랜 그들의 작업이 끝내면 작업이 완료되었다는 신호를 받아 처리한다. 그러다 보니 기존의 Thread 기반의 WAS 에 비해 동시 Request 를 더 많이 받을 수 있다는 장점이 있다.
위 그림과 같이 Thread Wating 이 따로 필요가 없는 것이다. 하지만 단점으로는 CPU intensive 한 로직이 Node Application 내에 존재하는 경우 굉장히 큰 단점이 될 수 있다. Single Thread 기반이기 때문에 이곳에서 병목이 생기면 다른 사용자들의 Request 도 전부 병목이 걸리는 현상을 보인다는 것이다.
이게 노드의 특징 중 하나인 "Single thread 기반" 에 대한 설명이고, 세간의 많은 사람들이 인정(?) 하는 노드의 장단점을 열거하면 아래와 같다.
Event Loop
하나의 Thread로 여러 클라이언트의 요청( 다수의 socket connection)을 Multiplexing방법으로 처리한다. 여러 개의 socket이 동시에 연결되어 있는 상태에서 하나의 Thread는 어느 socket으로부터 메시지가 들어오는 지 보다가, socket에서 메시지가 들어오면, 그 메시지를 꺼내 받아서 처리를 하는 방식이다.
- epoll, kqueue, dev/poll ,select등을 이용
노드의 장/단점
장점
단점
- CPU intensive 한 영역에서는 약하다.
- 스크립트 언어의 특성상 해당 코드가 수행이 되어야 코드에서 에러가 나는지를 확인할 수 있고, 에러가 날 경우 프로세스 자체가 내려가기 때문에 주의해야 한다.
Node js 내부 구조
Node.js는 Google의 Chrome V8 자바스크립트 엔진 위에서 동작한다.. 이를 기반으로 Single Thread 기반의 Event Loop (libuv)가 돌면서 요청을 처리한다. 그런데 그렇다고 해서 모든 process 에 Single Thread 를 쓰나? 그건 아니다. 시스템적으로 몇몇의 File 및 Network I/O 에서는 알아서 내부에서 Thread 를 새롭게 생성해 처리한다. 이것을 해주는 것이 libio 가 해준다. 다만 프로그램을 짜는 개발자 입장에서는 이것을 고려하면서 프로그래밍 할 필요 없다는 것이 큰 장점이다.
네트워크 프로토콜을 처리하는 socket, http 바인딩 모듈이 있고, 가장 위에, node.js에서 제공하는 standard library 이 있다.
V8 자바스크립트 엔진
구글이 크롬 웹 브라우저를 개발하면서 함께 개발것이 V8 자바스크립트 엔진이다. (http://code.google.com/p/v8)
V8 자바스크립트 엔진은 자바스크립트 처리 속도가 기존에 웹 브라우저에 포함된 엔진들 보다 월등히 빨랐습니다. 가히 혁명적이었지요. 기존 자바스크립트 엔진들은 자바스크립트를 바이트코드로 변환하거나 인터프리트하여 처리했지만 V8은 JIT(Just In Time) 컴파일 방식을 사용하여 성능을 획기적으로 개선했습니다. 그리고 인라인 캐싱과 같은 기법으로 좀더 최적화하고 있다.
JIT 컴파일 방식은 자바스크립트를 인터프리트하지 않고 실행 즉시 기계어(x86, ARM 등)로 컴파일한다.
NPM
Node.js가 대세가 된 결정적인 부분은 이 npm에 있다고 해도 과언이 아니다.
NPM(Node Packaged Modules)은 Node.js 의 패키지 매니지먼트이다.
잘 관리되고 있는 Node.js의 모듈들이 NPM 에 어마어마하게 많고 설치 및 사용이 간단하다. GitHub 저장소의 상당수가 Node.js 모듈이라고 할 정도니, 그 모듈 수는 어마어마하게 많을 것이다. (물론 너무 작은 것까지도 다 모듈하 한것 아니냐? 라는 말도 있다 ^^;) 그래서 필요한 기능이 있다면 새로 만들 필요 없이 왠만한건 검색해서 npm으로 설치해서 쓰면 됩니다.
Node.js 의 흑(?) 역사
"노드JS 망하지 않았나??"
주변에서 이런말들을 한번씩은 들어봤을 거라 생각한다. 이게 반은 맞고, 반은 틀리다. 자세한 내용은 아래를 읽어 보자.
http://m.zdnet.co.kr/news_view.asp?article_id=20161209155529#imadnews
여튼 간단하게 정리하면 Node 도 정치적으로 문제가 많았고, 문제가 많은 시기에( io.js 가 분리된 프로젝트로 따로 진행될 때 ) 많은 사람들이 망했다! 라고 생각했었다. 그리고 신기하게도 이 시기에 Node 로는 더 이상 문제를 해결할 수 없어.. 라는 인식들이 강해졌었다. 그런데 io.js 가 다시 node 에 합쳐지면서 node 가 1.x 버전도 건너뛰고 한방에 4.x 로 Release 하면서 지금의 Node 전성기가 다시 온것이다. +_+
Node Use Case
(참조 : http://readme.skplanet.com/?p=13042 )
현재 본인은 SK planet Data Infrastrucutre 팀에서 일하고 있는데 위 그림이 플래닛 빅데이터 인프라의 개괄적인 시스템 구조이다. Provision 쪽의 Galleon 뿐 아니라 다른 서비스 들( Middle ware ) 을 Node 로 많이 구축하려는 시도를 하고 있는데, 이러한 아키텍처에서는 Middle ware 로 Node 가 굉장히 잘 어울린다고 생각한다. 그 이유는 아래와 같다.
- 위와 같은 빅데이터 플랫폼 구조에서 연산이 오래걸리는 것은 Middle ware 쪽이 아니라 Hive 나 Phoenix 같은 부분이다. 즉, Event Callback 이 매우 잘 어우러 질 수 있는 구조이다.
- 생각보다 팀에 Front 개발자도 많이 포진되어 있다. (물론 이분들이 프론트 뿐 아니라 다른 영역의 업무도 잘 한다는것이 함정이지만... ㅋㅋ ) 이것 때문인지 명확치는 않지만 이상하게 Node 를 잘 다루는 개발자가 많다. ( 개인적으로 이 부분이 가장 중요하다고 생각한다 )
즉, 위의 두가지 이유로 우리 팀은 웹 서비스 같은 것을 통해 사용자에게 데이터를 보여주는 부분. 즉, Provisioning 하는 부분에서는 Node 로 많이 코딩을 하고 있다.
참고
- http://pyrasis.com/nodejs/nodejs-HOWTO
- http://m.zdnet.co.kr/news_view.asp?article_id=20161209155529#imadnews
- http://readme.skplanet.com/?p=13042