Phusion Passenger/mod_railsによってRailsのデプロイメントが容易に

作者 Werner Schuster , 翻訳者 編集部 投稿日 2008年5月1日

セクション

運用/インフラ,

デベロップメント,

設計/アーキテクチャ

トピック

Ruby ,

Ruby on Rails ,

テクノロジー ,

デプロイ/データセンター ,

パフォーマンス&スケーラビリティ ,

ランタイム ,

オープンソース

タグ

Ruby on Rails ,

Rails ,

デプロイ

新プロジェクトではApache Webサーバを使ったRuby on Railsアプリケーションのデプロイメントをいっそう容易にすることを目指している。すでにRailsの作者などから推薦を受けている(source)Phusion Passenger/mod_rails(source)は、この目標を達成しているように思われる。Phusion Passengerの作者の1人、Ninh Bui氏(source)に、このプロジェクトの裏側や今後について話を聞いた。

まず、名称の問題を明確にしたかった。このプロジェクトのWebサイトはmodrails.comだが、Phusion Passengerという名前も使われている。Ninh Bui氏の説明はこうである。

Phusionは我社の名称で、Phusion Passengerはmod_railsの公式名称です。コミュニティのほとんどの人は、mod_××という命名規則から、mod_railsが何たるかがよく分かるでしょうから、この別名をそのままキープしておくことにしました。当初はmod_railsだけを使う予定でしたが、Ruby on Railsの中心チームと私たちは、「Passenger」（乗客）という言葉が Railsのパラダイム内ではよりピンとくると考えました。特に、Phusion Passenger（別名mod_rails）がもたらそうと努力しているエクスペリエンスは、（列車の）乗客の体験と大差ないのです。ただ座って、乗車を楽しむだけですから。;-)。

もう1点は、Phusion Passengerの配布ライセンス（配布条件）である。

ライセンスについては、追加条項付きですが確かにGPLv2としましたが、しばしば誤解される傾向にあるため、この機会を借りてこの「問題」をまとめて処理したいと思います。ライセンスを制限する代わりに、実際のところ、コミュニティがいっそう自由にソースを使えるようにしたのです！


 私たちはオープンソース・コミュニティにおける経験も豊富ですし、非常に愛着を感じるようになりました。オープンソースの開発モデルが営利企業の推進力と連動することにより、より質の高い製品をお届けできると信じています。つまり、営利目的の団体がコミュニティに恩返しする最も良い方法が、オープンソースの開発モデルであると確信しているのです。

その証しとして、Phusion Passengerは本番環境で信頼性が高く、頑丈であるよう設計・プログラムされています。それにもかかわらず、デプロイメント上の問題に遭遇したり、カスタム機能が必要になったりするかもしれません。そのような方たちには、有料サポートを提供しています。我社の専門家チームは様々な環境に通じており、その中でもLinuxベースの環境には特に経験豊富で、Ruby内部やRuby on Rails、Passengerに対する深い知識も持っています。

また、Railsデプロイメント用の類似ソリューションとPhusion Passengerを比較した場合どうか、ということにも興味がある。

SwiftiplyやMongrel Clusterなどとは異なり、Phusion Passenger のアプリケーションプールはその時点でのトラフィックに基づいて自動的に管理されます。また、クラッシュしたRailsアプリケーションは自動的にリスタートされます。つまり、コンフィギュレーションやプロセスモニタリングが不要であることを意味し、結果としてシステムアドミニストレーション・オーバーヘッドの削減につながるはずです。また、様々なコンフィギュレーション・オプションが利用可能で、こうしたオプションについてはユーザーズガイドに明記されています。

Phusion Passengerを使ったRailsアプリケーションのデプロイと再デプロイには何が必要か、も知りたいところだ。

インターネット接続にもよりますが、2分必要です;-)。冗談はさておき、Phusion Passengerを利用したRailsアプリケーションの更新と再デプロイに必要なのは、アプリケーションの再アップロードとrestart.txtファイルにタッチすることだけでしょう。おおかたこの2段階の処置だけです。Apacheを再起動したくないなら、第2段階の処置であるrestart.txtファイルへのタッチが必要になります（大部分の方がこちらをご希望と思います ;-））。

