Swoole/RoadRunner常駐プロセスにおけるZend VMメモリ空間の支配と、リクエスト間汚染（Cross-Request Pollution）の完全撃退
PHPという言語は、長きにわたり「1リクエスト＝1プロセス（またはスレッド）の完全な死と再生」というShared-Nothingアーキテクチャの安全網の上に成り立ってきた。CGI時代からApache＋mod_php、そしてPHP-FPMに至るまで、リクエストが終端すればZend VMのプロセス空間は初期化され、`$_GET`や`$_POST`、そしてあなたが定義したあらゆるグローバル状態は容赦なくOSによって回収されてきた。
しかし、SwooleやRoadRunnerといった常駐型（Long-running）アプローチの台頭により、この前提は音を立てて崩れた。Zend VMはメモリ上に常駐し続け、リクエストは単なる「イベントループ上のコールバック」として処理される。
ここでエンジニアが直面するのが、「リクエスト間汚染（Cross-Request Pollution）」という、Zend VMのメモリ構造の深部を理解していない者が必ず踏み抜く地雷原である。本稿では、Zend VMの内部構造、OPcacheの挙動、そして並行処理ランタイムにおける真のコンテキスト分離設計の極意を、低レイヤの視点から解き明かす。
—
1. Zend VMのメモリ空間と「グローバル変数」の永続化のメカニズム
従来のPHP-FPM環境では、スクリプトの実行が完了すると、Zend Engineは `request_shutdown` フェーズに入り、Executorグローバル構造体（`EG()`）に紐づくすべてのシンボルテーブル（Symbol Table）が破棄される。
しかし、常駐プロセス（Swoole等）において、PHPスクリプトのモジュール初期化フェーズ（`MINIT`）や、サーバ起動時にロードされたファイル群は、ワーカプロセスのライフサイクル全体にわたってメモリ上に固定化される。
静的変数（`static`）とグローバル空間の罠
以下のコードを見てほしい。一見して無害に見えるこのクラスは、常駐環境において致命的なセキュリティホールとデータ破損を引き起こす。
リクエストBのコンテキストからリクエストAの認証済みセッションデータが丸見えになる。これは単なるバグにとどまらず、重大な権限昇格脆弱性（Cross-Tenant Data Leakage）に直結する。
—
2. OPcacheプリローディングとメモリの物理構造
PHP 7.4以降で導入されたOPcacheプリローディング（`opcache.preload`）は、パフォーマンスを極限まで引き上げる一方で、Zend VMのメモリ管理に対する深い理解を要求する。
プリロードされたスクリプトは、サーバ起動時にAST（抽象構文木）からオペコード（Opcode）へコンパイルされ、共有メモリ（Shared Memory: SHM）上に配置される。そして、ワーカプロセスが起動する際、この共有メモリ領域が各プロセスのプロセス空間にマッピング（`mmap`）される。
ここで重要なのは、「プリロードされたコード内で定義されたグローバル変数の初期値や静的変数の初期状態は、全ワーカプロセスで共有される読み取り専用（あるいはコピーオンライト）のベースラインになる」という点だ。
[ OPcache 共有メモリ (SHM) ]
┗ プリロードされたクラス定義 (zend_class_entry)
┗ 静的プロパティの初期状態 (Immutable)
│
├─→ [Worker Process 1] (Copy-on-Writeで分岐)
└─→ [Worker Process 2] (Copy-on-Writeで分岐)
もし、プリロードされたクラスの静的変数に対して、リクエスト処理中に書き込みが発生した場合、LinuxカーネルのCopy-On-Write（COW）メカニズムにより、そのページがプロセス固有のプライベートメモリ領域へとコピーされる。これにより、ワーカ間でのメモリ汚染は防がれるものの、同一ワーカ内で処理される後続のリクエストにはその変更が残留することになる。
—
3. Swoole/RoadRunner環境における『Context』管理の設計パターン
常駐環境でリクエスト間汚染を防ぐ唯一にして最大の防御策は、「グローバル状態への依存を断ち切り、リクエストのライフサイクルに完全に同期したコンテキストコンテナを注入（DI）すること」である。
Swooleのコルーチン環境を例にとる。Swooleには、各コルーチン固有のストレージを提供する `Swoole\Coroutine\Context` が存在する。これを利用し、リクエストスコープを完全に隔離するアーキテクチャを構築する。
堅牢なコンテキストマネージャの実装例
以下の実装は、Zend VMのグローバル空間を汚染せず、コルーチン（＝リクエスト）単位で完全に分離されたスコープを実現するプロダクションレベルの設計パターンである。
/
final class CoroutineRequestContext
{
private const CONTEXT_KEY = ‘__app_request_context__’;
/
- 現在のコルーチン空間にリクエスト固有のデータをバインドする
/
public static function set(ServerRequestInterface $request, ResponseInterface $response): void
{
$cid = Coroutine::getuid();
if ($cid <= 0) {
// 非コルーチン環境（フォールバック用：通常のCLIや同期FPM等）
// 実運用では例外を投げるか、リクエストローカルなストレージに切り替える
return;
}
$context = Coroutine::getContext();
$context[self::CONTEXT_KEY] = [
'request' => $request,
‘response’ => $response,
‘attributes’ => [],
];
}
/
- 現在のコルーチンのリクエストオブジェクトを取得する
/
PSR\Http\Message\ServerRequestInterface
public static function getRequest(): ServerRequestInterface
{
$context = Coroutine::getContext();
if (!isset($context[self::CONTEXT_KEY][‘request’])) {
throw new \RuntimeException(‘RequestContext is not initialized in this coroutine scope.’);
}
return $context[self::CONTEXT_KEY][‘request’];
}
/
- リクエスト処理終了時にコンテキストを明示的に解放する
- （メモリリークおよびコルーチン間のデータ残留を防ぐための極めて重要な処理）
/
public static function destroy(): void
{
$context = Coroutine::getContext();
if (isset($context[self::CONTEXT_KEY])) {
// 循環参照の防止とメモリの即時解放
unset($context[self::CONTEXT_KEY]);
}
}
}
ミドルウェア層でのライフサイクル管理
フレームワークのエントリーポイント、あるいはPSR-15ミドルウェアの最外殻で、このコンテキストの初期化と破棄を `try-finally` 構文で必ず担保しなければならない。
handle($request);
return $response;
} finally {
// 3. 実行完了後、例外の有無に関わらず必ずコンテキストを破棄
// これにより、同一ワーカで次に実行されるリクエストへのゴミの持ち越しを防ぐ
CoroutineRequestContext::destroy();
}
}
}
—
4. オブジェクトインジェクションとGadget Chainの脅威（常駐環境特有のリスク）
従来のPHP環境では、オブジェクトインジェクション脆弱性（`unserialize()` の不適切な利用など）が存在した場合でも、そのリクエストの終了とともに攻撃者が構築したGadget Chainのライフサイクルも終了していた。
しかし、SwooleやRoadRunnerのような常駐環境では、メモリ上に常駐するオブジェクトやクラス定義の肥大化に伴い、攻撃の持続性と危険性が何倍にも跳ね上がる。
Zend VMの型システムとメモリ破壊のメカニズム
`unserialize()` が呼び出されると、Zend VMは文字列をパースし、指定されたクラスのインスタンスを動的に生成する。もし攻撃者が任意のクラス（__wakeupや__destructを持つマジックメソッドを含むクラス）をインジェクションすることに成功した場合、ワーカプロセスのメモリ空間内で任意のメソッド実行（Remote Code Execution: RCE）へと繋げられる。
常駐環境における最大のリスクは、「汚染されたオブジェクトがグローバルなキャッシュやDIコンテナ、あるいは静的変数に誤って格納された場合、それが永続的なバックドアとして機能し続ける」という点だ。
防御の鉄則：
1. `unserialize()` の完全な廃止: 代わりに `ext-json` やセキュアなシリアライザ（例: Symfony Serializerのコンポーネントで厳格な型安全性を担保したもの）を使用する。
2. マジックメソッドの監査: アプリケーションコードベース全体で `__wakeup()`, `__destruct()`, `__toString()` などのマジックメソッド内で外部入力や未検証のプロパティを処理していないか、静的解析（PHPStanの厳格モードやPsalm）を用いて徹底的に排除する。
—
5. チーフアーキテクトからの提言：Zend VMを飼い慣らせ
SwooleやRoadRunnerを用いたハイパフォーマンスなPHPアプリケーションの構築は、もはや「動けばいい」というスクリプト言語の発想では通用しない。我々は今や、C/C++やJavaのネイティブスレッドプログラミングに近い、メモリ管理とスコープの厳密な統制を求められている。
- `$_GET`, `$_POST`, `$_SERVER` といったグローバルスーパーグローバル変数をビジネスロジックの深部で直接触るコードは、技術的負債ではなく「時限爆弾」である。
- すべての状態はイミュータブル（不変）であるか、あるいは明確に定義されたスコープ（Coroutine Context / Request Scope）の中に閉じ込められなければならない。
- リクエストの終端（`finally` ブロック）でのコンテキストの破棄とメモリクリーンアップをシステム全体で強制せよ。
Zend VMの挙動を完全に掌握した者だけが、PHPを真の超高速・高スループットなエンタープライズランタイムへと昇華させることができる。コードを書く手をとめ、自らのアーキテクチャのメモリ空間を見つめ直せ。そこにあるのは秩序か、それともカオスか。答えは常に、コードの低レイヤに宿っている。