ApacheとNginx-詳細な比較

はじめに

Webサーバーは、World Wide Webの開始以来、インターネットの基本的な部分でした。 Webサーバーソフトウェアは、リモートクライアントからの要求を受信し、専用サーバーなどのハードウェアに保存されたWebページをクライアントに提供します。

この比較記事では、今日最も人気のある2つのオープンソースWebサーバーであるApacheとNginxの違いについて説明します。

ApacheServerについて

Apache HTTPサーバー（または略してApache）は、ApacheSoftwareFoundationによって開発されたオープンソースのWebサーバーソフトウェアです。当初はプロセスベースのWebサーバーとして設計されていましたが、バージョン2.0およびマルチプロセッシングモジュールの導入により、プロセスベースのサーバーとスレッドサーバーの両方として構成できるようになりました。サーバーのモジュラーアーキテクチャでは、モジュラープロトコル処理などの機能も使用できます。

Apacheのアーキテクチャのもう1つの重要な機能は、モジュールが他のモジュールによって作成されたコンテンツと対話できるようにするフィルターです。この相互作用には、暗号化、ウイルススキャン、静的コンテンツと動的コンテンツの両方の圧縮が含まれます。

注： ApacheHTTPサーバーはLinuxで最適に動作します。 CentOSにApacheをインストールする方法を学びます。 Ubuntuについては、UbuntuにApacheWebサーバーをインストールする方法をお読みください。基本的なApacheWebサーバー管理については、Apacheを開始、停止、および再起動する方法を学習してください。

Nginxサーバーについて

Nginx（engine-xと発音）は、F5、Incの一部であるNginxによって開発されたオープンソースのWebサーバーです。
NginxはHTTPサーバーとして、拡張性の高いイベント駆動型（非同期）アーキテクチャを利用して、高性能と小さなメモリフットプリントを実現します。

Nginxは、リバースプロキシ、ロードバランサー、メールプロキシ、およびHTTPキャッシュとしても機能します。一部のユースケースでは、NginxはWebアクセラレータまたはSSL/TLSターミネータとしても機能します。

注： Apacheと同様に、NginxもLinuxと最も互換性があります。 CentOSにNginxをインストールするには、CentOSにNginxをインストールする方法を参照してください。 Ubuntuにインストールするには、UbuntuにNginxをインストールする方法をお読みください。 Nginxの基本的な管理手順については、Nginxを起動、停止、再起動する方法をご覧ください。

ApacheとNginx：簡単な概要

以下は、ApacheとNginxの主な比較ポイントの概要です。

カテゴリ	Apache	Nginx
コスト	無料で利用可能	主力製品であるOSSNginxは無料でご利用いただけます。 Nginx Plusは有料オプションで、サポートと追加機能を備えています。
ライセンス	Apache License 2.0	2-BSDライセンス条項
書き込み	C、XML	C
オペレーティングシステム	Linux、Microsoft Windows、その他のUnixライクなシステム、OpenVMS	Linux、macOS、Microsoft Windows、その他のUnixライクなシステム、HP-UX、IBM AIX
アーキテクチャ	モジュラー、プロセスベース/スレッド	モジュラー、イベント駆動型
構成	配布済み	一元化
解釈	主にファイルベース	主にURIベース
機能	-マルチプロセッシングモジュール -ディレクトリごとの構成のサポート -キャッシング付きリバースプロキシ -IPv6互換の負荷分散 -HTTP/2をサポート -XMLサポートFTPサポート（別のモジュールを使用）	-静的ファイルとインデックスファイルを提供する -ファイル記述子キャッシュを開く -キャッシングによる高速リバースプロキシ -負荷分散とフォールトトレランス -IPv6がサポートされていますが、デフォルトでは有効になっていません -HTTP/2をサポート -メールプロキシ -HTTPキャッシング
サポート	-ApacheHTTPサーバーのドキュメント -ApacheHTTPサーバーユーザーリスト -IRC - スタックオーバーフロー -サードパーティプロバイダーによる商用サポート	-コミュニティ運営のメーリングリスト -IRC - スタックオーバーフロー -NginxPlusの有料公式サポート

