Rack入門 概念編 (1/3)

RailsやSinatraなどのRuby製Webフレームワークを利用されている方は、Rackというキーワードを一度は目にしたことがあるのではないでしょうか。

よく聞くけど詳しくは知らない、そんなやつがRackです。

今回は自分の知識の整理も兼ねて、Rackとは何ものなのかについて調べたメモを、ここに残します。長かったので、全3回に分割しています。

目次

1. [本記事] Rack入門 概念編(1/3)
2. Rack入門 Rack Application編 (2/3)
3. Rack入門 Rack Middleware編 (3/3)

Rackとは何か。ひとことで

• Webアプリケーションサーバーとアプリケーションを接続するための標準化されたインターフェースのこと

Rackとは何か。詳細

Rackの公式リポジトリでは、Rackは以下のように記載されています。

a modular Ruby webserver interface

訳) モジュール化されたRuby Webサーバーインターフェース

そして、 Supported web servers として PumaやUnicorn が上げられています。

このWebサーバーという表現はいろいろとややこしいので、本稿ではPuma/Unicornのことは アプリケーションサーバー(アプリサーバー) と呼びます。

Rackはなぜ必要なのか。その前に基本的な概念についておさらいします。

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

アプリケーションサーバーって、なんでしたでしょうか。
ここで一度振り返っておきます。

Webサーバー、アプリサーバーの代表的なソフトウェアは以下のとおりです。

• Webサーバー

  • nginx, apache など

• アプリケーションサーバー

  • Rubyでは Puma, Unicorn など
  • JavaではTomcat など

Webシステムの多くは、いわゆる3層アーキテクチャと呼ばれる構成で設計されており、Webサーバーとアプリサーバーは別に運用します。
以下のような概念図をよく目にするのではないでしょうか。

DBサーバーについては、今回は関係ないので説明を割愛します。

別にこの構成に従わなくてもウェブシステムは運用できますが、システムの性能を引き出すために3層アーキテクチャを採用することが多いです。

Webサーバー

Webサーバーは、ユーザーからのリクエストを受け取り、処理結果をレスポンスとして返すソフトウェアのことです。

受け取ったリクエストはWebサーバー自身が処理することもありますし、そのまま処理をアプリサーバーに委譲することもあります。
静的なコンテンツ(画像やファイル)は、Webサーバーでデータを引っ張ってきて返すことが多いです。
ビジネスロジックはRubyなどで書いたアプリに処理を委譲して、処理結果をレスポンスとして返すことが多いです。

nginxなどのWebサーバーは、大量のアクセスが来ても素早く効率的にさばくための機構を持っています。
またSSL通信やデータを圧縮して返すなど、Webの面倒事を引き受けてくれるソフトウェアです。

アプリケーションサーバー

アプリサーバーは、アプリをあらかじめ起動しておき、リクエストが来たらすばやく処理をするためのサーバーです。

アプリサーバーがないと、どうなるでしょうか。

昔のWebシステムでは、アプリサーバーは立てませんでした。
CGI全盛期は、Webサーバーにリクエストが来た後、プログラムを都度起動していました。
リクエストのたびにプログラムの起動から始めるというのは、巨大なアプリケーションになればなるほど起動コストが無視できないですよね。

なので、あらかじめプログラムをメモリ上に読み込んでおき、アクセスが来たら処理を高速に返せるようアプリサーバーを用意します。

PumaやUnicornなどのアプリサーバーは、Webサーバーとしての最低限の機能も持っています。
Webサーバーを立てずにPumaだけでもシステムを運用できます。
ただ、大量のアクセスを効率的にさばくことはPuma単体ではできない(そこはWebサーバーの役割としている)ので、一般的には前段にWebサーバーを立ててリクエストを処理をします。

Rackはどこで使われ、なぜ必要か

Rackはアプリサーバーとアプリ(Webフレームワーク)間のデータのやり取りに利用します。

PumaやUnicornといったアプリサーバーは、特定のアプリ専用(たとえばRails専用)というわけではなく、RackのプロトコルにしたがっているWebフレームワークであれば何でも利用できます。

Rackに対応しているRuby製のフレームワークは、Railsの他にSinatra, Padrino, Hanamiなどがあります。

アプリサーバーとアプリ間の通信仕様を定めておく(=インターフェースの標準化をしておく)ことで、
アプリサーバーとアプリケーションフレームワークの組み合わせを自由に変えることができます。
Rails専用のアプリサーバーを作る、Sinatra専用のアプリサーバーを作るっていうのは大変ですよね。

アプリ・フレームワーク間の標準インターフェースを作るという流れは、PythonのWSGI(Web Server Gateway Interface)がはじめました。

PythonはもともとWebフレームワークとフレームワーク専用のアプリサーバーが乱立していましたが、WSGIはアプリとサーバーのその組み合わせを自由に変えられるよう標準インターフェースを定めました。
これにより、移植性の高いアプリサーバー/フレームワークを作ることができるようになりました。

Rackの細かいところはWSGIと異なりますが、このWSGIの影響を強く受けています。

まとめ

• アプリサーバーとは、アプリをあらかじめ起動しておきレスポンスを高速に返すためのサーバー
• Rackはアプリサーバーとフレームワーク(アプリ)間のインターフェースを定めている
• Rackのプロトコルに従うことで、アプリサーバーとWebフレームワークの組み合わせを自由に変えることができる