InfoQ「Ryan Dahlに45分間Node.jsのことを訊きまくった」

infoQ 2010.12.13公開のインタビュー記事
2010.12.16聞き手の質問書き足して、10分くらいまで書いた

InfoQ: Deep inside Node.js with Ryan Dahl

Node.jsクリエータRyan Dahlへの45:15のロングインタビュー
2010.11開催のQCon San Francisco 2010でRyanもスピーカーの一人として参加してたので、合間に収録されたインタビューと思う。
トランススクリプトが公開されてて助かるがtypoが多い
- whatがwasになってたりdomはdomeになったり、jsdomが "JS DOM"になったり
- 動画みて適宜
入門的な話題はほどほどにしてて結構突っ込んだ内容話してる
- その結果、結構歯が立たない箇所ばかり。けどなんとか斜め読んだ
聞き手は@synodinos

以下斜め読んだ内容

要旨
- Node.jsの目指すところ
  - concurrencyにかかわる問題を抽象化して脇に追いやる
  - ちょっとした経験で、数１０００コネクションレベルへサーバーをスケールすることできるサーバ作れるようにする
- このインタビュー
  - 入門的話題はスキップ
  - ryanのモチベーションや、node内部の問題やデバッグ、モニタリング、スケーリングなど現実的な問題へフォーカス
Ryan略歴
- Joyentで働くプログラマ
- Node.jsクリエータ
- NY州Rochester育ち
- San Francisco在住
Q：とりあえず自己紹介
A：
- ホスティングサービスやってるJoyentで働いてる。
- Node.js作った。だからインタビューされてるんだと思う
Ｑ：node.jsを始めた理由、解決したいと思った問題、到達した解決策
A：
- 大学では数学やってたし、computingの世界に入ったのは少し前から
  - （補足）University of Rochesterで2005年に数学専攻で修士号取得
    - - University of Rochester Mathematics And StatisticsDiploma CeremonySunday, May 15, 2005 @ 3:30pm
- rubyのウェブサーバー開発は長い間やってた
- まずrubyに興味もった
- 当時「面白い」と思った問題
  - ユーザがファイルアップロードしてるとする。そのユーザにアップロード進捗をプログレスバー使ってリアルタイムに通知したい。これをどう実装するか。
  - 実装が結構難しい問題とわかって驚いた
    - ブラウザは進捗を表示するのに使えそうなデータを持ってる。でもそのデータへDOMからはアクセスできない。
  - ひとつの解決
    - ウェブサーバーへリクエストだす
    - アップされてるファイルの何割を受け取ってるかをサーバへ問い合わせせる
    - レスポンスもらったらそのデータでDOMを更新する
    - という流れ
    - 普通はApacheモジュールをCで書くことが必要になる
  - Mongrel に出会う
    - Mongrelにはこの一連の仕事をやってくれるモジュールがあった
    - Mongrelに感心した
      - 動的な言語でこの機能を実装してる点
      - サーバーの中身を眺めるのがCよりもずっと簡単
- 数年間Mongrelにのめりこむ
- それからjavasccriptとイベントドリブンなプログラミングについて自分が得た知識を組み合わせてみた
  - 当時各ベンダー間でjavascript高速化競争が始まった頃
  - jsとイベントドリブンプログラミングの組み合わせはちょっとした実験としてやってみた
  - jsとイベントドリブンなプログラミングはとてもうまくフィットした
  - やってみたらうまくいった
Q[02:26]：
- サーバーサイドJSのプロジェクトは他にもいろいろ
  - RingoJSとか、AppengineJSとか、
  - たいていJVMで実行される
- Node.jsを他プロジェクトと分け隔てる重要な違いは？
A：
- 確かにサーバサイドJSは昔からいろいろあった
  - narwhalは前はhelmaというプロジェクト
  - RingoJSは前はhelma-ngというプロジェクト
- とりあえず、JVMではなくV8上で実行される
- 他のプロジェクトは伝統的なアプローチという点で共通
  - 他の言語（ruby/python/etc.）にあるものをサーバーサイドjavascriptでも実装しましょ、という流れ
  - 例
    - たくさんクライアントあってそれらがサーバーへリクエストするという場面
    - マルチスレッド欲しいね、マルチスレッドでリクエスト捌こう
    - というのが伝統的アプローチ
