Webサーバーとアプリケーションサーバーの違いとは?Railsデプロイの基礎知識

Railsアプリのデプロイ方法を調べると、Apache、Unicorn、Puma、Phusion Passenger、Nginx、Rainbowsなど、数多くのソフトウェア名が登場します。どれも「Railsのデプロイ」関連に見えますが、実は重要な違いがあります。それが「Webサーバー」と「アプリケーションサーバー」の区別です。

それぞれが何者で、システムのどこに位置するのかを理解できれば、デプロイはぐっと分かりやすくなります。とはいえ、この区分は必ずしも明確ではありません。

Webサーバーとは何か?アプリケーションサーバーとの違いは?片方だけで運用できるのか?そしてRackはどこに入るのか?順番に見ていきましょう。

Webサーバーとは?

Webサーバーとは、ユーザーからWebサイトへのリクエストを受け取り、何らかの処理を行うプログラムです。その後、必要に応じてリクエストをRailsアプリに引き渡します。代表的なWebサーバーとしては、NginxとApacheの2つが有名です。

CSS、JavaScript、画像といった頻繁には変わらないコンテンツへのリクエストであれば、Railsアプリに渡す必要はありません。Webサーバーが単独で処理でき、通常はその方が高速です。

Webサーバーは、SSL/TLS通信の処理、静的ファイルやアセットの配信、レスポンスの圧縮など、ほぼすべてのWebサイトが必要とするタスクを担当できます。そして、Railsアプリ自身が処理すべきリクエストの場合には、Webサーバーがそれをアプリケーションサーバーへ渡します。

アプリケーションサーバーとは?

アプリケーションサーバーは、Railsアプリを実際に動かす役割を担います。コードを読み込み、アプリをメモリ上に保持し続けるのが仕事です。Webサーバーからリクエストを受け取ると、それをRailsアプリに通知し、アプリが処理を完了すると、レスポンスをWebサーバー(最終的にはユーザー)へ返します。

多くのアプリケーションサーバーは、Webサーバーなしでも単体で動かせます。開発環境ではそうしていることが多いでしょう。しかし本番環境では、通常は手前にWebサーバーを配置します。複数のアプリを同時にさばき、アセット配信を高速化し、毎回のリクエストで発生する多くの処理を肩代わりしてくれるからです。

Rails向けのアプリケーションサーバーは非常に豊富で、Mongrel(現在はほぼ使われていません)、Unicorn、Thin、Rainbows、Pumaなどがあります。それぞれ特徴や設計思想が異なりますが、結局のところ目指すものは同じ――Railsアプリを稼働させ続け、リクエストを処理することです。

Passengerはどうなのか?

Phusion Passengerは少し特殊な存在です。「スタンドアロンモード」ではアプリケーションサーバーとして振る舞えます。さらに、Webサーバー本体に組み込むことも可能なので、Railsアプリを動かすために別途アプリケーションサーバーを用意する必要がありません。

これは非常に便利です。特に複数のアプリを運用予定があり、それぞれにアプリケーションサーバーをセットアップする手間を省きたい場合に有効です。Passengerをインストールすれば、Webサーバーの向き先をアプリケーションサーバーではなく直接Railsアプリに指定するだけで、アプリがリクエストの処理を開始します!

Passengerは優れた選択肢ですが、独立したアプリケーションサーバーを使うことにもメリットがあります。分離しておけば、ニーズに最も合ったサーバーを自由に選べ、個別に起動やスケーリングを行えます。とはいえ、次に小規模なアプリをデプロイする際には再度試してみようと思っています。今後、同じサーバーへ新しいアプリを簡単に追加できることを期待して。

Rackはどうなのか?

Rackは、これらのアプリケーションサーバーがRailsアプリ(SinatraやPadrinoなどのアプリでも)を実行できるようにする、いわば「魔法」のような仕組みです。

Rackは、RubyのWebフレームワーク(Railsなど)とアプリケーションサーバーの双方が話す「共通言語」だと考えると分かりやすいでしょう。お互いが同じ言語を理解しているため、RailsはUnicornと、UnicornはRailsと、互いの内部詳細を一切知らなくてもやり取りできるのです。

全体像:どう連携するのか

では、これらの要素はどのように組み合わさるのでしょうか?

まずWebリクエストは、最初に必ずWebサーバーに到達します。Railsで処理すべきリクエストであれば、Webサーバーが前段の処理を行ったうえで、アプリケーションサーバーへ引き渡します。アプリケーションサーバーはRackを通じてRailsアプリとやり取りし、アプリの処理が完了すると、レスポンスはアプリケーションサーバー→Webサーバー→ユーザーという順序で返されていきます。

より具体的に言えば、NginxがリクエストをUnicornに渡し、UnicornはRackへ、RackはRailsルーターへ、ルーターは適切なコントローラーへとリクエストをつないでいきます。レスポンスはその逆の経路をたどって返されます。

この概要は簡略化されていますが、このカテゴリ分けを知っているだけで、出会ったソフトウェアを頭の中で正しく整理・分類できるようになります。

Webサーバーとアプリケーションサーバーの関係を理解しておけば、サーバートラブルが起きたときのデバッグも格段に楽になります。調査すべき箇所と、それらがどう連携しているかが把握できるからです。次に新しいアプリケーションサーバーが登場したときも、入れ替え作業はさらにスムーズになるでしょう。

RailsとWebのやり取りについてさらに学びたい方は、「How Rails Sessions Work(Railsセッションの仕組み)」という記事もぜひチェックしてみてください。