【実務・中級編】Swoole/RoadRunner環境におけるリクエスト間メモリ分離の高度な実装：カスタムメモリマネージャーとサンドボックス化 – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

Swoole/RoadRunner時代におけるPHPメモリ管理の極意：リクエスト間サンドボックスとカスタムメモリマネージャーの実装

PHPは、従来のFPM（FastCGI Process Manager）アーキテクチャにおいて「1リクエスト = 1プロセス（またはスレッド）の完全な破棄」という、極めて乱暴かつ安全なメモリモデルを標準としてきた。このモデルの美しさは、メモリリークやステートの汚染について開発者が過剰に悩む必要がない点にある。アプリケーションコードがどれほどグローバル変数を汚し、どれほど循環参照を残そうとも、リクエストが終了した瞬間にOSがプロセスごとのアドレス空間を丸ごと回収する。PHPが「お気楽な言語」と揶揄されながらもWebの覇権を握り続けた最大の理由は、この強固なサンドボックス性に他ならない。

しかし、SwooleやRoadRunnerに代表される常駐型ランタイム（Long-running process）の普及により、このパラダイムは完全に崩壊した。

マスタープロセスがZend VMをメモリ上に保持し続け、Workerプロセスがプールされながら何万ものリクエストを非同期あるいは逐次的に処理していく。このアーキテクチャはI/O待ちのオーバーヘッドを劇的に削減し、Node.jsやGoに匹敵するスループットをもたらす一方で、「リクエストをまたいだメモリ汚染（State Pollution）」と「徐々に進行するメモリリーク（Memory Leak）」という、CやJavaが長年抱えてきた悪夢をPHPエンジニアの目の前に突きつけた。

コードレビューの現場で「なぜこのシングルトンや静的プロパティの利用が致命的なのか」「なぜガベージコレクションが走ってもメモリが減らないのか」をロジカルに説明できないようでは、常駐型PHPアプリケーションのテックリードは務まらない。今回は、Zend VMのメモリ管理の裏側を暴き、常駐環境において完全に安全なサンドボックスとカスタムメモリマネージャーを構築するための極限の知見を伝授する。

—

1. Zend VMのメモリ管理と常駐環境の罠

参照カウント（Reference Counting）と循環参照（Circular References）の限界

PHPの変数コンテナである `zval` は、`refcount`（参照カウント）によって管理されている。変数が代入されたり関数に渡されたりするたびに `refcount` がインクリメントされ、スコープを抜けるなどして破棄されるとデクリメントされる。これが `0` になった瞬間、対応するメモリ領域が解放される。

しかし、オブジェクトや配列が互いに参照し合う「循環参照（Circular Reference）」が発生した場合、スコープを抜けて外部からのアクセスが消失しても、お互いの `refcount` が `1` 以上残るため、参照カウント方式だけではメモリが解放されない。

PHPにはこれを解決するために「循環参照ガベージコレクタ（GC）」が組み込まれている。`zval` のバッファが一定量（デフォルトでは `zend_mm.gc_thresh` に依存）に達すると、ルートバッファに溜まった候補をスキャンし、参照を一時的にデクリメントして孤立しているかを判定するマーク＆スィープアルゴリズムを走らせる。

しかし、常駐環境（Swoole等）において、このGCメカニズムは「万能薬」ではない。
1. 確定的な破棄のタイミングの欠如: GCが走るタイミングはヒュージなメモリ消費をトリガーとするため、意図したタイミングでメモリが返還されない。
2. 静的プロパティ（`static`）とグローバルスコープの呪縛: クラスの静的プロパティや、常駐プロセスのヒープ上に保持されたクロージャ内のuse変数は、ルートバッファの対象外（永続的、あるいはリクエストを超えて生存するスコープ）として扱われることが多い。ここにリクエスト固有のユーザーオブジェクトやDoctrineのEntityManagerがキャッシュされ続けると、リクエストが進むにつれてメモリは確実に枯渇する。

