OPcacheプリローディングの深淵：共有メモリ（SHM）とZend VMの物理的制約を制する者
コードレビューをしていて、いつまでも「プリロードを入れておけば万全だ」などと幻想を抱いているジュニアや中堅のエンジニアを見ると、私は深く溜息をつく。
彼らはOPcacheをただの「コードキャッシュ機能」だと思い込んでいる。しかし、PHP 7.4で導入され、近年のバージョンでさらに洗練されたOPcacheプリローディング（Preloading）の本質は、OSのメモリ管理機構（mmap）とZendエンジン内部のデータ構造（HashTableやZend関数テーブル）を完全にハックし、プロセス間でのメモリ共有（Shared Memory）を強制する危険かつ強力なシステムだ。
今回は、このプリローディングが裏側のOSレベルやZend VMのメモリ空間（ZendMM）で何を引き起こしているのか、その物理的制約とパフォーマンスへの影響を、徹底的な低レイヤの視点から解き明かしていく。
—
1. Zend VMの裏側：なぜプリロードは「速い」のか？
通常、PHP-FPMの各ワーカープロセスは、リクエストを受け取るたびに、あるいはプロセス起動時にスクリプトを読み込み、レキシカル解析（Lexer）と構文解析（Parser）を経て、Zendオペコード（Opcode）へとコンパイルする。コンパイルされたオペコードはOPcacheの共有メモリ（Shared Memory: SHM）にキャッシュされるため、2回目以降のパースコストはスキップされる。
しかし、ここには重大なボトルネックがある。それが「シンボルテーブルの解決（Linking）」と「永続化（Permanent Allocation）」だ。
通常のOPcache環境であっても、リクエストを処理する各FPMワーカープロセスは、共有メモリ上のオペコードを参照しつつも、実行時に自身のローカルなメモリ空間（プロセスヒープ）へクラス定義や関数、定数をコピー（あるいはプロセス固有のテーブルへのマッピング）する必要がある。数千のクラスを持つ巨大なフレームワーク（SymfonyやLaravelのフルスタックなど）を動かす場合、このシンボル解決のオーバーヘッドは無視できない。
プリローディングがもたらすパラダイムシフト
`opcache.preload`ディレクティブによって指定されたスクリプトは、FPMマスタープロセスが起動した「リクエストを受け付ける前」の段階で実行される。
ここで何が起きるか。
1. マスタープロセスが対象スクリプトを読み込み、コンパイルする。
2. すべてのクラス、関数、定数をZendエンジンの永続メモリ（Persistent Allocation）へと昇格させる。
3. マスタープロセスがfork（フォーク）され、子プロセス（ワーカー）が生成される。
Linuxの `fork()` システムコールは、Copy-On-Write (COW) メカニズムを利用する。つまり、マスタープロセスがメモリ上に展開・リンクしきった巨大なクラス定義のツリー構造は、そのまま子プロセス群に物理メモリ上の同一アドレス空間として継承される。ワーカープロセスは、親が構築したシンボルテーブルを「追加のコピーコストゼロ」でそのまま共有できるのだ。これが、プリロードが圧倒的なスループットとレイテンシの改善をもたらす真の理由である。
—
2. 共有メモリの物理的制約と「COW破り」の悪夢
だが、甘い話には必ず代償がある。マルチプロセス環境における共有メモリの扱いを誤れば、パフォーマンスが向上するどころか、メモリリーク、OOM Killerによるプロセス絶命、あるいは深刻なデータ競合を引き起こす。
共有メモリの枯渇と `opcache.memory_consumption`
OPcacheの共有メモリは、`shm_open` や `mmap(MAP_ANONYMOUS | MAP_SHARED)` などを通じてOSから一括確保される。プリローディングを行う場合、すべてのクラス定義や静的プロパティの初期値がこの共有領域に常駐するため、従来のメモリサイズ設定では確実に不足する。
もし設定値を超過した場合、OPcacheは「Out of Memory」エラーを吐き、プリロード処理は途中でアボートする。それだけならまだマシで、最悪なのは、不完全な状態で起動したFPMワーカーがセグメンテーション違反（Segfault）を引き起こしてクラッシュし続ける地獄絵図だ。
「書き込み時コピー（COW）」の罠：静的プロパティの爆弾
ここからが最も重要な知見だ。Zendエンジンにおいて、クラスの静的プロパティ（static properties）は、プリロード時にどのように扱われるだろうか？
実は、プリロードされたクラスの静的プロパティは、共有メモリ上に配置される。しかし、PHPは動的言語である。もしワーカープロセスがリクエスト処理中にその静的プロパティの値を書き換えたらどうなるか？
OSのCOW機構により、そのページ全体がプロセス固有のプライベートメモリへとコピーされる（COW破り）。
結果として何が起きるか：
1. 共有メモリのメリット（メモリの節約）が完全に失われる。
2. 書き換えられた状態がそのワーカープロセス内に残り続け、「Keep-Aliveしているコネクションの次以降のリクエスト」や「次のリクエストに割り振られた時」に予期せぬ副作用（状態の汚染・バグ）をもたらす。
したがって、プリロード対象のコードを書く際、「ミュータブル（変更可能）な静的プロパティを持つクラス」をプリロードしてはならないという鉄則が生じる。
—
3. 実務で耐えうる堅牢なプリロード設計とリファレンスコード
この理論を踏まえ、実務の現場で安全かつ極限まで最適化されたプリロードスクリプトの設計を提示する。
以下のスクリプトは、単にファイルをインクルードするだけの粗悪なものではない。メモリの肥大化を防ぎつつ、ディレクトリトラバーサルや動的インクルードの破綻を防ぐための「堅牢なフィルタリング機構」を備えている。
/
declare(strict_types=1);
namespace Core\Optimization;
rtrim($appRoot = ‘/var/www/html’, ‘/’);
// 1. プリロード対象外とするべき「ミュータブルな状態を持つ」コンポーネントのブラックリスト
// （セッションハンドラ、リクエスト固有の状態を保持するシングルトンなど）
const PRELOAD_BLACKLIST = [
// 例: 状態を持つカスタムセッションハンドラ
\App\Session\DatabaseSessionHandler::class,
// 例: グローバルな実行コンテキストを持つサービス
\App\Context\RequestContext::class,
];
/
- 再帰的にディレクトリを走査し、安全にクラスをロードする
- @param string $directory 対象の絶対パス
- @return void
/
$safePreload = static function (string $directory) use (&$safePreload, $appRoot): void {
if (!is_dir($directory)) {
return;
}
$iterator = new \RecursiveIteratorIterator(
new \RecursiveDirectoryIterator($directory, \RecursiveDirectoryIterator::SKIP_DOTS),
\RecursiveIteratorIterator::LEAVES_ONLY
);
foreach ($iterator as $file) {
if (!$file->isFile() || $file->getExtension() !== ‘php’) {
continue;
}
$filePath = $file->getRealPath();
// テストコードや開発用スクリプトは絶対に混入させない
if (str_contains($filePath, ‘/tests/’) || str_contains($filePath, ‘/var/’)) {
continue;
}
// ファイルを評価してクラス/インターフェースをロード
// 注意: require_once はトップレベルでのみ安全に機能する
try {
require_once $filePath;
} \Throwable $e {
// ログに吐き出しつつ、マスタープロセスの起動自体は止めないフォールバック設計
// （本番環境のデプロイメントの揺らぎに耐えるため）
error_log(sprintf(‘[Preload Error] Failed to load %s: %s’, $filePath, $e->getMessage()));
continue;
}
}
};
// 2. コアフレームワーク層のプリロード（不変な定義群）
$frameworkCorePath = $appRoot . ‘/vendor/framework/core’;
if (is_dir($frameworkCorePath)) {
$safePreload($frameworkCorePath);
}
// 3. アプリケーションのドメインモデル・サービスクラス層のプリロード
$appDomainPath = $appRoot . ‘/src/Domain’;
if (is_dir($appDomainPath)) {
$safePreload($appDomainPath);
}
// 4. ブラックリストに該当するクラスの静的整合性チェック
foreach (PRELOAD_BLACKLIST as $blacklistedClass) {
if (class_exists($blacklistedClass, false)) {
trigger_error(
sprintf(‘Fatal Architecture Violation: Blacklisted class “%s” was accidentally preloaded.’, $blacklistedClass),
E_USER_ERROR
);
}
}
// 5. 統計情報のログ出力（CLI経由でのデバッグ用）
if (PHP_SAPI === ‘cli’) {
$status = opcache_get_status(true);
if ($status && isset($status[‘preload_statistics’])) {
printf(
“[OPcache Preload] Success. Memory used: %d bytes, Scripts loaded: %d\n”,
$status[‘preload_statistics’][‘memory_consumption’] ?? 0,
count($status[‘preload_statistics’][‘scripts’] ?? [])
);
}
}
—
4. チーフアーキテクトからの実務における警鐘
このコードと仕組みを導入するにあたり、最後に以下の3点を頭に叩き込んでおいてほしい。これらは障害対応の現場で幾度となく私を悩ませた教訓だ。
1. デプロイメント時の「ファイルロック」と「再起動の罠」
OPcacheプリロードを使用している環境では、ソースコードを書き換えても、FPMマスタープロセスをリロード（`systemctl reload php-fpm`）しない限り、変更が絶対に反映されない。CI/CDパイプラインにおいて、デプロイ時にFPMのリロードステップが抜けていると、古いプリロードコードと新しいコードの間で不整合（致命的な型エラーやメソッド不存在エラー）が起きてシステムが沈黙する。自動化スクリプトには必ずFPMのリロードを組み込むこと。
2. JIT（Just-In-Time Compiler）とのシナジー
PHP 8以降ではJITコンパイラが利用できるが、JITはOPcacheの共有メモリ空間上のオペコードをネイティブマシン語に翻訳する。プリローディングによってコードが綺麗にメモリ上に永続化されている状態こそが、JITが最も効率よく機能する理想郷である。JITのヒット率を最大化したければ、プリロードの設計を妥協してはならない。
3. 「とりあえず全部プリロードする」の愚行
すべてのファイルをプリロードすれば速くなるというのは素人の発想だ。使われないコードまで共有メモリに載せれば、メモリプレッシャーが高まり、OSのスワップやOPcacheの断片化（Fragmentation）を招く。「ホットパス（頻繁に実行されるコードパス）に存在する不変のクラス群」だけを厳選してロードすることこそが、真に洗練されたWebシステムアーキテクチャの姿である。
低レイヤの物理制約を理解し、Zend VMの挙動をコントロールする――それこそが、単なる「PHPプログラマ」から「本物のシステムアーキテクト」へと脱皮するための唯一の道である。