【テクニカル・上級編】Swoole/RoadRunner常駐環境下でのグローバル変数・静的変数の汚染防止：リクエスト分離とカスタムメモリマネージャーによる高度なクリーンアップ戦略 – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

Swoole/RoadRunner常駐環境下でのグローバル変数汚染の根絶：Zend VMとメモリマネジメントの極意

PHPは長年にわたり、「1リクエスト＝1プロセス（またはスレッド）の完全な消滅」という、ある種の暴力的なまでのシンプルさによってメモリリークやステート汚染から開発者を守ってきた。Apache＋mod_phpの時代からPHP-FPMに至るまで、リクエストが終端すればZend Engineが抱えていたすべての`zend_executor_globals`やプロセス空間のメモリはカーネルによって回収され、ゼロベースで次のリクエストが処理される。この「忘却の美学」こそが、PHPを最も安全でスケーラブルなWeb言語たらしめてきた基盤である。

しかし、SwooleやRoadRunnerに代表される常駐型（Persistent）アプリケーションサーバーの普及に伴い、この前提は完全に崩れ去った。Zend VMはプロセスを生存させたまま、イベントループやWorkerプロセスのなかで数千、数万というリクエストをループ処理する。

このアーキテクチャにおいて、PHPのグローバル変数や`static`変数は、もはや「リクエストごとの一時的な変数」ではない。それはプロセス生存期間中ずっと残り続けるグローバルステートであり、不適切な設計は、マルチテナント環境における致命的なデータ漏洩（クロスリクエスト・コンタミネーション）や、最悪の場合は任意のメモリ破壊を引き起こす。

本稿では、Zend VMのメモリ管理構造、Zendシンボルテーブルの実態、そして常駐環境下における厳密なリクエスト分離とカスタムクリーンアップ戦略について、低レイヤの視点から徹底的に解剖する。

—

1. Zend VMのメモリ空間と常駐環境の罠

PHPの実行実体であるZend VMは、リクエストのライフサイクルを明確な境界線で区切っている。 традиционный PHP-FPM環境では、リクエストの開始時に `php_request_startup()` が呼ばれ、終了時に `php_request_shutdown()` が走る。このシャットダウンプロセスにおいて、シンボルテーブル（`EG(symbol_table)`）に登録されたすべてのローカル・グローバルシンボルが走査され、参照カウント（`refcount`）がデクリメントされ、必要に応じて `zend_hash_destroy()` や `efree()` によってメモリが解放される。

しかし、SwooleやRoadRunnerのWorkerプロセス上では、メインのブートストラップスクリプト（アプリケーションの初期化、フレームワークのロード、コンテナの構築）が一度だけ実行された後、イベントループが回る。

[Master Process]
│
├── [Worker Process 1] ── (Bootstrap: 1回のみ実行 / グローバル領域の構築)
│ │
│ ├── Request 1 ──> Handler ──> グローバル/static変数の汚染が発生
│ ├── Request 2 ──> Handler ──> 前のgetRequestの残骸を読み込み
│ └── Request N …
│
└── [Worker Process 2] …

このブートストラップ時に読み込まれたクラス定義、サービスコンテナ、設定値、あるいは安易に定義されたグローバル変数や静的プロパティは、すべてWorkerプロセスのヒープ上に常駐する。

脆弱性の核心：シンボルテーブルとZendコンテナの共有

例えば、以下のようなコードを常駐環境で動作させたとしよう。

Request Aの機密データがそのまま返却される。

これはバグにとどまらず、マルチテナント環境における重大なセキュリティインシデント（Broken Object Level Authorizationの極端な形）である。Zend VMの視点から見れば、これは単に「生存し続けているZendオプジェクトのポインタを指しているだけ」であり、エンジン側からすれば何ら異常な挙動ではない。

—

2. OPcacheプリローディングの物理構造と副作用