アーキテクチャ

ApacheHTTPサーバー 小さなサーバーコアといくつかのモジュールを備えています。モジュールは静的にコンパイルされるか、動的にロードされます。

起動時に、Apacheは複数のサーバープロセスを開始します。これらのプロセスの目的は、ワークロードを共有することです。主なプロセスは親プロセスです、他は子プロセスですが。各子プロセスは、着信要求を処理する事前に決定された数のサーバースレッドを作成します。

サーバーをオペレーティングシステム用に最適化するために、Apacheはマルチプロセッシングモジュール（MPM）を使用します。。このモジュールの目的は、これらのタスクを実行する子プロセスを割り当てることにより、ネットワークポートにバインドし、要求を受け入れ、要求処理を管理することです。 Apacheは、検出されたOSとその機能に応じて、環境に最適なMPMをインストールします。

Apache Portable Runtime Libraries（APR） Apacheサーバーのもう1つの重要な部分です。 APRは、クロスプラットフォームのOSレイヤーを提供します。このレイヤーは、開発者向けのユニバーサルAPIとして機能し、プラットフォーム固有の問題や機能をコーディングする必要がなくなります。

Nginx 最新のハードウェアで簡単にスケーリングできるイベント駆動型アーキテクチャを備えています。

Apacheと同様に、Nginxにはプライマリのマスタープロセスがあります。このプロセスの目的は、ポートのバインドと構成の読み取りを制御することです。ただし、Apacheとは異なり、マスタープロセスによって作成されるプロセスは、予測可能なプロセスモデルに基づいて設計されており、その主な目標はハードウェアリソースを最大限に活用することです。

キャッシュローダー 起動時に実行され、ディスクベースのキャッシュをメモリにロードするプロセスです。
キャッシュマネージャー ディスクキャッシュエントリが定義されたサイズ制限内にあることを確認してください。
ワーカープロセス 読み取りおよび書き込み操作を実行し、ネットワーク接続を処理します。

ワーカープロセスは、イベントをリッスンして待機することから始まります。新しい着信接続が要求されるたびに、イベントが開始されます。接続を確立すると、Nginxは少量のワーカープロセスメモリのみを使用するファイル記述子を作成します。この機能により、Nginxは、個別の接続ごとに大量のリソースを消費するプロセスベースのアプローチを使用するApacheよりも大幅にスケーラブルになります。

モジュール

ApacheとNginxはどちらもモジュールベースのアプローチを使用しています。ただし、実装は異なります。

アパッチ 動的にロードされたモジュールを備えており、必要なときにいつでも利用できます。サーバーは、公式およびサードパーティの両方の多くの異なるモジュールをサポートします。これにより、Apacheは、ユーザーがニーズに合わせて調整できる非常にカスタマイズ可能なプラットフォームになります。

Nginx モジュールはコアに統合する必要があり、動的にロードすることはできません。非標準モジュールを含めるには、ユーザーはソースからサーバーをコンパイルする必要があります。この柔軟性の欠如は制限のように思われるかもしれませんが、動的なモジュール統合を許可するとセキュリティ上の懸念が生じるため、セキュリティが向上することも意味します。

パフォーマンス

サポートされているさまざまなマルチプロセッシングモジュールを利用することで、 Apache 3つのモードで実行できます：

プロセスベースモード。
ハイブリッドプロセスとスレッドモード。
ハイブリッドイベントモード。

ユーザーは、ニーズに合った方法でApacheを構成できます。したがって、サーバーリソースは特定のユースケースで効果的に使用されます。

Apacheは、スループットとスケーラビリティを向上させるための一連の最適化を備えています。これらの最適化の一部はデフォルトのサーバー構成の一部であり、サーバー管理者はシステムの特定のニーズに応じて残りを構成できます。パフォーマンスチューニングは、Apacheのランタイムおよびコンパイル時の構成の問題の多くを解決できます。

