PHP-FPMの代替としてNGINX Unit？アーキテクチャ、リスク、および活用事例

アーカイブされたステータスと明確な簡潔な評価

2026年9月30日時点での明確な結論は次の通りである： NGINX Unit PHPアプリケーションを直接実行し、HTTP接続の受け入れ、TLSの終端処理、静的ファイルの配信、およびリクエストのルーティングを行うことができた。これにより、その機能範囲はPHP-FPMをはるかに上回っていた。 とはいえ、Unitは新しい本番環境向けのPHPホスティングプラットフォームとして一般的に推奨されるものではありません。というのも、公式プロジェクトは2025年10月以降アーカイブ化され、メンテナンスが行われなくなっているためです。.

とはいえ、既存のUnitインストール環境がすぐに機能しなくなるわけではありません。その依存関係、セキュリティ対策、および移行手順が文書化されていれば、引き続きアプリケーションを稼働させることができます。 しかし、新規投資については別の観点から評価する必要があります。継続的なプロジェクトのメンテナンスが行われない場合、セキュリティ上の脆弱性、パッケージの入手可能性、新しいOSバージョン、および将来のPHP互換性に関するリスクが高まります。.

バージョン表記においては、明確な区別が重要です。引き続き利用可能なインストールドキュメントでは「Unit 1.34.2」と記載されている箇所が多数ありますが、安定版リリースタグとして「1.35.0」が公開されています。 このリリースは、とりわけPHP 8.5との互換性を保証していますが、それによって継続的なメンテナンスが行われるわけではありません。開発ブランチ master アーカイブ済みであるため、運用上の意思決定において基準となる製品バージョンではありません。.

NGINX、PHP-FPM、Unitの違い

確固たる判断を下すためには、各要素を個別に検討する必要がある。. NGINX はWebサーバーであり、リバースプロキシでもあります。HTTPリクエストを受け付け、静的コンテンツを配信し、動的なリクエストを転送します。 一方、PHP-FPMはFastCGIプロセスマネージャーです。PHPワーカーを提供しますが、HTTPリクエストの受信やルーティングといった、Webサーバーの典型的なタスク自体は処理しません。.

従来の構成では、リクエストはまずNGINXに到達します。静的ファイルの場合は、NGINXが即座にそれを配信できます。PHPスクリプトの場合は、NGINXが必要なFastCGIパラメータをPHP-FPMプールに渡します。 空き状態のワーカーがコードを実行し、NGINXを介してレスポンスを返します。PHP-FPMにおけるプールサイズとプロセスモードは、php.ini形式の設定ファイルで制御されます。.

一方、Unitは アプリケーションサーバー リスナー、ルート、静的配信、および言語実行時間を1つのJSON設定モデルに統合しています。 そこではPHPアプリケーションがアプリケーションタイプとして統合されており、これによりUnitは、リクエストの受信からPHPの実行に至るまでの流れを、同一プラットフォーム内で再現することが可能になります。これにより、運用リスクが自動的に低減されるわけではありませんが、責任の範囲が変化することになります。.

したがって、Unitは「PHP-FPMが組み込まれたNGINX」というものではありません。PHPモジュールをビルドすると、PHP Embedライブラリと連携した独自のSAPIモジュールが生成されます。 したがって、分析や移行の際、チームはFastCGIの設定を引き継ぐだけでなく、ルーティング、アプリケーション定義、モジュールのバインディング、および診断パスを再割り当てする必要があります。エラーの原因を、単に上流のWebサーバーや独立したFPMプールに一概に帰することはできません。.

PHPモジュール、バージョン、および設定制限

PHPの場合、Unitをインストールするには、コアに加えて適切な言語モジュールが必要です。このモジュールは、使用しているPHPのバージョンとUnitのインストール環境に依存します。 OSやPHPのバージョンに適したパッケージが利用できない場合、ドキュメントでは、Embed-SAPIを提供するPHPインストール環境を用いた自作ビルドの手順が説明されていました。これにより、アップデート、再現性のあるビルド、およびエラー解析にかかる手間が大幅に増大します。.

