Apache vs Nginx：実用的な考慮事項

Apache HTTPサーバーは、1995年にRobert McCoolによって作成され、1999年からApache Software Foundationの指示の下で開発されました。 HTTP Webサーバーは基盤の最初のプロジェクトであり、最も人気のあるソフトウェアであるため、多くの場合、単に「Apache」と呼ばれます。

Apache Webサーバーは、1996年以来インターネット上で最も人気のあるサーバーです。 この人気のため、Apacheは他のソフトウェアプロジェクトからの優れたドキュメントと統合サポートの恩恵を受けています。

Apacheは、その柔軟性、パワー、および広範なサポートのために管理者によって選択されることがよくあります。 動的にロード可能なモジュールシステムにより拡張可能であり、個別のソフトウェアに接続することなく、多数のインタープリタ言語を処理できます。

2002年に、イゴールシソエフはC10Kの問題に対する答えとしてNginxの作業を開始しました。これは、Webサーバーが最新のWebの要件として10,000の同時接続の処理を開始するという課題でした。 最初のパブリックリリースは2004年に行われ、非同期のイベント駆動型アーキテクチャに依存することでこの目標を達成しました。

Nginxは、軽量のリソース使用率と最小限のハードウェアで簡単に拡張できるため、リリース以来人気が高まっています。 Nginxは静的コンテンツの迅速な提供に優れており、動的な要求をそれらの目的により適した他のソフトウェアに渡すように設計されています。

Nginxは、リソースの効率性と負荷時の応答性から管理者によって選択されることがよくあります。 支持者は、コアWebサーバーとプロキシ機能にNginxが注力していることを歓迎します。

Apacheは、クライアント要求の処理方法を指示するさまざまなマルチプロセッシングモジュールを提供します（ApacheはこれらのMPMを呼び出します）。 基本的に、これにより管理者は接続処理アーキテクチャを簡単に交換できます。 これらは：

ご覧のとおり、Apacheはさまざまな接続および要求処理アルゴリズムを選択するための柔軟なアーキテクチャを提供します。 提供される選択肢は、主にサーバーの進化とインターネット環境の変化に伴う同時実行性の必要性の関数です。

Nginxは、Apacheの後、大規模なサイトに直面する並行性の問題をよりよく認識して、現場に登場しました。 この知識を活用して、Nginxは、非同期の非ブロッキングのイベント駆動型接続処理アルゴリズムを使用するようにゼロから設計されました。

Nginxはワーカープロセスを生成し、それぞれが数千の接続を処理できます。 ワーカープロセスは、イベントを継続的にチェックして処理する高速ループメカニズムを実装することでこれを実現します。 実際の作業を接続から切り離すことで、各ワーカーは、新しいイベントがトリガーされた場合にのみ接続に関与できます。

ワーカーによって処理される各接続は、他の接続とともに存在するイベントループ内に配置されます。 ループ内では、イベントは非同期で処理され、作業を非ブロッキング方式で処理できます。 接続が閉じると、ループから削除されます。

このスタイルの接続処理により、Nginxは限られたリソースで信じられないほど拡張できます。 サーバーはシングルスレッドであり、プロセスが新しい接続を処理するために生成されないため、メモリとCPUの使用量は、負荷が大きい場合でも比較的一貫したままになる傾向があります。

Apacheサーバーは、従来のファイルベースの方法を使用して静的コンテンツを処理できます。 これらの操作のパフォーマンスは、主に上記のMPMメソッドの機能です。

Apacheは、問題の言語のプロセッサを各ワーカーインスタンスに埋め込むことにより、動的コンテンツを処理することもできます。 これにより、外部コンポーネントに依存することなく、Webサーバー自体内で動的コンテンツを実行できます。 これらの動的プロセッサは、動的にロード可能なモジュールを使用して有効にできます。

動的コンテンツを内部で処理するApacheの機能は、動的処理の構成がより簡単になる傾向があることを意味します。 通信は追加のソフトウェアと調整する必要はなく、コンテンツ要件が変更された場合、モジュールは簡単に交換できます。

Nginxには、動的コンテンツをネイティブに処理する機能はありません。 PHPおよび動的コンテンツのその他のリクエストを処理するには、Nginxは実行のために外部プロセッサに渡して、レンダリングされたコンテンツが送り返されるのを待つ必要があります。 その後、結果をクライアントに中継できます。

管理者にとって、これは、Nginxが話す方法の1つ（http、FastCGI、SCGI、uWSGI、memcache）を介して、Nginxとプロセッサ間で通信を構成する必要があることを意味します。 これは、特に許可される接続の数を予測しようとする場合、プロセッサへの呼び出しごとに追加の接続が使用されるため、状況をわずかに複雑にする可能性があります。

ただし、この方法にはいくつかの利点もあります。 動的インタープリターはワーカープロセスに埋め込まれていないため、そのオーバーヘッドは動的コンテンツに対してのみ存在します。 静的コンテンツは簡単な方法で提供でき、必要な場合にのみ通訳者に連絡します。 Apacheもこの方法で機能しますが、そうすると前のセクションの利点がなくなります。

