[解決済み】Ruby on Railsのサーバーオプション【終了しました

2022-05-12 10:59:33

質問

Ruby on Railsアプリケーションの開発サーバーのセットアップの問題は、私を混乱させます。WEBrick、Mongrel、Passenger、Apache、Nginx、その他にもたくさんありますが、それらが果たすさまざまな役割についてよく理解できていません。

最初はWEBrickを使っていて、今は開発用にMongrelを使っています。これらのサーバーは独立したものなのでしょうか、それともApacheの前に置かれるものなのでしょうか？

サイトには "makes deployment of Ruby web applications a breeze" と書かれていますが、Mongrel の代わりになるものなのでしょうか？また、WebアプリケーションをデプロイするCapistranoのようなものですか？

SSLをテストしたいのですが、mongrelではサポートされていないことを念頭に置いて、最適な開発サーバーのセットアップは何でしょうか？

ありがとうございます。

解決方法は？

デプロイメントという言葉は、文脈によって2つの意味を持つことがあります。また、Apache/Nginxの役割と他のコンポーネントの役割を混同しています。

歴史的メモ：この記事は2010年11月6日に書かれたものです。2013年3月15日にこの記事を更新し、エコシステムのすべての最新アップデートを行いました。

免責事項 : 私は、アプリサーバーの一つであるPhusion Passengerの作者の一人です。

ApacheとNginxの比較

どちらもウェブサーバーです。静的なファイルを提供することができますが、適切なモジュールを使用すれば、PHPで書かれた動的なウェブアプリケーションを提供することもできます。Apacheはより人気があり、より多くの機能を持っています。Nginxはより小さく、より速く、より少ない機能を持っています。

Apache と Nginx はどちらも Ruby ウェブアプリケーションをそのまま提供することはできません。これを行うには、Apache/Nginx と後述する何らかのアドオンを組み合わせて使用する必要があります。

Apache と Nginx はリバースプロキシとしても動作します。つまり、入ってくる HTTP リクエストを受け取り、同じく HTTP を話す別のサーバに転送することができるのです。そのサーバが HTTP レスポンスを返すと、Apache/Nginx はそのレスポンスをクライアントに転送します。これがなぜ関係するのかは後でわかります。

Mongrel やその他のプロダクションアプリサーバーと WEBrick の比較

MongrelはRubyのquot;アプリケーションサーバーです。具体的に言うと、Mongrel はアプリケーションサーバーです。

独自のプロセス空間内にRubyアプリをロードします。
TCPソケットをセットアップし、外部（インターネットなど）と通信できるようにします。 Mongrel はこのソケットで HTTP リクエストをリッスンし、リクエストデータを Ruby ウェブアプリに渡します。
そして Ruby ウェブアプリケーションは、HTTP レスポンスがどのように見えるかを記述したオブジェクトを返し、Mongrel はそれを実際の HTTP レスポンス（実際のバイト）に変換してソケット経由で送り返す処理を行ないます。

しかし、Mongrelはかなり古いもので、現在ではメンテナンスが行われていません。新しい代替アプリケーションサーバーはメンテナンスされています。

フュージョンパッセンジャー
ユニコーン
薄型
プーマ
トリニダード(JRubyのみ)
TorqueBox (JRubyのみ)

後ほど取り上げて、それぞれの違いやMongrelとの違いを説明します。

WEBrickはMongrelと同じことをしますが、違いは。

WEBrick は、前に述べた他のものとは異なり、生産用には適していません。WEBrick は完全に Ruby で書かれています。Mongrel (そして他のほとんどの Ruby アプリサーバー) は、一部が Ruby で一部が C (ほとんどが Ruby) ですが、その HTTP パーサーはパフォーマンスのために C で書かれています。
WEBrick は速度が遅く、堅牢性に欠けます。メモリリークやHTTPパースに関する問題があることが知られています。
WEBrick は Ruby にデフォルトで含まれているため、通常は開発中のデフォルトサーバとしてのみ使用されます。Mongrel や他のアプリサーバーは別途インストールする必要があります。本番環境でのWEBrickの使用は推奨されませんが、なぜかHerokuはWEBrickをデフォルトサーバーとして選択しました。以前はThinを使っていたそうですが、なぜWEBrickに切り替えたのかはわかりません。

アプリサーバーと世界

現在のRubyアプリサーバーはすべてHTTPを話しますが、アプリサーバーによっては80番ポートで直接インターネットに公開されている場合もあれば、そうでない場合もあります。

インターネットに直接公開できるアプリサーバー Phusion Passenger、Rainbows
インターネットに直接公開されない可能性のあるアプリサーバー。Mongrel、Unicorn、Thin、Puma。これらのアプリサーバーは リバースプロキシWebサーバ ApacheやNginxのような
TrinidadとTorqueBoxについては、十分な知識がないので省略しました。

なぜ一部のアプリサーバはリバースプロキシの後ろに置かなければならないのですか？

アプリサーバーによっては、1プロセスあたり1リクエストしか同時に処理できないものがあります。2 つのリクエストを同時に処理したい場合は、複数のアプリサーバインスタンスを実行し、それぞれが同じ Ruby アプリを提供する必要があります。このようなアプリサーバプロセスの集合を アプリサーバクラスタ (Mongrel Cluster、Thin Clusterなどの名称の由来）。次に、このクラスタにリバースプロキシするように Apache または Nginx をセットアップする必要があります。Apache/Nginxはクラスタ内のインスタンス間のリクエストの分散を行います（これについてはセクション「"I/O concurrency models"」で詳しく説明します）。
ウェブサーバーはリクエストとレスポンスをバッファリングし、「スロークライアント」（あまり速くデータを送信または受信しないHTTPクライアント）からアプリサーバーを保護することができます。クライアントが完全なリクエストを送信するか、完全なレスポンスを受信するのを待つ間、アプリサーバが何もしないのは好ましくありません。ApacheとNginxはマルチスレッドまたはイベント化されているため、同時に多くのことを行うのが非常に得意です。
ほとんどのアプリサーバーは静的ファイルを提供することができますが、特に優れているわけではありません。Apache と Nginx はより高速に処理することができます。
通常、静的ファイルを直接提供するように Apache/Nginx を設定しますが、静的ファイルに対応していないリクエストをアプリサーバに転送することは、セキュリティ上、良い方法です。Apache と Nginx は非常に成熟しており、（おそらく悪意を持って）破損したリクエストからアプリサーバを保護することができます。

なぜ、一部のアプリサーバーはインターネットに直接公開できるのですか？

Phusion Passengerは、他のすべてのアプリサーバーとは全く異なる存在です。そのユニークな特徴の1つは、Webサーバーに統合されていることです。
レインボー作者は、インターネットに直接公開しても問題ないと公言している。作者は、HTTPパーサー（およびそれに類するもの）に脆弱性がないことをかなり確信しています。それでも、作者は何の保証もせず、使用は自己責任でお願いしますと言っています。

アプリケーションサーバーの比較

このセクションでは、これまで紹介したほとんどのアプリケーションサーバーを比較しますが、Phusion Passengerは除きます。Phusion Passengerは他とは異なる存在であるため、専用のセクションを設けました。また、TrinidadとTorqueBoxはよく知らないので省きましたが、JRubyを使うのであれば、いずれにしても関係することです。

モンクレール はかなり骨太でしたね。先に述べたように、Mongrelは純粋にシングルスレッドのマルチプロセスなので、クラスタでないと使い物になりません。プロセスの監視はありません。もしクラスタ内のプロセスがクラッシュしたら（たとえばアプリのバグが原因で）、手動で再起動する必要があります。そのため、Monit や God などの外部プロセス監視ツールを使用する傾向があります。
ユニコーン は Mongrel のフォークです。限定的なプロセス監視をサポートしています。プロセスがクラッシュすると、マスタープロセスによって自動的に再起動されます。プロセスごとに個別のソケットを用意するのではなく、すべてのプロセスを一つの共有ソケットでリッスンさせることができます。これにより、リバースプロキシの設定が簡単になります。Mongrel と同様、純粋にシングルスレッドでマルチプロセスです。
薄型は、EventMachine ライブラリを利用したイベント型 I/O モデルを採用しています。Mongrel HTTPパーサーを使う以外は、Mongrelをベースにしているわけではありません。クラスターモードではプロセスの監視ができないので、クラッシュなどを監視する必要があります。Unicornのような共有ソケットはないので、各プロセスは自分のソケットでリッスンします。理論的には、Thin の I/O モデルは高い同時実行性を可能にしますが、Thin が使われるほとんどの実用的な状況では、1つの Thin プロセスは1つの同時リクエストしか処理できないので、やはりクラスタが必要です。この特殊な性質については、「I/O同時実行モデル」セクションで詳しく説明しています。
プーマ もMongrelからフォークされましたが、Unicornとは異なり、Pumaは純粋にマルチスレッドになるように設計されています。そのため、現在のところビルトインのクラスタサポートはありません。マルチコアを利用できるように特別な注意を払う必要があります（これについては "I/O同時実行モデル" のセクションで詳しく説明します）。
レインボー は、異なるライブラリの使用により、複数の並行処理モデルをサポートしています。

Phusion Passenger

フュージョン・パッセンジャーは、他のすべてのものとは全く異なる動作をします。Phusion PassengerはApacheやNginxに直接統合されるため、Apacheのmod_phpと比較することができます。mod_php が Apache にほとんど魔法のように PHP アプリケーションを提供できるように、Phusion Passenger は Apache (そして Nginx も！) にほとんど魔法のように Ruby アプリケーションを提供できるようにします。Phusion Passengerのゴールは、できるだけ手間をかけずに、すべてをJust Work(tm)することです。

アプリのためにプロセスやクラスタを起動し、静的ファイルを提供するために Apache/Nginx を設定したり、プロセス/クラスタへのリクエストをリバースプロキシする代わりに、Phusion Passenger を使用すれば、次のような作業を行うだけでよいのです。

Webサーバーの設定ファイルを編集して、Rubyアプリの「public」ディレクトリの場所を指定します。
ステップ2はありません。

すべての設定は、Webサーバーの設定ファイル内で行います。Phusion Passengerはほとんどすべてを自動化します。クラスタを起動したり、プロセスを管理したりする必要はありません。プロセスの起動/停止、クラッシュ時の再起動など。- はすべて自動化されています。他のアプリサーバーと比較して、Phusion Passengerは可動部分が非常に少ないです。この使い勝手の良さが、Phusion Passengerを利用する主な理由の一つです。

また、他のアプリサーバーとは異なり、Phusion Passengerは主にC++で書かれているため、非常に高速に処理することができます。

またエンタープライズ版は、自動ローリング再起動、マルチスレッドのサポート、デプロイメントエラーへの耐性など、さらに多くの機能を備えています。

上記の理由から、Phusion Passengerは現在最も人気のあるRubyアプリサーバーであり、New York Times、Pixar、Airbnbなどの大規模なものを含む15万以上のウェブサイトを動かしています。

Phusion Passengerと他のアプリサーバーとの比較

Phusion Passengerはより多くの機能を提供し、他のアプリサーバーと比較して以下のような多くの利点を提供します。

トラフィックに応じてプロセス数を動的に調整。私たちは、リソースが制限されたサーバーで、一般公開されておらず、組織内の人が1日にせいぜい数回しか使用しないようなRailsアプリを大量に実行しています。GitlabやRedmineなどです。Phusion Passengerは、これらのプロセスが使用されていないときはスピンダウンし、使用されているときはスピンアップすることで、より重要なアプリに使用できるリソースを増やすことができるのです。他のアプリサーバーでは、すべてのプロセスが常時オンになっています。
アプリサーバの中には、設計上、特定のワークロードを苦手とするものがあります。例えば、Unicornは高速に実行されるリクエストのみに対応するように設計されています。参照ユニコーンのウェブサイトのセクションを参照してください。

ユニコーンが苦手とするワークロードは

ストリーミングワークロード（例：Rails 4のライブストリーミングやRails 4のテンプレートストリーミングなど）。
アプリがHTTP APIコールを実行するワークロード。

のハイブリッドI/Oモデルは Phusion Passenger Enterprise 4 は、この種のワークロードに最適な選択肢です。

他のアプリサーバーでは、ユーザーはアプリケーションごとに最低1つのインスタンスを実行する必要があります。それに対して、Phusion Passengerは1つのインスタンスで複数のアプリケーションをサポートします。これにより、管理のオーバーヘッドが大幅に削減されます。
セキュリティ対策に便利なユーザー自動切り替え機能。
Phusion Passengerは、多くのMRI Ruby、JRuby、Rubiniusをサポートしています。Mongrel、Unicorn、ThinはMRIのみをサポートしています。Pumaは3つともサポートしています。
Phusion Passenger は、実は Ruby 以外にも対応しているのです! Python WSGIもサポートしているので、例えばDjangoやFlaskのアプリを実行することもできます。実際、Phusion Passengerはポリグロットサーバーになる方向に向かっている。Node.jsのサポートはTodoリストに入っています。
アウトオブバンドガベージコレクション。Phusion Passengerは、通常のリクエスト/レスポンスサイクルの外側でRubyガベージコレクタを実行することができ、リクエスト時間を数百ミリ秒短縮できる可能性があります。Unicornにも同様の機能がありますが、Phusion Passengerのバージョンは以下の点でより柔軟です。 1) GCに限定されず、任意の作業に使用できる。 2) Phusion Passengerのバージョンはマルチスレッド・アプリと相性が良いが、Unicornのものはそうでない。
ローリングリスタートの自動化ユニコーンや他のサーバーのローリングリスタートには、スクリプト作業が必要です。Phusion Passenger Enterpriseは、この作業を完全に自動化します。