パフォーマンスを極限まで高めるため、OPcacheのプリローディング（`opcache.preload`）が多用される。PHP 7.4以降で導入されたこの機能は、サーバー起動時に指定されたスクリプトをパースし、生成されたopcode（Zendオプコード）を共有メモリ（SHM）上に配置する。これにより、リクエストごとのファイルI/Oやパースコストが完全にゼロになる。

しかし、ここにも常駐環境特有の罠がある。プリロードされたスクリプト内で定義されたクラスの静的プロパティや、定数（`const`）、グローバルスコープで生成されたオブジェクトは、すべてのWorkerプロセス間で読み取り専用のメモリとして共有される。

もしプリロードされたクラスの静的プロパティに対して、リクエスト処理中に書き込みを行おうとするとどうなるか。

class DatabasePool {
// プリロードされたクラスの静的プロパティ
public static ?PDO $connection = null;

public static function getConnection(string $dsn, string $user, string $pass): PDO {
if (self::$connection === null) {
// ここで接続を確立すると、SHM上のクラス定義に対して
// プロセス固有の書き込み（Copy-on-Write）が発生する
self::$connection = new PDO($dsn, $user, $pass);
}
return self::$connection;
}
}

Linuxのメモリ管理機構（Copy-on-Write: CoW）により、プリロードされたセグメントへの書き込みはプロセスごとにプライベートなメモリ領域へのコピーを引き起こす。しかし、アプリケーションレベルで「このプロパティはリクエストごとにリセットされるべきだ」という意図がある場合、CoWが発生したあとの状態は次のリクエストに引き継がれてしまう。

—

3. Swoole/RoadRunner環境におけるリクエスト分離とクリーンアップ戦略

この問題を根本から解決するためには、アプリケーション層とフレームワーク層の協調による「厳密なリクエスト境界のシミュレーション」が必要となる。

具体的には、以下の3つのレイヤで防御壁を構築する。

1. スコープの強制分離（Dependency Injectionの適切なライフサイクル管理）
2. リクエスト終了時のファイナライザー（Destructor / Cleanup Hook）の徹底
3. カスタムメモリマネージャーによるリソースの強制解放

実装パターン：エンタープライズ向けリクエストスコープコンテナ

以下に、Swoole/RoadRunner環境下でグローバル汚染を防ぐための、リクエストスコープ管理機構の実装例を示す。

/
final class RequestScopeManager
{
private static ?self $instance = null;

/ @var array リクエストスコープに紐づくレジストリ /
private array $registry = [];

/ @var array リクエスト終了時に実行されるクリーンアップフックのスタック /
private array $destructors = [];

private function __construct() {}

public static function getInstance(): self
{
if (self::$instance === null) {
self::$instance = new self();
}
return self::$instance;
}

/

• 新しいリクエストの開始時にコールされる。
• 前回の残骸が残っていないことを保証するため、レジストリを完全にフラッシュする。

/
public function beginRequest(): void
{
$this->registry = [];
$this->destructors = [];
}

/

• リクエストスコープ内に値/オブジェクトを登録する。

/
public function set(string $key, mixed $value): void
{
$this->registry[$key] = $value;
}

/

• リクエストスコープから値を取得する。

/
public function get(string $key): mixed
{
return $this->registry[$key] ?? null;
}

/

• リクエスト終了時に実行すべきクリーンアップ処理（コールバック）を登録する。

/
public function registerDestructor(Closure $destructor): void
{
$this->destructors[] = $destructor;
}

/

• リクエストの終端で必ず呼び出される。
• 登録されたデストラクタを逆順（LIFO）で実行し、オブジェクトの循環参照を断ち切る。

/
public function endRequest(): void
{
try {
// LIFO (Last In, First Out) 順でクリーンアップを実行
while ($destructor = array_pop($this->destructors)) {
try {
$destructor();
} catch (Throwable $e) {
// ログ出力等に留め、クリーンアップの連鎖を止めない
error_log(“Destructor execution failed: ” . $e->getMessage());
}
}
} finally {
// 最後に参照を完全に断ち切る
$this->registry = [];
$this->destructors = [];

// Zend EngineのZTS/非ZTS環境におけるメモリ断片化を抑制するため、
// 必要に応じてガベージコレクションを明示的に発火させる
if (gc_enabled()) {
gc_collect_cycles();
}
}
}
}

