Webサーバーの世界：Apache vs. Nginx

ApacheとNginxの紹介

Webサーバーとプロトコルは、ユーザーがWebページを閲覧できるように設計されています。これらはドキュメントを閲覧するためのリクエストを送信し、サーバーがそれを受け入れます。その後、ホストは基本的にそのドキュメントや情報を閲覧者に提供します。Webサーバーは、ブラウザ上でWebページを閲覧し、アクセスできるようにする上で中心的な役割を果たしています。

この目的のために使用できるWebサーバーは数多くあります。中でも特に人気があるのは、Nginx とApacheです。実際、これらのサーバーは現在インターネット上で利用可能なほとんどのWebサイトをホストしています。

ApacheとNginxは多くの点で非常によく似ています。まず、どちらのWebサーバーもオープンソースです。これは、世界中の誰もが完全に無料で利用できることを意味します。しかし、それぞれのサーバーには独自の機能が数多くあります。これらの特別な特徴により、さまざまなアプリケーションや目的に最適となっています。

あなたがどちらのWebサーバーが優れているか、または自分にとって理想的かを判断できるように、NginxとApacheを比較します。この比較は、Webサーバーのユーザーにとって極めて重要な、いくつかの不可欠なパラメータにわたって行われます。それでは始めましょう！

基本的な概要

まず、2つのWebサーバーの一般的な概要から始めます。ApacheとNginxはどちらもコミュニティで高い評価を築いています。そのパフォーマンスは絶賛されており、世界中のいくつかの有名組織で使用されています。

Apache

Apacheは1995年に登場しました。Robert McCoolがこのHTTPサーバーを開発したのは、the Apache Software Foundationのもとであり、それが名前の由来となっています。リリース以来、世界中の何十万人もの人々がApacheを使用しています。

その圧倒的な人気は、多くのサードパーティ製ソフトウェアやソースが頻繁に連携していることを意味します。したがって、多くの統合機能を備えた優れたサポートネットワークをお探しの場合は、Apacheが最適です。また、Apacheはより動的で柔軟であるため、多くの人に好まれています。さらに、解釈できる言語の幅も広いです。

Nginx

Nginxは比較的、新しいWebサーバーで、2004年に登場しました。これは、現在C10K問題として知られている問題に対処するためのIgor Syosevの努力の成果です。この問題は、サーバーが大量のトラフィックを処理することが困難になり始めたときに発生しました。インターネットを利用する人が増えるにつれ、Webサイトのサーバーは過負荷になり始めました。これらのサーバーが同時に数千の接続を処理できなかったため、サイトがクラッシュして障害が発生しました。

Nginxはこの問題を解決するためにリリースされました。そのため、そのアーキテクチャは非常に軽量な設計となっており、限られたリソースやハードウェアでも動作可能です。静的コンテンツの処理に最も適していますが、動的コンテンツを適切に処理できるソフトウェアと統合することも可能です。

トラフィック処理能力

各サーバーの基本的な概念を理解したところで、さらに詳細に進みましょう。まず最初に、個々のサーバーのトラフィックと処理能力について説明します。これは、これら2つのプラットフォームを分ける主要なポイントの1つです。複数の接続を同時に処理する場合、それらのアーキテクチャは異なる原則に基づいて動作します。

Apache

Apacheは、MPM- Multi-Processing Modulesと呼ばれるものを使用します。管理者はさまざまなMPMを使用して、接続処理アーキテクチャを操作および変更します。Apache Webサーバーの魅力の1つは、そのアーキテクチャが提供する柔軟性です。処理を個々のスレッドやスレッドグループに分割するこのようなモジュールベースのインフラストラクチャにより、スケーリングやさまざまな種類の接続への適応が容易になります。

Apacheで使用されている個々のモジュールの一部を見てみましょう：

• mpm_prefork

1つ目は mpm_prefork です。これは、訪問者からの受信リクエストを処理する役割を担う処理モジュールです。特定の時点で1つの接続を処理するために、1つのスレッドまたは子プロセスを作成します。つまり、リクエスト数がプロセス数よりも少ない場合、mpm_prefork はその機能において非常に効率的です。

個々の子プロセスがそれぞれを個別に処理するため、リクエストは迅速に処理されます。しかし、これはリクエスト数がプロセス数を超えると、処理速度が大幅に低下する可能性があることも意味します。その結果、リクエスト処理ステップで大量の RAM が消費されます。

• mpm_worker

