NginxとApacheの比較 〜 ウェブサーバー直接対決 〜

私たちが、現在、感覚的に周知の事実として把握しているように、インターネットは90年代にその「世界征服」に乗り出しました。「ウェブ」プロトコル全体の動きを要約すると、訪問者が特定のウェブアドレスから文書を要求し、DNSとIPがその要求を正しいコンピュータに転送する、という流れになります。要求されたウェブページをホストしているコンピュータは、そのページを訪問者に「提供（つまり“サーブ”）」します。

ウェブページは基本的にHTML文書です。訪問者に異なるWebページを提供できるようにするためには、「提供（サーブ）」を担うマシンにサーバープログラムが必要となります。Nginx、Apacheのようなソフトウェアは、リクエストを処理し、それらを分析し、そして訪問者のブラウザで見えるように対応するドキュメントを渡します。

Apache

Apacheが最初にリリースされているので、まずはApacheから。

インターネットが誕生してから数年という時期の、Tim Berners-Lee氏のCERN httpd、そしてNCSA HTTPdを追うようにして1995年にリリースされたApacheは、すぐに市場を席巻し、世界で最も人気のあるウェブサーバーに。今日でも、まだ市場で存在感を放っていますが、それは、主にその燦然たる歴史によるものです。Apacheは、Apacheのライセンスの下、Apache Foundationによって開発および保守されています。

Apacheという名前の由来については2つの説があります。1つは、「かの有名なアメリカ先住民族アパッチ族に由来する」というもの。2つ目は「（いくつものソフトウェアパッチ—つまり修正プログラム—を経てきたことから“パッチのサーバー”を意味する駄洒落を使った」というものです。

Linux

Apacheの圧倒的市場占有率は、Red Hat、CentOS、Ubuntuなど、Linuxの全ての主要ディストリビューションにプリインストールされているという事実に一部起因しています。

LinuxにおけるApacheの役割の重要性を示す1例として、そのサーバープロセス名がHTTPdであり、Apacheがウェブサーバーソフトウェアの同義語となっていることが挙げられます。

ウェブサーバー市場で最初に本格的な役割を果たしたことに加えて、Apacheによる世界席巻の背景には、その設定システムと.htaccessファイルがあります。

.htaccess

Apacheはその設定に.htaccessを使用します。Apacheが要求を処理する方法は柔軟に設定でき、.htaccessのファイルを設定、編集、使用方法に関するチュートリアルは多数存在します。例としては、様々なリダイレクトルール、最大アップロードファイルサイズ、URL書き換え、メモリ制限、ディレクトリ保護（htpasswd）、 expiresヘッダー、Cache-Controlヘッダー、Accept-Encodingヘッダー、クッキー、クエリ文字列の操作などがあります。

一方、Kinstaでは、.htaccessファイルをサポートしていないNginxを利用しています。しかし、.htaccessファイルの設定と規則は、Nginx独自の書き換えルールに簡単に「翻訳」することができます。

Apacheの主な「長所」の1つとして、サーバールート（メインのウェブサイトディレクトリ）では、ディレクトリツリー内のすべてのレベルまたはディレクトリに、独自の設定を持つ固有の.htaccessファイルを含めることができます。

共有ホスティングプロバイダにとって、これは夢のような状況です。なぜなら、他の人に影響を与えることなく、同じマシン上で何百人ものユーザーに独自のウェブサイト​​設定方法を提供できるからです。利用者は、グローバルサーバーの設定に触れることなく、制限つきの共有ホスティング環境で多くの詳細を設定できます。

公式文書によると以下のようになっています。

「通常、メインサーバーの設定ファイルにアクセスできない場合にのみ、.htaccessファイルを使用してください」

ただし、この柔軟性はパフォーマンスを犠牲にすることに。「実際に使用するかどうかにかかわらず、.htaccessファイルを許可するとパフォーマンスが低下」するとのことです。

