【実務・中級編】Swoole/RoadRunner常駐環境下でのグローバル変数・静的変数の汚染防止：リクエスト分離とクリーンアップ戦略 – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

常駐型PHPのパラダイムシフト：メモリ空間の永続化がもたらす「静かなる爆弾」

PHP-FPMの時代は終わった。正確には、終わってはいないが、高スループットを要求されるモダンなWebシステムやAPI基盤の主役は、SwooleやRoadRunnerに代表される常駐型（Long-running）PHPプロセスへと完全に移行した。

従来のPHP-FPMでは、1つのHTTPリクエストが来るとプロセスがフォーク（あるいはプールからアサイン）され、リクエストの終了とともにZend Engineのメモリ空間はすべてOSに回収されていた。いわば「使い捨てのクリーンルーム」である。

しかし、SwooleやRoadRunnerの基盤上では、一度起動したPHPプロセスはメモリ上に常駐し続け、数百万ものリクエストを単一のプロセスで処理し続ける。これはI/O待ちのオーバーヘッドを劇的に削減し、Node.jsやGoに匹敵する爆発的なパフォーマンスをもたらす反面、PHPエンジニアが長年意識する必要のなかった「メモリリーク」と「グローバル状態の汚染（State Pollution）」という巨大なパンドラの箱を開けることになった。

コードレビューをしていて、次のようなコードを見たことはないだろうか。

// 某フレームワークの古いプラグインで見かけた悪夢のようなコード
class DatabaseConnection {
private static ?PDO $instance = null;

public static function getInstance(): PDO {
if (self::$instance === null) {
self::$instance = new PDO(‘mysql:host=127.0.0.1;dbname=app’, ‘user’, ‘pass’);
}
return self::$instance;
}
}

FPM環境であれば、このシングルトンは「リクエストごとに安全に生成され、リクエスト終了時に消え去る」ものだった。しかし、常駐型環境では違う。初回のリクエストで確立されたPDO接続はプロセスが生きている限り維持され、2回目以降のリクエストでも使い回される。

もし、途中でトランザクションが異常終了してロールバックされ忘れたり、テナント識別子（テナントID）のようなリクエスト固有のコンテキストが静的変数やグローバル変数にキャッシュされたりしたらどうなるか？

次のリクエストに前のリクエストのデータが漏れ出し、全く関係ない顧客のデータが露出する致命的なセキュリティインシデント（データ混入：Cross-Request Data Pollution）へと直結する。

Zend VMの内部構造から、この問題の本質を解き明かしていこう。

—

Zend VM内部の挙動：なぜ静的変数とグローバル変数は「汚染」されるのか？

PHPの裏側で動いているZend Engineにおいて、すべての変数、関数、クラス定義はシンボルテーブル（Symbol Table）という `HashTable` 構造体に格納されている。

常駐型アプリケーションにおいて、スクリプトのロードフェーズ（`bootstrap` や `worker` の起動時）で読み込まれたクラスの静的プロパティ（`static $property`）や、グローバルスコープで定義された変数は、プロセスのライフサイクル全体を通じてZend VMのヒープメモリ上に固定化される。

[ OS Process Memory Space (Swoole / RoadRunner Worker) ]
├── Zend Engine Global State
├── Opcode Cache (Opcache)
└── Symbol Tables (Persistent across requests)
├── Class::$static_cache <-- ⚠️ ここに前リクエストの残骸が残る └── $GLOBALS['...'] <-- ⚠️ ここも永続化されるリクエストAが処理される際、あるコントローラが静グローバル変数や静的プロパティに一時的なデータを書き込んだとする。リクエストAが終了し、Swooleが次のリクエストBの処理にそのプロセスをアサインしたとき、Zend VMのメモリ空間は初期化されない。前回のゴミ（参照カウントが維持されたままのデータ構造）がそのままそこに鎮座している。これが、常駐型PHPにおける最大の罠である。 ---

堅牢な設計ルール：常駐型環境を制する3つの鉄則

SwooleやRoadRunner上でエンタープライズクオリティのアプリケーションを動かすには、以下の3つの設計ルールをコードベースに強制しなければならない。

1. グローバル・静的変数の原則禁止（Read-Onlyの許容）

設定値やDIコンテナの定義など、イミュータブル（変更不可）なもの以外、`static` や `$GLOBALS`、`$_SESSION`（ファイルやDBドライバ外のメモリ上）の書き込みを一切禁止する。

2. リクエスト・コンテキストの明示的な分離（Context Isolation）

認証ユーザー、リクエストID、ロガーのコンテキストなどは、プロセス共有の領域に置かず、リクエストごとにインスタンス化されるコンテナオブジェクトに閉じ込める。

3. 明示的なクリーンアップと例外安全なファイナライゼーション

リクエストの終端（Middlewareのレスポンス返却後など）で、必ずコンテキストを破棄し、参照を切り離す。

—

実装リファレンス：安全なコンテキスト管理とクリーンアップ戦略

理論はこれくらいにして、実務でそのまま使える堅牢な設計パターンコードを見ていこう。ここでは、RoadRunnerやSwooleのHTTPWorkerを想定し、リクエストごとのコンテキストを完全に隔離・浄化する仕組みを構築する。

1. リクエスト固有のデータを安全に保持する Context Container

まず、グローバル汚染を防ぐための「リクエストコンテキスト」を定義する。このクラス自体はリクエストごとに生成され、捨てられるべきものである。

declare(strict_types=1);

namespace App\Context;

use Psr\Http\Message\ServerRequestInterface;

