Realtime
오후 첫 세션들의 발표들은 리얼타임에 대한 얘기입니다. 이 주제는 이번엔 머에 대해서 얘기하겠다 이런 안내가 있는 것은 아닙니다. 그냥 듣다보면 아~ 이번엔 리얼타임에 대한 얘기구나 하는 것입니다.


node knockout
이 발표는 매년 진행되고 있는 48시간짜리 해카톤인 낙아웃에 대한 발표였습니다. 낙아웃을 진행하는 사람인 것 같은데 정확한 발표자의 이름을 모르겠습니다. Rails Rumble 2008에 참여부터 참여했고 2009년에도 참여했지만 이름은 레일즈이지만 루비코드는 12줄 뿐이고 1,000여줄의 자바스크립트 코드로 만들었습니다. 그리고 2010년 2011년 연속해서 노드를 위한 낙아웃을 진행하였습니다. 올해는 11월 10~12일에 낙아웃 해카톤이 진행될 예정이고 등록은 곧 오픈할 예정입니다. 올해 달라진 부분은 별도로 수상을 하지 않고 Nodejitsu만 이용할 수 있다는 점이랍니다.



Socket.IO - Guillermo Rauch
오 후의 첫 발표는 Socket.IO를 만든 Rauch의 발표였고 이 시간에는 Socket.IO를 만들게 된 배경에 대해서 얘기했습니다. 오픈소스에서 가진 경력에 대해서 얘기했는데 2007년 AppJet에로 Rhino 기반으로 프로젝트를 만들기 시작했고 Etherpad라 는 프로젝트에 참여하게 됩니다. AppJet에 소속된 건지 그냥 오픈소스로 참여한 건지는 잘 모르겠지만 Etherpad는 리얼타임으로 다른사람들과 협업으로 문서를 작성할 수 있는 도구로 나중에 구글이 AppJet을 인수하고 Google Wave 프로젝트에 합쳐진 것으로 알고 있습니다. Etherpad는 롱폴링에 기반한 웹 어플리케이션이었고 단일 언어의 이득(서버와 클라이언트가 모두 자바스트립트)을 본 프로젝트였다고 합니다.

하지만 롱폴링은 아주 끔찍했고 그때 유일한 대안은 ifreame streaming뿐이었다고 합니다. COMET도 달리 장점도 없었고 WebSocket만이 유일한 대안이라고 할 수 있습니다. 웹소켓은 W3C의 API 명세가 있고 RFC 6455가 웹소켓의 프로토콜입니다. API는 간단하고 단순이 메시지만 주고 받는게 아니라 데이터의 스트리밍이라고 할 수 있습니다. 하지만 웹소켓에도 문제가 있었습니다. 각 브라우저는 다른 Draft를 구현하고 있고 크롬은 하루가 다르게 새버전을 릴리즈하고 있으며 실제로 웹소켓을 모두 다 구현한 것은 크롬과 IE 10 뿐이었습니다. iOS 4.2나 Safari, Opera는 구버전이나 안전하지 않은 프로토콜을 이용하고 있고 Firefox는 MozWebSokcet을 사용하고 있었습니다. 그래서 WebSocket.IO를 만들었고 실제 프로젝트에서는 크로스 브라우징과 크로스 플랫폼이 필요했기 때문에 Socket.IO가 탄생하게 됩니다.


Socket.IO는 리얼타임을 위한 많은 기능이 추가되고 여러 곳에서 사용하게 되면서 꽤 무거워졌습니다. 그래서 Egine.IO를 만들게 됩니다. (Egine.IO는 Socket.IO의 코어역할을 하게 됩니다.) Engine.IO는 명확한 목적을 가지고 있습니다. 폴백(fallback) 대신 업그래이드 방식을 사용하고 모든 브라우저와 네트워크에서 제대로 된 방법으로 접속을 한 다음에 WebSocket으로 업그래이드를 시도합니다. Socket.IO와 같은 API를 사용하며 Flash Socket을 위한 swf는 속도가 느리게 때문에 지연로딩을 하게 만들어졌으면 gzip한 채로 6kb밖에 안되며 로드밸런싱도 쉽습니다. 그래서 Socket.IO 1.0은 Engine.IO + WebSocket + 확장성이라고 할 수 있습니다. 이날 공식적으로 Engine.IO 0.1.0을 발표한 것입니다.