.htaccessファイルを許可している場合、Apacheはリクエストがある度に要求されたURLまたはファイルから、サーバーのルートディレクトリまでの階層を遡りディレクトリツリー全体を検索し、.htaccessファイルを読み込みます。その後、ファイルを処理し、この方法で設定された各ディレクトリに対して自らの再設定を行う必要があります。

WordPressサイトは大いに複雑になることがあります。典型的なWordPressサイトであっても、異なるディレクトリから何百ものリクエストを受け取るものです。

/wp-content/uploads/yyyy/mmタイプのディレクトリから、通常1ページの読み込みで複数のリクエストがあり、多くの場合、異なる月ごとのディレクトリを形成します。それから/wp-content/themes/parent-theme静的リソース、/wp-content/themes/child-themeリソースがあります。これらはjavascript、cssファイル、画像を含みます。

それから、何十ものプラグインサブディレクトリから読み込まれた静的ファイルを含む/wp-content/pluginsもあるでしょう。これらの各リソースについて、Apacheは設定を探すためにツリー全体を検索しなければならないのです。

ある分析によると、（共有ホスト上のウェブサイトでは特に一般的に言えることですが）WordPressの一般的な設定には、42の.htaccessの実行と、249の.htaccessファイル検索が含まれとのことです。

これはウェブサーバーレベルでの話です。訪問者は、PHPプロセスがWordPressコールスタック全体を実行、データベースクエリを作成し、それをMySQLに渡しウェブページを組み立てサイト訪問者に送信するのを待つ必要があります。

モジュール

Apacheの普及に一役買ったもう1つの要因は、その動的モジュールシステムです。

モジュール（ユーザーによるウェブサーバー機能拡張を可能にする機能の一つ）は、NginxとApacheの両方に存在します。Apacheでは、ウェブサーバーのインストールとデプロイが完了した後に、モジュールをインストールし、 必要に応じて有効化/無効化できます。Debianベースのディストリビューションには、設定ファイルを編集しなくてもこれらのモジュールを有効または無効にできるコマンド、a2enmodおよびa2dismodがあります。

Apache標準ディストリビューションの一部として付随するモジュールの公式リストはこちらにある通りです。圧縮、暗号化、ログ、リダイレクトから、要求の編集、高度なシンタックスでの応答のようなより高度なものが含まれます。

Nginx

Nginx（またはnginxまたはNGINXとも表記される）は、ロシアの開発者Igor Sysoev氏によって2004年に公にリリースされました。Nginxのプロジェクトマネジャー、Owen Garrett氏は次のように述べています。

「Nginxは、Apacheウェブサーバーのパフォーマンス制限に対処すべく生み出されました」

このサーバーは、2002年にウェブサイトrambler.ruのスケーリングツールとして作成されました。バージョンは2つあります。オープンソース（BSDタイプライセンス付き）とNginx Plus（サポートおよび追加のエンタープライズ機能付き）です。

リリース後、Nginxは主に静的ファイルを提供するために、そしてApacheインストール前のロードバランサーまたはリバースプロキシとして使用されました。ウェブが進化し、速度とハードウェア使用効率の最後の一滴を絞り込む必要性が増すにつれて、より成熟したソフトウェアの登場も背景に、多くのウェブサイトがApacheを完全にNginxへと置き換え始めました。

2019年3月、Nginx IncはF5 Networksに6億7000万ドルで買収されました。その時期、Techcrunchが報告するところによると、Nginxサーバーは「3億7500万のウェブサイトを支え、約1,500の有料顧客」を保有していたとのこと。

w3techsのデータによると、Nginxの市場シェアは着実に成長しており、Apacheを王座から引きずり落としている最中とのことです。

このデータは世界全体のウェブサーバー全体に関するものですが、上位100万のウェブサイトのサンプルを取ると、Nginxはしばらく前からその地位を独占していることがわかります。

Google Search Trendsもこの事実を反映しているようです。

Netcraftの調査によると、Apacheは2019年4月にNginxに追い越されました。

Nginxのコンフィギュレーション

Nginxはるかに効率的で速いにもかかわらずApacheのような設定システムを持っていないため、リテールホスティングプロバイダでは広く採用されていません。共有環境ではApacheのような活躍はできていないことになります。