フレームワーク統合のフック（Swoole/RoadRunnerのイベントループ駆動）

この `RequestScopeManager` を、Swooleの `onRequest` イベントやRoadRunnerのPSR-7 Workerループのなかでフックする。

on(‘request’, function (Swoole\Http\Request $request, Swoole\Http\Response $response) {
$scopeManager = \App\Core\Memory\RequestScopeManager::getInstance();

// 1. リクエストスコープの初期化（グローバルステートの完全リセット）
$scopeManager->beginRequest();

try {
// 2. DIコンテナやグローバルな状態をリクエストスコープでラップ
$scopeManager->set(‘request’, $request);

// — アプリケーションの実行 —
$kernel = new \App\Http\Kernel($scopeManager);
$res = $kernel->handle($request);

$response->end($res);

} catch (Throwable $e) {
$response->status(500);
$response->end(“Internal Server Error”);
} finally {
// 3. 確実なクリーンアップとメモリ解放の実行
// これにより、次のリクエストへステートを持ち越さない
$scopeManager->endRequest();
}
});

$http->start();

—

4. 循環参照とZend GCの限界を見据えた防御的コーディング

PHPのガベージコレクション（GC）は、循環参照（Circular Reference）を検出するために専用のアルゴリズム（コンテナのルートバッファリングと色塗りアルゴリズム）を使用している。しかし、常駐環境において、開発者が不用意に「クロージャ内で自分自身や親オブジェクトを参照する構造（Circular References）」を作り上げてしまうと、リクエスト終了時の `efree()` だけではメモリが回収されず、徐々にWorkerのメモリ消費量が増加する（メモリリーク）。

脆弱・リークしやすいコードパターン

class BadService {
private ?Closure $callback = null;

public function initialize(): void {
// $this がクロージャにキャプチャされ、クロージャが $this のプロパティに格納されることで循環参照が発生
$this->callback = function () {
return $this->doSomething();
};
}

private function doSomething(): string {
return “data”;
}
}

このようなコードが常駐環境で何百万回もインスタンス化されると、Zend VMのメモリマネージャー（ZMM）の許容量を超え、OOM（Out of Memory）キラーによってWorkerプロセスが無慈悲に殺害される。

対策：明示的な参照の切断（Destructorの活用）

クラス設計において、常駐環境を意識する場合は `__destruct()` を過信せず、前述した `RequestScopeManager` のような仕組みを使って明示的にクロージャや巨大な配列の参照を `null` に代入し、`refcount` を強制的に 0 に落とすアプローチが極めて有効である。

class GoodService
{
private ?Closure $callback = null;

public function initialize(): void
{
$this->callback = function () {
return “data”;
};

// クリーンアップマネージャーに自身の参照解除を登録
\App\Core\Memory\RequestScopeManager::getInstance()->registerDestructor(function () {
$this->callback = null;
});
}
}

—

5. まとめ：常駐PHPを制する者がパフォーマンスを制する

SwooleやRoadRunnerによる常駐型PHPアプリケーションは、従来のPHP-FPMの枠組みを粉砕し、Node.jsやGo言語に匹敵するスループットと低レイテンシをもたらす。しかしその代償として、開発者は「Zend VMのメモリ空間がプロセス生存期間を通じて持続する」という事実と真っ正面から向き合わなければならない。

グローバル変数や静的変数の安易な利用は、マルチテナント環境におけるデータ汚洩という致命的なセキュリティリスクを孕んでいる。Zend VMの内部構造を理解し、リクエスト境界をコードレベルで厳密にシミュレートするカスタムメモリ管理、そして徹底的なクリーンアップ戦略を実装すること。それこそが、エンタープライズの荒波に耐えうる、真に堅牢なモダンPHPアーキテクチャの絶対条件である。