以下斜め読んだ内容

pseudo translation of useful posts, book reviews, remarks,etc. twitter: feeddict

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
    • スマフォ版トランシーバ(walkie-talkie)
    • リアルタイムでの通話とチャットができる
    • テキスト、写真、位置情報、音声のポストやfacebookの友達とのコミュニケーションなど、メッセ系機能は一通り網羅したアプリ
    • 開発プラットフォームとして世の中的には無名なもの(=Node)を使ってる
    • 初期VoxerはC++ベース
      • 軍事関係者向けのソフトウェア
      • 2方向VoIPラジオ
      • 性能への要求が超シビアだった
      • 古き良きC++で開発
      • C++で開発での開発はとても複雑・厳密すぎた
    • Pythonベースに移行
    • nodeへ移行
  • 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/O)
  • nodeで使われてるevent drivenなシステムでのメモリ使用
    • ユーザがシステムに接続したとする
    • nodeのイベントループでは、ユーザの接続後に発生することに対して事前にメモリ割り当てはしない
    • イベントループではプレースホルダーとして少量のメモリを割り当てるだけ
    • 必要な場面になってからメモリを追加で割り当てる
  • Matt Ranney
    • VoxerのCTO
  • Matt曰く
    • nodeの仕組みはVoxerにとって理想的
    • Voxerには、ほぼゼロに近いレイテンシと桁外れに大量のコネクションを開くことの両方が必要
    • ユーザがリアルタイムで更新ストリームを受信できるようしたい。これを実装したいとする
    • この場合、大量コネクションを開いたままにしないといけない
    • これを実現するコストはPHPでやろうとしたらとても高コスト
    • nodeだったらコストはほぼゼロ。長時間コネクションを開いたままにできるし、接続数が増えるたびに増えるコストもとても低い
    • nodeがベストである理由は2つ
      • event drivenなシステムに最適な言語であるjavascriptを使ってる
      • パフォーマンスもとてもよい
    • nodeでVoxerのプロトタイプ作ってからサーバ1台でどれだけコネクションさばけるか試してみた
    • どこまで接続数を増やしたらVoxerが落ちるかを見極めようとした
    • 用意したipアドレスで全部コネクションを開けた
    • 使用メモリも少なかった
    • 使えるポート番号も使い尽くした
  • シリコンバレーの一部エンジニアの間での位置づけでは、nodeは「新しいPHP」「新しいRails」「新しい・・・・」etc.
  • Tom Hughes-Croucher
  • Tom曰く
    • node=新しいRailsと紹介してた
    • 最近githubでのview数がrailsを上回るようになった
    • てことで、新しいPHPとして紹介することにした
  • 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
  • nodeの48時間ハカソンNode Knockout
    • 2011.08末に開催
    • Gerad Suyderhoudがファウンダー
  • Gerad曰く
    • webの動きの速い世界の中でプラットフォームは次のメジャーなフェーズにある
    • 最初は、CとCで開発されたamazon
    • 次いで、PerlPerlで開発されたCraiglist
    • 次いで、PHPFacebook
    • 次いで、RailsTwitter
    • 今度は、nodeと「・・・」
    • メジャープラットフォームのどの段階においてもその時直面していた難しい問題を解決してきた
    • 今新しい問題が目の前に現れてて、nodeはこの新しい問題群を解決してくれるはず
    • 新しい問題は、webのリアルタイム性にまつわる問題
    • nodeと「・・・」の「・・・」に入るメジャーなサービスはやがて登場すると思う
  • nodeはごく限られたアプリで使われてる、というわけではない
  • 今のところFacebookのようなメジャーなサイトでの導入事例はnodeにはない
  • そのうちメジャーなサイトでの導入事例は出てくると予想してる人は色々いる
  • Node Knockout
    • Joyentがオフィスしたりホストになって開催された48時間耐久ハカソン
    • 500名のエンジニアが参加
    • WordSquared (旧名Scrabb.ly)
      • ハカソンのウィナー、Scrabbleマルチプレーヤ版、ハカソン後名称変えて商用化
  • クラウドの世界でもNodeは活躍中
    • PAAS、クラウドサーバー管理ツール、メッセージ・キューイング
    • それぞれについて1つずつ、Node使ってる会社紹介
  • Joyent
    • Node使ったクラウド型サーバ作ってる
    • amazon EC2ライク
    • オンデマンドでスケールできるプラットフォームサービス
  • Cloudkick
  • Rabbit Technologies
  • 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を作った理由
    • モダンなウェブアプリにフィットする高速なウェブサーバがほしかった
    • event drivenなシステムやノンブロッキングI/Oについてアイディアを膨らませた
    • event drivenなサーバEbbをRubyで実装したがRubyからはRyanが望むだけの性能を引き出せなかった
  • Ryan曰く
    • Ebbはevent drivenだったがえられたパフォーマンスは乏しかった
    • Ebbはマルチスレッド、ブロッキングIOといったレガシーなシステムを対話しないといけないサーバーだったので遅かった
    • すべてをノンブロッキングI/Oしたら超高速化できるとわかっていたので、問題は別の所に。
    • 問題は、全てブロッキングI/OとするかノンブロッキングI/Oとするかの二者択一になる点
    • 全てブロッキングI/Oでやることにすると、途端の難しくなる
    • 通常ノンブロッキングなインターフェースを持たない他の多くのシステムと自分の設計するシステムを対話させないといけなくなるから
  • Ryanは新しいプラットフォームをゼロから作ることにした
    • アプリケーション開発の流儀を再定義するようなプラットフォーム
    • 最初はCライブラリを使って開発
    • Cは前ほどポピュラーな言語じゃないことに遅まきながら気づく
    • 次にLua使った
      • LuaにはブロッキングI/Oのライブラリが満載だったのでダメだと気づく
  • 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なシステムというアイディア自体は前からある
    • RubyならEventMachineがあるし
    • PythonならTwistedがある
  • Ryanはjsを選び、event drivenなシステムを先鋭化させた
  • ちょうどその頃ブラウザ業界ではjavascript高速化競争が勃発し、Googleはその競争の中でいい位置占めてた
  • Matt曰く
    • nodeを最初に知ったとき「これは完璧」と思った
    • nodeはイベントループを使ってた。これは高速ウェブサーバー設計のセオリー通りにしてる
    • nodeではjs使う。jsは高級言語でクロージャをサポートしてる
    • クロージャーはevent drivenなシステム設計では必須になる
    • nodeはV8エンジンというjs高速化競争のキープレーヤーであるGoogleの力を受けてる
  • Ryanはnode on SpiderMonkeyで2日試した
    • 2日で終了。以降ずっとV8使ってる
  • Ryan曰く
    • V8は優れたクリーンなライブラリ
    • V8はコンパクトでChromeから独立してて、V8だけでパッケージ化されて配布されてる
    • ビルドも簡単
    • V8のヘッダファイルは優れてる
    • V8のドキュメントも優れてる
    • 自分にとって他のシステムやライブラリに依存したライブラリを使うのはとてもストレス
    • V8はMozillaSpiderMonkeyよりもずっとモダンだと思う
  • nodeへのGoogleへのオフィシャルなプロジェクト参加はない
    • nodeプロジェクトとGoogleの関係は良好
    • nodeの開発の中でV8のバグfixやV8の仕組みについて助言がほしいときもGoogleは積極的に動いてくれてる
  • Eric Corry(V8チームのエンジニア)曰く
    • 参加した2010年のjsconf.euではnodeの話でもちきりだった
    • nodeはV8のクールな活用例
    • オープンソースソフトウェアを組み合わせてできることの新しい側面を示してる
    • この新しい側面はソフトウェアの開発者(=ここだとV8開発チーム)の予想もしなかったもの
  • web.jsが最初のプロジェクト名
    • Ryanがnodeのプロジェクトを始めた初期
    • Apache等のサーバへのオルタナティブとして開発してたため
    • プロジェクトが進むとウェブサーバを作るというところを越えて成長
    • サーバーに限らずほぼ何でも作れてしまうフレームワークへと成長した
    • プロジェクトの成長を見てNode.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
    • オープンソースメッセージングプラットフォームRabbitMQとNodeを組み合わせて使われてる事例
    • RabbitMQは他言語のevent drivenなシステムへ対応してる
    • 次はnodeにも対応という流れが自然にできてた
  • 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が成功した理由の1つは、非同期でのデータシャッフルする手段を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
    • このサービスでエンジニアがやることはnodeサーバーへgitリポジトリを作ること
    • joyentのクラウドインフラへ上で動くVMへgit pushする
    • するとdaemonが起動し、daemonはコントロールされる
    • 同じ仕組みがjoyentのSmart Datacenter 6.0(SDC6.0)でも使われてて、SDC6.0上にno.deクローンを作れる
  • Tom(joyent エバンジェリスト)曰く
    • サービスリリース時にベンチマーク取った
    • 「ハローワールド」でベンチマーク
    • 1cpuあたり8,000リクエストを捌いた
    • もっとも「hello world」では信用ならないという人もいるかも
    • node使ったアプリの中には、サーバ1台で15,000同時接続を実現してるケースも報告されてる
  • Ryan曰く
    • nodeは未だニッチなプラットフォーム
    • たいていのエンジニアはasp/php/javaで開発してて、彼らは新しいプラットフォームを必要としてない
      • 新しいプロダクトも当然Microsoftの技術使うし、実行ランタイムをどれにしようか、と調査したりしない
  • マルチスレッドの世界に通暁したエンジニアにはnodeのコンセプトは異質すぎる
  • Ryan曰く
    • マルチスレッドの世界から来ました〜なエンジニアはノンブロッキングなスタイルで書かないといけなくなる
    • リモートのバックエンドへコールしたいときは常にコールバックを付けないといけいない
    • 「DBがレスポンスをくれてから、次のステップに進み、次の行で結果を処理しよう」という風にできなくなる
    • コールバックを付けること、別の関数へ移動することが普通になる
    • シークエンスに処理が続くコードを書かないといけない場面ではエンジニアの苦痛は相当なものに
    • aやったらb、次にc、次いでd、とか
    • ブロッキングな世界だったら、順番にaする、bする、cする、dする、と1行ずつかけばよかった
    • nodeでは、各行ごとに別の関数へ移動とかが発生する
      • DBにデータ送ってくれとリクエストしたり
      • イベントループに戻ったり
      • 別のリクエストも処理したり
      • レスポンスを受信したり
      • 次のリクエストを送る関数を呼び出したり
      • イベントループに戻ったり
      • たくさんのリクエストを処理したり
      • etc.
  • フロントエンドエンジニアにとっては一転してnodeの世界は居心地がよいもののはず
    • 特にサーバサイドの開発経験のない人だとなおさら
  • Ryan曰く
    • クライアントサイド開発者からすれば、ノンブロッキングなスタイルはおなじみのこと
    • クライアントサイド開発者は別のやり方とか考えもしないだろう
  • 最近登場し始めたリアルタイムなウェブアプリにnodeは最適である
  • もちろんnode以外にも開発環境・ツールは存在する
  • nodeだとリアルタイムなウェブアプリだけでなく、そのサイト上で動く他のシステムも含めてすべて同じプラットフォームで開発できる。
  • facebookが経験してるようなケースは回避できる
    • チャットサーバはErlangで書かれ、他の部分は別の言語で書かれてる
  • Guillermo曰く
    • php/apacheという伝統的なスタックだとリアルタイム性を実現するのはほぼ不可能
    • 伝統的スタックで行く場合、リアルタイムコミュニケーションの処理は専用サーバをスクラッチで書かないといけない
    • facebokはチャット機能のためにErlang使ってサーバー書いてfacebookを構成するphpのスタックと対話させるという手間をかけてる
    • nodeだとこの手の複雑さはなくせる
    • リアルタイム性が求められるスタックをいま動かしてるウェブアプリケーションとかDB等と同じコードベースに書ける
  • nodeは新しいrailsでも新しいphpでもなく、全く異なる何か、とまとめておく