- 要するにここが違う
  - VMが違う
  - JSの本質から外れた拡張をやってない点が違う
    - 「シングルスレッド」「ノンブロッキング」というJavascriptという言語がもつ特徴をそのまま使う
- ちなみに自分が最初にウェブサーバーの例でNode.jsの話をしてるのは、これが典型的例だから
- サーバーサイドの世界でjavascriptはどうあるべきかという話
  - CommonJSがやってること。仕様を作ろうとしてる
Q[04:21]：
- node.jsで非同期API群が動く仕組みをざっくり説明
  - サーバーサイドの開発やってる人は非同期APIに慣れてないので
- ディスクI/O、DBへの接続、RESTなウェブサービスの実装についてはどうやってるか？
A：
- すべてコールバック
- 普通のサーバーサイド開発だとこうなる
  - はじめにDBへアクセス
  - それからファイルへ書き込んで
  - それからファイル移動して
  - それから他にもいろいろやって
  - となる
  - この手のシーケンシャルな処理を１つずつ実行
  - ブロッキングI/Oとスレッドが当たり前の世界のやり方
- nodeの場合
  - やり方を変えないといけない
  - 処理１つ１つに時間がかかる。所要時間ゼロにならない
    - ファイルの移動にはディスクが回転が必要
    - DB問合せだってレスポンス来るまでに数ミリ秒は待つ
  - nodeではすべてがノンブロッキング
    - 「レスポンスを待ちレスポンスが来てから処理に移る」ということができない
  - コールバックが必須の世界
  - nodeには大量の無名関数。
    - 無名関数内で、レスポンスを受け取るためにコールバックを用意する
- nodeの世界の混乱のもとはスタイルの問題なので、慣れれば解決する話
Q[05:48]：nodeの世界はフロントエンド開発者がよく慣れ親しんでる世界と言える？
A：
- そのとおり
- nodeのセールスポイント
  - nodeの世界の原則であるノンブロッキング/コールバックベースのプログラミングを多くの人が習得済みである点
    - フロントエンド開発で習得済み
  - xhrオブジェクト使いたければ非同期プログラミングが必須であることは周知のこと
  - xhrを同期的に使えばウェブページがロックされてしまうことを知ってる
- 同期的にxhrを使うべきところはある
  - DBへリクエスト投げるとき
    - 同期的でないといけないし、同期的でないとプログラムが書けないということだってある
Q[06:35]：
- ryanのプレゼンを何個かみた
- js/nodeやるまえに他の言語でも実験してたんじゃない？と思った
- jsのシンタックスやV8に（ほかの言語にはない）魅力があったのか？
A：
- ruby長いこと使ってみた
- rubyのVM使ってると本末転倒なことになる。
- 遅すぎ。速くしようとしたら「この部分はCで書きなおそう」ってなる
- rubyで１行書くたびにサーバーがもっさりしていく
- rubyやめてCでサーバー書くことになった
- Cだけになったら超快適
- Cでサーバー書き、ファイルi/oも実装し
- ちょうどそのとき夢想してたこと
  - 面倒そうな問題は抽象化して脇に追いやってくれるライブラリがリリースされる。
  - みんなCでその手のライブラリをガシガシ書く
  - みんなが自分用にちょっとしたサーバーを書く
- もちろんこの夢想は現実にはあり得ない。みんなCで書きたがらない
- ノンブロッキングな環境
  - これをエンジニアたちに提供したいとも思ってた
  - ノンブロッキングな世界こそが、サーバーデザインに最適
- サーバーデザイン
  - コンピュータシステムを作り上げる様々なピースを駒にして司令官が作戦指揮をとっていくようなところがある
  - HaskellやHaskellに似たある種の宣言型の言語を使ってこの手のことをやるのが大好きだった