Zend Memory Manager（Zend MM）の挙動

Zend MMは、OSからまとまったメモリチャンク（通常は2MB単位の巨大なブロック）を `malloc()` で一括確保し、それを細分化して `zval` や内部構造体に割り当てる。これにより、細かなアロケーションによるOSへのシステムコール負荷を激減させている。
常駐環境では、リクエスト1で肥大化したZend MMのヒープ領域は、リクエストが終了して `zval` が解放されても、オペレーティングシステムには返還されず、Zend MMの「空きリスト（Free List）」に戻るだけである。つまり、一度ピーク時に消費されたメモリサイズは、プロセスが生存し続ける限り維持され続ける。

—

2. Swoole/RoadRunner環境におけるリクエスト間分離の設計思想

常駐環境で安全なアプリケーションを構築するための原則はただ一つ。
「リクエスト処理の開始時にクリーンなサンドボックスを構築し、終了時にそのスコープ内で生成されたすべての動的リソースを強制的に破棄・リセットする」ことだ。

これを実現するために、フレームワークレベルやミドルウェア層で「カスタムメモリマネージャー（Isolation Container）」を実装し、DIコンテナやリクエスト固有のサービスをリクエストごとに完全にインスタンス化し直す仕組みが必要となる。

—

3. 実装：リクエスト分離サンドボックスとカスタムメモリマネージャー

以下のコードは、SwooleやRoadRunnerのWorkerループ内で動作することを想定した、リクエスト分離を実現するカスタムメモリマネージャーおよびサンドボックスの堅牢な実装例である。

declare(strict_types=1);

namespace App\Core\Memory;

use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;
use Throwable;

/

• クラス名: RequestSandboxManager
• 概要: 常駐プロセス環境（Swoole/RoadRunner等）におけるリクエストごとのメモリ分離と
• クリーンアップを強制するサンドボックスマネージャー。

/
final class RequestSandboxManager
{
/ @var array リクエスト終了時に実行すべきクリーンアップタスクのスタック /
private array $destructors = [];

/ @var bool サンドボックスが現在アクティブかどうか /
private bool $isActive = false;

/

• 新しいリクエストスコープ（サンドボックス）を開始する。
• ここでDIコンテナのインスタンスやリクエスト固有のグローバル状態を初期化する。

/
public function enterScope(ServerRequestInterface $request): void
{
if ($this->isActive) {
throw new \RuntimeException(‘前回のサンドボックスが正常に閉じられていません。メモリリークの危険性があります。’);
}

$this->isActive = true;
$this->destructors = [];

// リクエスト固有のグローバルステート（スーパーグローバル等の模倣・初期化）
$_GET = $request->getQueryParams();
$_POST = $request->getParsedBody() ?? [];
$_SERVER = array_merge($_SERVER, $request->getServerParams());
}

/

• 登録されたデストラクタ（クリーンアップ関数）を追加する。
• リクエスト中に生成された永続リソースやファイルハンドラなどをここに登録する。

/
public function registerDestructor(callable $destructor): void
{
if (!$this->isActive) {
throw new \LogicException(‘アクティブなサンドボックス外でデストラクタを登録することはできません。’);
}
$this->destructors[] = $destructor;
}

/

• サンドボックスを安全に終了し、割り当てられたリソースを解放・回収する。

/
public function leaveScope(): void
{
try {
// 登録されたクリーンアップタスクを逆順（LIFO）で実行
while ($destructor = array_pop($this->destructors)) {
try {
$destructor();
} catch (Throwable $e) {
// ログ出力のみ行い、残りのクリーンアップ処理を継続させる
error_log(sprintf(‘[Sandbox Error] Cleanup failed: %s’, $e->getMessage()));
}
}

// スーパーグローバル変数の強制クリア（次のリクエストへの汚染を防ぐ）
$_GET = [];
$_POST = [];
$_FILES = [];

// Zend GCの強制実行（必要に応じてサーキットブレーカー的に動作させる）
if (function_exists(‘gc_collect_cycles’)) {
// 循環参照を強制回収し、Zend MMの空きリストを整理
gc_collect_cycles();
}

} finally {
$this->isActive = false;
}
}

/

• サンドボックス内で安全にコールバックを実行する。
• 例外が発生した場合でも確実にメモリ解放を行わせるための高階関数パターン。

/
public function runInSandbox(ServerRequestInterface $request, callable $handler): ResponseInterface
{
$this->enterScope($request);

try {
/ @var ResponseInterface $response /
$response = $handler($request, $this);
return $response;
} catch (Throwable $e) {
// 例外発生時も確実にサンドボックスを閉じる
throw $e;
} finally {
$this->leaveScope();
}
}
}