他にも機能や利点はありますが、リストアップすると本当に長くなってしまいます。Phusion Passengerの包括的なマニュアルを参照してください ( Apacheバージョン , Nginxバージョン ) または Phusion Passengerのウェブサイトをご覧ください。

I/O並行処理モデル

シングルスレッド・マルチプロセス。 これは伝統的にRubyアプリサーバで最も人気のあるI/Oモデルで、Rubyエコシステムのマルチスレッドサポートが非常に貧弱だったことも理由のひとつです。各プロセスは一度にちょうど1つのリクエストを処理することができます。ウェブサーバはプロセス間の負荷分散を行います。このモデルは非常に堅牢で、プログラマが並行処理のバグを持ち込む可能性はほとんどありません。しかし、その I/O 同時実行性は非常に限られています (プロセス数によって制限されます)。このモデルは、高速で短時間に実行されるワークロードに非常に適しています。例えば、HTTP API の呼び出しを含む作業負荷のような、低速で長時間実行するブロッキング I/O 作業負荷には、非常に不向きである。
純粋なマルチスレッド。 現在、Rubyのエコシステムは優れたマルチスレッドサポートを備えているため、このI/Oモデルは非常に現実的なものとなっています。マルチスレッドは高いI/O同時実行性を可能にし、短時間実行と長時間実行の両方のブロッキングI/Oワークロードに適している。プログラマーが並行処理のバグを引き起こす可能性は高くなりますが、幸いなことに、ほとんどのWebフレームワークは、このようなバグが発生する可能性はまだ非常に低いように設計されています。ただし、MRIのRubyインタプリタでは、GIL（Global Interpreter Lock）を使用しているため、複数のスレッドがあっても複数のCPUコアを利用することができないことに注意が必要です。複数のマルチスレッドプロセスを使用することで、各プロセスがCPUコアを活用できるため、この問題を回避することができます。JRubyとRubiniusにはGILがないため、1つのプロセスで複数のコアをフルに活用できる。
ハイブリッド型マルチスレッド・マルチプロセス。 主にPhusion Passenger Enterprise 4以降で実装されています。シングルスレッド・マルチプロセス、純粋なマルチスレッド、あるいはそれぞれが複数のスレッドを持つマルチプロセスなどを簡単に切り替えることができます。このモデルは、両者の良いとこ取りをしたようなモデルです。
イベント化した。 先に紹介したモデルとは全く異なるモデルです。非常に高いI/O同時実行性を可能にするため、長時間実行するブロッキングI/Oワークロードに優れています。これを利用するには、アプリケーションとフレームワークからの明示的なサポートが必要です。しかし、RailsやSinatraのような主要なフレームワークはすべて、イベント化されたコードをサポートしていません。このため、実際にはThinプロセスは一度に1つ以上のリクエストを処理することができず、事実上シングルスレッド・マルチプロセスモデルと同じ動作をすることになります。Crampのような、イベント化されたI/Oを利用できる特別なフレームワークがあります。