一方、ディレクトリレベルでの設定を許可しないことで、NginxはApacheよりも大きな優位性を持ちます。Nginxウィキにはパフォーマンスへの影響を比較した記事があります。

Nginxのモジュール

NginxのモジュールシステムもまたNginxの優位性を高める要因の一つとなっています。Nginxモジュールは通常ビルド時に有効にする必要があります。これにはより技術的な能力が必要であり、モジュールのインストール後の追加はやや複雑になります。

2016年のバージョン1.9.11では、状況が変わり、有料顧客向けに公式の検証済み動的モジュールをサポートするように。2019年5月現在、QUICとHTTP/3サポートの開発を開始することが発表されています。

キャッシュについて — NginxとApacheの比較

キャッシュとは—とても簡単に言うと—ユーザーが訪問する前にウェブサイトのコンテンツをあらかじめ準備しておき、訪問があった時に探すことなくすぐに提供できるようにしておくような仕組みです。

Apache同様、Nginxの典型的なキャッシュ機能は、サーバーとエンドユーザーの間にキャッシュサーバーとして置くことによりサーバー全体の負荷を軽減するために使われていました。

そうすることで毎回本来のサーバーからコンテンツを取得することなく静的コンテンツをキャッシュできるのです。

（Kinsta LXCコンテナの場合のように）Nginxをスタンドアローンサーバーとして利用する場合、別途キャッシュサーバーを置く必要はありません。Nginxはそれ単体で静的コンテンツを非常に効率的に提供できるのです。

また、動的コンテンツのキャッシュ、ページキャッシュについてもNginxは対応しています。WordPressサイトにおいては、すべてのURLに対して生成されたすべてのWordPressページをメモリまたはディスクに保存しなければなりません。

そんな時に便利なFastCGIキャッシュは標準のNginxパッケージでインストール可能です。あまり一般的に使われていないNginxの機能の一つですが、シンプルで非常に便利です。

これをApacheと比較してみましょう。Apacheにはmod_cacheモジュールがありますが、バグが発生する傾向にあり、他のモジュールとの干渉が懸念されるとのこと。そのため、Apacheで展開されている標準のキャッシングソリューションはVarnish HTTPアクセラレータとなっています。Varnishは業界専用のソリューションですが、最近実施された複数のテストの結果としては、NginxはVarnishよりも優れたキャッシング性能を記録しました。

Kinstaでは、動的WordPressキャッシュにNginxを採用。これをキャッシュされたページとKinsta CDNによってキャッシュされた静的な資産を細かく制御することを可能にする弊社独自のキャッシュプラグインと併用しています。

リクエストの処理 — NginxとApacheの比較

ApacheとNginxの最大の違いは、リクエストを処理する方法の基盤となるアーキテクチャにあります。

ApacheはMPM-sまたはマルチプロセッシングモジュール（MPM）を使用して要求を処理します。これは「マシン上のネットワークポートへのバインド、要求の受け入れ、および要求の処理のための子のディスパッチ」を担当します。

Apacheが登場した当初から使用されている最も古いMPMはpreforkモジュールです。Apacheのパフォーマンスに関する悪評の原因はこのモジュールによるものと言っても過言ではないでしょう。このモードでは、Apacheはリクエストごとに1つのスレッドで新しいプロセスを起動します。

このモジュールはmod_phpと共に使用され、CSSファイルや画像を提供する必要がある場合でもすべてのプロセスにPHPインタプリタが組み込まれました。

これは非効率です。PreforkモジュールはデフォルトモジュールとしてApacheに付属します。これによりHTTP / 1への接続も制限されます。

後年、Apacheはマルチスレッドモデルのワーカーmpmを、その後イベントmpmを開発。どちらもApacheのパフォーマンス面での問題の多くを軽減しています。php-fpmへ切り替えることで、今でもApacheは競争力を保てており、同時に.htaccessを使用せずに済むことにも繋がりますが、その本来の目的にはそぐわないかもしれません。

