もともとRubyをターゲットにしていた人気のあるWebアプリケーションサーバ、Phusion PassengerがNode.jsアプリをサポートした。この機能は今年初めに、Passengerのエンタープライズ版で取り入れられたが、フリー版の4.0.21リリースでオープンソース化された。
Passengerは、ApacheやNginxといったWebサーバと組み合わせて、Webアプリケーションの提供、モニタリング、スケーリングのための完全なソリューションになることを目的としている。オランダを拠点とするPhusionによると、PassengerでNode.jsアプリを動かすことには、次のようなメリットがあるという。
- マルチテナント性 – 最小構成で複数のアプリを動かすことができる
- 監視 – 自動的にNode.jsプロセスを開始し、クラッシュ時に再開させることができる
- スケーリング – 処理すべきリクエスト数に応じて、プロセスを増減させることができる
- 統計情報 – プロセスの動作状態を知るのに役立つツールを提供する
Passengerの開発者たちは、Apache/Nginxと組み合わせることで、静的ファイル配信の高速化、大量のアクセス攻撃や遅いクライアントに対する防御といったメリットも得られると述べている。
この発表はPhusionが自ら課した、Passengerを「究極の多言語アプリサーバ」にするという目標に向けた一歩だ。昨年、PassengerのPythonサポートがベータになったが完成したようだ。Node.jsサポートの発表に続いて、PhusionはNodeベースのアプリフレームワークであるMeteorのサポートも明らかにした。
Passenger自体はC++で書かれており、Rubyやその他の言語と密に結合してはいない。バージョン4のリリースでは、いくつかのアーキテクチャ上の変更がなされた。Passengerの内部I/OハンドラはNode.jsとよく似たイベント駆動になり、エンタープライズ版はマルチプロセスおよびマルチスレッドのハイブリッド実行をサポートする。これにより、WebSocket上のライブストリーミングといった機能を可能にしつつ、リソースを最大限に活用することができる。
Rubyアプリに関して、Passengerはたとえば、リクエスト間までガベージコレクションを遅延させることができる"out of band"実行のような機能や、サブスクリプションベースのアプリモニタリングおよび分析サービスであるPhusionのUnion Station製品とのインテグレーションも提供する。
人気のあるRubyアプリサーバのうち、ThinやUnicornのようなイベント駆動のサーバアーキテクチャよりもスレッド化を好むという点において、PumaはPassengerとよく似ている。Phusionチームは最近、PassengerとPumaの比較を公表し、Pumaの開発者であるEvan Phoenix氏がHackerNewsでこれに反応した。
InfoQでは、Passengerの最近のアップデートについて、PhusionのCTO、Hongli Lai氏から話を聞いた。
PassengerはRubyユーザにout-of-band実行のような、言語ランタイムに密接に関係した独自機能を提供していますね。Node.jsやPythonユーザにも同様のメリットはありますか？
ほとんどの機能は、Node.jsとPythonを含むサポートしている言語すべてで利用できます。当初より、私たちはRubyへの依存関係を最小限にしてきました。最初のリリースから数ヶ月ですでにPythonをサポートしていたのですが、積極的な売り込みをしていなかっただけです。次のリリースではMeteorのサポートを計画しています。Node.jsとPythonで利用できない機能がわずかにありますが、これらはその言語では意味がないか、必要な言語固有のサポートコードがまだ書かれていないためです。NodeとPythonのガベージコレクタは通常、Rubyのような長いGCポーズに苦しむことはありません。そのため、Node.jsとPythonユーザにはout-of-band work機能は必要ないと思います。
現時点で、Node.jsのサポートはどれくらい安定していますか？
安定していると思います。私たちのテストアプリケーションはすべてパスしており、テスターのアプリケーションもすべてうまく動いています。既知の問題はありません。
もともとPassengerの目標は、RubyのデプロイメントをPHPと同じくらい簡単にすること、適切なディレクトリにアプリを置くだけにすることでしたよね。Passengerはその約束を達成できたと思いますか？
アプリのデプロイメントには、OSや言語ランタイムのプロビジョニングからライブラリ依存関係の管理やアプリケーションプロセスの監視まで、あらゆることが関係しています。PHPのデプロイが簡単な理由の1つは、mod_phpモジュールを通して、Webサーバが自動的にPHPアプリケーション実行の面倒を見てくれるためです。
Passengerを最初に開発した当時、Rubyアプリケーションの実行、監視、管理は大変な苦痛でした。複数のアプリケーションサーバプロセスを実行し、ローカルソケットをリッスンし、このソケット集合にプロキシが向かうようWebサーバをセットアップし、プロセスがクラッシュしたときに再開するようプロセス監視ツールをセットアップする必要がありました。Passengerで、私たちはmod_phpに似た仕組みを開発することで、この部分を解決しました。ですから、バージョン1.0の時点で、適切なディレクトリに置くだけでRubyアプリを実行するという目標はすでに達成しています。
それでもPHPの方がデプロイするのが簡単だと思われている理由は、多くの人気のあるPHPアプリケーションがアプリ実行以上のことを自動的に世話してくれるためです。たとえば、Wordpressには依存関係がなく、ユーザが設定ファイルを編集する必要もなく、きれいなGUIを通してデータベースのクレデンシャルを求めます。でも自分でPHPアプリを書く場合には、RubyやNode、Pythonアプリで経験するのと同じ問題が起こります。
実際のところ、Passengerがすぐに使えるホスティング会社はありますか？
Passengerがすぐに使える知名度の高いホスティング会社には、Amazon Elastic Beanstalkや Red Hat OpenShiftがあります。Herokuのような多くのプロバイダはアプリサーバの選択にとらわれていませんが、ユーザは簡単にPassengerを使うことができます。BrightBoxやSpeedyRailsなど、デフォルトでPassengerを使っている小さなホスティング会社もたくさんあります。
Rubyアプリサーバには、強い競合がいくつかありますね（Thin、Unicorn、Puma）。この時点で、Passengerはどんな位置にいますか？
他のRubyアプリサーバは、Passengerよりもスコープが限定されています。ユーザはプロセスを開始し、ソケットをリッスンするようセットアップし、リバースプロキシルールを設定したりする必要があります。システム全体を細かくコントロールしたいエキスパートにとって、これは必ずしも悪いアプローチではありませんが、私たちの哲学とは違います。私たちの好みは、安定して柔軟性がありながら、インストール、利用、管理がシンプルなソフトウェアです。
そうは言っても、私たちは他からたくさんのことを学んでいます。たとえば、Passengerの"smart spawning"機能はUnicornよりも先でしたが、Passengerのout-of-band work機能は独自に改善しているものの、Unicornをベースにしています。それぞれのサーバには強みと弱みがあるのです。