最近、Phusionのブログで、ワークロードに応じたプロセス数やスレッド数の最適なチューニングについての記事が投稿されました。参照 Phusion Passengerの並行処理設定のチューニング .

カピストラーノ

Capistranoは全く別のものです。これまでのすべてのセクションで、quot;deployment" は、アプリケーションサーバで Ruby アプリを起動し、訪問者がアクセスできるようにする行為を指しますが、その前に通常、以下のような準備作業を行う必要があります。

Rubyアプリのコードとファイルをサーバーマシンにアップロードする。
アプリが依存するライブラリのインストール。
データベースのセットアップまたは移行。
Sidekiq/Resque ワーカーなど、アプリが依存する可能性のあるデーモンの起動と停止を行います。
その他、アプリケーションのセットアップ時に必要なこと。

Capistranoの文脈では、このような準備作業をすべて行うことをquot;deployment"と呼びます。Capistranoは、アプリケーションサーバーではありません。Capistranoはアプリケーションサーバではなく、その準備作業をすべて自動化するためのツールです。Capistrano にサーバーの場所と、アプリの新バージョンをデプロイするたびに実行する必要があるコマンドを指示すると、Capistrano がサーバーへの Rails アプリのアップロードと指定したコマンドの実行を代行してくれます。

Capistranoは、常にアプリケーションサーバーと組み合わせて使用します。アプリケーションサーバーを置き換えるものではありません。逆に、アプリケーションサーバーは Capistrano を置き換えるものではなく、Capistrano と組み合わせて使用することができます。

もちろん があります。 はCapistranoを使用する必要があります。FTPでRubyアプリをアップロードして、毎回同じステップのコマンドを手動で実行するのが好きなら、そうすればいいのです。他の人はそれに飽きたので、Capistranoでそのステップを自動化しています。