設定もまた、異なるモデルに従っています。Unitは、設定インターフェースを介して、リスナー、ルート、アプリケーションをJSONデータとして束ねています。 一方、PHP-FPMはphp.ini形式のファイルでプールを管理します。この違いは単なる構文上の違いにとどまりません。FPMスタックでは、WebサーバーのルールとPHPプールの定義が分離されているのに対し、Unitではこれら両方をプラットフォーム内でより密接に統合しています。移行計画を立てる際には、この構造を考慮に入れる必要があります。.

PHPディレクティブに関しては、Unitは以下の範囲を区別しています admin そして ユーザー. 管理オプションは PHP_INI_SYSTEM に対応しており、アプリケーション側では実行時に変更できません。ユーザーオプションは PHP_INI_USER に対応しています。ただし、Unit によって PHP ディレクティブの許容範囲が拡張されることはありません。 設定をこの方法で設定できるか、あるいはアプリケーションコードによって変更できるかは、引き続きその設定のPHP構成モードによって決定されます。.

警告：Unit 1.35.0 で記載されている PHP 8.5 との互換性は、直近の安定版リリースにおけるこのバージョンへの対応を証明するのみです。これは、将来のセキュリティ修正や Unit PHP モジュールの対応を保証するものではありません。 したがって、既存のシステムを運用する際には、正確なUnitタグ、PHPバージョン、モジュールの出所、およびテスト済みの移行パスを、相互に関連する依存関係として文書化しておく必要があります。.

PHPのルーティングとフロントコントローラーの設定

ユニット構成では、リスナーをルートおよびアプリケーションに紐付けます。ローカルでのデモを行う場合、リスナーは 127.0.0.1:8080 耳を澄ます。あるルートでは、まず、要求されたファイルを /srv/example-app/public 静的に配信する。PHPファイルは、MIMEタイプの除外設定によりこの配信の対象から外され、PHPアプリケーションに渡されます。存在しないファイルについても同様です。これにより、公開ファイルとアプリケーションの実行が、別々のステップとして追跡可能になります。.

アプリケーション内では、 root ドキュメントディレクトリを固定し、一方で type: php PHPのランタイムを選択します。 script: index.php アプリケーションに渡されたすべてのリクエストは、このスクリプトに転送されます。これは、 フロントコントローラ 多くのPHPフレームワークでは、アプリケーションが元のパスを自ら解析し、コントローラーやエラーページなどを決定します。.

その姿勢がなければ script UnitはURIベースのスクリプトパスを処理します。これは、PHPファイルを直接呼び出す必要がある古いアプリケーションには適しているかもしれませんが、アクセス可能なパスを慎重に制限する必要があります。. targets さらに、root、script、index の挙動が異なるサブ領域を許可します。したがって、これらはルーティングの代わりとなるものではなく、複数のアプリケーションルールを目的を定めて定義するための手段です。.

以下の例は、公開サービス向けではなく、ローカルでのデモ用のJSON設定ファイルです。このファイルには、ドメイン名、TLS情報、および認証情報は含まれていません。この設定を適用する前に、ファイルの権限、実際にインストールされているPHPのサポート状況、およびUnitで設定をインポートするために使用される方法を必ず確認してください。.

{
  "listeners": {
    "127.0.0.1:8080": {
      "pass": "routes/example"
    }
  },
  "routes": {
    "example": [
      {
        "action": {
          "share": "/srv/example-app/public$uri",
          "types": ["!application/x-httpd-php"],
          "fallback": {
            "pass": "applications/example-php"
          }
        }
      }
    ]
  },
  "applications": {
    "example-php": {
      "type": "php",
      "root": "/srv/example-app/public",
      "script": "index.php"
    }
  }
}

順序が重要です：その 静的配信 このshareステップはフォールバックの前に実行されますが、PHPファイルは明示的に除外されます。これらのリクエストや存在しないファイルは、 index.php; これにより、次のような「話すURL」も機能します。 /artikel/beispiel 同名のファイルがない場合。アップロードディレクトリ、管理エリア、または直接アクセス可能なPHPファイルに対して追加のルールが必要かどうかは、それぞれのアプリケーションによって異なるため、このデモから一概に判断すべきではありません。.

