- IT Tips
READ MORE
BPS社内勉強会のmorimorihogeさんのスライド「Webアプリの基礎とさまざまな実行環境を理解する」の第2回です。当初2分割の予定を3分割に変更しました。
Webサーバの役割を一言で言うと「HTTPリクエストにHTTPレスポンスを返すソフトウェア」です。
一般には以下のWebサーバが知られています。
サーバ | 説明 |
---|---|
Nginx | Apacheに比べて軽く、大量のリクエストを捌けるということでここ数年でシェアを伸ばしているWebサーバ |
Apache | 長い歴史を持つ世の中のWebサーバの実質的なスタンダード |
IIS | Windows Serverに付属のWebサーバ。ASP.NET等のMicrosoftプロダクトと多分相性がいいはず |
この他にも特定機能に特化したさまざまなWebサーバがあります。なおNginxは「エンジンエックス」と読みます(公式FAQ参照)。
「特定機能に特化したWebサーバ」の例としてはリバースプロキシがあります。Nginxはリバースプロキシとしても使えますし、逆にプロキシサーバとして有名なSquidも実はWebサーバの一種ということになります。
WebサーバでサポートするHTTPバージョンはソフトウェアとバージョンによって異なりますが、当該ソフトでサポートするHTTPバージョンの仕様上「必須(MUST)」とされている機能は必ずそのWebサーバに実装されています。これができていないWebサーバはそのプロトコルバージョンに対応していると謳ってはいけないことになっているからです。
Webサービスにはさまざまな形態があり、以下の最初の4つの基本構成が代表的です。複雑なWebサービスも、何らかの形でこれらの基本構成を元にしています。
主要な4つの構成について以下で詳しく説明します。「Webサーバ単独系」「Webサーバ+CGI系」「アプリケーションサーバ系」の3つ(I〜III)と、合わせ技としてRailsに代表される「Webサーバ+アプリケーションサーバ」(IV: 次回)の順になります。
静的なコンテンツを配信するだけの最も単純な形式のサービスですが、パフォーマンス面とセキュリティ面で有利なので、要件に合えば現在でも非常に有用な形態です。
コーポレートサイトや静的な情報系サイト、あるいはコンテンツをFTPやSCPなど手動だけで更新しているサイトもこれに該当します。
なお、昨今サーバーサイドエンジニア不要説を唱える過激派フロントエンジニア界隈では、動的処理は全て外部サービスを利用して実装し、自前でホスティングするWebサーバーは完全に静的なコンテンツを配信するWebサーバーとする構成も出てきています。
ブラウザ側でできることが高機能化してきた昨今ではまだまだ増えていく界隈だと思いますので、コンテンツを静的配信する=完全に静的なサービスとは限らない(JavaScript+外部サービスを使って動的に見える)ことは頭に置いておくと良いでしょう。
CGI(Common Gateway Inteerface)という言葉そのものはあまり見かけなくなりましたが、CGI系Webサーバは実は今も昔も動的なWebサービスの主流です。というのも、世界のWebサイトの1/4を占めるとまで言われるWordPressもこれに該当するからです。
CGIはWebサーバがプログラムを実行した結果を返すしくみで、ざっくり「PHPやPerlのスクリプトファイルを置いたら動くやつ」ぐらいに思っていればだいたい間違いではありません。ただし、本来の意味でのCGIを使っているものは少数で、今現在の多くのWebサーバでは言語別のサーバモジュールを使っています(パフォーマンス上有利なため)。
この手のWebサーバには上述のApacheやNginxが一般に使われますが、たまにIISなども見ないことはないです。
CGI方式は動的Webページの基本であり主流なので、Web開発者はまずはここから触ることが多いのではないでしょうか。
こうしたレンタルサーバでは、1台のWebサーバを複数ユーザーで共有する「共有型サービス」が一般的です。共有型サービスでは特定の操作だけが許可されているのが普通なので、sshで接続はできてもroot権限の必要な操作は行なえません。
また、サーバー側や利用者側のファイルなどの権限設定が適切に行われていないと、同居している他のユーザーにデータを抜かれる可能性もゼロではありません(適当に権限を777
(誰でも読み書き可能)とかにしていると今でもたまに見る)。
レンタルサーバはWebサーバを専有できないので、その分さまざまな制限が生じます。一般的な使い方ならほぼ問題ありませんが、特殊な使い方はできないこともあるので注意しましょう。
世の中の多くのサービスはこの形式で動作しています。WordPressその他のメジャーな「サーバーに置いたら動く」系のソフトウェアは大抵この形式で動作するので、Webサイトの実数上のシェアもかなりの割合を占めていると思います。
また、もちろん自前でサーバーを立てる場合もPHPやPerlのプログラムではこの形式を選ぶことがほとんどですので、業務アプリケーションでは使えないということも全くないです。
一方、レンタルサーバーなどを利用する場合には「インフラはお任せ」と思いがちですが、実はレンタルサーバー業者によって細かい設定(例えばphp.iniなど)はかなり異なりますので、レンタルサーバー間でプログラムを移設する場合なんかにはそれまで「おまかせ」だと思っていたものにも気を配らないといけないことがあります。
例えば、さくらのレンタルサーバーではSNIを使ってマルチサイトTLS対応した場合にX-Sakura-Forwarded-Forというさくらのレンタルサーバー独自ヘッダに本来のホスト名が入ります。こういった落とし穴は探せば解決策は見つかりますが、落とし穴がある可能性は考慮しておかないとトラブル対処でスケジュールに影響が出たりするので注意ですね。
汎用的なWebサーバソフトを使わず、Webアプリケーション専用のサーバプログラムが直接リクエストに応答します。このタイプはアプリケーションサーバが何もかも引き受けるので、ApacheやNginxなどのWebサーバを持ちません。
Java serverで構築されるサービスはたいていこれに該当します。Tomcatなどのサービスが有名です。
今なら、Railsのミドルウェアとして使われているRackを単体で使ったWebアプリもこれに相当します(Rackは単体でもWebサービスを構築できます)。ちなみにHerokuではRackアプリもホスティングできます。
※が、一般的には次回IVで紹介するようにRailsはNginxと組み合わせて使われることが多いです。
現代では、ほとんどのアプリケーションサーバー型のシステムは次回説明するIVの形式を利用していると思います。ただ、例えばRailsアプリケーションをローカル環境でrails s
してlocalhost:3000
にアクセスしている時なんかはこの形式になります。
また、メリットにも書いたように細かいレート制御を行いたい場合(例えばTCPの生SocketのAPIを叩きたい)にはこの形式を用いる必要があります。WebSocketやUDPを用いた高い応答性やレート制御が求められるアプリケーション開発の場合には、間にWebサーバが入ってしまうとリクエストがバッファリングされて困るというケースはあるので、アーキテクチャの一つとして理解はしておくと良いと思います。
なお、ここで話す「Webサーバー」が意味する機能的な役割は、アプリケーションサーバーとしてのプログラム実行機能は含まず、一般的なファイル配信やリバースプロキシ機能程度までを処理する範囲までとしています。
※細かい定義をすると色々あれ?と思うところがあると思いますが、説明のための簡略化だということで目を瞑って下さい>詳しい人