- しばらく純粋関数型な（Purely functionalな）世界がお気に入りだった
  - HaskellやHaskellライクな宣言型言語の世界
  - ソケットからイベントをキャッチする場面であっても、purely functional
  - あらゆる副作用（Side effect）がイベントループ内で起こる。イベントループで起こるようにコントロールできる
  - 関数をコールしてなんかデータ（どんなデータでも）渡すことができるし、副作用ゼロの関数呼び出し
  - こんなことができる
    - データをバッファへ書き込む。そのバッファはカーネルへ渡される
    - またイベントループへ戻る
  - イベントループからイベントをキャッチしてるときに、purely functionalなままで、副作用とか他のことから切り離されていることができる世界
- でも、関数型言語に自分は挫折した
  - GHC（The Glasgow Haskell Compiler）のソース読もうとしてみた
  - 超ムズイ。これが読みこなせるほど自分は達人プログラマーじゃないと思った
  - 挫折。
- ちょうどその頃V8がリリースされてた
- javascriptはそれほど使ってないし、V8のことも初見だった
- V8でちょっと遊んでみたら、意外にも色々フィットする点が多かった
Q[09:18]：
- Rubyでの経験は予想してたけど、Haskellもやってたのは驚いた
- よく言われるnodeのセールスポイントは、javascript。
- だがRyanからすればjavascriptは重要なポイントではなくnodeの特徴の１つ
- この理解であってる？
A：
- 正解
- 本当はnode.jsにとってjsは重要なのかもしれないが、自分的には重要じゃない
- googleがV8作ってBSDライセンスで配布してるのはいいこと
- V8はとてもいいプロダクト
- V8の開発が活発なのもいいこと
- javascriptの大変良い点
  - stdin/stdout/etcなどのI/O回りが一切未定義。仕様にもない。ビルトイン関数にもない
  - もちろんjsでI/Oはどうすべきかという議論はよくされてるし、独自拡張してるのもある
  - jsでI/Oの実装を制約なくできる
- rubyだったらどうなるか
  - put()とかが組み込み関数としてある
  - put()などのビルトイン関数を前提にI/Oを考えないといけないから
- Luaも長いこと使ってみたことあった
  - Luaにもio.read()とかio.write()等々の標準ライブラリがある
  - jsにはこの手のものがないのが自分には魅力
- javascriptは（ruby/Luaと比べると）とてもピュアでシンプル
  - 数値の加算、文字列結合、無名関数、等々の小ぶりな言語
  - ここが魅力的
- nodeがみんなから注目されるようになってる理由は自分がjsに魅力を感じる部分とは別の所にあると思う
  - nodeではjavascript使うとこがうけてる。
  - 「JVM系言語からjavascriptへ」と表現できるような開発環境の移行を経験するようなエンジニアは皆無
  - こういうことがらは、多くの人には魅力的かもしれない
- javascriptはただ単に使い勝手のいい小ぶりな言語
  - この点がまず自分にとって魅力的
Q[11:06]:
- Ryanの観測範囲でどういうタイプのウェブアプリでnodeが使われてる？
- nodeが活きるケースは？
A：
-
-
Q[12:25]：
- リアルタイムウェブ的な？
A：
-
-

Q[13:05]：
- Yahoo! Emailブログに、yahoo mailでnodeを検討してるというエントリあった
- 何か知ってる？あとほかにデカイ採用ケース知ってる？
A：
- Yahoo!はnodeを結構気に入ってくれてる
- Yahoo!はnodeをプロジェクトに使うのを検討してる
- Yahoo!のは実験フェーズだと思う
- Yahoo!のチームはブラウザサポートでgraceful degradationをすごく大事にしてる
  - （補足）：graded browser support
- リッチなブラウザにはリッチな機能、そうでないブラウザにはシンプルな機能、等々
- たとえばYahoo!のサイトはjsがオフになってても機能制限はあってもコンテンツにアクセスできる
Q[14:00]：
- 今Yahoo!にアクセスしてもjsオフで利用できる？
A：
-

Q[14:47]
- nodeではeventベースプログラミングである点について掘り下げたい
- eventベースプログラミングを使うことが含意すること
- eventベースプログラミングで取り組まないといけない問題
A：
-
-

Q[17:00]：
- nodeハッカーのツールセット
- Ryanはどう予想してる？
- エディタ,、デバッグ機能、テスト、デプロイ、イベントモニタリング

