Web APサーバーとWebフレームワークをつなぐもの

インターネット黎明期はCGIが一般的でPerl+CGI掲示板を作るというのはよくあるパターンだったと思う。

CGIは言語非依存で環境変数経由でHTTPリクエストパラメーターなどを受け取って標準出力に出せば良いというシンプルなモデル。リクエストごとにプロセスを生成するので負荷が大きいというデメリットがある。

Javaの世界ではServletという標準化されたAPIがあり、これを実装したWeb APサーバーは1リクエストをスレッドで扱うためCGIに比べると性能が良い。

またServletは標準化されたAPIであるためこれに依存したWebフレームワーク、古くはStruts、今だとSpring Web MVCなんかで実装したWebアプリケーションはServlet APIに準拠したどのWeb APサーバーでも動く。

一方Perl, Ruby, PythonといったLL言語Javaとは違う道を歩んできた。

CGIの問題を解決するために作られたFastCGIはプロセスをメモリ上に永続化させることでその起動と終了にかかる時間をカットする。最初にプロセスが実行された段階で、そのプロセスはメモリ上に格納され、次の要求に対してはそのメモリに格納されたプロセスを実行する。

mod_perl/mod_python/mod_rubyのようなApacheモジュールはApacheに言語のインタプリタを組み入れてプログラムを実行する。FastCGIと異なりプロセス管理はApacheまかせとなる。

Apache以外にもlighttpd, nginxなどさまざまなWebサーバがあるわけだが、そうした多様なWebサーバ環境ごとの差異を吸収するためのコードをWebフレームワーク(例:Catalyst, Django, Rails)が書くのは大変である。ましてWebフレームワークは沢山あるわけだし。

そうした状況を解決するために出てきたのがPythonならWSGIであり、RubyならRackであり、PerlならPSGIである。まあどれもざっくりいえばServlet APIみたいな標準化されたものだと思う。

これが出てきたことにより、Perlなら第1回 PSGI/Plack―フレームワークとサーバをつなぐエンジン (1):Perl Hackers Hub|gihyo.jp … 技術評論社にあるように

というようになった。めでたし、めでたしである。

Webアプリケーション側もWSGI/Rack/PSGI対応を進めているようで、PSGIの例でいうとYAPC::Asia Tokyo 2013: 「本当にあったレガシーな話」と最近のlivedoorBlogの改修 : D-7 <altijd in beweging>なんかが mod_perl から PSGI + Starlet にかえた例のようだ。StarletはPSGI仕様のサーバのこと。ちなみにRack仕様のサーバーの例としてはunicornがあり、WSGI仕様のサーバーの例としてはgunicornがある。

pythonで作られたBTSであるTrac(ただしTracはWebフレームワーク使ってない)なんかだとmod_pythonは非推奨となっている。こっちはFastCGIかもしくはApache+mod_wsgiあたりが良いのかな。

Trac provides various options for connecting to a "real" web server:

TracInstall – The Trac Project

Ruby, Railsで作られたBTSであるRedmineだとRailsがRack対応しているのでデプロイ先はいろいろ選択肢がありそう。

Note: Webrick is not suitable for production use, please only use webrick for testing that the installation up to this point is functional. Use one of the many other guides in this wiki to setup redmine to use either Passenger (aka mod_rails), FCGI or a Rack server (Unicorn, Thin, Puma, hellip;) to serve up your redmine.

RedmineInstall - Redmine


ところでJavaの世界はServlet APIで完結しているのかというと、まあだいたい完結しているような気もするけど例外もある。それがPlayでこれはServlet APIを使っていなくてJavaにもWSGI/Rack/PSGI的なものが必要なのかもという意見もあるようだ。

根本的な問題は、 JEE サーバと HTTP 層を結ぶには Servlet APIを使う以外に選択肢がないことだと思う。おそらく、 java のエコシステムには Rack の様なものが必要なのではないだろうか。つまり、HTTP を扱う本当に低レベルでポータブルな API が必要だと思う。少々欠陥のあるアーキテクチャ原則に基づいて構築された、半ばでたらめな HTTP API ではなく。

なぜ Play は Servlet を使っていないのか(Why there is no servlets in Play 翻訳) - ikeike443のブログ