プライム・ストラテジー「KUSANAGI」開発チームの石川です。
Nginxは高パフォーマンスを発揮するWebサーバで、Weサーバの1/3はNginxを利用1しています。直近では HTTP/3に対応 しています。
一方でApache HTTP Serverは歴史が長く、.htaccess を使った細やかな設定が可能なWebサーバで、根強い人気があります。
KUSANAGI は Nginx と Apache HTTP Server のどちらでも使える
KUSANAGIではNginxとApache HTTP Serverの両方に対応しています。kusanagi init
コマンドで初期設定時にWebサーバを選択することができるのはもちろんですが、それぞれコマンド1つで使用するWebサーバを切り替えることができます。
Nginxに切り替える場合2
# kusanagi nginx
Apache HTTP Server3に切り替える場合
# kunsanagi httpd
KUSANAGI の Nginx と Apache HTTP Server でそれぞれできること、できないこと
性能
Nginx と Apache HTTP Server はいずれもWebサーバとしての基本的な機能は有していて、一般的な運用における大きな違いはありません。
かつては Nginx に比べて Apache HTTP Server では PHP の実行性能が劣ったり、メモリの消費が多くなる (mod_php) といったことがありましたが、KUSANAGI ではどちらの場合でも php-fpm を利用することで PHP そのものの処理性能には大きな差は出ないようにしています。
しかし、Webサーバとしての処理性能では Nginx の方に軍配が上がります。
非常にアクセスの多いサイトであったり、負荷が高いサイトである場合は Nginx の方がApache HTTP Serverと比べて同じアクセス・負荷での少ないリソース消費で済みます。そのため、同一のスペックのサーバの場合には Nginx の方がより多くのアクセス・負荷に耐えられることになります。
キャッシュ
KUSANAGI ではアクセスが多いサイトで負荷を軽減するために、キャッシュを利用する仕組みを用意しています。
- bcache
- fcache
bcache
bcacheは WordPress の組み込みキャッシュの仕組みを利用しているものです。詳細は コラム を参照してください。
このbcaacheは Nginx と Apache HTTP Server のいずれでも利用できます。
ただし、WordPress以外のCMSやLAMPでは利用できません。
fcache
fcacheは Nginx の FastCGI のキャッシュの仕組みを利用しているものです。詳細は コラム を参照してください。
このfcacheは Nginx でのみ利用できます。 Apache HTTP Server では利用できません。
ただし、WordPress以外のPHPを使用するCMSやLAMPでも利用することができます。
アクセス制限
Nginx では設定ファイルの location
ディレクティブに記述することでアクセス制限を行います。location
ディレクティブの書き方については、コラムでその 概要 や注意事項 を紹介しています。
Nginx では設定ファイルに記述を行うため、設定の変更には root 権限やNginxのリロードが必要になります。
一方で、 Apache HTTP Server は .htaccess ファイルに記述します。
.htaccess ファイルの書き方についてもコラム で取り上げていますので参考にしてください。
.htaccessファイルはDocumentRoot内にアップロードすることで反映できるため、設定と動作の確認が容易に行えるのがメリットです。
Nginx と Apache HTTP Server のいいとこ取りをする httpd-behind-nginx
このように Nginx は性能面と fcache によるキャッシュの仕組みがあり、Apache HTTP Server では .htaccess ファイル による柔軟なアクセス制限の仕組みがあるなど、それぞれのWebサーバにメリットがあることが分かりました。
では、このメリットを同時に享受することができないか? という贅沢な要求を満たすことができるのがKUSANAGI の httpd-behind-nginx
です。httpd-behind-nginx
とは Webサーバとアプリケーションを Apache HTTP Server で動作させつつ、Nginxでリバースプロキシを行う機能です。
具体的には Nginx がポート 80, 443 で HTTP/HTTPS の接続を受け持ち、リバースプロキシとして動作します。
Nginxが受けたHTTPリクエストは、ポート 8000で待ち受けている Apache HTTP Server にフォワードされ、実際の処理は Apache HTTP Server 側で行われます。
これにより Nginx で HTTP/3 を利用したり、fcacheでキャッシュを利用したまま、.htaccess ファイルの処理などを Apache HTTP Server で行うことを実現しています。
切り替えは kusanagi httpd-behind-nginx
4 で行います。
# kusanagi httpd-behind-nginx
もしも不都合があったり、何らかの理由で Nginx / Apache HTTP Server 単体の動作に戻したくなった場合には、 kusanagi nginx
や kusanagi httpd
で、すぐに戻すことができます。
httpd-behind-nginx で運用する際のポイント
httpd-behind-nginx
を実行している場合、単体の Nginx / Apache HTTP Server の運用と異なる点があります。
まず、Nginx と Apache HTTP Server が同時に起動しています。そのため、 kusanagi status
コマンドでは Nginx と Apache HTTP Server で両方が出力されます。
*** (active) nginx : nginx129 ***
* nginx129@with_httpd.service - The NGINX HTTP and reverse proxy server (with_httpd)
Loaded: loaded (/usr/lib/systemd/system/nginx129@.service; enabled; vendor preset: disabled)
Active: active (running) since Fri 2025-07-11 12:27:42 JST; 19s ago
*** (active) httpd : httpd24 ***
* httpd@with_nginx.service - The Apache HTTP Server (with_nginx)
Loaded: loaded (/usr/lib/systemd/system/httpd@.service; enabled; vendor preset: disabled)
Active: active (running) since Fri 2025-07-11 12:27:45 JST; 15s ago
トラブルシューティングをする際は Nginx と Apache HTTP Server の両方を見ることになります。
ログファイルは単体で動作している際の出力先と同じになります。
なお、サービス名がそれぞれ nginxXXX@with_httpd
httpd@with_nginx
になります。( XXX は Nginx のバージョン)
そのため、 systemctl
コマンドで直接サービスを指定している場合は注意は必要ですが、kusanagi httpd-behind-nginx --reload
でリロード、kusanagi httpd-behind-nginx --test
で設定ファイルのチェック、kusanagi httpd-behind-nginx
で一括して再起動が行えますので、kusanagi httpd-behind-nginx
コマンドの活用してみてください。
また、SSL証明書を更新する際は Nginx 側で対応することになります。これは Apache HTTP Server は常にポート 8000でHTTPで待ち受けているためです。
SSL証明書の更新についても kusanagi ssl
コマンドを利用して実際に動作しているWebサーバに関わらずに一括で更新できますので、コマンド を活用してください。