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にかかわる問題を抽象化して脇に追いやる
- ちょっとした経験で、数1000コネクションレベルへサーバーをスケールすることできるサーバ作れるようにする
- このインタビュー
- 入門的話題はスキップ
- ryanのモチベーションや、node内部の問題やデバッグ、モニタリング、スケーリングなど現実的な問題へフォーカス
- Node.jsの目指すところ
- Ryan略歴
- Joyentで働くプログラマ
- Node.jsクリエータ
- NY州Rochester育ち
- San Francisco在住
- Q:とりあえず自己紹介
- A:
- ホスティングサービスやってるJoyentで働いてる。
- Node.js作った。だからインタビューされてるんだと思う
- Q:node.jsを始めた理由、解決したいと思った問題、到達した解決策
- A:
- 大学では数学やってたし、computingの世界に入ったのは少し前から
- (補足)University of Rochesterで2005年に数学専攻で修士号取得
- rubyのウェブサーバー開発は長い間やってた
- まずrubyに興味もった
- 当時「面白い」と思った問題
- 数年間Mongrelにのめりこむ
- それからjavasccriptとイベントドリブンなプログラミングについて自分が得た知識を組み合わせてみた
- 当時各ベンダー間でjavascript高速化競争が始まった頃
- jsとイベントドリブンプログラミングの組み合わせはちょっとした実験としてやってみた
- jsとイベントドリブンなプログラミングはとてもうまくフィットした
- やってみたらうまくいった
- 大学では数学やってたし、computingの世界に入ったのは少し前から
- Q[02:26]:
- サーバーサイドJSのプロジェクトは他にもいろいろ
- RingoJSとか、AppengineJSとか、
- たいていJVMで実行される
- Node.jsを他プロジェクトと分け隔てる重要な違いは?
- サーバーサイドJSのプロジェクトは他にもいろいろ
- A:
- 確かにサーバサイドJSは昔からいろいろあった
- とりあえず、JVMではなくV8上で実行される
- 他のプロジェクトは伝統的なアプローチという点で共通
- 他の言語(ruby/python/etc.)にあるものをサーバーサイドjavascriptでも実装しましょ、という流れ
- 例
- たくさんクライアントあってそれらがサーバーへリクエストするという場面
- マルチスレッド欲しいね、マルチスレッドでリクエスト捌こう
- というのが伝統的アプローチ
- 要するにここが違う
- VMが違う
- JSの本質から外れた拡張をやってない点が違う
- 「シングルスレッド」「ノンブロッキング」というJavascriptという言語がもつ特徴をそのまま使う
- ちなみに自分が最初にウェブサーバーの例でNode.jsの話をしてるのは、これが典型的例だから
- サーバーサイドの世界でjavascriptはどうあるべきかという話
- CommonJSがやってること。仕様を作ろうとしてる
- Q[04:21]:
- A:
- すべてコールバック
- 普通のサーバーサイド開発だとこうなる
- はじめにDBへアクセス
- それからファイルへ書き込んで
- それからファイル移動して
- それから他にもいろいろやって
- となる
- この手のシーケンシャルな処理を1つずつ実行
- ブロッキングI/Oとスレッドが当たり前の世界のやり方
- nodeの場合
- やり方を変えないといけない
- 処理1つ1つに時間がかかる。所要時間ゼロにならない
- ファイルの移動にはディスクが回転が必要
- DB問合せだってレスポンス来るまでに数ミリ秒は待つ
- nodeではすべてがノンブロッキング
- 「レスポンスを待ちレスポンスが来てから処理に移る」ということができない
- コールバックが必須の世界
- nodeには大量の無名関数。
- 無名関数内で、レスポンスを受け取るためにコールバックを用意する
- nodeの世界の混乱のもとはスタイルの問題なので、慣れれば解決する話
- Q[05:48]:nodeの世界はフロントエンド開発者がよく慣れ親しんでる世界と言える?
- A:
- そのとおり
- nodeのセールスポイント
- nodeの世界の原則であるノンブロッキング/コールバックベースのプログラミングを多くの人が習得済みである点
- フロントエンド開発で習得済み
- xhrオブジェクト使いたければ非同期プログラミングが必須であることは周知のこと
- xhrを同期的に使えばウェブページがロックされてしまうことを知ってる
- nodeの世界の原則であるノンブロッキング/コールバックベースのプログラミングを多くの人が習得済みである点
- 同期的にxhrを使うべきところはある
- DBへリクエスト投げるとき
- 同期的でないといけないし、同期的でないとプログラムが書けないということだってある
- DBへリクエスト投げるとき
- Q[06:35]:
- ryanのプレゼンを何個かみた
- js/nodeやるまえに他の言語でも実験してたんじゃない?と思った
- jsのシンタックスやV8に(ほかの言語にはない)魅力があったのか?
- A:
- ruby長いこと使ってみた
- rubyのVM使ってると本末転倒なことになる。
- 遅すぎ。速くしようとしたら「この部分はCで書きなおそう」ってなる
- rubyで1行書くたびにサーバーがもっさりしていく
- rubyやめてCでサーバー書くことになった
- Cだけになったら超快適
- Cでサーバー書き、ファイルi/oも実装し
- ちょうどそのとき夢想してたこと
- 面倒そうな問題は抽象化して脇に追いやってくれるライブラリがリリースされる。
- みんなCでその手のライブラリをガシガシ書く
- みんなが自分用にちょっとしたサーバーを書く
- もちろんこの夢想は現実にはあり得ない。みんなCで書きたがらない
- ノンブロッキングな環境
- これをエンジニアたちに提供したいとも思ってた
- ノンブロッキングな世界こそが、サーバーデザインに最適
- サーバーデザイン
- しばらく純粋関数型な(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の特徴の1つ
- この理解であってる?
- 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をすごく大事にしてる
- リッチなブラウザにはリッチな機能、そうでないブラウザにはシンプルな機能、等々
- たとえばYahoo!のサイトはjsがオフになってても機能制限はあってもコンテンツにアクセスできる
- Q[14:00]:
- 今Yahoo!にアクセスしてもjsオフで利用できる?
- A:
- -
- Q[14:47]
- A:
- -
- -
- Q[17:00]:
- nodeハッカーのツールセット
- Ryanはどう予想してる?
- エディタ,、デバッグ機能、テスト、デプロイ、イベントモニタリング
- A:
- -
- -
- Q[17:30]:Ryanは何使ってる?
- A:
- -
- -
- Q[18:50]:
- 公開してるチャットアプリのサンプルで利用可能なメモリを出力してる件
- Q[19:37]:
- nodeではフローコントロールの仕組みが色々ある。ざっくり説明よろしく
- コールバック
- Eventemitter
- promise
- A:
- -
- -
- Q[21:00]:
- nodeでのロードバランシング
- 現時点でのやり方
- 今後のプラン
- A:
- -
- -
- Q[24:18]:
- Q[28:02]:
- -
- -
- Q[29:57]:
- V8以前、jsのVMはしょぼいとみなされ続けてきた
- V8は今後数年で成功していくと思うか?
- Q[31:00]
- 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]:
- 10種類のブラウザ?
- 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ツリー構築
- サーバー用のコード生成とか
- スクレイピング技術
- あとで
- Q[45:15]:
- thank you very much Ryan.
- A:
- thank you