Node.jsはコールバック・スパゲティを招くか

技術動向

» 2011/03/22

　近ごろ話題のNode.jsですが、その理由は以下のようにいくつかあると思います。

1. イベント・ループを使った非同期処理で、同時接続クライアント数が多数となる高負荷時のスケーラビリティに優れる。急増中のNode.js向けライブラリは最初からすべてノンブロッキングであることもポイント。
2. クライアントで使われるJavaScriptと同じ言語でサーバサイドのアプリも作れる。
3. Google Chromeに搭載されるJavaScriptエンジン「V8」はバージョンが上がるたびに高速化していて、V8を利用したNode.jsもそれに伴い高速化している。
4. パッケージライブラリの充実。「時代の変わり目ならオレにも天下が取れるかも！」と思ったかどうか、新しい物好きの人々が、盛大な勢いでライブラリを書きまくっている。
5. シンプルさ。Webサーバとアプリケーションサーバ、処理系がすべて一体。ライブラリをrequireするだけで既存のミドルウェアやCライブラリも使える。
6. Cloud9のような「サーバアプリ＋WebSocket＋ブラウザ」で動くIDEが実用レベルに近付いている。サーバ側なのでオンラインストレージやGitHubのようなレポジトリとダイレクトにつながる上に、CI環境との統合にも期待できる。ローカルマシンのIDEよりもデータセンター上の開発環境のほうが強力になる可能性がある。

　2番をメリットと考える人は現時点では多数派ではないかもしれません。でも、プログラマ全体での学習コストを考えると、「C（POSIX）→C++（GUI）→Java（サーバ）」と進んできた「最もメジャーな言語」の変遷の先にあるものが、「JavaScript（ブラウザ）」である可能性は高いと思います。jQueryのように見た目やイベント処理を頑張るライブラリだけでなく、CoffeeScriptのようなものが普及すれば、ずいぶん状況が変わりそうな気もします。

　さて、本題は1番です。Node.jsやNginx、EventMachine、Twistedなど、イベント駆動モデルを使ったWebサーバが注目されています。スレッドやプロセスをたくさん用意して処理性能をスケールさせるのではなく、リクエストはキューに入れて、ワーカーで処理するというアーキテクチャです。リアルタイム性が高く、WebSocketやCometを使ってストリームとしてデータを吐き出すAPIを実装するようなケースで威力を発揮すると言われています。

コールバックのネスティングでメンテ困難に

　Node.jsの未来は明るいように見えますが、一方で、非同期処理を自然に記述する方法としてコールバックを多様したプログラミングモデルは、別の問題を引き起こすという指摘があります。コールバックが数百もネストし始めたときに増す複雑さにより、コードの見通しやデバッグ、メンテナンスが難しくなると、PostRankのCTO、Ilya Grigorik氏は自分たちの経験に基づいて論じています。PostRankはソーシャルネットワーク上での反応をアグリゲートして数値化するサービスです。収集データをリアルタイムに処理して、そのデータをビジネスパートナーであるメディア企業などにAPI経由で提供するのがビジネスモデルのようです。

　Grigorik氏はPostRankではNode.jsとは違ったアプローチを取ったといいます。それは、Ruby 1.9で取り入れられたFiberを使うことで、実際の処理は非同期で行いつつも、プログラマには従来通りに同期APIのように見えるRack対応のアプリケーションサーバ「Goliath」（ゴリアテ。英語読みならゴライアス）を実装することでした。PostRankは2008年からGoliathの開発をスタートして、現在の実装はバージョン4に当たるそうです。最新バージョンは1年ほど稼働実績を積んで十分な安定性が得られたので、2011年3月8日にGoliathをオープンソースで公開したといいます（ブログ）。Grigorik氏によればRubyのFiberは、スレッドに比べてオーバーヘッドが小さく、メモリ使用量も少なく済むといいます。現時点でGoliathはMRI、JRuby、Rubiniusで動作していて、MRI 1.9.2＋EventMachineが最も性能が良いということです。

　「継続」（コンティニュエーション）はSchemeなどでは広く使われている概念・機能で、「処理の途中の状態」を変数などにバインドしておいて、処理の流れを変えて、再び処理を再開するような使い方ができるようです。RubyのEnumerableもFiberで動いているといいます。継続それ自体は並行処理のためのプリミティブではなく、例外処理や相互再帰など大域ジャンプが必要な制御構造を実装するためのプリミティブというのが私の理解ですが、非同期処理も書きやすいということでしょうか。

【追記】YARV作者のささださんから、Fiberについての私の勘違いをご指摘いただきましたので当該箇所を消しました。詳しくはコメント欄をご覧ください。いい加減な理解で書いてスミマセン……。

　Grigorik氏はInfoQのインタビュー中で、「GoliathはRuby版のNode.jsか？」という質問に対して、基本的に同ジャンルだとしながらも、次のように答えています。

Goliathの3つのメジャーバージョンアップの過程で見出したのは、非同期のコード（RubyであれJavaScriptであれ）をコールバックを使って書いていると、読んだりテストしたりメンテするのが非常に難しいコードベースになってしまうということです。従って、Node.js人気を横目で見つつも、われわれは違うアプローチを取ったのです。すでにあるコードを“解きほぐす”方法を探したのです。“コールバック・スパゲティ”とRubyのエレガントさは、非常におかしな不調和にも思えましたし、正直、PostRankはJavaScriptも大好きなんですが、RubyやRubyの素晴らしいライブラリ、フレームワークを全部捨ててJavaScriptを選ぶ必要があるようには感じませんでしたね。

　コールバック・スパゲティとは具体的にどういうことで、Goliathの場合どうかという解説はコードサンプルとともに、このブログエントリで読めます。

　Node.jsのようなイベントループを基本としたフレームワークが時代の要請応えているのだとしたら、GoliathもRubyコミュニティで一定の支持を得ることになるのかもしれません。ただし、Goliathは高負荷が予想されるリソース公開用APIのエンドポイントなどで使うべきもので、RailsやSinatra、あるいはMongrelやThinといった既存のフレームワークやアプリケーションサーバを代替するようなものではない、ということですから、この意味ではNoSQLと似ていますね。ほとんどのケースでは従来通りの手法を使ったほうがよく、パフォーマンスやスケーラビリティの問題があるなら、NoSQLやイベントループ系のWeb・アプリサーバに目を向けるということでしょうか。