Nodejs에 대한 단상.

Nodejs에 대한 단상.

요즘 여러 커뮤니티 및 컨퍼런스에 화두가 되고있는 기술 중 하나인 Node.js에 대한 생각을 정리해본다. 

우선 Node.js를 이해하기 위해 c10k problem (http://www.kegel.com/c10k.html , 동시접속 10k를 처리하기 위한 문제) 에 대한 문제를 먼저 생각해봐야 한다. 이는 무어의 법칙에 의해 (반도체 집적회로의 성능이 18개월마다 2배로 증가한다는 법칙) 하드웨어의 발전속도에 비해 더디게 발전하는 소프트웨어의 한계에 의해 발생한 문제이며, 최대 동접자를 얼만큼 수용 가능한가에 대한 문제를 다루고 있다. multi-thread의 I/O 처리는 task의 양이 cpu core수에 종속적이다. 동시에 10,000개의 요청이와도 multi-thread의 경우 동시에 처리할 수 있는 물리적인 갯수는 코어수에 종속 될 수 밖에 없다는 것이다. 또한 예전버전의 Kernel에서 사용하는 select()/poll()의 I/O multiplexing함수는 처리할 수 있는 fd갯수가 설계당시부터 10k 이상의 접속을 고려 하지 않았다는 것이다. Node.js와 같은 I/O 다중화 처리를 위한 event-driven 모델의 철학은 동시 10,000 또는 그이상의 I/O에 대한 처리를 위함이며, event loop와 I/O를 분리하여 Context Switching 비용을 줄이고 비동기 I/O를 처리 함으로써 병목을 줄이는데 초점을 두어 설계되었다. select()/poll()에서 모든 fd_set을 조회하는 비효율적인 구조를 epoll()을 이용하여 발생한 이벤트만 조회가능 하도록 바꾸고 I/O를 aio library를 이용하여 요청을 비동기 callback을 이용하여 처리함으로 최대한의 I/O 병목을 줄여, 동시에 많은 I/O처리가 가능하도록 설계한 오픈소스가 바로 Nginx, Node.js와 같은 event-driven 모델의 철학이라고 볼 수 있다. 

 Node.js를 두고 가지고 있는 오해중 하나가 Node.js가 java보다 빠르다. 뭐보다 빠르다 라는 얘기들을 하는걸 본 적이 있다. 본질적으로 동시접속에 대한 처리량을 늘리기 위함일뿐 처리속도는 V8엔진의 성능, Java는 JVM의 처리성능에 의존적일 수 밖에 없다는 것이다. (관련 자료 : http://attractivechaos.github.io/plb/) 또한 동접이 아무리 많아도 하드웨어 스펙이 그만큼의 동접을 처리 할 수 없는 스펙일 경우 수많은 동접은 오히려 부하로 다가 올 것이다. ( DB I/O 병목 등을 고려한다면 ) 또한 CPU Intensive한 작업은 오히려 Node.js의 성능을 떨어뜨릴 수 있음에 주의 해야한다. Single Thread모델이기 때문에 Thread에서 CPU를 잠식하고 있다면, 다른 event 처리에 영향을 미칠 수 있다는 얘기이다. 이렇듯 장점과 단점을 명확히 가지고있는 언어가 바로 Node.js이다.
하지만 내가 Node.js를 쓰는 또다른 이유는 빠른 생산성이다. 나온지 2~3년 남짓 된 언어, 아직 version 1.0도 안된 언어인데도 불구하고 수많은 모듈이 나와있다. 심지어 이런것까지?? 할 정도로 많은 영역의 모듈등이 있으며 gcm, apns push 기능, socket I/O를 이용한 메세징 처리 어플리케이션 개발 생산성과 퍼포먼스에 매료되어 버렸다. 또한 Cluster를 이용하면 추가의 Thread를 생성할 수 있고 여러가지면에서 많은 가능성을 지속적으로 보여주고 있기에 기존에 사용하던 다른 스크립트언어들을 잠시 접어두고 Node.js를 활용한 개발을 주로 하고있다. 결론을 짓자면 각 업무의 성격에 맞게 언어를 사용하면 실보단 득이 더 많을 것이라 생각이 되며, 요즘같이 시장의 변화가 빠르게 움직이고 있는 상황에서 빠른생산성은 강력한 무기라고 볼 수 있으며, 특히나 스타트업과 같은 환경에서는 빠르고 유연하게 대처할 수 있는 Node.js같은 언어는 더없이 필요한 기술이 아닌가 생각해 본다.