MORE REALTIME - Daniel Shaw
Daniel Shaw는 이 날 세가지를 발표했는데 RedisStore Docs와 Socket.io-Announce와 Redis Monitor입니다. Socket.IO는 RedisStore를 통한 클러스터 확장을 지원하고 있습니다만 어떻게 사용하는 지가 제대로 설명되어 있지 않습니다. 그래서 RedisStore Docs를 만들었습니다. Socket.IO-Announce는 기존의 Socket.IO가 웹서버과 커플링이 심한 반면 Socket.IO-Announce는 서버가 필요없습니다. 그냥 Announce에 데이터를 던지면 Socket.IO에 접속된 유저에게 브로드캐스팅할 수 있습니다. Redis는 정말 좋고 잘 만들어졌지만 Redis가 제공하는 RedisLive는 디버깅에는 유용하지만 모니터링 용도로는 좋지 않습니다. 그래서 만든 Redis Monitor는 앞의 발표한 두 프로젝트를 사용하고 있습니다.




Real time at larger scale - Mikito Takada
Takada 는 Socket.IO와 Engine.IO의 공헌자이고 현재 Zendeck라는 회사에서 일하고 있습니다. 작년에 haproxy와 Scoket.IO + Redis로 만든 채팅을 올해에는 Haproxy, engine.IO, Redis로 변경했습니다. 리얼타임을 구현할 때 어려운 일은 확장성부분과, 도구/모니터링, 새로운 유즈케이스를 만드는 것입니다. 기술적으로 이런 부분을 해결 할 수 있는 여러가지 이야기를 해주었습니다.

어플리케이션의 모든 레이어는 독립적으로 확장할 수 있어야 하고 다음 레이어로 전달할 때 상세를 신경쓰지 않아야 합니다.
각 단계는 최대한 간결해야하고 실패한 경우에는 그냥 새로 인스턴스를 시작해서 해결할 수 있어야 합니다.
무상태를 유지하고 아무것도 공유하지 않습니다. Socket.IO는 핸드쉐이크때문에 세션에 깊게 결합되어 있는데 인메모리 세션을 만들지 말고 자동으로 복구할 수 있어야 합니다.
실패한 경우에는 안전하게 실패하고 복구할 수 있어야 합니다. 클라이언트가 깨진 경우에는 리로드하고 서버가 깨진 경우에는 존재하는 상태로 재구축할 수 있어야 합니다
디 버깅뿐만 아니라 모니터링도 해야하며 실폐를 식별해서 실폐 비율을 알 수 있어야 합니다. 단순히 콘솔의 파일로깅으로는 무슨 일이 발생했는지 알기 어렵습니다. 데이터를 수집할 수 있게 만들고 로그에 해시태그를 붙혀서 추적할 수 있게 하는게 좋습니다. minilog의 사용을 추천하고 Hive나 Hadoop를 이용해서 간단한 그래프로 모니터링할 수 있게 합니다.


Platforms
리 얼타임과 관련된 세션이 끝나고 한시간 정도를 쉬었습니다. 한시간이나 쉰다는 말에 잘못 들은게 아닌가 싶었지만 잘못들은게 아니더군요. 주피터호텔이나 아미고 극장 주위에 모여서 다들 두런두런 얘기하거나 자기 할일들을 했습니다. 국내 세미나나 컨퍼런스는 쉬는 시간은 고작 10분뿐이라 사람들과 인사할 시간도 부족할 정도인데 여유있는 컨퍼런스 운영은 꽤 좋아보입니다. 사람들과 교류도 맺을 수 있고요.


libuv: The little library that could - Bert Belder
Bert Belder는 Node의 메인커미터중 한사람이고 현재 Cloud9에서 일하고 있습니다. Node는 0.5부터 불안해졌었는데 이는 기존의 기반기술인 lieio와 libev를 libuv로 바꾸었기 때문입니다. libev는 select()와 epoll, kqueue같은 핵심부분의 랩퍼이고 libeio는 쓰레드 풀로 파일작업에 대한 편리한 메서드를 제공합니다. 목표를 위해서 가정한 것은 확장 어플리케이션에서 셀렉트 모델은 최고의 모델이고 read(), write(), accept()는 어디서나 똑같이 동작해야하면 파일작업은 반드시 쓰레드풀에서 수행되어야 한다는 것이었습니다.


그 래서 선택한 것이 libuv입니다. libuv는 이벤트가 아닌 오퍼레이션에 대한 추상화로 여러가지 다른 논블락킹 I/O 모델을 지원하고 있습니다. libev와 libeio를 대체하며 노드의 기반으로 확장성과 성능에 초점을 맞추고 있습니다.