技術的な点になりますが、第2段階の処置をすることによりrestart.txtファイルのタイムスタンプが更新されます。Phusion Passengerはこのタイムスタンプに基づいてRailsアプリケーションを再起動するか否かを決定します。

 Railsのデプロイメントは、Phusion開発者が対処しようとしている唯一の問題ではない。多数のRailsプロセスをホスティングすることに伴う問題の1つに、メモリオーバーヘッドがある。いかなるRubyプロセスもRubyライブラリとRails ライブラリをメモリにロードしなければならないが、このロードは別プロセスであるため、現在はまったく共有されていない（Rubyコードはヒープ上に格納されるため、共有ライブラリとは異なり、プロセス間で共有されていないのである）。Phusion開発者のひとりであるHongli Lai氏(source)は、Rubyプロセス間でデータを共用できるようにするため、Unixのsyscall fork()の使用を試みた。ライブラリ構成からRubyプロセスを入手し、次にそのプロセスをfork()して、別のRubyプロセスを手に入れることを狙っている。プロセス中にfork()を呼び出せば、それは要するに、このプロセスを効率的に複製することになる。2つのプロセスの外見は基本的に同一で、アドレス空間には同じデータが入っている。しかし、これは共有メモリではなく、その代わりにOSのバーチャル・メモリ・システムはCOW（コピー・オン・ライト）というメソッドを使うことにより、プロセスのデータは同一にするが、プロセスの専有コピーは修正可能にする。データがリードオンリーである限り、存在する必要のあるデータのコピーは1つだけだが、ひとつのプロセスがデータ修正を開始するやいなや、そのデータはプロセスにコピーし直される。これを利用すれば言うまでもなく、ライブラリコードやその類のリードオンリー・データは、共有可能になる。

しかし、ガーベジコレクションを使う言語では問題がある。フル・ガーベジコレクションはヒープを回って、手の届く全オブジェクトに印を付ける。ここで重要なのは「印をつける」という言葉で、つまりオブジェクト上のフラグを反転させる。こうしたオブジェクトを別のプロセスと（fork()から）共有していると、COWが割り込み、データをコピーし直すが、そうするとそのデータはもう共有されておらず、全プロセスが独自のコピーを持つようになることを意味する。


この問題に対するHongli Lai氏の解決策は、RubyのガーベジコレクションをCOWフレンドリー(source)にすること、すなわち、コレクションにデータコピーの原因を作らせないことである。この取り組みの現状について、またこの取り組みがPhusion製品にどう関係しているのかを、Ninh氏は次のように詳細を説明している。

 「コピー・オン・ライトのガーベジコレクター」はもうほとんど完成しています。現在はリリースに磨きをかけ、Webサイトを作成しているところです。また、Twente大学工学修士Hans Scholten氏の助けを借りて、この件についての学術論文に取り組んでいます。今後数週間内にリリースできるでしょう。Rubyにパッチを当てるという考え方を嫌がる方々が存在するかもしれないので、インストールが可能な限り簡単になるよう、また、インストールが完全に独立してシステムファイルにはまったく変更を加えないように、特に注意を払いました。


 私たちは出来上がった物を「Ruby Enterprise Edition」としてリリースするつもりであり（名称については十分承知していますが、Railsconfにおいて詳しく説明させてください;-））。その名前だけの価値があると保証しますので、どうかそれまでお許しください。Ruby Enterprise Editionは標準Ruby（1.8）と完全に下位互換性があることも指摘しておきます。


Phusion PassengerがRuby Enterprise Editionを使用するよう命令されると、Passengerは自動的にコピー・オン・ライトのセマンティクスを利用します。これによりRailsアプリケーションでメモリを大幅に節約できます。 実際、初期のテストでは平均的なケースで約33%の節約が見られました。

鑑識眼のある読者なら、Ruby Enterprise Editionがこのすべてを透過的に行い、ランタイム時にはGC最適化のオン・オフのトグルをアプリケーションプログラマーに提供することも、お気づきのことでしょう。Ruby Enterprise EditionをRubyのスーパーセットとして検討するべき理由がここにあります。


このために、Rubyのヒープ実装方法を変える必要がありました。オブジェクト内のマークビットの代わりに、今ではビットフィールドのセットを使っています。パフォーマンスは可変的で、アプリケーションと作業負荷に依存します。Railsアプリケーションの中には、5%のパフォーマンスヒットを計測したものもあります。20%のものもあれば、0%、つまりまったくパフォーマンスヒットがなかったものもあります。この件について詳細な情報を希望する方々のために、Railsconfで詳しく説明する予定ですが、スケジュール的に可能であれば、もっと近い将来に説明できるかもしれません。

Phusion Passengerを試してみたい全ての方々向けに、PhusionWebサイトには必要なステップを説明するスクリーンキャストが準備されているし(サイト・英語)、単にPhusion Passengerのインストール説明を読んでみるのもよいだろう(サイト・英語)。Phusion Passengerはオープンソース・プロジェクトであるため、Phusion PassengerのGitHubリポジトリを見ることができる(サイト・英語)。

原文はこちらです：http://www.infoq.com/news/2008/04/phusion-passenger-mod-rails-gc

• 次へ >