Apacheには、コンテンツディレクトリ内の隠しファイル内のディレクティブを検査および解釈することにより、ディレクトリごとに追加の構成を許可するオプションが含まれています。 これらのファイルは、.htaccessファイルと呼ばれます。

これらのファイルはコンテンツディレクトリ自体に存在するため、リクエストを処理するときに、Apacheはリクエストされたファイルへのパスの各コンポーネントで.htaccessファイルをチェックし、その中にあるディレクティブを適用します。 これにより、Webサーバーの分散構成が効果的に可能になります。これは、URLの書き換え、アクセス制限、承認と認証、さらにはキャッシュポリシーの実装によく使用されます。

上記の例はすべてメインのApache構成ファイルで構成できますが、.htaccessファイルにはいくつかの重要な利点があります。 まず、これらは要求パスに沿って見つかるたびに解釈されるため、サーバーをリロードせずにすぐに実装されます。 第二に、非特権ユーザーが設定ファイル全体を制御することなく、自分のWebコンテンツの特定の側面を制御できるようにします。

これにより、コンテンツ管理システムなどの特定のWebソフトウェアが、中央の構成ファイルにアクセスせずに環境を簡単に構成できます。 これは、共有ホスティングプロバイダーによっても使用され、メイン構成の制御を維持しながら、クライアントが特定のディレクトリを制御できるようにします。

Nginxは、.htaccessファイルを解釈せず、メイン構成ファイルの外部でディレクトリごとの構成を評価するためのメカニズムも提供しません。 これはApacheモデルよりも柔軟性が低い場合がありますが、独自の利点があります。

ディレクトリレベル構成の.htaccessシステムに対する最も顕著な改善は、パフォーマンスの向上です。 任意のディレクトリで.htaccessを許可する可能性のある一般的なApacheセットアップの場合、サーバーは、要求ごとに、要求されたファイルにつながる親ディレクトリのeachでこれらのファイルをチェックします。 この検索中に1つ以上の.htaccessファイルが見つかった場合は、それらを読み取って解釈する必要があります。 ディレクトリオーバーライドを許可しないことにより、Nginxは、リクエストごとに1つのディレクトリルックアップとファイル読み取りを実行することで、リクエストをより高速に処理できます（ファイルが従来のディレクトリ構造にあると想定）。

別の利点は、セキュリティに関連しています。 また、ディレクトリレベルの構成アクセスを配布すると、このタスクを適切に処理することを信頼できない個々のユーザーにセキュリティの責任が分散されます。 管理者がWebサーバー全体を制御できるようにすることで、他の関係者にアクセスが許可されたときに発生する可能性のあるセキュリティの誤操作を防ぐことができます。

これらの懸念があなたの心に響く場合は、Apacheで.htaccessの解釈をオフにすることが可能であることに注意してください。

Apacheは、リクエストをファイルシステム上の物理リソースまたはより抽象的な評価が必要なURIロケーションとして解釈する機能を提供します。 一般に、前者の場合、Apacheは<Directory>または<Files>ブロックを使用しますが、より抽象的なリソースには<Location>ブロックを使用します。

ApacheはWebサーバーとしてゼロから設計されたため、デフォルトでは通常、リクエストをファイルシステムリソースとして解釈します。 まず、ドキュメントルートを取得し、ホストとポート番号の後にリクエストの部分を追加して、実際のファイルを見つけようとします。 基本的に、ファイルシステム階層は、利用可能なドキュメントツリーとしてWeb上で表されます。

Apacheは、リクエストが基礎となるファイルシステムに一致しない場合の代替手段をいくつか提供します。 たとえば、Aliasディレクティブを使用して、別の場所にマップできます。 <Location>ブロックの使用は、ファイルシステムではなくURI自体を操作する方法です。 ファイルシステム全体でより柔軟に構成を適用するために使用できる正規表現バリアントもあります。

Apacheは、基礎となるファイルシステムとWebスペースの両方で動作する機能を備えていますが、ファイルシステムメソッドに大きく依存しています。 これは、ディレクトリごとの構成に.htaccessファイルを使用するなど、いくつかの設計上の決定に見られます。 Apache docs自体は、要求が基になるファイルシステムをミラーリングするときに、URIベースのブロックを使用してアクセスを制限しないように警告します。

Nginxは、Webサーバーとプロキシサーバーの両方として作成されました。 これらの2つの役割に必要なアーキテクチャにより、主にURIで動作し、必要に応じてファイルシステムに変換します。

これは、Nginx構成ファイルが構築および解釈される方法のいくつかで見ることができます。Nginxは、ファイルシステムディレクトリの構成を指定するメカニズムを提供せず、代わりにURI自体を解析します。

