こんにちは。日々の開発や本番環境のチューニング、本当にお疲れ様です。
他のモダンな言語やフレームワークを深く知っているあなたなら、PHPの「1リクエストごとにプロセスが破棄され、ゼロからすべてを初期化する」という潔い（そしてかつては非効率と言われた）アーキテクチャに、最初は驚いたかもしれませんね。
しかし、近年のPHPは、OPcacheの進化によって劇的な変貌を遂げました。特に「OPcacheプリローディング（Preloading）」を使いこなせるようになると、PHPは単なる「リクエストごとのスクリプト実行エンジン」から、メモリ上に永続化された巨大なクラス構造を持つ高効率なアプリケーションプラットフォームへと生まれ変わります。
今回は、このOPcacheプリローディングが裏側のエンジン（Zend VM）でどのようにメモリを永続化し、OSの共有メモリ空間（SHM）をどう揺さぶるのか、その物理的な制約とパフォーマンスへの影響を一緒に紐解いていきましょう。ここを理解すると、PHPの裏側の挙動がくっきりと見えてきますよ。
—
1. 従来のOPcacheと「プリローディング」の決定的な違い
まずは、これまでのOPcacheが何をしていて、プリローディングが何を変えたのかをZendエンジン（Zend VM）のメモリ管理の観点から整理しておきましょう。
通常のOPcacheの挙動
通常、OPcacheはPHPスクリプトをパースして生成されたオペコード（Opcode）を共有メモリ（Shared Memory）にキャッシュします。
しかし、リクエストが来ると、Zendエンジンはキャッシュからオペコードを読み出し、リクエスト固有のシンボルテーブル（変数や関数名のマップ）を構築し、クラスや関数の定義を「現在のプロセス空間」にバインドする作業を行います。数千ものクラスを持つ巨大なフレームワーク（SymfonyやLaravelなど）では、この「ファイルを探して、パースして、キャッシュからシンボルを復元して…」という一連の処理が、毎リクエストのわずかなオーバーヘッドとなって積もり積もっていました。
プリローディングの魔術
PHP 7.4で導入されたプリローディングは、「PHP-FPMのマスタープロセス起動時に、指定したコードを完全に実行し、生成されたすべてのクラス、関数、定数を永続的な共有メモリに永久に焼き付けてしまう」仕組みです。
リクエストが到達した瞬間、すでにすべてのクラス構造（`zend_class_entry`）はメモリ上に構築されており、プロセスはそれを「参照」するだけになります。ファイルI/Oは完全にゼロになり、シンボルテーブルの構築コストも消え去ります。
—
2. 内部構造：永続化メモリ（Persistent Allocation）の正体
では、このプリローディングされたデータは、物理的にどこに存在し、どのように管理されているのでしょうか。
Zendエンジンは、メモリ割り当てを行う際に `emalloc()`（リクエスト単位で解放されるメモリ）と `pemalloc()`（永続的なメモリ）を使い分けています。OPcacheのプリローディングによってロードされたデータは、すべて後者の 永続的共有メモリ（Shared Memory Segment） に配置されます。
[ OS 共有メモリ空間 (SHM) ]
├── OPcache オペコードキャッシュ
└── プリローディング領域 (永続化された zend_class_entry / 関数テーブル)
│
├── [FPM Child Process A] ──(Copy-on-Writeで参照)
├── [FPM Child Process B] ──(Copy-on-Writeで参照)
└── [FPM Child Process C] ──(Copy-on-Writeで参照)
ここで重要なのが、Linuxの Copy-on-Write（COW：書き込み時コピー） メカニズムです。
マスタープロセスが起動時にプリロードしたクラス群は、すべてのFPM子プロセス間で物理的なメモリページとして共有されます。子プロセス側でこれらのクラスのメソッドを呼び出したりプロパティを参照したりする分には、メモリの複製は一切発生しません。数MB〜数十MB規模のフレームワークのコアが、プロセス間で完全に共有されるため、実質的なメモリフットプリント（RSS）が劇的に削減されるのです。
—
3. 実践：プリローディングスクリプトの設計と罠
言葉だけではイメージしにくいと思いますので、実際に本番環境で耐えうる堅牢なプリローディングスクリプトの書き方を見てみましょう。
/
// 1. ロード対象のベースディレクトリを定義
$baseDir = ‘/var/www/html’;
// 2. プリロード対象のファイルを安全にイテレートする
// 注意: すべてのファイルをロードするとメモリを食いつぶすため、コアなクラスに絞るのが定石です。
$directory = new RecursiveDirectoryIterator($baseDir . ‘/src’, RecursiveDirectoryIterator::SKIP_DOTS);
$iterator = new RecursiveIteratorIterator($directory);
foreach ($iterator as $file) {
if ($file->getExtension() === ‘php’) {
$filePath = $file->getRealPath();
// 抽象クラスやインターフェース、依存関係の深いコアサービスを優先的に読み込む
// ※ 実際に opcache_compile_file を使うことで、実行（eval等）せずにオペコード化して永続化できます。
if (file_exists($filePath)) {
// opcache_compile_file は構文エラーがあると致命的なエラーになるため厳重に扱う
if (!opcache_compile_file($filePath)) {
trigger_error(“Preloading failed: {$filePath}”, E_USER_WARNING);
}
}
}
}
ここに注意！ プリローディングの物理的制約と「罠」
非常に強力なプリローディングですが、アーキテクトとして知っておくべき致命的な物理的制約がいくつかあります。
1. コードを変更したらPHP-FPMの再起動が必須
一度共有メモリに焼き付けられたクラスは、ファイルが書き換えられても自動的には更新されません。「コードをデプロイしたのに挙動が変わらない！」というバグの多くは、OPcacheのクリア忘れ、あるいはプリロードされたコードが古いまま残っていることが原因です。CI/CDパイプラインには必ず `systemctl reload php-fpm` を組み込む必要があります。
2. メモリリークと「死のプロセス」
プリロードされたクラスのプロパティに動的なデータを保持させようとすると、それがすべてのプロセス、すべてのリクエスト間で共有されてしまい、意図しないデータ共有（セッション汚染のような状態）や深刻なメモリリークを引き起こします。プリロードするクラスは、「状態を持たない（Stateless）純粋な構造体・サービス」に限定しなければなりません。
3. 共有メモリ（SHM）の枯渇
`php.ini` の `opcache.memory_consumption` の設定値を超えてプリロードを行おうとすると、エンジンは途中でロードを打ち切り、警告を出して起動します。結果として一部のクラスだけがロードされ、実行時エラー（Class not found）の原因になります。
—
4. パフォーマンスへの影響：トレードオフをどう見極めるか
最後に、このプリローディングが実際のWebアプリケーションのパフォーマンスにどう影響するか、アーキテクトとしての判断基準をお伝えします。
| 評価軸 | メリット | デメリット・リスク |
| :— | :— | :— |
| レイテンシ（TTFB） | ファイルI/Oの消滅とシンボルテーブル構築コストの削減により、リクエスト処理の初動が数ミリ秒単位で高速化。 | なし（恩恵のみ） |
| メモリ効率 | FPM子プロセス間でのCopy-on-Writeによる物理メモリ（RAM）の節約。 | 設定を誤るとメモリを圧迫し、OOM Killerの標的に。 |
| デプロイ運用 | 大規模フレームワークのウォームアップ時間が完全にゼロに。 | コード変更時にFPMの再起動が必須となり、デプロイ手順が厳格化する。 |
小規模なアプリケーションや、エンドポイントが数個しかないAPIサーバーであれば、OPcacheの標準的なキャッシュだけで十分なパフォーマンスが出ます。プリローディングという重い扉を開けるべきなのは、「数千のクラスを持ち、フレームワークのロードだけでCPUサイクルを消費している中規模〜大規模なWebアプリケーション」です。
—
まとめ：PHPの裏側を掌握する
いかがでしたでしょうか？
OPcacheプリローディングは、単なる「便利な設定項目」ではなく、OSのメモリ管理（SHMとCOW）とZendエンジンのライフサイクルを直接結びつける高度なアーキテクチャです。
「なぜこの設定が必要なのか」「裏でメモリはどう動いているのか」をここまで解像度高く理解していれば、万が一の本番障害時にも迷うことなく原因を特定できるはずです。
あなたのPHPアプリケーションが、限界を超えた高速性と堅牢性を手に入れるためのヒントになれば幸いです。それでは、また次の深淵でお会いしましょう。