すでに知られているように、1つのスレッドが1つの接続を担当します。このモジュールはさらに一歩進んで、一度に複数のスレッドを管理できるようにします。これは、特定のしきい値を超えると苦戦する mpm_prefork と比較して、はるかにスケーラブルなモジュールです。新しい接続は、待機することなくすぐにスレッドに接続できます。

• mpm_event

mpm_event は、キープアライブ（keep-alive）接続の維持を担当します。このモジュールの主な目的は、キープアライブリクエストによってシステムが停滞するのを防ぐことです。アクティブなリクエストがない場合でも、接続にスレッドを割り当てることでこれを実現します。スレッドは、接続が維持されている限り専用のままになります。入ってきたリクエストは、空いているスレッドに転送されます。

Nginx

Apache とは対照的に、Nginx は非常に明確な目的を念頭に置いて構築されました。このレベルでの接続とスケーラビリティに関して発生していた問題はすでに分かっていました。そのため、非同期でノンブロッキングなアルゴリズムが使用されています。接続ごとに個別のスレッドを割り当てることはしません。代わりに、Nginx は一度に数千の接続を処理できる多数のワーカープロセスを生成します。

Nginx のアーキテクチャの背後にある動作原理は、高速ループメカニズムです。このアルゴリズムは、常にイベントを処理し、監視しています。これは、プロセスがイベント駆動型であり、各ワーカープロセスが自身の接続のみに専念することを意味します。ワーカープロセスのすべての接続はイベントループ内に配置されます。ここで、それらは共存し、この特定のワーカーの下にある他の接続と非同期に処理されます。

このようなアーキテクチャの大きなメリットは、優れたスケーラビリティ容量を可能にすることです。これは、リソースが限られている場合や、最小限のハードウェアで動作させたい場合に特に当てはまります。大量のトラフィックが発生している場合でも、RAM の使用量への影響はほとんどありません。これは、接続ごとに個別のスレッドを生成しないためです。

静的コンテンツと動的コンテンツの処理

2つの Web サーバーを比較するために使用できるもう1つのパラメータは、それらがどのように 静的 と 動的コンテンツ.

Apache

Apache は、静的コンテンツを処理するためにファイルベースの方法を使用します。その MPM 処理システムにより、この従来の方法で動作することができます。

動的コンテンツの処理に関して、Apache は外部コンポーネントの支援を必要とせずに処理を行うことができます。モジュールをロードすることで、動的プロセッサを有効にできます。このモジュールは、言語を分析して関連するプロセッサをワーカーに組み込むことで、コンテンツを処理します。

動的コンテンツを処理するために外部コンポーネントを使用する必要がないことの大きなメリットは、設定と調整の際に明らかになります。内部コンポーネント同士のみを調整する方がはるかに簡単です。

Nginx

Apache と Nginx のコンテンツ処理方法の最大の違いは、Nginx が単体では内部で動的コンテンツを処理できない点です。動的コンテンツのリクエストを処理するには、外部コンポーネントと組み合わせる必要があります。つまり、Nginx サーバーを外部プロセッサと連携して使用する必要があります。そのコンポーネントは、PHP/動的コンテンツのリクエストを受け取り、それを処理して、サーバーに送り返します。

情報は2つのコンポーネント間で中継される必要があるため、それらの間の通信を調整する必要があります。許可する接続数とプロトコルの設定を決定する必要があります。HTTP、FastCGI、SCGI、uWSGI、memcacheなど、Nginxが読み取り、理解できるプロトコルを使用する必要があります。

一方で、Nginxは静的コンテンツの処理を非常に得意としています。そうするためには、外部ソースからの助けを必要とします。また、必要なときにのみインタプリタを起動します。これはNginxを使用するメリットの1つです。インタプリタはプロセスに組み込まれていません。これは、動的コンテンツの処理時にのみ存在することを意味します。

コンテンツディレクトリ：分散型構成 vs 集中型構成

すべてのWebサーバーには、独自のコンテンツディレクトリがあります。ApacheとNginxを評価する上で最も重要なパラメータの1つは、ディレクトリレベルの構成を許可するかどうかです。

Apache

コンテンツディレクトリには、ディレクティブを含む特定の隠しファイルが存在します。これらは.htaccessファイルです。Apacheを使用すると、これらのディレクティブをディレクトリごとに解釈できます。したがって、リクエストを送信すると、Apacheはファイルのパスを検査して.htaccessファイルを探します。見つかると、その中のディレクティブを即座に解釈して適用します。Apacheは、これらのディレクティブを実装するためにサーバーを再起動することはありません。

上記で定義されたプロセスにより、Webサーバー内のディレクトリの分散型構成が可能になります。分散型構成は、URLの書き換え、アクセス制限の実装、権限の確認、およびキャッシュポリシーの設定に役立ちます。