Nginx Apacheよりも優れたパフォーマンスを発揮するために特別に作成されたWebサーバーです。接続時間、1秒あたりの受信リクエスト数、転送速度、リクエストの処理に費やされた時間など、いくつかのカテゴリでこれを行うことに成功しています。

サーバー管理者は、システム仕様に合うようにサーバーの構成を編集することで、Nginxのパフォーマンスをさらに調整できます。ワーカープロセスと接続を調整し、Gzip圧縮を有効にし、静的ファイルをキャッシュすると、Nginxのパフォーマンスが大幅に向上します。

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

Apache 動的にロードされたモジュールを使用して静的コンテンツと動的コンテンツの両方を処理し、外部コンポーネントに依存しません。

どちらのサーバーも動的コンテンツの読み込みで同様のパフォーマンスを示しますが、 Nginx 使用するメモリがはるかに少なく、静的ファイルを提供するために1秒あたり約4倍のリクエストを処理します。これは主に、動的コンテンツのインタープリターがNginxサーバーの不可欠な部分ではないためです。代わりに、サーバーはすべての動的Webページ要求を外部プロセスに渡し、プロセスがコンテンツを返すのを待ってから、コンテンツをクライアントに提供します。これにより、動的ページ処理がより複雑になりますが、静的ページを提供するプロセスが簡素化されます。

分散構成と集中構成

Apacheの 構成が配布されます。サーバーは、このタイプの構成を容易にするために.htaccessファイルのサポートを提供します。

.htaccess fileは、複数のWebサーバーでサポートされているディレクトリレベルの構成ファイルであり、URLリダイレクト、URL短縮、アクセス制御（さまざまなWebページおよびファイル用）などのWebサイトアクセスの問題を処理するために使用されます。このアプローチの主な利点は、 .htaccessで行われた変更です。 すぐにシステムに適用されます。メイン構成ファイルを変更するには、変更を適用するためにシステムを再起動する必要があります。

さらに、複数のWebサイトをホストするサーバーでは、 .htaccess 各ユーザーは、サーバーのメイン構成ファイルを変更せずに、Webサイトの構成を変更できます。

Nginx 構成は一元化されており、 .htaccessをサポートしていません 。これは、 .htaccessを使用するためです。 また、いくつかの欠点があります。重要なのはパフォーマンスの低下です。サーバーがHTTPリクエストを受信するたびに、 .htaccessをホストできるすべての親ディレクトリをチェックする必要があります。 ファイル、それらがそれを含んでいるかどうかを確認します。もう1つの重要な懸念事項は、セキュリティです。非特権ユーザーにサーバー構成の変更を許可すると、適切に実装されていない場合、安全ではなくなる可能性があります。

Nginxにはディレクトリレベルの構成がないため、ユーザーはメインの構成ファイル nginx.confにディレクティブを書き込んで、すべての構成変更を実行します。 。変更は、サーバーがリロードされた後に適用されます。

接続処理アーキテクチャ

アパッチ マルチプロセッシングモジュールを利用してクライアントリクエストを処理します。これの主な利点は、接続処理アーキテクチャを必要なときにいつでも簡単に置き換えることができることです。これらのモジュールは次のとおりです。

mpm_prefork_module – preforkモジュールは、処理する必要のあるリクエストごとにスレッドを使用してプロセスを作成します。すべての子プロセスは1つの接続をサポートできます。作成されたプロセスの数はリクエストの数よりも多くなりますが、このモジュールは良好に機能します。モジュールの主な問題は、大量のリクエストがパフォーマンスに悪影響を及ぼし、RAM消費量を大幅に増加させることです。
mpm_worker_module –ワーカーモジュールは子プロセスを作成します。各子プロセスは複数のスレッドを管理し、各スレッドは接続をサポートします。スレッドはプロセスよりも効率的であるため、このモジュールはpreforkモジュールよりもパフォーマンスに優れています。
mpm_event_module –イベントモジュールは、ワーカーモジュールのメカニズムと同様のメカニズムを備えています。ただし、「生き続ける」の解決も試みます。「問題– Apacheは、クライアントの最初のリクエストを完了した後、子プロセスまたはスレッド全体をクライアントからの次のリクエストを待機させ続けるという事実。イベントモジュールは、指定されたリスナースレッドにソケットの状態を監視させることで、この問題に対処します。

