こんにちは。大規模なWebアプリケーションを支えるアーキテクチャの設計、日々お疲れ様です。
他の高水準言語、例えばJavaやNode.js、Goなどを深く経験されてきた優秀なエンジニアほど、PHPの世界に踏み込んだときに「なんだか裏側の仕組みがブラックボックスで不気味だ」と感じることが多いのではないでしょうか。「1リクエストごとにプロセスが破棄されるのに、なぜフレームワークがあんなに高速に動くのか」「メモリリークとは無縁のはずのPHPで、なぜメモリ管理を意識する必要があるのか」——。
今回は、そうした疑問の根幹であり、モダンPHPの高速化の切り札である「OPcacheプリローディングと共有メモリ（SHM）の物理的制約」について、Zend VMの内部挙動とOSのメモリマッピングのレイヤから紐解いていきましょう。
ここを理解すれば、PHPの裏側がまるで一枚の美しい絵画のようにクリアに見えてきますよ。
—
1. 伝統的なPHPのライフサイクルと、OPcacheがもたらしたパラダイムシフト
まず、私たちが普段書いているPHPスクリプトが、CPUで実行されるまでの基本のおさらいから始めましょう。
伝統的なCGI、あるいは初期のPHP-FPMの挙動において、1つのリクエストが飛んできたときのZendエンジンは、以下のような過酷な労働を毎リクエストごとに行っていました。
1. ファイルI/O: ディスクから `.php` ファイルを読み込む。
2. Lexical Analysis (字句解析) & Parsing (構文解析): ソースコードをトークンに分解し、抽象構文木（AST）を構築する。
3. Compilation (コンパイル): ASTをZend VMが理解できる「オペコード（Opcode）」へと変換する。
4. Execution (実行): 仮想マシンがオペコードを解釈し、CPU命令へと落とし込む。
これらはすべて、リクエストが来てからレスポンスを返すまでの「数ミリ秒のライフサイクル内」で行われていました。毎リクエストごとにディスクを叩き、同じコードを何度もパースし直す。これは高トラフィックな環境では耐え難いオーバーヘッドです。
そこで登場したのが OPcache です。OPcacheは、ステップ1〜3の「パースとコンパイル結果（Opcode配列）」を共有メモリ（Shared Memory: SHM）にキャッシュし、2リクエスト目以降はディスクを見ることなく、メモリ上のオペコードを直接Zend VMに流し込むことで爆発的な高速化を実現しました。
—
2. OPcache プリローディングとは何か？（Zend VM視点での真実）
OPcacheの登場により「リクエストごとのパース処理」は消滅しましたが、まだ一つだけボトルネックが残っていました。それは、「フレームワークの巨大なクラス定義や関数群を、リクエストの最初にメモリへインクルード（読み込み）するコスト」です。
LaravelやSymfonyのようなモダンなフレームワークでは、1つのリクエストを処理するために数十、あるいは数百のファイルが読み込まれます。たとえオペコードがキャッシュされていても、Zend VMはリクエストごとに「どのクラスが存在するか」「どのファイルが依存しているか」をシンボルテーブル（Symbol Table）に登録する作業（`include`/`require` の解決）を行わなければなりません。
PHP 7.4で導入されたOPcacheプリローディング（Preloading）は、この「ファイル読み込みとシンボル解決のコスト」すらも起動時に一掃するための技術です。
プリローディングの仕組み
PHP-FPMがマスタープロセス（親プロセス）を起動するまさにその瞬間、`opcache.preload` で指定されたエントリーポイントスクリプトが読み込まれます。
[PHP-FPM マスタープロセス起動]
↓
preload.php を実行（全クラス・関数を読み込み）
↓
Zend VMの永続メモリ（Shared Memory）上に「完全解決された状態」で展開
↓
[fork()] ─── 子プロセス（Worker）が誕生
↓
子プロセスは親プロセスのメモリ空間をCopy-on-Writeで共有し、即座にリクエスト受付可能に！
マスタープロセスがコンパイルし、メモリ上に展開したすべてのクラス、関数、定数、トレイトは、子プロセス（Worker）に `fork()` を通じて引き継がれます。 子プロセスから見れば、自分であらゆるファイルを `require` したかのように、最初からすべてのクラスがメモリ上に存在している状態からリクエスト処理を開始できるのです。
—
3. 実践：プリローディングスクリプトの書き方と注意点
では、実際にプリローディングを行うためのスクリプトがどのように書かれるのかを見てみましょう。
getExtension() === ‘php’) {
$filePath = $file->getRealPath();
// opcache_compile_file は構文解析とオペコード化を行い、
// opcache_invalidate と異なり、キャッシュに強制常駐させます。
// ※ ただし、依存関係の解決を含めて安全に行うには require_once が一般的です。
require_once $filePath;
// デバッグ用ログ（マスタープロセスの起動時にのみ出力される）
// echo “Preloaded: {$filePath}\n”;
}
}
これを有効にするためには、`php.ini` に以下のように設定します。
[opcache]
opcache.enable = 1
opcache.memory_consumption = 512
opcache.preload = /var/www/html/preload.php
opcache.preload_user = www-data
ここで知っておくべき「重大な罠」
他の言語（Javaなど）の常識で考えると、「アプリの全コードをプリロードすれば最速になるのでは？」と思いがちですが、ここにPHP特有の物理的制約があります。
1. コードを変更したらPHP-FPMの再起動が必須
プリロードされたコードは、マスタープロセスのメモリ上に「永続化」されます。開発中にソースコードを書き換えても、OPcacheの自動再検証（revalidate_freq）はプリロードされたファイルには効きません。 コードを反映させるには、FPMプロセスのリロード（`systemctl reload php-fpm`）が絶対に必要になります。
2. メモリの無駄遣い（Over-allocation）
使われるかどうかわからないマイナーなコントローラーや、ごく稀にしか実行されないバッチ処理用のクラスまですべてプレロードしてしまうと、プロセスごとのメモリ消費量（RSS: Resident Set Size）が膨れ上がり、OSの物理メモリを圧迫します。
—
4. プロセス間共有メモリの物理的制約とパフォーマンス影響
さて、ここからが本題の核心です。OSレベルのメモリ管理とパフォーマンスのトレードオフについて、シビアな現実を見ていきましょう。
Copy-on-Write（CoW）とメモリ共有の幻想
「OPcacheでメモリが共有されるなら、何GBのコードをプレロードしてもメモリ使用量は一定だよね？」と考えてしまうのは早計です。
OS（Linux）の `fork()` は、メモリ効率を最大化するために Copy-on-Write（書き込み時コピー） というメカニズムを採用しています。マスタープロセスが保持しているOPcacheのメモリ空間は、子プロセスから見ると「読み取り専用」として共有されます。
しかし、PHPの実行中、Zend VMは完全にイミュータブル（不変）な世界だけで完結しているわけではありません。
- 内部キャッシュやJITの最適化
- グローバルな状態の変更（一部のレガシーなグローバル変数や、内部的な統計情報の更新）
- リクエストごとのZendシンボルテーブルへの書き込み
これらが発生すると、共有されていたメモリページの一部が「子プロセス独自のメモリ領域」として複製され、物理メモリ（RAM）の消費量がじわじわと増加します。
共有メモリの断片化（Fragmentation）とOOM
OPcacheの共有メモリ（`opcache.memory_consumption`）は、一つの巨大な連続したメモリ領域として確保されますが、スクリプトのロード・アンロード（プレロードでは通常発生しませんが、通常の動的キャッシュでは発生します）が繰り返されると、メモリの断片化（Fragmentation）が起きます。
もし、設定した共有メモリのサイズを超過した場合、Zend VMは以下のようなエラーをログに吐き出し、最悪の場合はリクエストのクラッシュやFPM全体の停止を招きます。
> `[Opcache] Out of memory: unable to allocate X bytes of memory…`
この状態に陥ったとき、単に `opcache.memory_consumption` を増やせば解決するわけではありません。OSの仮想メモリ空間、SHM（Shared Memory）セグメントの上限値（`/proc/sys/kernel/shmmax` など）、そして物理RAMとのバランスを慎重に見極める必要があります。
—
5. アーキテクトとして知っておくべき極意
最後に、私たちが現場でこの技術をどう扱い、どう設計に落とし込むべきかの指針をお伝えします。
1. プレロードの対象は「頻繁に実行されるコアクラス」に絞る
フレームワークのカーネル、DIコンテナの基底クラス、頻繁に使われるORMのモデルなど、「全体の8割以上のリクエストで必ず通るコード」だけをプレロードの対象に選定してください。網羅性を求めて全コードを突っ込むのは、保守性とメモリ効率の観点からアンチパターンです。
2. 本番環境のデプロイメントパイプラインに「FPMのリロード」を組み込む
プリロードを使用する場合、コードのデプロイとFPMのgraceful reload（無停止リロード）はセットで行われなければなりません。CI/CDパイプラインの最後に `sudo systemctl reload php-fpm` を忘れない自動化の仕組みを作りましょう。
3. ベンチマークとメモリプロファイリングの常態化
`opcache_get_status(true)` を叩くことで、現在の共有メモリの使用率やヒット率、無駄になっているメモリ（Wasted memory）を正確に観測できます。勘や推測ではなく、必ずメトリクスをベースに `opcache.memory_consumption` の値をチューニングしてください。
—
PHPは、単なる「お手軽なスクリプト言語」ではありません。その下層では、C言語で書かれたZend VMとLinuxのメモリ管理が緻密に連携し、極限まで最適化された高速なランタイムとして動作しています。
このプリローディングと共有メモリの仕組みを完全に手中に収めたあなたなら、大規模なトラフィックをさばく高負荷なWebシステムであっても、自信を持って美しいアーキテクチャを描き切ることができるはずです。
さあ、次のデプロイでは、ぜひこの知見をあなたのプロダクトに活かしてみてください。PHPの裏側がクリアに見えたとき、開発はもっと楽しく、もっとエキサイティングになりますよ。