なぜ我々はnginxとApacheを併用してウェブアプリケーションを運用するのか

はじめに

ウェブシステムを構築する際には、それを動作させるサーバー環境の設計・構築が不可欠です。
弊社では、特にPHPアプリケーションを運用する場合に、サーバー上で動作するnginxと、Docker上で動作するApacheという、2種類のウェブサーバーアプリケーションを同時に利用する構成を採用しています。

一見すると、サーバーアプリケーションを二重に運用するのは構成を複雑にするだけのように思われるかもしれません。しかしこのアーキテクチャは、特にインフラ担当者の観点から見ると、理にかなった選択であり、運用上の多くのメリットをもたらします。

本記事では、我々がnginxとApacheを併用している理由とメリットについて詳しく解説します。

構成の概要

本構成では、nginxとApacheにそれぞれ役割を分担させています。 通信の流れは「ユーザー → nginx → Apache」という順番になります。

• nginx：ユーザーからのリクエストをまず受け付けます。 画像・JavaScript・CSSなどの静的ファイルはnginx側で直接レスポンスを返し、アプリケーション処理が必要なリクエストについてはApacheにproxy_passします。
• Apache：受け取ったリクエストに対して、ウェブアプリケーション（PHPなど）を実行して応答を生成します。

このように、アプリケーション側は基本的にApacheのみで完結して処理を行いますが、その前段にnginxという独立したレイヤーを設けることで、柔軟な通信制御を実現しています。

この構成のメリット

このように nginx + Apache の２段構成にすることで、以下のようなメリットが得られます。

・静的ファイル配信の高速化：nginx は静的ファイル配信に特化した設計になっており、軽量かつ高速なI/O処理を実現しています。これにより、サーバーリソースを無駄に消費せず、大量のリクエストにも効率よく対応できます。

・柔軟なリクエストハンドリング：nginx でアプリケーションに到達する前のリクエストにパラメータを追加したり、条件ごとに異なるプロキシ先へ振り分けたりすることが可能です。さらに、アプリケーションから返されたレスポンスに対して一部の編集を行うこともできるため、アプリケーションを改修せずに柔軟な運用対応が可能になります。

・アプリケーションサーバーの独立性確保：Docker 化された Apache は、バージョン管理や切り戻しをインフラ側で柔軟に制御できます。複数バージョンの並列稼働も容易であり、アップグレードやロールバック時のリスクを最小限に抑えられます。

・担当レイヤーの明確化：インフラ担当者はnginxの設定を、アプリケーション担当者は.htaccessによる制御を担当するという形で役割分担を明確にしています。これにより、各担当者が自身の責任範囲内で設定変更を行えるため、作業効率の向上と運用時の混乱防止につながります。

・セキュリティレイヤーの分離：nginxでWAF的な簡易フィルタやヘッダ制御を行うことで、Apache側のアプリケーションサーバーをインターネットから直接露出させることなく、安全に保護できます。

この構成のデメリット

一方で、nginx + Apacheの2段構成には、以下の2つの主なデメリットが存在します。

• サーバー負荷の増大：2つのサーバーアプリケーションを並行稼働させるため、単体構成と比較してCPU・メモリなどのリソース消費量が増加します。小規模用途では、このリソースコストが運用メリットを上回る場合もあります。
• インフラ構成の複雑化：リバースプロキシとアプリケーションサーバーを分離するため、設定・運用管理が複雑になります。トラブルシュート時には問題箇所の切り分けが必要となり、より高いインフラスキルが要求されます。

この構成にしていて良かったと感じたこと

先に挙げたように、デメリットも確かに存在しますが、特にインフラ担当者の観点では、この構成にしていて助かったと感じる場面が多くありました。 ここでは、具体的なエピソードをいくつか紹介します。

ApacheやPHPのバージョンアップ

ある環境では、PHP 7.3で動作しているApacheを運用していました。 PHPのバージョンアップを実施することになり、新たにPHP 8.3で動作するApacheを立ち上げ、それぞれに nginx の upstream 設定で backend-php73、backend-php83という名前を付与しました。
nginxの設定上でbackend-php73をbackend-php83に切り替えた後にリロードすることで、ほぼノーダウンタイムでバージョン切り替えを実現しました。
また、動作不良が発見された場合には、対象範囲のみを一時的にbackend-php73へ戻し、最小限の影響範囲で運用を継続できるようにしました。

複数バージョンのApache・PHPを並列稼働

既存コンテンツの中には、古いPHPバージョンでなければ動作しないものが存在することがあります。 このような場合、特定パス以下に旧バージョン用のコンテンツをまとめ、それ以外は最新のPHPバージョンで運用することで、必要最小限の領域のみ古い環境を残しつつ、全体は最新環境に移行する運用を実現できました。

サイトリニューアル時のリダイレクト対応

ウェブサイトのリニューアルに伴い、URL構成が変更されるケースは少なくありません。

このような場合でも、nginx側でリダイレクトルールを記述することで、旧URLへのアクセスを新URLに適切に誘導し、既存アプリケーションに変更を加えることなく、スムーズなサイト移行を行うことができました。

異なるドメインで異なる意味を持つウェブサイトの構築

通常、ウェブサイトは単一のドメインで運用されますが、処理効率、セキュリティ、機能の分割などの理由から、複数のドメインを使用して1つのサービスを提供するケースがあります。

具体例として、CDN経由のWordPressサイトにおいて、管理者向けサイトを異なるドメインで運用したいという要件がありました。主な理由は以下の通りです。

• フロントサイトに管理機能URLを残したくない：フロントサイトでは、管理機能へのリクエストをApacheに渡すことなく遮断することで、管理機能を利用できないようにしたい。
• 管理機能のプレビュー結果がCDNにキャッシュされることを防ぎたい：多くのサービスではこれを防ぐオプションがありますが、設定ミスなどの可能性を排除し、問題が起こるリスクを最小限に抑えたい。

WordPressは設定済みのドメインに強く依存するため、通常はドメインの変更が難しいですが、nginxの設定で適切なパラメータを設定したり、sub_filterやproxy_redirectを使用してレスポンス内のドメインを置換することで、アプリケーション側の修正を行うことなく、同一のサイトを異なるドメインで運用できます。

このように、nginxを活用することで、運用上の柔軟性が向上し、特定の要件に応じたドメイン構成を実現できます。

まとめ

我々がnginxとApacheを併用してウェブアプリケーションを運用する理由は、性能面だけではなく、システムの柔軟性、バージョン管理の容易さ、リクエスト制御の自由度といった、運用面での高い柔軟性を重視しているからです。この記事の中で挙げた具体例にあるように、さまざまな場面でこの柔軟性に助けられてきました。

変化の多いウェブサービス運営において、拡張性と安定性を両立できるこの構成は、非常に実践的であり、大きなメリットを感じています。