.htaccessファイルのメリットの1つは、認証権限を持たないユーザーでも、ブラウザで表示しているコンテンツの少なくとも一部の側面を制御および変更できることです。そのため、Apacheは共有ホスティングプロバイダーによって頻繁に使用されます。サービスプロバイダーは中央構成へのアクセス権限を持っています。クライアントは、メインの構成にアクセスすることなく、特定のディレクトリを制御することができます。

必要に応じて、Apacheで.htaccessの解釈を無効にすることも可能です。

Nginx

Apacheとは異なり、Nginxは.htaccessファイルを一切使用しません。そのため、比較的柔軟性に欠けます。しかし、Nginxはその代わりに構成スタイルに多くの改善をもたらしています。まず、Apacheよりもはるかに速い速度でリクエストを処理できます。これは、パス内にある各.htaccessファイルを検索、読み取り、解釈、そして実行しないためです。各親ディレクトリを検索する代わりに、Nginxは1つのリクエストに対して1回だけディレクトリの検索を行います。

さらに、NginxはApacheに対して大きなセキュリティ上の優位性を持っています。Apacheとは異なり、Nginxはコンテンツディレクトリの構成のいかなる部分も個々のユーザーに委ねることはありません。あなたが厳格なセキュリティ対策を維持しているとしても、個々のユーザーが同じようにできるとは限りません。Nginxを使用すると、ディレクトリネットワーク全体のセキュリティステータスと構成の制御を維持できます。

リクエストの解釈

2つのサーバーを区別するもう1つの方法は、リクエストの解釈方法です。

Apache

サーバーはリクエストを受信すると、それを解釈し、関連するシステムリソースに接続します。リクエストをファイルシステム上の物理リソースとして解釈するか、またはURI の場所として解釈します。

物理リソースとして解釈する場合、<Directory>または<Files>  ブロックを使用します。これはサーバーのデフォルトの解釈方法です。ドキュメントのルートを取得します。次に、リクエスト内のホストとポート番号に従って、ドキュメントツリー内の関連するファイルを見つけます。

一方、URIの場所は抽象的な評価を必要とします。そのため、Apacheはファイルシステムを操作する代わりに、抽象リソースに対して<Location>ブロックを採用します。

URI以外にも、デフォルトのファイルベースのシステムを使用する代わりの方法がいくつかあります。例えば、Aliasディレクティブを使用して、マッピング先となる別の場所を見つけることができます。また、式のバリアントを利用して、ファイルシステムの設定をより柔軟にすることもできます。

Nginx

Apacheがウェブサーバーとして誕生したのに対し、Nginxはウェブサーバーとプロキシサーバーの両方の役割を果たします。そのため、Nginxはファイルシステムに依存するのではなく、URIを扱うことを好みます。Nginxではファイルシステムのディレクトリに対する設定を指定する方法がないことからも、その傾向が伺えます。ただし、必要に応じてファイルシステムに変換することは可能です。

Serverとlocationは、Nginxで主に使用される設定ブロックです。前者はリクエストされているホストを解釈します。後者はホストとポートの後のURI部分にマッチします。その結果、サーバーはリクエストをシステム上の実際のファイルではなく、URIのロケーションとして解釈します。

URIベースの解釈システムにより、Nginxはウェブサーバー、プロキシサーバー、メールサーバーとしての役割を果たすことができます。リクエストを解釈する際にファイルシステムを参照しないため、.htaccessファイルも実装していないのは当然と言えます。

モジュールシステム

ApacheとNginxはどちらも拡張用のモジュールシステムをサポートしていますが、その内部動作にはいくつかの大きな違いがあります。

Apache

Apacheでは、サーバーの実行中にモジュールを動的にロードおよびアンロードできます。コアはプロセスの中心に留まり、モジュールは機能を拡張する役割を果たします。これらのアタッチ可能なモジュールを使用して、多くのタスクを実行できます。Apacheの膨大なライブラリにより、選択肢は事実上無限です。

実際、mod_phpのようなモジュールを使用することで、サーバーコアの機能を変更することさえ可能です。前述のように、このモジュールを使用すると、個々のワーカープロセスにPHPインタプリタを組み込むことができます。これは、動的コンテンツを処理する必要がある場合に便利です。

しかし、それだけではありません。クライアント認証、サーバーの堅牢化、キャッシュ、URL書き換え、プロキシ、レート制限、圧縮、暗号化などの機能を有効にするモジュールを追加することもできます。

Nginx

