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

前書き

ApacheとNginxは、世界で最も一般的な2つのオープンソースWebサーバーです。 合わせて、インターネット上のトラフィックの50%以上を提供する責任があります。 どちらのソリューションも、さまざまなワークロードを処理し、他のソフトウェアと連携して完全なWebスタックを提供できます。

ApacheとNginxは多くの性質を共有していますが、完全に互換性があると考えるべきではありません。 それぞれが独自の方法で優れており、選択したWebサーバーを再評価する必要がある状況を理解することが重要です。 この記事では、各サーバーがさまざまな分野でどのように積み重ねられるかについて説明します。

総括

ApacheとNginxの違いを説明する前に、これら2つのプロジェクトの背景と一般的な特徴を簡単に見てみましょう。

アパッチ

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

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

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

Nginx

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

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

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

接続処理アーキテクチャ

ApacheとNginxの大きな違いの1つは、接続とトラフィックを実際に処理する方法です。 これはおそらく、さまざまな交通状況への応答方法に最も大きな違いをもたらします。

アパッチ

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

  • * mpm_prefork *:この処理モジュールは、リクエストを処理するためにそれぞれ単一のスレッドでプロセスを生成します。 各子は一度に1つの接続を処理できます。 要求の数がプロセスの数より少ない限り、このMPMは非常に高速です。 ただし、要求がプロセス数を超えた後はパフォーマンスが急速に低下するため、これは多くのシナリオで適切な選択ではありません。 各プロセスはRAM消費に大きな影響を与えるため、このMPMを効果的に拡張することは困難です。 ただし、スレッドを念頭に置いて構築されていない他のコンポーネントと組み合わせて使用​​する場合、これは依然として適切な選択です。 たとえば、PHPはスレッドセーフではないため、このMPMは、これらのファイルを処理するApacheモジュールである `+ mod_php +`を使用する唯一の安全な方法として推奨されます。

  • * mpm_worker *:このモジュールは、それぞれが複数のスレッドを管理できるプロセスを生成します。 これらの各スレッドは、単一の接続を処理できます。 スレッドはプロセスよりもはるかに効率的です。つまり、このMPMはプリフォークMPMよりも優れた拡張性を備えています。 プロセスよりもスレッドが多いため、これは、新しい接続が空きプロセスを待たずにすぐに空きスレッドを取得できることも意味します。

  • * mpm_event *:このモジュールはほとんどの状況でworkerモジュールに似ていますが、キープアライブ接続を処理するために最適化されています。 ワーカーMPMを使用する場合、接続が維持されている限り、要求がアクティブに行われているかどうかに関係なく、接続はスレッドを保持します。 イベントMPMは、キープアライブ接続を処理するための専用スレッドを確保し、アクティブな要求を他のスレッドに渡すことにより、キープアライブ接続を処理します。 これにより、モジュールがキープアライブリクエストによって動かなくなるのを防ぎ、実行を高速化できます。 これは、Apache 2.4のリリースで安定とマークされました。

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

Nginx

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

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

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

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

静的コンテンツと動的コンテンツ

現実のユースケースに関して、ApacheとNginxの最も一般的な比較の1つは、各サーバーが静的コンテンツと動的コンテンツのリクエストを処理する方法です。

アパッチ

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

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

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

Nginx

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

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

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

分散構成と集中構成

管理者にとって、これら2つのソフトウェアの最も明白な違いの1つは、コンテンツディレクトリ内でディレクトリレベルの構成を許可するかどうかです。

アパッチ

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

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

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

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

Nginx

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

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

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

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

ファイルとURIベースの解釈

Webサーバーが要求を解釈してシステム上の実際のリソースにマッピングする方法は、これら2つのサーバーが異なる別の領域です。

アパッチ

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

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

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

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

Nginx

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

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

たとえば、Nginxの主要な設定ブロックは、「+ server 」および「 location 」ブロックです。 ` server `ブロックはリクエストされているホストを解釈しますが、 ` location +`ブロックはホストとポートの後に来るURIの一致部分を担当します。 この時点で、リクエストはファイルシステム上の場所としてではなく、URIとして解釈されています。

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

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

モジュール

NginxとApacheはどちらもモジュールシステムを通じて拡張可能ですが、動作方法は大きく異なります。

アパッチ

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

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

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

Nginx

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

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

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

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

サポート、互換性、エコシステム、およびドキュメント

考慮すべき主要な点は、実際に起動して実行するプロセスに、他のソフトウェアの中で利用可能なヘルプとサポートの状況が与えられることです。

アパッチ

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

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

一般に、Apacheは、市場シェアと利用可能期間の長さだけで、サードパーティのプロジェクトからより多くのサポートを受けることになります。 また、管理者は、その普及率だけでなく、多くの人々が `+ .htaccess +`分散管理機能のためにApacheのみに依存する共有ホスティングシナリオで開始するため、Apacheでの作業経験が多少あります。

Nginx

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

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

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

ApacheとNginxを一緒に使用する

ApacheとNginxの両方の利点と制限を検討した後、どのサーバーがニーズにより適しているかをよりよく理解できるかもしれません。 ただし、多くのユーザーは、各サーバーを組み合わせて使用​​することで、各サーバーの長所を活用できることを認識しています。

このパートナーシップの従来の構成では、NginxをリバースプロキシとしてApacheの前に配置します。 これにより、Nginxはクライアントからのすべてのリクエストを処理できます。 これは、Nginxの高速処理速度と多数の接続を同時に処理する機能を利用しています。

Nginxが優れている静的コンテンツの場合、ファイルはクライアントに迅速かつ直接提供されます。 PHPファイルなどの動的コンテンツの場合、NginxはリクエストをApacheにプロキシし、Apacheは結果を処理してレンダリングされたページを返すことができます。 Nginxは、コンテンツをクライアントに戻すことができます。

このセットアップは、Nginxがソーティングマシンとして機能できるようにするため、多くの人々に適しています。 可能なすべての要求を処理し、ネイティブに処理できない要求を渡します。 Apacheサーバーが処理するように要求されたリクエストを削減することにより、Apacheプロセスまたはスレッドが占有されているときに発生するブロッキングの一部を軽減できます。

この構成では、必要に応じてバックエンドサーバーを追加してスケールアウトすることもできます。 Nginxは、サーバーのプールに簡単に渡されるように構成できます。これにより、この構成の障害に対する耐性とパフォーマンスが向上します。

結論

ご覧のとおり、ApacheとNginxはどちらも強力で柔軟性があり、能力があります。 どのサーバーが最適かを決定するのは、主に特定の要件を評価し、予想されるパターンでテストする機能です。

これらのプロジェクトには、生のパフォーマンス、機能、および各ソリューションを実行するために必要な実装時間に非常に大きな影響を与える違いがあります。 しかし、これらは通常、何気なく却下されるべきではない一連のトレードオフの結果です。 最終的に、万能型のWebサーバーはないため、目的に最適なソリューションを使用してください。

前の投稿:Ubuntu 14.04でmemcachedを使用してNoSQLクエリをMySQLに追加する方法
次の投稿:Ubuntu 16.04でSAML認証用のSimpleSAMLphpをインストールおよび構成する方法