Nginxは非同期のノンブロッキング、イベントドリブンアーキテクチャを採用。

この違いを説明すると、Linux/Unixの世界では、プロセスとはプログラムを実行することです。

スレッドはプロセスのサブセットであり、1つのプロセス実行内に複数のスレッドが存在する可能性があります。ブラウザウィンドウ内の複数のタブとお考えください。このようにして、プログラムは複数のCPUとマルチコア、マルチスレッドのCPUを活用してより高速に動作します。Linus Torvalds氏がこの違いを詳しく説明しています。

つまり、Apacheはすべての接続に対してプロセスを使用します（ワーカーmpmではスレッドを使用）。トラフィックが増加すると、すぐに費用がかさみます。

新しいプロセスやスレッドの生成はコンピュータやプログラムの起動に例えられるでしょう。最速のコンピュータでも、まだ時間がかかります。今日のウェブサイトでは、1ページの読み込みで数百ものリクエストが行われ、これはすぐに膨大な数になります。

イベントmpmは最適化に関してはもう少し進んでいますが、複数のテストからは、これが、Nginxを追い越すことができないことが明らかになっています。特に静的ファイルにおいて、NginxはApacheの2倍の要求を処理します。

Nginxは理想的にはCPU/コアごとに1つのワーカープロセスを持ちます。Nginxのワーカープロセスの違いは、ワーカーあたり何十万もの着信ネットワーク接続を処理できることにあります。接続ごとに新しいスレッドやプロセスを作成する必要はありません。

これが、Cloudflare、MaxCDN、および当社のパートナーであるKeyCDNなどの主要なContent Delivery Networks、あるいはNetflixなどのウェブサイトにおいて、Nginxがコンテンツ配信に不可欠だと考えられている理由です。

Nginxを利用する企業は枚挙に遑がありません。WordPress.comの背後にある非公開会社であるAutomatticをご紹介します。

Automattic converted all their load-balancers to Nginx for WordPress.com in 2008 (you can read about it here) and migrated their server stack completely to Nginx.

Automatticは2008年にWordPress.com用にすべてのロードバランサーをNginxに変換し（これについてはこちらから詳細を読むことができます）、サーバースタックを完全にNginxに移行しました。

実際に確認してみる

稼働中のウェブサイトで何が使用されているのかを調べたい場合は、通常、HTTP応答ヘッダーから確認できます。ウェブサイト上で、クリックして「検証」を選択し、デベロッパーツールでネットワークパネルを選択してから、ウェブサイトを再読み込みすると、ウェブサイトに読み込まれているすべてのリソースが表示されます。特定のリソースとその「ヘッダー」タブを選択すると、通常サーバー情報が表示されます。ウェブサイトでCDNを使用している場合、サーバーラインにCloudflareのようなものが表示されるか、ウェブサイトでHTTPアクセラレータを使用している場合はVarnishのようなものが表示されることがあります。

これは、cPanel、Apache、およびPHPでの一般的な共有ホスティング設定を使用するWordPress ウェブサイトの例です。

これはNginxを使用しているウェブサイトです。

左側に展開すると、すべてのリソースの時間を分析し、それがページ全体の読み込み時間に与える影響も確認できます。

まとめ

この記事では、NginxとApacheの違いに焦点を当て、Nginxがウェブサーバーの分野でより多くの注目を集めるようになった理由、つまり主なアーキテクチャの違いをご紹介しました。これは、リソースを大量に消費する業界におけるパフォーマンスの優位性を支える主な特徴です。

もちろん、すべての状況においてが同じ優先順位があるわけではなく、ApacheやLighttpd、IIS、LiteSpeed、Caddyなどの他のツールが良い解決策となることもあります。

Kinstaでは、WordPressおよびWooCommerce用のパフォーマンス最適化ホスティングソリューションの一部としてNginxを使用しています。すべてのWordPressサイトは、それを実行するために必要なすべてのソフトウェアリソース（Nginx、Linux、PHP、MySQL）を持つ独自の独立したコンテナに格納されています。リソースは100％非公開で、他のサイトと共有されません。