Nginxのモジュールシステムは、メインサーバーにモジュールを動的にロードできないという点で異なります。代わりに、コアソフトウェア上でモジュールを収集してコンパイルする必要があります。このため、柔軟性や使いやすさの面で改善の余地が多く残されています。ディストリビューションパッケージにはいくつかの一般的なモジュールが含まれていますが、その他のモジュールについてはサーバーをビルドする必要があります。したがって、従来のパッケージングシステム以外でコンパイルされたソフトウェアを維持する方法を知っておく必要があります。

いずれにせよ、この非標準的なモジュールシステムの利点は、高度な専門性が得られることです。必要な機能だけを組み込んでモジュールをカスタマイズできます。不要なコンポーネントを排除し、その過程でセキュリティリスクを回避することができます。同時に、Nginxモジュールを使用しても、Apacheと同じタスクを実行できます。これには、URL書き換え、ロギング、認証などが含まれます。

エコシステムとサポート

ウェブサーバーにおいて、統合とソフトウェアサポートは非常に重要です。次に、ApacheとNginxで利用可能な互換性とサポートについて説明します。

Apache

Apacheはより古く、より人気のあるプラットフォームです。そのため、Nginxと比較して、サポートするツールやソフトウェアのラインナップが豊富であることは容易に理解できます。コアサーバーをサポートするために、自由に利用できるサードパーティのドキュメントが大量に存在します。それだけでなく、他のソフトウェアと組み合わせて特定のタスクを実行することもできます。これらのツールは、プロジェクトまたはパッケージに追加できます。これらはApacheのエコシステム内で簡単にブートストラップできます。

Nginx

この点においてNginxはApacheの後塵を拝していますが、追いつくために最善を尽くしていることは間違いありません。その真の可能性に気づき、Nginxを採用する個人がますます増えています。便利で高速な処理を行うWebサーバーとしての有機的な成長に伴い、このプラットフォームへのサポートも向上し続けています。

Nginxが乗り越えなければならなかった大きなサポートのハードルの1つは、英語のドキュメントを見つけることでした。これは、Nginxの大部分（ほとんどのドキュメントを含む）が元々ロシア語で書かれていたためです。しかし、サーバーが普及し、より有名になるにつれて、現在では世界共通語である英語で多くのサードパーティ製リソースが利用可能になっています。

共同ソリューション？

これで、ApacheとNginxの重要なコンポーネントと内部の仕組みについて、より深く理解できたはずです。これらは互いに大きく異なりますが、一部のユーザーはこの事実を利用して、両方の良いとこ取りをしています。その通りです。ApacheとNginxを一緒に使用することは可能なのです。

従来、ユーザーはNginxをリバースプロキシとして使用し、Apacheの前に配置する傾向があります。これにより、Apacheのリクエスト処理およびプロセッシングにおける速度不足を補うことができます。Nginxは、最も高速な状態で、すべてのリクエストを受け取って処理します。また、多くのリソースを投入することなく、大量の同時リクエストに迅速に対処することも可能になります。

ユーザーが活用するもう1つのNginxの機能は、静的コンテンツを効率的に処理する能力です。Nginxが動的コンテンツを処理するために外部コンポーネントを必要とするという事実を補うために、プロキシを介してPHPやその他の関連リクエストをApacheに転送することができます。ApacheはリクエストをWebページにレンダリングし、それをNginxに送り返してクライアントに提供します。

以下は、当社のブログで公開されている、両方のWebサーバーを使い始めるのに役立つリソースです：

Apache

• Ubuntu 18.04へのApacheサーバーのインストール：ハウツーガイド
• Ubuntu 20.04でのApacheバーチャルホストの設定
• CentOS 7にLinux、Apache、MySQL、PHP（LAMP）スタックをインストールする方法
• Ubuntu 18.04でLet’s Encryptを使用してApacheを保護する

Nginx

• Ubuntu 18.04へのNginxのインストール
• NginxのLetsEncrypt SSL証明書更新の自動化
• Ubuntu 20.04でLet’s Encryptを使用してNginxを保護する方法
• Ubuntu 20.04にLEMPスタック（Linux、Nginx、MySQL、PHP）をインストールする方法

結論

結局のところ、ApacheとNginxの双方に強みと弱みがあります。プロジェクトにどちらのサーバーを使用すべきかについて、厳格なルールや推奨事項はありません。独自の要件に基づいて、アプリケーションに何が最適かを最もよく判断できるのはあなた自身です。

妥協できない側面や機能を見極め、それに応じて選択する必要があります。決定が難しい場合は、カスタマイズされたソリューションで両方のサーバーを併用することもいつでも可能です。

快適なコンピューティングを！