OPcacheプリローディングと共有メモリの深淵：Zend VMの物理構造をハックする
PHPは長らく「リクエストライフサイクルごとの全破棄」という潔いメモリモデルによって、メモリリークの恐怖からWebアプリケーションを解放してきた。リクエストが終息すれば、Zend Engineが管理するヒープ領域はOSへ返還され、`zend_execute_ex` が刻んだ痕跡はきれいさっぱり消え去る。
だが、モダンなフレームワークが数千のクラスファイルとアノテーションを抱える現代において、毎リクエスト数千ファイルのディスクI/O、レキシカル解析、パース、そしてAST（抽象構文木）からZend OPcodeへのコンパイルを繰り返すコストは、CPUサイクルとI/Oバスに対する暴力に他ならない。
ここで登場するのが OPcacheプリローディング（Preloading） である。これは、PHPのライフサイクルそのものを根本から変異させ、親プロセス（PHP-FPM Master）の段階で全コードをコンパイルし、OSの共有メモリ（SHM）へ永久に焼き付ける禁断の最適化技術だ。
本稿では、Zend VMの内部構造、OPcacheのメモリマッピング、プロセス間共有の物理的制約、そしてこの強大な機構が孕むセキュリティ上の致命的な罠（Gadget Chainの永続化）まで、妥協なき低レイヤの視点から解き明かす。
—
1. Zend VMの血肉：OPcacheプリローディングの物理構造
PHPスクリプトが実行されるとき、Zend Engineはソースコードをトークン化し、ASTに組み立て、最終的にZend VMが解釈実行可能なオペコード（Opcode）の配列へと変換する。
通常のOPcacheは、このコンパイル済みオペコードを共有メモリ（`opcache.memory_consumption`）にキャッシュする。しかし、ファイル変更の検知（`opcache.revalidate_freq`）やキャッシュの有効性確認という「動的なオーバーヘッド」が微かに残る。
プリローディングはこれを極限まで排除する。`php.ini` の `opcache.preload` に指定されたスクリプトは、PHP-FPMの起動時（`post-fork` の前）に一度だけ実行され、読み込まれたすべてのクラス、関数、定数は、一切の有効性確認を剥ぎ取られた状態で共有メモリへ恒久的に固定（Persisted）される。
; php.ini の極限チューニング例
opcache.enable=1
opcache.memory_consumption=512
opcache.interned_strings_buffer=64
opcache.max_accelerated_files=100000
opcache.preload=/var/www/html/config/preload.php
opcache.preload_user=www-data
この時、メモリ上で何が起きているのか。Zend VMの内部構造体である `zend_class_entry` や `zend_function` は、通常リクエストごとにヒープ上にアロケートされるが、プリロードされたオブジェクト構造は、共有メモリ領域内の連続したアドレス空間に配置される。
プリロード構築スクリプトの実装パターン
isFile() && $file->getExtension() === ‘php’) {
$filePath = $file->getRealPath();
// OPcacheの内部関数により、強制的にコンパイル＆共有メモリへ永続化
// 実行時エラーを防ぐため、存在チェックと例外ハンドリングが必須
if (@include_once($filePath)) {
// デバッグ用標準出力（FPM起動ログに記録される）
// echo “Preloaded: {$filePath}\n”;
}
}
}
—
2. 共有メモリ（SHM）とCOW（Copy-on-Write）の幻想と現実
PHP-FPMのワーカープロセス（Child Process）は、マスタープロセスから `fork()` によって生成される。OSレベルの仮想記憶機構において、`fork()` 直後のプロセスは物理メモリ上のページを共有し、書き込みが発生した瞬間にコピーが走る Copy-on-Write (COW) の恩恵を受ける。
OPcacheの共有メモリは、この `fork()` の「前」に確保されるか「後」に確保されるかによって、その振る舞いが劇的に変わる。
共有メモリの配置とプロセス間共有のメカニズム
1. Shared Memory Segment (System V / mmap):
OPcacheが確保する共有メモリは、通常のプロセスヒープとは異なり、OSの `mmap(MAP_SHARED)` または `shmget` によって割り当てられた独立したアドレス空間である。
2. ポインタの不整合（Pointer Swizzlingの回避）:
共有メモリ内に格納される `zend_string` や `zend_function` などの構造体内部には、他のメモリ領域を指す「ポインタ」が含まれている。
もしプロセスごとに共有メモリのマップ先アドレス（仮想アドレス）が異なるとしたらどうなるか？ 幸いなことに、現代のOS（Linux）のASLRやmmapの挙動、およびOPcacheの設計により、全ワーカープロセスで同一の仮想アドレス空間に共有メモリがマッピングされるよう最適化されている。これにより、ポインタの書き換え（Pointer Swizzling）という重いコストを支払わずに済んでいる。
しかし、ここに 極限の罠 が潜む。
プリロードされたオブジェクトの「状態」は共有されるか？
もし、プリロードスクリプトの実行中に「インスタンス化（`new`）」まで行い、それを静的プロパティ（Static Property）に格納してしまったらどうなるか？
すべてのFPMワーカープロセスが同一のTCPソケットやファイル記述子（FD）を共有する という、マルチスレッド並みの悪夢が再現される。結果として、リクエスト並行処理時にパケットがインターリーブし、DB通信は完全に崩壊する。
> アーキテクトの教訓: プリロードできるのは「静的な構造（クラス定義、関数、定数、メソッドのオペコード）」のみである。「動的な状態（インスタンス、リソース）」を共有メモリに焼き込んではならない。唯一の例外は、イミュータブル（不変）であることが保証されたプリミティブな値の静的プロパティのみである。
—
3. FiberとOPcache：非同期コンテキストスイッチのメモリフットプリント
PHP 8.1で導入された Fiber（ファイバー） は、スタックフルな協調的マルチタスク（Coroutine）をPHPにもたらした。I/O待ちの間に他の処理へコンテキストをスイッチすることで、プロセス数を増やすことなくスループットを最大化する。
ここでOPcacheプリローディングとFiberがどのように交錯するのか。
Fiberが実行される際、Zend VMの実行コンテキスト（`zend_execute_data`）やコールスタックは、プロセス全体の巨大なヒープから切り離され、個別のヒープチャンク（ZendMMのallocator）上に動的に確保される。
[ PHP-FPM Worker Process ]
├── OPcache Shared Memory (Read-Only)
│ └── Preloaded Opcodes (Classes, Functions) [全プロセス共通]
└── Process Heap (ZendMM)
├── Request 1 Context
│ └── Fiber A Stack (Heap allocated)
└── Request 2 Context
└── Fiber B Stack (Heap allocated)
プリロードされたクラスのメソッドがFiber内で呼び出されるとき、オペコード自体は共有メモリ（Read-Only）上にあるため、CPUキャッシュヒット率は跳ね上がる。プロセス間でコード領域が完全に共有されているため、L1/L2/L3キャッシュのフットプリントが極小化され、キャッシュミス（Cache Miss）に起因するストールが劇的に減少する。
しかし、Fiberが大量に生成・破棄される非同期アーキテクチャでは、ZendMMの断片化（Fragmentation） が深刻な問題となる。プリロードによってベースラインのメモリ消費量が固定化されるため、ZendMMの空きチャンク管理アルゴリズムが不適切だと、長期間稼働するFPMプロセスでメモリリークに類似したメモリ肥大化が発生する。これを防ぐためには、`memory_limit` の適切な設定に加え、リクエスト数に応じた `pm.max_requests` の厳格な管理が不可欠となる。
—
4. 攻防の極限：OPcacheプリローディングとオブジェクトインジェクションの脅威
セキュリティの文脈において、OPcacheプリローディングは「両刃の剣」である。
通常、リモートコード実行（RCE）やオブジェクトインジェクション（PHP Object Injection）の脆弱性が存在する場合、攻撃者は未定義のクラスをオートローダー経由で読み込ませたり、既存のクラスのメソッドを悪用して Gadget Chain（ガジェットチェーン）を構築する。
しかし、アプリケーションがプリロードされている環境では、以下の脅威モデルが成立する。
1. ガジェットチェーンの「常時常駐」
プリロードによって、アプリケーション内の全クラスとメソッドがすでにメモリ上にロードされ、いつでも呼び出し可能な状態になっている。これは、攻撃者にとって 「攻撃に必要なパーツ（ガジェット）があらかじめ完璧に並べられたテーブル」 が用意されている状態に等しい。
2. クラス定義の改ざん不可能性と脆弱性の固定化
プリロードされたクラスは共有メモリ上に読み込まれ、通常は保護（Read-Only / Protect Pages via `mprotect`）されるため、実行時にクラス定義を書き換えるパッチ当て（Monkey Patchingなど）や動的な改ざんが極めて困難になる。
逆に言えば、脆弱性を含んだコードが一度プリロードされてしまうと、コードファイルを修正してファイルシステム上を書き換えても、FPMを再起動しない限り脆弱性がメモリ上に残り続ける。
クラス上書きの脆弱性（Class Redefinition Attack）に対する懸念
もしアプリケーション内に「ユーザーからの入力に基づいて動的にクラスをロードまたはインスタンス化する脆弱なロジック」が存在し、かつプリロード対象外の領域からクラスを持ち込む場合、Zend Engineは次のような挙動を示す。
防御の要諦：プリロードにおけるセキュリティ要件
1. 厳格なホワイトリスト運用:
プリロードスクリプト（`preload.php`）では、汎用的な `RecursiveDirectoryIterator` で全ファイルを呑み込むような雑な実装を避ける。フレームワークのコアや依存関係のうち、絶対に安全で、かつ実戦で使用されるものだけを明示的に指定してインクルードする。
2. `opcache.protect_memory=1` の有効化:
共有メモリ領域をOSレベルで読み取り専用（Read-Only）に強制し、バッファオーバーフロー等によるオペコードの書き換え攻撃を物理的にブロックする。
3. FPMプロセスの適切なライフサイクル管理:
CI/CDパイプラインでのデプロイメント時には、必ず `systemctl reload php-fpm` を実行し、古い共有メモリセグメントを完全に破棄して新しいオペコードへリフレッシュすることを自動化の絶対条件とする。
—
5. 結び：限界を突破するアーキテクトへ
OPcacheプリローディングとは、PHPという動的言語の皮を被った、静的コンパイル言語の極致である。
Zend VMのメモリ空間、OSの仮想記憶、プロセス間の共有メモリ、そしてCPUのキャッシュラインに至るまで、すべてのレイヤーを理解した者だけが、この機構から極限のパフォーマンスを引き出すことができる。
「動的だから遅い」という神話は、Zend Engineの内部構造を掌握したエンジニアの手によって過去のものとなった。メモリの物理的制約を直視し、コードの1バイト、ポインタの1つに至るまでデザインされたWebシステムこそが、真にスケーラブルで強靭なインフラストラクチャの基盤となる。