たとえば、Nginxの主要な構成ブロックはserverブロックとlocationブロックです。 serverブロックは要求されているホストを解釈し、locationブロックはホストとポートの後に続くURIの部分を照合する役割を果たします。 この時点で、リクエストはファイルシステム上の場所としてではなく、URIとして解釈されています。

静的ファイルの場合、最終的にすべての要求をファイルシステム上の場所にマッピングする必要があります。 最初に、Nginxはリクエストを処理するサーバーブロックとロケーションブロックを選択し、ドキュメントルートとURIを組み合わせて、指定された構成に従って必要なものを調整します。

これは似ているように見えるかもしれませんが、主にファイルシステムの場所ではなくURIとしてリクエストを解析すると、NginxはWeb、メール、プロキシサーバーの両方の役割でより簡単に機能します。 Nginxは、さまざまな要求パターンに応答する方法をレイアウトするだけで構成されます。 Nginxは、リクエストを処理する準備ができるまでファイルシステムをチェックしません。これは、.htaccessファイルの形式を実装しない理由を説明しています。

Apacheのモジュールシステムを使用すると、モジュールを動的にロードまたはアンロードして、サーバーの実行中にニーズを満たすことができます。 Apacheコアは常に存在しますが、モジュールのオン/オフ、追加機能の追加または削除、メインサーバーへの接続が可能です。

Apacheは、この機能をさまざまなタスクに使用します。 プラットフォームの成熟度により、利用可能なモジュールの広範なライブラリがあります。 これらは、実行中の各ワーカーにPHPインタープリターを埋め込むmod_phpなど、サーバーのコア機能の一部を変更するために使用できます。

ただし、モジュールは動的コンテンツの処理に限定されません。 他の機能の中でも、URLの書き換え、クライアントの認証、サーバーの強化、ロギング、キャッシュ、圧縮、プロキシ、レート制限、暗号化に使用できます。 動的モジュールは、多くの追加作業なしでコア機能を大幅に拡張できます。

Nginxはモジュールシステムも実装していますが、Apacheシステムとはまったく異なります。 Nginxでは、モジュールは動的にロードできないため、選択してコアソフトウェアにコンパイルする必要があります。

多くのユーザーにとって、これによりNginxの柔軟性は大幅に低下します。 これは、ディストリビューションの従来のパッケージングシステム以外でコンパイルされた独自のソフトウェアを保守することに抵抗があるユーザーに特に当てはまります。 ディストリビューションのパッケージには、最も一般的に使用されるモジュールが含まれる傾向がありますが、非標準モジュールが必要な場合は、サーバーをソースから自分で構築する必要があります。

ただし、Nginxモジュールは依然として非常に便利であり、使用する機能のみを含めることで、サーバーに必要なものを指示することができます。 また、一部のユーザーは、任意のコンポーネントをサーバーにフックできないため、これをより安全だと考える場合があります。 ただし、サーバーがこれが可能な位置に置かれた場合、おそらく既に危険にさらされています。

Nginxモジュールでは、Apacheモジュールと同じ機能の多くを使用できます。 たとえば、Nginxモジュールは、プロキシサポート、圧縮、レート制限、ロギング、書き換え、ジオロケーション、認証、暗号化、ストリーミング、およびメール機能を提供できます。

Apacheは長い間人気があったため、サーバーのサポートはいたるところにあります。 コアサーバーや、Apacheを他のソフトウェアと接続するタスクベースのシナリオで使用できる、ファーストパーティとサードパーティのドキュメントの大きなライブラリがあります。

ドキュメントに加えて、多くのツールとWebプロジェクトには、Apache環境内でブートストラップするツールが含まれています。 これは、プロジェクト自体に含まれるか、ディストリビューションのパッケージチームが管理するパッケージに含まれます。

一般に、Apacheは、市場シェアと利用可能期間の長さだけで、サードパーティのプロジェクトからより多くのサポートを受けることになります。 また、管理者は、Apacheが普及しているだけでなく、.htaccessの分散管理機能のためにApacheにほぼ独占的に依存している共有ホスティングシナリオから始めるため、Apacheの使用経験がある可能性がいくらか高くなります。

Nginxのパフォーマンスプロファイルに採用するユーザーが増えるにつれて、サポートが強化されていますが、いくつかの重要な分野でやるべきことがいくつかあります。

以前は、初期の開発とドキュメントのほとんどがロシア語であったため、Nginxに関する包括的な英語のドキュメントを見つけることは困難でした。 プロジェクトへの関心が高まるにつれて、ドキュメントが記入され、Nginxサイトとサードパーティを通じて多くの管理リソースがあります。

サードパーティのアプリケーションに関しては、サポートとドキュメントがより簡単に入手できるようになり、パッケージメンテナーは、場合によっては、ApacheとNginxの自動構成の選択肢を提供し始めています。 サポートがなくても、プロジェクト自体が要件（許可、ヘッダーなど）を文書化する限り、Nginxを代替ソフトウェアで動作するように構成するのは通常簡単です。