A：
-
-

Q[17:30]：Ryanは何使ってる？
A：
- Vim
-
-

Q[18:50]：
- 公開してるチャットアプリのサンプルで利用可能なメモリを出力してる件

Q[19:37]：
- nodeではフローコントロールの仕組みが色々ある。ざっくり説明よろしく
- コールバック
- Eventemitter
- promise

A：
-
-

Q[21:00]：
- nodeでのロードバランシング
- 現時点でのやり方
- 今後のプラン

A：
-
-

Q[24:18]：
- node/Nginx/js+jvmの小規模なベンチマークがネットでよくみかける。
- こうしたプチベンチマークから色々結論を出そうとしてる。
  - 「GCではV8よりも上」「パケットサイズが大きくなるとnodeのパフォーマンスは下がる」etc
- ryan自身はnodeのパフォーマンスについてどう思ってる？

Q[28:02]：
-
-

Q[29:57]：
- V8以前、jsのVMはしょぼいとみなされ続けてきた
- V8は今後数年で成功していくと思うか？

Q[31:00]
- 「OOPのパワーをjsでも」的なプロジェクトがいくつかある件
  - traits.jsやJS.Class
- 当然アンチがいる
- パフォーマンスが低いがまず批判される
- 次にprototypeなどjavscriptネイティブの機能を使ってOOPを実装してる点も批判されてる
- Ryanの意見は？
A：
- 自分はjavascriptをそのまま使おうとしてる
- この手のライブラリは好きじゃない

Q[31:35]：
- node.jsアプリをホストできる場所？
A：
-
-
Q[32:46]：
- 2010年10-12月のロードマップを最近MLに投稿してた件
- （補足）2010 Q4 Roadmap - nodejs
- ざっくりとした説明
- 今後の展開のヒントを少々
A：
-
-
Q[34:15]：
- 注目のnode.jsフレームワークを何個かピックアップ
A：
-
-
Q[35:59]：
- １０種類のブラウザ？
A：
-
-
Q[37:48]：
- 本当にマルチプロセス？
A：
-
-
Q[39:24]：
- nodeとCommonJSの関係
- CommonJSのスペックで現在nodeでのサポート状況
  - 済みのものはModulesの他にある？
- CommonJSとnodeのは今後どうなってくと思う？
A：
- あとで
-
-

2011年以降にでも

Q[42：49]：
- 今の話は、異なるサーバーサイドでの解決方法の間でのinteroperabilityの話だと思った
- ブラウザ上で実行されるために書かれたコードとnodeの関係はどう思う？
- 「サーバーサイド用に書いたこのコードは、実はブラウザ上でも実行できる」
  - こんな言い回しが当てはまるような現場はあると思うか？
  - もしくは実際にありそうなケースをRyanの観測範囲内で知ってるものある？
    - ブラウザ上で実行されるコードの大半はDOM操作なので「既にありそう」と思ってる。
A：
- サーバーサイド／フロントエンドでのコード共有は、そんなに多くの人は望んでることじゃない
- 「サーバー／ブラウザでコードが共有できる。これはいいことあるぞ」とか
  - node見てこうこと言う人たちを山ほどみてきた
- でも、ブラウザがやる処理とサーバーサイドで必要な処理は全然違う
- 実際にサーバー／ブラウザ間で共有できるコードの量は少ないと思う
- 少しはコード共有できる場面はあるかも
  - validation系のコード／ライブラリ
  - 入力フォームでの内容（mailアドレスちゃんと入力してるか、とか）を、ブラウザ／サーバーサイドでチェック、とかよくあるやつ
- 今後共有できる場面は出てくるかも
- YUIチームが今やってる
  - サーバーサイドでのDOMツリー構築
  - サーバー用のコード生成とか
- スクレイピング技術
  - サーバー／ブラウザでのコード共有と関係してくるテクニック
  - jsdom
    - nodeのモジュール
    - node上にdomツリー構築できる
    - jqueryとかjsライブラリを読み込んで、dom操作とかできる
- あとで
Q[45:15]：
thank you very much Ryan.
A：
- thank you