Cade Metz「好調Node」
The Register 2011.3.1の記事
The Node Ahead: JavaScript leaps from browser into future
- node知らない人向けに書かれた記事だけど、node紹介記事たくさん読んだことのある人にとってもinformativeな記事
- V8の前は2日だけSpiderMonkey試したとか、web.jsが最初のプロジェクト名だったとか
- Ryan Dahlだけでなく、socket.ioクリエータとかnode本の著者とかV8チームの人とか色々な人にインタビューしまくって書かれてる
以下斜め読んだ内容
- リード文
- ブラウザからサーバへ飛び出したJS、とか
- V8はサーバーの世界に分身を生み出した、とか
- iphoneアプリVoxer
- nodeについておさらい
- リリースから2年たった開発プラットフォーム
- chromeに同梱されてるjsエンジンV8の上に構築されてる
- V8はブラウザの技術という括りだった
- nodeはV8＝ブラウザの技術という位置付けを変え、フロントエンド同様にバックエンドもJSでアプリケーション開発できるようにした
- 「V8をサーバーサイドでの応用」。nodeの一面にすぎない
- nodeはevent drivenなシステムを突き詰めた形
- event drivenなシステム
- スレッドやデータでなく（ソフトウェアからのメッセージ、ユーザからの入力などの）イベントを中心に設計されたソフトウェア
- あるステップの発生を待たずに、次のステップに移動してしまうシステム。
- 例えばDB問合してる場面。DBからの応答を待たずに次のタスクへ進むシステム
- マルチスレッドシステムが向いてる場面
- CPUに負荷のかかる処理（ヘビーCPU）
- event drivenなシステムが向いてる場面
- 大量のI/Oを処理しないといけない場面（ヘビーI/Ｏ）
- nodeで使われてるevent drivenなシステムでのメモリ使用
- ユーザがシステムに接続したとする
- nodeのイベントループでは、ユーザの接続後に発生することに対して事前にメモリ割り当てはしない
- イベントループではプレースホルダーとして少量のメモリを割り当てるだけ
- 必要な場面になってからメモリを追加で割り当てる
- Matt Ranney
- VoxerのCTO
- Matt曰く
- nodeの仕組みはVoxerにとって理想的
- Voxerには、ほぼゼロに近いレイテンシと桁外れに大量のコネクションを開くことの両方が必要
- ユーザがリアルタイムで更新ストリームを受信できるようしたい。これを実装したいとする
- この場合、大量コネクションを開いたままにしないといけない
- これを実現するコストはPHPでやろうとしたらとても高コスト
- nodeだったらコストはほぼゼロ。長時間コネクションを開いたままにできるし、接続数が増えるたびに増えるコストもとても低い
- nodeがベストである理由は２つ
- event drivenなシステムに最適な言語であるjavascriptを使ってる
- パフォーマンスもとてもよい
- nodeでVoxerのプロトタイプ作ってからサーバ1台でどれだけコネクションさばけるか試してみた
- どこまで接続数を増やしたらVoxerが落ちるかを見極めようとした
- 用意したipアドレスで全部コネクションを開けた
- 使用メモリも少なかった
- 使えるポート番号も使い尽くした
- シリコンバレーの一部エンジニアの間での位置づけでは、nodeは「新しいPHP」「新しいRails」「新しい・・・・」etc.
- Tom Hughes-Croucher
- オライリーか発売予定のnode本「Up and Running with Node.js」著者
- Joyent（nodeをバックアップしてる会社）のチーフ・エヴァンジェリスト
- Tom曰く
- Rails
- githubで最初にホストされたメジャープロジェクト
- rails/rails - GitHub
- 「watch」数はrailsの方がnodeよりも上（rails7,000くらい。nodeが5,000くらい）
- railsは7年続いてるプロジェクト
- nodeは2009年始まったばかり。
- nodeはv1.0リリースはまだまだ。先月（2011.02）にv0.4がリリースされたばかり
- joyentのnodeホスティングサービスno.de
- joyentはオープンソースプロジェクトとしてのnodeのバックアップだけでなくnodeでデプロイできるサービスの提供をはじめてる
- no.deまだクローズドベータ段階
- Google App EngineチームのエンジニアIkai Lanがno.deのクーポンコードをGetしたときに喜びの声をtweetしてた
- nodeの48時間ハカソンNode Knockout
- 2011.08末に開催
- Gerad Suyderhoudがファウンダー
- Gerad曰く
- nodeはごく限られたアプリで使われてる、というわけではない
- Voxer以外にも色々
- Mockingbird
- ワイアーフレームを作成できるウェブサービス
- LearnBoostは教育機関向けにnode使ったサービス
- 採点簿管理サービス（Gradebook）
- 今のところFacebookのようなメジャーなサイトでの導入事例はnodeにはない
- そのうちメジャーなサイトでの導入事例は出てくると予想してる人は色々いる
- Node Knockout
- Joyentがオフィスしたりホストになって開催された48時間耐久ハカソン
- 500名のエンジニアが参加
- WordSquared （旧名Scrabb.ly）
- ハカソンのウィナー、Scrabbleマルチプレーヤ版、ハカソン後名称変えて商用化
- クラウドの世界でもNodeは活躍中
- PAAS、クラウドサーバー管理ツール、メッセージ・キューイング
- それぞれについて１つずつ、Node使ってる会社紹介
- Joyent
- Node使ったクラウド型サーバ作ってる
- amazon EC2ライク
- オンデマンドでスケールできるプラットフォームサービス
- Cloudkick
-
- クラウド向けサーバー管理ツール
- Node使ってサービス開発
- （補足）
- twisted/python/Lua/C/etcという構成から始めたがNodeへ変更
- Writing Node.js Native Extensions | Cloudkick, manage servers better
- YCombinatorから援助受けてるスタートアップ
- Rackspaceが最近買収
-
- Rabbit Technologies
- オープンソースmessagingプラットフォームRabbitMQ開発
- rabbit.jsをリリース
- nodeモジュール
- RabbitMQとnodeで書かれたソケットサーバーのゲートウェイ
- （補足）
- Rabbit Technologiesは2010年にSpingSourceに買収されてる。ただしSpringSource自体はそれより前にVMWareに買収されてるので、VMWareファミリーの１つ
- RyanがAMQPクライアントをnodeモジュールとして作った
- rabbit.jsはsocket.ioとRyanが作ったAMQPクライアント（をフォークしたモジュール）を使ってる
- squaremo/rabbit.js at master - GitHub
- RabbitMQ » Blog Archive » rabbitmq + node.js = rabbit.js - Messaging that just works
- Ryan Dahl
- Nodeクリエータ
- 大学では数学選考
- フリーランスエンジニア時代にNode作った
- 今はJoyentにjoin
- Ryan曰く
- クラウド向けのサーバ管理ツールを入れると、モニタリングしたりとスナップショット取ったりetc.してくれるエージェントがサーバーの各所に常駐する
- この手のエージェントは大量のスループットを扱っていたりいなかったり
- この手のエージェントをevent-drivenなスタイルで書いてみるのはかなり相性がいいことがわかった
- event-driveなスタイルだと、いくつもスレッドを扱う必要はない
- event-drivenなスタイルだと必要なのは、メッセージ受信と送信
- nodeはHPのスマフォ／タブレットでも動いてる
- Palm WebOSのバックグラウンドサービスにはnodeが使われてる
- Ryan曰く
- nodeはスケールダウンできることがWebOSへの導入で分かった
- nodeにはGB単位のメモリは不要
- nodeは起動時間も高速でフットプリントも少ない
- nodeはデバイスに組み込みのに十分なだけ小ぶり
- Ryanがnodeを作った理由
- Ryan曰く
- Ebbはevent drivenだったがえられたパフォーマンスは乏しかった
- Ebbはマルチスレッド、ブロッキングIOといったレガシーなシステムを対話しないといけないサーバーだったので遅かった
- すべてをノンブロッキングI/Oしたら超高速化できるとわかっていたので、問題は別の所に。
- 問題は、全てブロッキングI/OとするかノンブロッキングI/Oとするかの二者択一になる点
- 全てブロッキングI/Oでやることにすると、途端の難しくなる
- 通常ノンブロッキングなインターフェースを持たない他の多くのシステムと自分の設計するシステムを対話させないといけなくなるから
- Ryanは新しいプラットフォームをゼロから作ることにした
- Ryan曰く
- ブロッキングなライブラリ群の周りにLuaのカルチャーが出来上がっていた
- 白紙の状態から始めることを求めてた
- プロジェクト始めて6か月経過したころ「そうだjavascriptだ」と閃いた
- サーバーサイドjavascriptのプロジェクトは昔から結構ある
- wikipediaに登録されてるだけで100
- どれもヘンだしどれもRyanの興味ひかなかった
- Ryanがサーバーで実装しようとしててこと
- サーバーを起動
- ソケット作成
- ユーザと接続
- DNS名前解決
- ユーザのアクションを監視
- ファイルを開く
- これらの実装について参考になるものは過去のサーバーサイドJSプロジェクトでは皆無に等しい
- Ryan曰く
- 自分が実装しようとしてることについてはJSには何の文化もなかった
- 実装はどうあるべきかについて何の了解事項もなかった
- そういう状況だったからこれらの実装はノンブロッキングでやることに自分が決めて、それを使ってくれる人に「大丈夫大丈夫」とやれてしまう状況だった
- JSはクライアントサイドのエンジニアのグループが慣れ親しんでる言語だった
- JSは新しい言語という立ち位置にはなかった
- Matt（VoxerのCTO）曰く
- クライアントサイド／サーバーサイドの作業の切り替えのときに心のギアも切り替える必要はない
- JSというクライアントサイド言語が実はイベントベースのプログラミングにぴったりだった
- Ryan、Ranneyともに指摘してる
- JSは高階の抽象化を提供してる。たとえばクロージャーのサポート
- クロージャーがあるとevent drivenなシステムでコールバックののセットが手軽になる
- nodeはJS使ったクライアントサイドの開発をしたことのある人にとってはとてもとっつきやすかった（by Ranney)
- Ryan曰く
- クライアントサイドプログラミングでページのボタンにコールバックをセットする、的な場面
- 例えばこのボタンをクリックすれば関数が呼び出される
- nodeでプログラミングしてる場面
- サーバーをセットアップ。ボタンのクリックの代わりにユーザがサーバーへ接続する
- コールバックセットして、ユーザがサーバーに接続するとこの関数が呼び出される、とできる
- event drivenなシステムというアイディア自体は前からある
- Ryanはjsを選び、event drivenなシステムを先鋭化させた
- ちょうどその頃ブラウザ業界ではjavascript高速化競争が勃発し、Googleはその競争の中でいい位置占めてた
- Matt曰く
- Ryanはnode on SpiderMonkeyで2日試した
- 2日で終了。以降ずっとV8使ってる
- Ryan曰く
- V8は優れたクリーンなライブラリ
- V8はコンパクトでChromeから独立してて、V8だけでパッケージ化されて配布されてる
- ビルドも簡単
- V8のヘッダファイルは優れてる
- V8のドキュメントも優れてる
- 自分にとって他のシステムやライブラリに依存したライブラリを使うのはとてもストレス
- V8はMozillaのSpiderMonkeyよりもずっとモダンだと思う
- nodeへのGoogleへのオフィシャルなプロジェクト参加はない
- Eric Corry（V8チームのエンジニア）曰く
- 参加した2010年のjsconf.euではnodeの話でもちきりだった
- nodeはV8のクールな活用例
- オープンソースソフトウェアを組み合わせてできることの新しい側面を示してる
- この新しい側面はソフトウェアの開発者（＝ここだとV8開発チーム）の予想もしなかったもの
- web.jsが最初のプロジェクト名
- Ryanは2009年6月にプロトタイプを公開
- この時点では存在を知る人は少数
- 2009年のjsconfでRyanはスピーカとしてnodeのプレゼンを45分
- 終了後スタンディングオベーションで迎えられた
- その後プロジェクトは加速し、アプリケーションエンジニアの間だけでなく有名なクラウド型のサービス提供企業にも広まった
- プレゼンを聴いたAlexis Richardson（元Rabbit Technologies CEO、現 VMWareシニアディレクタ）曰く
- リアルタイムWebの世界の含意を把握する点においてRyanは一歩先を行っている
- Ryanのプレゼンを聴いたとき本当に感動した
- 話題のプレゼンの1か月後、RyanはJoyentへ入社
- node以前からJoyentはサーバーサイドJSについてリサーチしていた
- （補足）
- 以前「Smart Platform」というSpiderMonkeyベースのサーバサイドJSサービスやってた時期あり
- 「Smart Platform」自体は「Reasonably Smart」から買収した技術
- nodeはjoyentのビジネスにマッチしてた
- （補足）
- Joyent入社後のRyanは、joyentのPaasサービス上でnode使えるように開発を始めた
- Ryan入社から2年たつとnodeはjoyentのサービスのいたるところで使われるようになった
- joyentのデータセンターサービスのSmart Datacenter6.0でもnodeを使ってる
- Smart Datacenter6.0はISPが独自のクラウドサービスを作るためのインフラサービス
- 再びrabbit.js
- Alexis（元Rabbit Technologies CEO）曰く
- RabbitMQ/rabbit.jsとnodeの組み合わせはデータの流れをシンプルにする
- RabbitはDBのようなストレージの技術でなく、流れてるデータのための技術（data-in-motion technology)
- nodeを使うと、アプリケーションであふれた世界とやり取りのための手軽なツールキットが得られる
- rabbitを使うとデータが流れるようになる
- nodeがしてることは、jsユーザへこの流儀でコーディングする手段を提供すること
- rabbit.jsはsocket.io使ってる
- socket.ioを使うと、クライアント側への高速なデータプッシュができる
- Guillermo Rauch（socket.ioクリエータ、Learnboost CTO）曰く
- ブラウザがwebsocket対応してるかどうかを気にせずにメッセージ送信のためのシンプルな手段を提供するのが、socket.io
- Michael Bridgen（rabbit.js開発者、VMWareエンジニア）
- socket.ioは2方向チャンネルを用意してる
- このチャンネルで流れてくるメッセージをどう扱うか（種類・プロトコルetc..の特定など）。これをsocket.ioは行わない
- RabbitMQではメッセージングをどう扱うかについてのsemanticをもつ。
- nodeとRabbitMQの組み合わせはスイートスポットとなる
- クラウドからブラウザへのメッセージングの考え方を変えていく部分がある
- バックエンドではRabbitMQはDBを経由しないでデータを流してる
- rabbit.js/socket.ioを使ってrabbit.jsのチームがやってることはアプリケーションがweb経由でクライアントへ問合せするときにやってることと同じこと
- nodeのデザインが向いてる部分
- Michael曰く
- nodeでは、webプログラミングがデータベースに関係するよりもネットワークに関係してる点が踏まえられえる
- 複数のデータを保持する、ある宛先へデータを送信する、レスポンスとしてデータが返ってくる、データを再送信する、etc
- あちこちでデータをシャッフルしてるようなもの
- nodeが成功した理由の１つは、非同期でのデータシャッフルする手段をjsに慣れた人たちに提供したところ
- Guillermo曰く
- Michaelと同じ意見
- nodeはLearnboostが手掛けるアプリでヘビーに使われてる
- nodeを使うと、フロントエンド／バックエンドで共通の言語を使える。これは魅力
- jsでウェブアプリを書く、バックエンドのインフラもjsで書く。クライアントアプリもjsで書く
- シングルスタックの世界の実現
- Ryan曰く
- エンドユーザ向けのアプリを開発してるエンジニアたちは、nodeの想定ユーザではなかった
- nodeはtcpコネクションを開くなどの低レベルの仕事、OSレベル降りる必要のある仕事に関係するものだった
- 自分の読みは間違ってた
- nodeユーザはnodeでウェブサイトを作り出した
- nodeでウェブアプリ作りたいというニーズに燃料を投下するように、Joyentはno.deをリリース
- Guillermo（Learnboost CTO）曰く
- nodeは他の類似のプラットフォームよりもPaas構築を手厚くできる
- nodeはクラウドに向いてる
- nodeサーバが1インスタンスが使うリソースは非常に少ないのに、たくさんのユーザをさばくことができる
- no.de
- Tom（joyent エバンジェリスト）曰く
- サービスリリース時にベンチマーク取った
- 「ハローワールド」でベンチマーク
- 1cpuあたり8,000リクエストを捌いた
- もっとも「hello world」では信用ならないという人もいるかも
- node使ったアプリの中には、サーバ1台で15,000同時接続を実現してるケースも報告されてる
- Ryan曰く
- マルチスレッドの世界に通暁したエンジニアにはnodeのコンセプトは異質すぎる
- Ryan曰く
- マルチスレッドの世界から来ました〜なエンジニアはノンブロッキングなスタイルで書かないといけなくなる
- リモートのバックエンドへコールしたいときは常にコールバックを付けないといけいない
- 「DBがレスポンスをくれてから、次のステップに進み、次の行で結果を処理しよう」という風にできなくなる
- コールバックを付けること、別の関数へ移動することが普通になる
- シークエンスに処理が続くコードを書かないといけない場面ではエンジニアの苦痛は相当なものに
- aやったらb、次にc、次いでd、とか
- ブロッキングな世界だったら、順番にaする、bする、cする、dする、と1行ずつかけばよかった
- nodeでは、各行ごとに別の関数へ移動とかが発生する
- DBにデータ送ってくれとリクエストしたり
- イベントループに戻ったり
- 別のリクエストも処理したり
- レスポンスを受信したり
- 次のリクエストを送る関数を呼び出したり
- イベントループに戻ったり
- たくさんのリクエストを処理したり
- etc.
- フロントエンドエンジニアにとっては一転してnodeの世界は居心地がよいもののはず
- 特にサーバサイドの開発経験のない人だとなおさら
- Ryan曰く
- クライアントサイド開発者からすれば、ノンブロッキングなスタイルはおなじみのこと
- クライアントサイド開発者は別のやり方とか考えもしないだろう
- 最近登場し始めたリアルタイムなウェブアプリにnodeは最適である
- もちろんnode以外にも開発環境・ツールは存在する
- nodeだとリアルタイムなウェブアプリだけでなく、そのサイト上で動く他のシステムも含めてすべて同じプラットフォームで開発できる。
- facebookが経験してるようなケースは回避できる
- チャットサーバはErlangで書かれ、他の部分は別の言語で書かれてる
- Guillermo曰く
- nodeは新しいrailsでも新しいphpでもなく、全く異なる何か、とまとめておく
