📜
連載: FrankenPHP導入検討 - PHP実行環境の歴史

Ryo Maruta
2025/07/23に公開
こんにちは！英語学習サービスを提供しているプログリットで、サーバーサイドエンジニアをしているMaruです。
プログリットのエンジニアチームでは、英語コーチングで利用する学習アプリやコンサルタント向けの社内システム、サブスクの英語学習アプリなど複数のシステムを開発しています。
また、サーバーサイドチームでは、各プロダクトのAPI開発をメインとし、認証基盤、外部システム連携やコンテンツ管理のための社内システムなどさまざまな開発を行っています。
メインの開発言語はPHP(Laravel)となっており、開発業務の大半はPHPを書いています。またインフラはNginxをWebサーバーとして、AWS ECSで実行する構成がほとんどです。
2025年現在、各プロダクトのお客様の数が順調に伸びていることもあり、「パフォーマンス問題」に直面する機会が徐々に増えてきました。また、各ECSタスクではNginxとPHPコンテナそれぞれ動作させており、複数プロダクトを運用する上で設定の煩わしさなども感じるようになってきました。
そのため、より多くのアクセスを安定して処理できるようにPHPの実行環境を見直したいと考え、Webサーバーと統合したPHPStan実行環境である FrankenPHP の導入を検討したいと考えています。
第1回として、そもそものPHPの実行環境の歴史についてまとめ、なぜFrankenPHPが速いのかや、導入にあたっての注意点などを理解しながら進めていきます。
CGIの基本から始まり、FastCGI、PHP-FPM、そしてLaravel Octaneの登場による実行方式の変遷について簡単にまとめたいと思います。

 WebサーバーでPHPプログラムを実行するにはWebアプリケーションではサーバにリクエストしてページを表示しますが、WebサーバーはHTMLや画像など静的なページはそのまま返却することができるものの、PHPのようなスクリプト言語は直接実行できません。
そのため、PHPの処理を別プロセスに依頼する必要があり、リクエストごとにそのプロセスを起動してその実行結果を返すという流れで処理をします。

 CGIPHPの処理結果をWebサーバに返すためにはCGIという仕組みでやり取りをします。
CGIはCommon Gateway Interfaceの略で、Webサーバーとスクリプト言語(PHPなど)間でデータを受け渡すためのインターフェースです。
CGIの仕様はRFCで定義され、この仕様に基づいて作成されたプログラムを「CGIプログラム」と呼びます。

 FastCGIとはCGIではリクエストの都度プログラムのプロセスを起動して処理を行うため、低トラフィックでは問題になりませんが、アクセスが増えると プロセス生成コストがボトルネックになります。
そこであらかじめ常駐プロセスとしてCGIプログラムを起動させておくことで、より高速に結果を返せるようにしたものがFastCGIという仕組みになります。

 PHP-FPMとはPHP-FPMとは、「PHP FastCGI Process Manager」の略で、FastCGIの仕組みでPHPを実行するための管理システムです。
PHP-FPMのプロセス構成は、主に次の2種類に分かれます。

マスタープロセス：全体の管理を行う親プロセス

ワーカープロセス：実際にPHPスクリプトを実行する子プロセス
php-fpm.conf の設定に従ってプロセスを管理し、スケーリングの挙動などを調整して利用します。
pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
なお、min(max)_spare_serversは待機中として確保するプロセス数を表します。待機中のプロセス数に応じて常駐させるプロセス数をマスタープロセスが管理します。
なお、各リクエストをphp-fpmのプロセスに振り分けるためには、NginxなどのWebサーバを別途準備する必要があります。

 OPcacheによる高速化
PHPはスクリプト実行時に以下のような処理を行います：
.phpファイルを読み込む
ファイル内容をパースしバイトコード（オペコード）にコンパイル
スクリプト実行エンジンで処理
OPcacheは、このバイトコード（オペコード）をPHP-FPMのメモリ空間にキャッシュし、以降のリクエストで 再コンパイルなしで即実行できるようにする仕組みです。
これによりプロセス起動コストだけでなくコンパイルのコストも減らすことでさらに高速にリクエストを処理することができるようになります。

 PHP-FPMとフレームワークの起動コスト実際の開発ではLaravelなどのフレームワークを利用して開発することが多いかと思います。
Laravelのようなフレームワークでは、たとえバイトコードがOPcacheによりキャッシュされていても、毎リクエスト時に環境設定の読み込み、サービスプロバイダの登録、依存関係の解決、ルーティング構築といった初期化処理が行われます。
Laravelの場合は、リクエストを受け付けるとまず public/index.php が呼び出されますが、そのたびにアプリケーションの土台を組み立てる処理が毎回発生することになります。

 Laravel OctaneとはPHP-FPMではPHP実行環境のみ常駐プロセスとして処理をしますが、Laravel Octaneを利用すると、Laravelアプリケーション自体を常駐プロセスとして扱い、リクエストごとに発生する初期化処理を省略できます。それによりリクエストごとに行っていた初期化を短縮し高速でリクエスト処理ができるという特徴があります。
なお、OctaneはSwooleやRoadRunnerといったサーバー常駐型ランタイム上で動作します。
また、FrankenPHPは独立した統合PHP実行環境であり、 PHP実行環境そのものにWebサーバー機能が内蔵されていて、CGIのような中間インターフェースの実装がありません。常駐プロセスはFrankenPHPなどのサーバーによって行われており、FrankenPHPとOctaneを組みあわせる構成の場合、PHP-FPMを使う従来の構成とは異なり、NginxなどのWebサーバーを別途準備する必要はありません。

 まとめ
上記のように、PHPの実行環境は「リクエスト都度にスクリプト起動」から「アプリケーションがプロセスとして常駐する」というように、パフォーマンス課題に向き合いながら進化してきました。
また、WebサーバーとPHPのプロセスが統合されるように進化しており、FrankenPHPなど新しい実行環境が生まれてきました。
2025年5月にPHP FoundationがFrankenPHPを公式にサポートすると発表しており、Webサーバーと統合されたプロセス常駐型のPHP実行環境は今後主流になっていくと考えられそうです。
https://thephp.foundation/blog/2025/05/15/frankenphp/
次回は、FrankenPHPにどういった特徴やメリット、導入にあたっての懸念があるのかを調査しまとめていきたいと思います。