OPcacheプリローディングの物理構造とプロセス間共有メモリ：Zend Engineが隠蔽するメモリ永続化の真実
PHPは「リクエストごとに全プロセスが破棄され、何事もなかったかのようにクリーンな状態で次のリクエストを処理する」という美しい思想のもとに設計された。このライフサイクルは、Webアプリケーションにおけるメモリリークの悪夢から開発者を救い続けてきた。
しかし、現代の大規模なフレームワーク（SymfonyやLaravelなど）が抱えるコードベースの肥大化は、この「毎リクエストのコンパイルとファイルI/O」というコストを無視できないボトルネックに変えた。このパラダイムの壁をブチ破るために存在するのが OPcacheプリローディング（Preloading） である。
本稿では、Zend Engineの内部メモリ管理、SHM（Shared Memory：共有メモリ）の物理的制約、そしてそれがパフォーマンスとセキュリティに与える影響について、低レイヤの視点から一切の妥協なく解き明かす。
—
1. Zend VMとOPcacheのライフサイクル：リクエスト境界の消滅
伝統的なPHP-FPMの実行モデルでは、1つのリクエストが到着すると以下のフェーズが走る。
1. Lexing（字句解析）: ソースコードをトークンに分解。
2. Parsing（構文解析）: AST（抽象構文木）を構築。
3. Compilation（コンパイル）: ASTをZend VMが実行可能な Opcode（オペコード） に変換。
4. Execution（実行）: VMがOpcodeを順次評価。
リクエストが終了すると、プロセスに割り当てられたヒープメモリは解放され、コンパイルされたOpcodeのキャッシュ（OPcache）を除き、すべての状態がリセットされる。
プリローディングの本質：永続化（Persistent Allocation）
PHP 7.4で導入されたプリローディングは、サーバーの起動時（`php-fpm` のマスタープロセス起動時）にあらかじめ指定されたスクリプト群を読み込み、コンパイルし、永続的な共有メモリ（SHM）領域に固定化（Permanent Allocation）する機能だ。
通常のOPcacheは、SHM内のキャッシュが一杯になるとLRU（Least Recently Used）アルゴリズムで古いOpcodeを追い出す（Eviction）。しかし、プリロードされたスクリプトは 「決して解放されない不滅の存在」 としてマークされる。
+————————————————————-+
| Master Process (PHP-FPM) |
| 1. サーバー起動時に preload.php を実行 |
| 2. ASTからOpcodeを生成 |
| 3. 共有メモリ(SHM)へ永続配置 (Immutable) |
+————————————————————-+
|
| fork() （Copy-on-Writeによるメモリ共有）
v
+—————————–+ +—————————–+
| Worker Process A | | Worker Process B |
| – 永続化されたOpcodeを共有 | | – 永続化されたOpcodeを共有 |
| – リクエスト固有のヒープ | | – リクエスト固有のヒープ |
+—————————–+ +—————————–+
この仕組みにより、ワーカープロセスは `include` や `require` を行うことなく、メモリ上のOpcodeにダイレクトにアクセスできる。ファイルシステムへのアクセス（`stat()` システムコールによるタイムスタンプ確認すら不要）は完全にバイパスされる。
—
2. プリローディングにおけるメモリの物理構造とZend Type
プリローディングの恩恵を語る前に、Zend Engineがメモリ上でそれをどう表現しているかを知る必要がある。
PHPの内部では、クラス定義、関数定義、定数などはすべて `zend_class_entry` や `zend_function` といった巨大なCの構造体（Struct）としてヒープ上に構築される。通常のOPcacheはこれらをSHMにキャッシュするが、クラス間の依存関係やインターフェースの解決（Linking）はリクエストごと、あるいはキャッシュヒット時に行われる。
しかし、プリローディングでは、起動時にすべてのクラスの 完全なリンク（Linking） が行われる。
- 親クラスの解決
- インターフェースの実装確認
- トレイトの平坦化（Trait Flattening）
- 関数ポインタのバインド
これらがすべて完了した状態で、メモリイメージがそのままSHMに焼き付けられる。
危険な罠：`persistent` 領域の永続化とメモリリークの不可逆性
ここで重大な問題が生じる。Zend Engineのメモリマネージャー（ZMM）は、通常の割り当てには `emalloc()`（Request-bound）を使用し、永続的な割り当てには `pemalloc(…, 1)`（Persistent）を使用する。
プリロードスクリプト内で生成されたデータが `pemalloc` によってSHMに配置されると、それはマスタープロセスのライフサイクルと一体化する。もしプリロードのコードに不備があり、不要な巨大配列やオブジェクトがグローバルスコープで永続化された場合、それは すべてのFPMワーカープロセスが恒久的に抱え込むメモリ肥大化（Bloat） となる。
さらに恐ろしいのは、一度プリロードされたクラスや関数は、実行中に再定義・上書き・アンロードできない点だ。開発環境でプリローディングを有効にすると、コードを変更しても反映されないのはこのためである（ファイル変更検知の `opcache.revalidate_freq` はプリロード領域には適用されない）。
—
3. プロセス間共有メモリ（SHM）の物理的制約とパフォーマンス影響
OPcacheの共有メモリは、OSの仕組み（System V IPC または POSIX Shared Memory、あるいは `mmap`）を利用して確保される。ここに潜む物理的な制約が、パフォーマンスに決定的な影響を与える。
1. NUMA（Non-Uniform Memory Access）アーキテクチャの壁
マルチソケットの物理サーバー（例: 2基のXeonやEPYCプロセッサを搭載したサーバー）では、NUMAアーキテクチャが採用されている。CPUソケットごとに割り当てられたメモリコントローラーがあり、自ソケットから遠いメモリ（リモートメモリ）にアクセスする場合、レイテンシが増大する。
OPcacheのSHMが特定の物理メモリ領域に偏って配置され、それを別のソケットで稼働しているPHP-FPMワーカーが頻繁に参照する場合、バスの帯域幅がボトルネックとなり、キャッシュヒット率が高いにもかかわらずCPU待機時間（Stall cycles）が増加するという現象が発生する。
2. TLB（Translation Lookaside Buffer）ミスの爆発
プリローディングによって数千のクラスファイルがメモリ上に展開されると、コードとデータのフットプリント（占有容量）が巨大化する。
CPUのMMU（Memory Management Unit）が仮想アドレスを物理アドレスに変換する際に使用するTLBのキャッシュエントリが溢れ、TLBミスの頻度が急増する。
特に、巨大なモノリスアプリケーションで何万ものメソッドがランダムに呼び出される環境では、L1/L2インストラクションキャッシュのヒット率が低下し、命令のフェッチレイテンシが悪化する。
「ファイルを読み込まなくてよくなったのに、なぜかCPU使用率が張り付く」という現象の多くは、このTLBミスとキャッシュミスの複合要因によるものである。
—
4. 実践：安全かつ極限まで最適化されたプリロードスクリプトの構築
理論を頭に叩き込んだところで、実務で使える堅牢なプリロードスクリプトの設計を示す。
無計画にフレームワーク全体を読み込むのではなく、依存関係の順序を厳密に制御し、不要なメモリ消費を防ぐコードを書く必要がある。
/
declare(strict_types=1);
// プリロード対象のベースディレクトリ
$baseDir = __DIR__ . ‘/src’;
if (!file_exists($baseDir)) {
// 存在しない場合は安全に終了（マスタープロセスのクラッシュを防ぐ）
return;
}
$iterator = new RecursiveIteratorIterator(
new RecursiveDirectoryIterator($baseDir, FilesystemIterator::SKIP_DOTS),
RecursiveIteratorIterator::LEAVES_ONLY
);
$loadedFilesCount = 0;
$startTime = microtime(true);
foreach ($iterator as $file) {
if ($file->isFile() && $file->getExtension() === ‘php’) {
$filePath = $file->getRealPath();
// 例外処理や動的コンポーネント、インターフェースを持たないデータ構造体など、
// プリロード不向きなファイルをここでホワイトリスト/ブラックリストフィルタリング
if (str_contains($filePath, ‘/Migrations/’) || str_contains($filePath, ‘/Tests/’)) {
continue;
}
// Zend VMへOpcodeとしてコンパイルし、SHMへ永続化
// 注意: require_once はコンパイルと同時に実行（評価）まで行うため、
// 副作用（グローバル空間での変数代入やDB接続など）のあるコードは絶対に避けること。
try {
require_once $filePath;
$loadedFilesCount++;
} catch (\Throwable $e) {
// マスタープロセスが死ぬとPHP-FPM全体が起動不能になるため、厳重にキャッチする
error_log(sprintf(
‘[OPcache Preload Fatal] Failed to preload %s: %s’,
$filePath,
$e->getMessage()
));
}
}
}
$duration = microtime(true) – $startTime;
$memoryUsage = memory_get_usage(true);
// 起動ログにメトリクスを残し、CI/CDや監視システムで追跡できるようにする
error_log(sprintf(
‘[OPcache Preload Success] Preloaded %d files in %.4f seconds. Memory peak: %d bytes.’,
$loadedFilesCount,
$duration,
$memoryUsage
));
アーキテクトの警告：`require_once` の副作用
上記のコードで最も重要なのは 「`require_once` はファイルを読み込むだけでなく、トップレベルのコードを実行する」 という点だ。
もしプリロード対象のファイル内に、関数やクラスの定義だけでなく、以下のようなコードが含まれていた場合、それらはマスタープロセスのコンテキストで一度だけ実行される。
- グローバル変数への代入
- 定数の定義（`define()`）
- 意図しないファイルI/Oや設定ファイルの読み込み
これがワーカープロセスに `fork()` された際、予期せぬ状態の共有（あるいはCopy-on-Writeによる無駄なメモリ消費）を引き起こす原因となる。プリロードするスクリプトは、「純粋なクラス・インターフェース・トレイト・関数の定義のみ」で構成されていなければならない。
—
5. 脆弱性の影：プリロード領域とオブジェクトインジェクションの脅威
最後に、セキュリティの観点からプリローディングが持つダークサイドに言及しなければならない。
PHPのセキュリティにおいて、PHPオブジェクトインジェクション（PHP Object Injection） は最も危険な脆弱性の一つである。ユーザー入力を `unserialize()` に渡してしまうことで、攻撃者は任意のクラスのインスタンスを復元し、マジックメソッド（`__destruct()`, `__toString()` など）を起点とした Gadget Chain（ガジェットチェーン） を構築し、リモートコード実行（RCE）を達成する。
通常、この攻撃の成否は「ターゲットとなるクラスがスコープ内に存在するか（オートローダーによって読み込まれるか）」に依存する。
プリローディングがもたらすアタックサーフェスの拡大
OPcacheプリローディングを導入すると、アプリケーション内のすべてのクラス定義が常にメモリ上に常駐し、オートロードの必要すらなくなり、いつでもインスタンス化可能な状態になる。
これは何を意味するか？
攻撃者が任意のアプリケーションからガジェットを探す際、通常なら実行経路に含まれないためオートロードされない「隠しクラス」や「レガシーなヘルパークラス」であっても、プリロードされていれば 無条件で攻撃のパーツ（Gadget）として利用可能になる。
さらに、プリロードされたクラスのプロパティやデフォルト値は、マスタープロセスのメモリ空間に固定化されている。もし、何らかのメモリ破損脆弱性（PHP本体や拡張モジュールのバグ）が存在した場合、共有メモリ領域の改ざんを通じて、すべてのワーカープロセスの挙動を一瞬で掌握されるリスクが理論上存在する。
—
総括
OPcacheプリローディングは、適切に運用すれば、高トラフィックなWebアプリケーションのレイテンシを劇的に削減する最強の武器となる。しかし、それはZend Engineの内部メモリ構造、共有メモリの物理的制約、そしてライフサイクルのルールを完璧に理解しているエンジニアにのみ、その真価を発揮する。
「とりあえず動くからプリロードを有効にする」というアプローチは、やがて原因不明のメモリ肥大化や、テスト環境と本番環境の挙動の乖離という技術的負債として跳ね返ってくる。
コードの1行、メモリの1バイトが、OSとハードウェアのどのレイヤで処理されているか。その解像度を持ち続けることこそが、真のWebシステムアーキテクトの条件である。