実務での利用パターン：ミドルウェアとしての統合

上記のマネージャーをSwooleやRoadRunnerのPSR-15ミドルウェア、あるいはイベントループのコールバック内に組み込む。

namespace App\Http\Middleware;

use App\Core\Memory\RequestSandboxManager;
use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;
use Psr\Http\Server\MiddlewareInterface;
use Psr\Http\Server\RequestHandlerInterface;

final class SandboxMiddleware implements MiddlewareInterface
{
public function __construct(
private RequestSandboxManager $sandboxManager
) {}

public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface
{
// runInSandbox を用いてリクエスト処理全体を完全にカプセル化
return $this->sandboxManager->runInSandbox($request, function ($req, RequestSandboxManager $sandbox) use ($handler) {

// 例：データベースコネクションをサンドボックスに紐付け、終了時にクローズを保証
/
$dbConnection = new \PDO(‘dsn’, ‘user’, ‘pass’);
$sandbox->registerDestructor(function () use ($dbConnection) {
// 明示的にコネクションを切断し、ソケットリークを防ぐ
$dbConnection = null;
});
/

return $handler->handle($req);
});
}
}

—

4. コードレビューの視点：何が危険で、どう修正すべきか

レガシーなフレームワークのコードベースをSwoole環境に移植する際、コードレビューで必ずチェックすべき「アンチパターン」と、その修正アプローチを提示する。

🚨 危険なパターン 1: 静的プロパティ（Static）によるインスタンスのキャッシュ

// ❌ 致命的に危険なコード（常駐環境ではメモリリークとステート混濁を引き起こす）
class UserContext
{
private static ?self $instance = null;
private ?array $userData = null;

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

public function setUserData(array $data): void {
$this->userData = $data; // リクエストAのユーザーデータがリクエストBに漏洩する！
}
}

【なぜ危険か】
`self::$instance` はプロセスが生存している限りメモリ上に残り続ける。リクエストAでセットされたユーザー情報が、次のリクエストBを処理する別ユーザーにそのまま露出する（セキュリティインシデント）だけでなく、リクエストごとに生成されたオブジェクトが静的プロパティからの参照を維持し続けるため、GCの対象外となりメモリリークを引き起こす。

【正しいアプローチ】
シングルトンや静的プロパティによるステートの保持を完全に禁止し、DIコンテナのスコープ（リクエストスコープ）を利用して、リクエスト終了と共にインスタンスが破棄される設計へリファクタリングする。

—

5. まとめ

常駐型PHPランタイムの運用は、従来のFPMのような「甘え」を一切許さない。Zend VMのメモリモデル、参照カウント、Zend MMのヒープ確保の特性を深く理解し、「リクエスト終了時に何が残るか」を常に意識したアーキテクチャ設計が求められる。

カスタムメモリマネージャーによるサンドボックスの徹底は、単なるメモリリーク対策に留まらず、マルチテナントな常駐環境におけるセキュリティの担保そのものである。コードレビューの基準をブラッシュアップし、モダンで堅牢なPHPアプリケーションを構築してほしい。