プロセスモデルとRAM予算を比較する

PHP-FPM は、モードを通じてプールごとのワーカーを制御します static, dynamic そして ondemand. 一方、Unitでは、プロセス数はアプリケーション内でモデル化されます。動的なUnit構成は、 processes.max 総数を維持し、 processes.spare アイドル状態のプロセスを；; idle_timeout 余分な非アクティブなプロセスをクリーンアップします。.

したがって、これらの用語はそのまま置き換えられるものではありません。特に、文書化されたデフォルト設定は、ウェブサイトにとって適切な値とは言えません。どちらも pm.max_children 併せて processes.max PHPの並列処理を制限しますが、値が低すぎるとキューが発生する可能性があります。一方、値が高すぎると、OS、データベース、キャッシュ、その他のサービスとメモリを奪い合うことになります。.

A RAM予算 これはあくまで計画上のモデルに過ぎません。総メモリ容量から、OS、データベース、キャッシュ、その他のプロセス用に確保されるリザーブが差し引かれます。 残りの値は、PHPワーカー1人あたりのメモリ要件（控えめに見積もった値）で割られます。例えば、PHP用に1,200 MiBを、ワーカー1人あたり120 MiBで割ると、計算上10人のワーカーとなります。これらの値はいずれも意図的に設定された仮の数値であり、実測値や構成の推奨値ではありません。.

その結果、 上限 これは観察の出発点に過ぎず、正しい設定ではありません。重要なのは、通常の負荷および高負荷下における実際のピーク値、待ち行列、応答エラー、およびメモリ使用量です。体系的な導出と微調整については、 pm.max_children 社内投稿が役立ちます PHP-FPMの子プロセスを適切に計算する. Unit でも、パラメータの名称は異なりますが、同じ原則が適用されます。.

警告：他者の数値を単に採用するだけで処理の制限を設定すると、多くの場合、問題を先送りするだけになります。明確なメモリ予算を設定し、繰り返し監視を行って初めて、そのワーカーの上限が、アプリケーションやその拡張機能、および同時に稼働しているサービスに適しているかどうかが判明します。.

PHPホスティングの運用モデルを評価する

この表はアーキテクチャを分類したものであり、速度やメモリ使用量を比較したものではありません。NGINX-PHP-FPM構成において、新しいPHPホスティングを推奨する最大の理由は、その明確な役割分担にあります。すなわち、WebサーバーがHTTP処理、プロキシ、静的コンテンツを扱い、PHP-FPMがプールごとのPHPワーカーを管理する仕組みです。 こうした役割分担により、設定、エラーの分析、およびアップデートの評価を個別に容易に行うことができます。.

Unitは、リスナー、ルーティング、静的ファイル、アプリケーションを1つのプラットフォームに統合し、PHP以外にもさまざまなランタイムをサポートすることができました。このマルチ言語対応というアプローチこそが、既存の環境がUnitを選んだ理由を説明しているのかもしれません。 しかし、PHPのみに基づくサービスにおいては、これが必ずしも自動的な利点となるわけではありません。必要な機能の評価や、チームが異なる構成および運用ロジックを長期的に習得できるかどうかの検証に取って代わるものではないからです。.

Unit 1.35.0 では、技術的な機能範囲は メンテナンス状況 区別される。リリース日とは、公開されたバージョンとその変更内容を記録するものであり、それ以降、すでにアーカイブ化されたプロジェクトのさらなるメンテナンスは行われない。新たな判断を行う際には、この境界線は、目に見えるコンポーネントの数が少ないことよりも重要視される。一方、既存のインストール環境においては、依存関係や移行手順を文書化するきっかけとなる。.