Nginx 非同期の非ブロッキングイベント駆動型アルゴリズムを使用して接続を処理します。高速ループ機能を使用すると、サーバーのワーカープロセスは、イベントを継続的に検索して処理することにより、同時に多くの接続を処理できます。

ワーカーが接続を確立すると、接続はイベントループに参加し、そこで非同期処理が行われます。接続が閉じると、ループを終了します。このタイプの接続処理により、Nginxは経済的な方法でリソースを拡張および利用できます。

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

アパッチ Directoryを使用して、主にリクエストをファイルシステムリソースとして解釈します およびFile ブロック。サーバーはDocumentRootで始まります ホストとポート番号に続くリクエストの一部を使用してファイルを見つけようとします。

Apacheは、ファイルシステムを調べても適切な一致が見つからない場合に、リクエストを処理する別の方法を提供します。

Alias URLをファイルシステムの場所にマップします。これにより、ドキュメントを DocumentRoot以外の場所に保存できます。 。
Redirect 古いURLを新しいURLにマップします。サーバーはクライアントに、探しているリソースを別の場所で見つけるように要求します。
Location ブロックを使用すると、URIを操作できます。

デザインが主にWebサーバーのニーズを反映しているApacheとは異なり、Nginxアーキテクチャではサーバーをプロキシとして使用できます。したがって、Nginxは主にURIを扱います。

Nginx サーバーブロックとロケーションブロックをプライマリ構成ブロックとして使用します：

サーバーブロックは、リクエスト処理用の仮想サーバーを定義する構成ファイルのサブセットです。仮想サーバーは特定の接続タイプを処理するように割り当てることができるため、サーバー管理者はさまざまなドメイン名、ポート、およびIPアドレスにさまざまなブロックを割り当てることができます。
ロケーションブロックは、さまざまなリソースとURIのリクエストを処理するサーバーブロックの一部です。リクエストをファイルシステム内の正しい場所にルーティングします。

複数のブロックが個別のWebサーバーインスタンスとして機能できるため、Nginxには各リクエストに最適なものを見つけるシステムがあります。これは、 listenを使用して実行されます 可能なブロック一致を見つけるディレクティブ、および server_name ディレクティブ。最適なものを選択します。

Nginxが静的ファイルを処理する場合、リクエストをファイルシステムにマップします。ただし、サーバーは、サーバーとロケーションブロックを選択し、ドキュメントルートとURIを接続した後にのみこれを実行します。 Nginxがリクエストを処理する準備ができるまでファイルシステムを処理しないという事実は、Nginxが .htaccessを備えていない理由の1つです。 同等のファイル。

キャッシュ

アパッチ サーバーのパフォーマンスを向上させるためのキャッシュを提供します。キャッシュには次の3つのタイプがあります。

スリーステートRFC2616HTTPキャッシング ローカルに保存されたプロキシコンテンツまたは動的コンテンツを処理するときに、インテリジェントなHTTP対応のキャッシュを提供します。
2つの状態のキー/値共有オブジェクトのキャッシュ キー/値ベースの共有オブジェクトキャッシュを提供します。
特殊なファイルキャッシュ 起動時にファイルをプリロードできるようにし、頻繁に必要となるファイルのアクセス時間を改善します。

Nginx 動的コンテンツをキャッシュしてすばやくアクセスできるようにすることで、読み込み時間を短縮し、サーバーの負荷を軽減します。キャッシュはトラフィックとコンテンツ量の多いWebサイトの速度を上げるのに役立ちますが、他のシナリオではお勧めしません。

Nginxの基本的なキャッシュは、次の2つのディレクティブのみを使用します。

proxy_cache_path キャッシュパスと構成を設定し、
proxy_cache キャッシュをアクティブにします。