Candor: The biginning - Fedor Indutny
Fedor 는 Nodejitsu에서 일하고 있으며 Candor는 Fedorr가 만든 새로운 트랜스파일러라고 할 수 있습니다. Candor는 세미콜론 없이 뉴라인을 사용하고 function 키워드나 예외, 프로토타입 체인이 없어서 전역 누수가 없습니다. 간단한 문법으로 컴파일 친화적인 언어이며 다양한 최적화를 지원하고 있다고 합니다. (이런 강조는 커피스크립트와 비슷하군요.) 왜 Candor를 만들었는가 하면 ECMAScript가 너무 복잡하고 서버사이드에서는 그리 유용하기 않기 때문이랍니다. 컴파일해서 자바스크립트가 만들어지며 현재는 노드보다 5배정도 느려서 새로운 컴파일러를 작성하고 있다고 합니다.




James Halliday
이 발표는 딱히 제목도 없었으면 Jame Halliday는 Substack이라는 닉네임으로 더 유명하고 등장하자마자 사람들이 Substack을 연호하는 것이 흥미로왔습니다. 현재 노드모듈에서 갯수로는 가장 많은 모듈을 배포한 개발자로 온라인에서도 특이한 느낌이긴 했지만 실제로 보니 딱 Geek의 전형적인 느낌인듯 했습니다. 서브스택은 유용한것도 많이 만들지만 아주 간단한 것들도 많이 만듭니다. 예를 들어 eral-grey 모듈을 실행하면 콘솔에 얼그레이 차의 애니메이션이 그려지는 등이죠.. 상당히 산만(?)하게 진행이 되어서 말을 많이 알아듣지는 못했짐난 seprate all the concern이라는 컨셉대로 모든걸 모듈화해서 개발하는듯 합니다. browserify 모듈은 노드 모듈을 브라우저에서 실행할 수 있도록 만들어주고 서버에서 랜덤수를 만들어서 클라이언트에 스트림으로 보내는 간단한 예제에서 스트림을 동시에 2개 사용하는 muxDemux 예제를 보여준 뒤에 dnode를 사용해서 muxDemux에 시간까지 추가로 보내는 데모를 시연했습니다.




Intersting use case for node.js - Voicebox Karaoke
이 세션을 특별세션같은 느낌이었습니다. Voicebox는 카라오케 서비스업을 하는 회사로 (본사는 모르겠지만) 포틀랜드에 있습니다.(그냥 노래방 생각하면 됩니다.) 친구들과 노래하고 싶다는 생각으로 만들었으며 음악을 틀고 관리하고 노래책을 프린트하는 프로그램이 처음엔 필요했고 클라우드에 올리고 아이폰, 페이스북 연동도 필요하게 되면서 데이터센터도 만들어야 하는 듯 아키텍쳐가 엄청나게 커졌습니다 노드는 노래방의 각 방과 서버를 연결하는 곳에서 사용하고 있으며 리얼타임에 적합하고 반응이 빠르고 신뢰할 수 있어서 사용하고 있다록 합니다. 0.1때부터 사용하다가 지금은 0.8.1로 동작하고 있다고 합니다. node.js는 시스템의 일부일 뿐이고 그 외에 rails, sinatra, wordpress, coffeescript, ruby, C#, C++, php, perl등을 사용하고 있으며 3개 OS를 모두 사용한답니다.(무슨 노래방이.. 덜덜 제대로 헤터로지니어스입니다.. 덜덜) 이 발표는 실 사용사례라 흥미로왔으면 우리는 API가 있는 바다(We're a bar with a API)라는 말이 재미있었습니다.



Evening Party
저 녁파티전에 일본에서 참석한 개발자들이 3명 있어서 너구리형이 그들과 접촉을 시도해서 저녁을 같이 먹었습니다. 저녁을 먹으면서 일본의 Node.js 상황이나 어떤 일에 쓰고 있는지 등을 이야기 나누고 다같이 모여서 이날 들었던 내용에 대해서 랩업(Wrap-up)  모임을 했습니다.


랩 업후에 파티가 열리고 있는 보이스박스로 이동했습니다. 보이스박스는 마지막 세션을 발표한 노래방으로 이날 저녁파티를 후원해서 보이스박스 전체를 빌려줬습니다. 그냥 맥주를 달라면 주기에 맥주한잔을 먹으면서 구경했는데 각 방에 들어가서 다들 노래를 부르는데 노래를 모르기에 여기엔 끼기 어려웠고 로비도 음악소리에 많이 시끄러웠기 때문에 오프닝파티때 처럼 대화하기는 좀 힘들어서 좀 구경하다가 숙소로 귀가했습니다. ㅎ