node.js, vert.x?, websocket? sails 0.10.x

이번에 진행할 토이프로젝트의 솔루션 선정에 있어서 고려한 내용들을 정리해보고자 합니다.

결론부터 정리하자면, 서버측의 app운용은 sails.js(node.js+express.js+socket.io)를 이용해 개발을 진행해볼까 합니다.

sails.js?
sails.js프레임워크는 express.js와 socket.io를 기반으로 하는 node.js mvc 프레임워크입니다.

websocket을 기반으로 하는 애플리케이션을 개발함에 있어서 정형화된 rails와 흡사한 형태의 프레임워크를 고르자고 했을때

http://nodeframework.com/

가장 주목받고 있는 프레임워크가 sails.js가 아닌가 생각되어, 우선 이 프레임워크를 이용해 토이프로젝트를 진행해볼까 생각하고 있습니다.

node.js, 더불어 express.js를 통해 개발을 진행한다 하였을 경우, 소스 운용에 관한 구조를 직접 구조화할 필요가 있습니다. 물론 그것 자체를 개개인이 만들지 못할것도 없지만, 공개된 오픈소스중에 서비스를 운용함에 있어서 충분한 기능, 검증이 된 프레임워크를 이용한다면, 팀이 확장될 경우라던가의 경우, 그 팀원이 해당 프레임워크의 지식이 있었다면 조금이나마 빠르게 소스의 파악이 가능하고, 혹여 모른다 하더라도 공식 배포처에서 제공, 혹은 제 3자가 거친 시행착오를 가까운 사람이나, 인터넷의 커뮤니티 등을 통해 해결할 수 있을 가능성이 높아집니다. 이러한 문제를 생각한다면, 어느정도 기반이 정리된 프레임워크를 이용하는 것이 현명하지 않나 하는 생각이 들곤합니다.

따라서 이번에 작성하는 토이 프로젝트는 rails like MVC framework for node.js인 sails.js를 이용하고자 합니다.

Vert.X?

웹소켓이 가능한 서버개발환경을 고려했을때, node.js이외에 생각해볼법한 프레임워크로서 Vert.X가 곧잘 거론되곤 합니다.

Vert.X는 node.js에서 영향을 받아, 싱글 스레드의 구조로 인한 멀티코어의 활용 등에 관한 문제점. javascript에 종속되어있는 node.js에 비해 여러 언어를 서포트하는것을 특징적으로 꼽을수 있는, java가 대표적인 기반언어인 프레임워크입니다.

성능상의 문제등으로 nodejs의 대안으로 vert.x가 떠오르고 있는듯 한데, 아직은 관련 모듈이 그렇게 많지가 않다는점. 어느정도 정리가된 프레임워크가 존재하여 여러 사람들에 의한 검증이나 그에 관한 자료가 보이지 않는 점 등에서 vert.x는 시기상조가 아닌가 하는 생각이 듭니다. (개중엔 결국 다른 환경에 embedded된 vert.x를 이용해야 효율적인거 같다라는 말이 들리기 까지도... 거기에 더해 embedded된 환경이기에 추가적으로 제공되는 모듈의 이용이 불가능하다는 제약조건까지... 라면 역시나 좀 시기상조인 느낌이 드는건 어쩔수 없는거 같습니다. 하다못해 최소한의 특정 언어용이나마 vert.x용 프레임워크가 있다면 간편하게 이용하면 좋을 것 같지만, 직접 짜야한다면 비지니스 코드에 할애하고 싶을 시간이 아까울거 같다는 생각마저 들어버리는건 어쩔수가 없는거같습니다)

vert.x의 경우 멀티스레드를 띄워 중추가되는 하나의 node.js를 이용하는 경우에도, 멀티코어 서버에서 인스턴스를 여러개 띄워 로컬 파일 데이터베이스나 memory-adaptor를 이용하지 않는다면 운용함에 부족함이 없는 성능을 낼 수 있지 않을까 하는 생각이 들기때문에, 무리하게 vert.x를 이용하지 않더라도 성능문제에서 문제가 될건 없다는 생각이 들었습니다.

http://vertxproject.wordpress.com/2012/05/09/vert-x-vs-node-js-simple-http-benchmarks/

실제로 벤치마크한 결과가 거재된 내용인데, 6프로세스에서 저정도의 성능저하선이라면, 아직까지는 서드파티 모듈의 이점을 버릴정도는 아닐까 하는 생각이 들곤 합니다.

어차피 어느정도 AWS의 auto-scaling/로드 밸런서를 통한 분산처리를 전제로 생각하고 있기에, 1개 서버에서 복수 인스턴스를 띄워 운용함으로서 위의 그래프 정도 선의 퍼포먼스까지는 끌어낼수 있지 않나 하는 생각이 듭니다.

따라서 이번에는 일단 적용하지 않기로.

socket.io? Websocket?
실시간 통신을 구현함에 있어서 일반적인 tcp/ip를 이용하지 않고, websocket을 이용하고자 하는 이유는 아래와 같습니다.

1. 프론트환경인 유니티에서 websocket(socket.io)이 동작하는것은 확인완료.
2. socket.io(사실 sails를 이용한다면 순정이 아닌 일종의 수정버전이긴 하지만)의 존재로 인한 개발의 간편함. pubsub패턴이 몹시 편리하다.
3. tcp/ip를 통해 전용 프로트콜을 이용하기에는 일반적으로 사용되지 않는, 여타 프로트콜과 충돌하지 않는 포트를 이용하여야 하나, websocket은 기존 http리퀘스트의 연장선이기에, 80번 포트로 그대로 이용이 가능함. 기존의 인프라에 영향을 최소화 할수있음.
firewall/router등에 대한 대책등도 실시간 통신을 위해 고려하지 않아도 된다는 잇점을 들수있음.

그리고 socket.io는 websocket, xhr-longpolling, jsonp, 등과 같은 여러 웹에서 실시간 정보를 얻을 수 있는 패턴중에 통신 가능한 수단으로 웹 브라우저에 실시간 피드를 가능케 해주는 모듈입니다.

sails.js에서는 이 socket.io를 확장해, 자신이 가진 모델에 대한 pubsub패턴을 제공하고 있어 간단하게 사용이 가능합니다.
(아직 문서화가 부족한듯 하여 처음에 이용하는데 조금 애는 먹었지만.)

다만 sails에서 클라이언트도 커스텀된 내용으로 제공하고 있기 때문에, 현재 사용을 검토중이던 UniWeb의 클라이언트를 참조하여 어느정도 sails.io.js(클라이언트용 io스크립트)와 동등한 기능을 제공하는 mod-component의 작성이 불가피해 보이긴 합니다.

sails.js에서의 websocket의 복수 서버환경에서의 동작은, 동작 메모리를 local-disk에 두고있는 부분을 redis서버로 치환, 인프라내의 1개소의 redis로 설정하는것으로 커버가 가능할거란 부분도 직접 확인을 했습니다 (2개의 다른 포트의 인스턴스를 띄워 local-redis에 접근하거나, 기본설정으로 운용하거나로 메세지가 오고 오지 않음을 확인)