Nginxの便利な機能は、サーバーがダウンまたはビジーのときにキャッシュされたWebサイトコンテンツを表示するようにサーバーを構成する機能です。

セキュリティ

ApacheとNginxはどちらも安全であると見なされます。潜在的なセキュリティリスクは、主に不適切な構成に起因します。したがって、セキュリティを強化するには、Webサーバーのセキュリティのベストプラクティスに従ってください。

Apacheの場合：

DoS攻撃を防ぐために構成を調整します。これに関連するディレクティブのいくつかは、 RequestReadTimeoutです。 、 KeepAliveTimeout 、および TimeOut 。
ServerRootの権限を調整します ディレクトリ。
サーバーサイドインクルード（SSI）に注意してください。
CGIスクリプトに注意してください。
システム設定を.htaccessから保護します サーバー構成ファイルを構成してオーバーライドします。
ログを監視します。
サーバーを最新の状態に保ちます。

Nginxの場合：

不要なモジュールを無効にすることで、潜在的な脆弱性の悪用のリスクを軽減します。
server_tokensを無効にします Nginxバージョンを公開するディレクティブ。
不要なHTTPメソッドを無効にします。
潜在的なDoS攻撃を防ぐために、リソースと制限を制御します。
サーバーの状態をよりよく理解するために、アクセスログとエラーログを設定、構成、および監視します。
セキュリティヘッダーを含めます。
サーバーを最新の状態に保ちます。

サポートとドキュメント

アパッチ ApacheHTTPサーバーユーザーメーリングリストを通じてコミュニティサポートを提供します。専用のIRCチャネル、StackOverflowなどでもサポートを利用できます。

Apache HTTPサーバーのドキュメントには、リファレンスマニュアル、ユーザーガイド、チュートリアル、およびその他のドキュメントが用意されています。

Nginx コミュニティが運営するメーリングリストとフォーラムで構成されるコミュニティサポート、および管理ガイドやモジュールリファレンスガイドなどの他のサポートリソースを提供します。有料オプションのNGINXPlusの商用サポートを利用できます。

オープンソースのNginxドキュメントには、インストール手順、ハウツー、開発ガイド、モジュールリファレンス、およびその他のドキュメントが含まれています。

ApacheまたはNginx

最新の市場シェア調査データは、ApacheがNginxよりもわずかに進んでいることを示しています。

ただし、上位1000の最高ランクのWebサイトのみを見ると、Nginxは大幅に進んでいます。

ApacheとNginxはどちらも洗練された、パフォーマンスの高いサーバーです。ハードウェアにインストールする適切なサーバーを選択するときは、そのサーバーを何に使用するかを検討する必要があります。

次の場合はNginxではなくApacheを選択してください：

ユースケースでは、非特権ユーザーが自分のWebサイトを制御できることが望ましいです。それらのケースの1つは、Apacheの .htaccessが存在する共有ホスティング環境の管理です。 ファイルは実質的に不可欠になります。
Nginxがサポートしていない特定のモジュールが必要です。

次の場合はApacheではなくNginxを選択してください：

使用シナリオには、ほとんど（または排他的に）静的コンテンツの提供が含まれます。
ウェブサイトのトラフィック量が多いと予想されます。

NginxとApacheの両方を使用する場合

ApacheとNginxを並べて使用して、ワークロードに最適化されたサーバーを作成できます。 Nginxは、Apacheのリバースプロキシとして機能するように設定されています。これは、Nginxの処理速度と大量のトラフィックを処理する機能を活用しています。 Nginxは、動的コンテンツをApacheに転送しながら、静的コンテンツを処理して提供します。

Nginxにリクエストを並べ替えさせ、単独で処理できるリクエストを処理させることで、Apacheはより少ない量のリクエストを受け取ります。これにより、潜在的なオーバーロードの問題が先制的に解決されます。 Nginxはバックエンドのサーバープールと通信できるため、サーバーの追加とスケールアウトを簡単に実行できます。