ApacheとPHP-FPMの組み合わせは、一概に「良い」あるいは「悪い」という選択肢ではなく、既存のApache要件を満たすための選択肢の一つです。 選択にあたっては、保守性、利用可能なPHPのバージョン、パッチ適用プロセス、チームの知識、およびフェイルオーバー計画などを基準とすべきです。比較可能な負荷プロファイルや文書化された測定手法がなければ、このアーキテクチャの概要から信頼性の高いパフォーマンスの順位を導き出すことはできません。.

運用中のユニットを安全に稼働させる

既存のUnitインストールは、まず現状のシステムとして把握すべきであり、新しいプラットフォームのテンプレートとして扱うべきではありません。 重要なのは、実際に導入されているバージョン、連携しているアプリケーション、およびそれらの依存関係です。Unitが技術的に引き続き実行可能であることは、プロジェクトがアーカイブされたという事実を変えるものではありません。したがって、運用と置き換えは併せて計画する必要があります。.

WordPress、Joomla、Drupal では、 フロントコントローラ 重要なポイント：ファイルとして存在しないパスはPHPの中央エントリファイルにリダイレクトされる必要がありますが、存在するファイルは直接配信できます。WordPressのUnitに関するガイドでは、PHPファイルの扱いも含めたこのルーティングの原則が説明されており、 /wp-admin/. 既存のCMSにとっては、これは妥当な設定と言えるかもしれませんが、新規インストールの場合、Unitを推奨する根拠にはなりません。.

PHP、Python、Ruby、あるいはNode.jsで開発された複数の小規模なアプリケーションを、UnitのListener、Route、ランタイムの下で単一のプラットフォームに統合することができました。これが、当時の既存のアーキテクチャがUnitを採用した理由を説明しているのかもしれません。 ただし、純粋なPHPホスティングの場合、このマルチ言語対応はそれ自体が目的ではありません。別個に管理されたコンポーネントは、追加のインターフェースが必要になるものの、長期的にはメンテナンス性が向上する可能性があります。.

コンテナのデプロイメントを凍結させる場合は、特に詳細なインベントリ作成が必要です。そのため、正確なユニットタグ、PHPのバージョン、インストール済みの言語モジュール、ベースイメージ、および完全な設定を文書化してください。 さらに、イメージやパッケージの入手元、パッチ適用プロセス、およびテスト済みの移行手順とフォールバック手順も記載してください。なお、特定のUnitリリースのPHP互換性は、関連するモジュールが将来的にセキュリティ修正を受けられることを保証するものではありません。.

NGINXはUnitの前に配置されることがあります。例えば、既存のNGINX層を維持したい場合や、アクセスを意図的に前段に誘導する場合などです。 Unitのドキュメントでは、この統合について、コントロールソケットのセキュリティ確保という文脈でも言及されています。しかし、この方法ではアーカイブされた状態は解消されず、独自の設定、ログ記録、更新管理を伴う新たなサービスが追加されることになります。したがって、そのメリットと、こうした運用負荷とを具体的に比較検討する必要があります。.

タイムアウト、ログ、および応答停止したプロセス

プロセスの限界値はエラー診断ではありません。 limits.requests Unitは、処理されたリクエスト数が所定の数に達すると、アプリケーションプロセスを置き換えることができます。これにより、累積メモリ使用量を時間的に制限することはできますが、メモリリークや過大なデータ構造、あるいはブロックする外部呼び出しを解消するものではありません。 したがって、定期的な再起動は、アプリケーションコードが安定していることの証拠とはみなしてはなりません。.

と一緒に limits.timeout Unitは、設定された時間が経過すると、HTTP 503でリクエストを終了します。これは個々のリクエストに対する目に見える保護措置ですが、フリーズしたワーカーに対する完全な保護ではありません。ドキュメントによると、Unitはフリーズしたプロセスを検知しないため、それらはプロセスポール内に残留する可能性があります。 タイムアウト時間を長く設定しても、この問題は先送りされるだけであり、短く設定すると、通常は処理に時間がかかるリクエストが途中で打ち切られる可能性があります。.