リクエストスコープのコンテキストを安全に保持するクラス。
プロセス全体で共有してはならない。

/
final class RequestContext
{
private ?ServerRequestInterface $request = null;
private ?string $tenantId = null;
private array $attributes = [];

public function setRequest(ServerRequestInterface $request): void
{
$this->request = $request;
}

public function getRequest(): ?ServerRequestInterface
{
return $this->request;
}

public function setTenantId(string $tenantId): void
{
$this->tenantId = $tenantId;
}

public function getTenantId(): ?string
{
return $this->tenantId;
}

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

public function get(string $key, mixed $default = null): mixed
{
return $this->attributes[$key] ?? $default;
}

⚠️ 極めて重要：次のリクエストへの汚染を防ぐため、内部状態を完全にリセットする

/
public function reset(): void
{
$this->request = null;
$this->tenantId = null;
$this->attributes = [];
}
}

2. DIコンテナを通じたスコープの管理とライフサイクル・ミドルウェア

次に、この `RequestContext` をPSR-15互換のミドルウェアで制御し、リクエストの開始時に初期化、終了時（例外発生時を含む）に必ず `reset()` を呼ぶ仕組みを作る。

declare(strict_types=1);

namespace App\Http\Middleware;

use App\Context\RequestContext;
use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;
use Psr\Http\Server\MiddlewareInterface;
use Psr\Http\Server\RequestHandlerInterface;
use Throwable;

final class RequestLifecycleMiddleware implements MiddlewareInterface
{
public function __construct(
private RequestContext $requestContext
) {}

public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface
{
// 1. リクエスト開始時のセットアップ
$this->requestContext->setRequest($request);

// ヘッダーからテナントIDを抽出してコンテキストにバインド（例）
$tenantId = $request->getHeaderLine(‘X-Tenant-ID’);
if ($tenantId !== ”) {
$this->requestContext->setTenantId($tenantId);
}

try {
// 2. アプリケーションの実行
$response = $handler->handle($request);
} catch (Throwable $e) {
// 例外が発生した場合でもクリーンアップが走るようにfinallyを保証
throw $e;
} finally {
// 3. ⚠️ 鉄則：リクエスト終了時に必ずコンテキストをパージする
$this->requestContext->reset();
}

return $response;
}
}

3. 常駐型ワーカー（Worker Loop）での例外安全なメモリ管理

SwooleやRoadRunnerのループ本体では、メモリリークの蓄積を防ぐためにガベージコレクションの挙動にも配慮する必要がある。PHPのGCは循環参照を自動回収するが、意図しない参照の切り忘れ（プロパティへのクロージャ保持など）があると、GCが機能せずメモリが枯渇する。

以下は、RoadRunnerなどのWorkerを模擬した堅牢なメインループの構造である。

declare(strict_types=1);

namespace App\Worker;

use App\Context\RequestContext;
use Psr\Container\ContainerInterface;
use Throwable;

final class HttpWorkerRunner
{
public function __construct(
private ContainerInterface $container
) {}

public function run(): void
{
// 擬似的な常駐ループ
while ($this->hasNextRequest()) {
$request = $this->acceptRequest();

try {
// スコープごとのコンテナ（DIコンテナのサブスコープ）を生成するべき
// ここでは簡略化のためRequestContextを直接リセット・操作
$requestContext = $this->container->get(RequestContext::class);

// アプリケーションカーネルの実行
$kernel = $this->container->get(\App\Http\Kernel::class);
$response = $kernel->handle($request);

$this->sendResponse($response);

} catch (Throwable $e) {
$this->handleException($e);
} finally {
// 明示的なメモリ解放の促し（循環参照の回収）
// 大量のオブジェクトが生成・破棄された後、強制的にGCサイクルを回すことで
// RSS（Resident Set Size）の肥大化を抑える
if (function_exists(‘gc_collect_cycles’)) {
// 毎リクエスト呼ぶとオーバーヘッドになるため、必要に応じてカウンタで間引くのも手
gc_collect_cycles();
}
}
}
}

private function hasNextRequest(): bool { / 略 / return true; }
private function acceptRequest(): mixed { / 略 / return null; }
private function sendResponse(mixed $response): void { / 略 / }
private function handleException(Throwable $e): void { / 略 / }
}

—

チーフアーキテクトからの警鐘：コードレビューのチェックリスト

常駐型PHPアプリケーションのコードレビューを行う際、以下のアンチパターンを発見したら、即座に差し戻しを命じてほしい。

「とりあえず `static` にキャッシュしておこう」という安易な実装
→ 読み取り専用（マスターデータのマスタフラット化など）を除き、状態を持つプロパティへの `static` 付与は厳禁。
シングルトンパターンの濫用
→ DIコンテナのライフサイクル管理（シングルトンバインド vs リクエストスコープバインド）を正しく理解していない開発者が書いたシングルトンは、ほぼ確実にデータ混入の温床になる。
クロージャや匿名関数への重いオブジェクトのキャプチャ
→ イベントリスナーやキューのジョブに `$this` や巨大なオブジェクトを不必要にキャプチャして保持させると、参照カウントが落ちずにメモリリークを引き起こす。

常駐型PHPは、適切に扱えばモンスターのようなパフォーマンスを発揮する最高の武器だ。しかし、メモリの寿命とリクエストの寿命の不一致を理解していない者にとっては、いつ爆発するか分からない不発弾にもなり得る。

Zend Engineのメモリモデルを脳内に置き、「リクエストが去った跡には、草一本残してはならない」という気概を持って、クリーンで安全なアーキテクチャを構築してほしい。