• 閾値を変更する前に、HTTPステータス、影響を受けるパス、時間枠、および発生頻度を把握しておく。.
• アクセスログ、エラーログ、アプリケーションログをタイムスタンプに基づいて統合する。PHP-FPM の場合、スローログから追加のスタックトレース情報が得られることがある。.
• CPU、メモリ、I/O、ネットワーク接続、およびプロセスの状態と数を確認する。.
• その後、コード、データベースクエリ、ファイルシステムへのアクセス、および外部サービスを、考えられる原因として調査する。.
• 原因と負荷プロファイルが判明してから初めて、タイムアウト、プロセス制限、または再起動ルールを的確に調整してください。.

したがって、HTTP 503 エラーはタイムアウトを示している可能性もありますが、上流のコンポーネントやその他のエラーが原因で発生することもあります。繰り返し発生する長時間かかる PHP リクエストについては、ワーカーの数だけで対処すべきではありません。その手順については、 PHP-FPMのスローログと、リクエストの遅延原因の分析について スタックトレースをリクエストデータと関連付ける方法を示しています。この同じ因果関係のロジックは、ユニット在庫分析においても有用です。.

特に問題となるのは、明確な終了が見られない症状です。例えば、待ち時間の増加、プロセスが継続的に占有されたままの状態、あるいはログへの進捗記録が記録されない場合などです。このような場合、一律にタイムアウト時間を延長するよりも、プロセスの状態や依存関係を把握することが重要です。 例えば、PHPワーカーがデータベース、DNS、ファイルシステム、あるいはネットワークI/Oを待機していないかを確認してください。具体的なボトルネックを特定して初めて、コードの修正、リソースの調整、あるいは制御された再起動のいずれが適切かを判断できます。.

新旧のシステムに関する決定

新しいPHPホスティング環境においては、PHP-FPMを搭載した適切に管理されたWebサーバーが、より理にかなった標準的な選択となります。PHP-FPMは標準的なPHPディストリビューションに含まれており、文書化されたプールおよびプロセスマネージャーのオプションを提供しています。 一方、Unitの場合、問題は単なる機能性から保守性へと移ります。インストール自体は継続可能ですが、アーカイブ化されたプロジェクトの状態は、長期的な依存リスクを高めることになります。.

既存のユニットシステムについては、客観的な判断は資産調査から始まります。オペレーティングシステム、PHP、ベースイメージのメンテナンス状況やパッチ適用可能性、インストール済みの言語モジュールの互換性、既存の運用知識、および連携しているサービスを確認してください。 同様に重要なのは、エクスポート可能な設定、再現可能なロールバック、そしてルーティング、PHPの設定、デプロイメントを段階的に移行できるターゲットシステムです。.

移行には、恣意的に設定された普遍的な期限は必要ありませんが、優先順位をつけた順序が必要です。インターネットに公開されているアプリケーション、更新できないイメージ、モジュールの出所が不明確なもの、およびフォールバック計画のないビジネスクリティカルなアプリケーションに、まず注意を向ける必要があります。その後、アプリケーションを複雑さや依存関係に基づいてグループ分けすることができます。 管理された移行期間中の並行運用は、データ管理、セッション、および元に戻す手順が事前に定義されていれば、リスクを低減することができます。.

仝 Control API これは管理用アクセスであり、通常のWebサイトのエンドポイントではありません。 UnitはこれをUnixドメインソケットとして文書化しており、その採用理由としてセキュリティ上の観点を示しています。厳格なファイル権限と明確に区切られた管理アクセス権を設定してください。一般に公開された状態では、攻撃者がアクセスの成功時に設定を大幅に変更できる可能性が生じます。.

実用的な移行プロセスは、新しいプロセス構成の設定だけで終わるわけではありません。 アプリケーションごとに、PHPのバージョン、拡張機能、環境変数、ファイル権限、ルーティングルール、および可観測性をターゲットシステムに引き継いでいきます。その際、一律的な速度評価を下すのではなく、期待される応答やエラーケースを比較検討してください。そうすることで、予期せぬレガシーな課題が、文書化された 移籍戦略 理解しやすい技術的な判断に基づき。.