FiberとPHP-FPMの連携：プロセスの壁を越えられない非同期処理の現実と解法
PHP 8.1で導入された `Fiber` は、長らくPHPコミュニティの悲願であった「スタックフルな協調的マルチタスク（コルーチン）」をもたらした。I/Oバウンドな処理、例えば外部APIへのリクエストやデータベースへのクエリ発行において、イベントループと組み合わせることでブロッキングを回避し、スループットを劇的に向上させる――理論上は、そう語られている。
しかし、コードレビューの現場で、この `Fiber` を「Node.jsやGoの感覚」で素朴にPHP-FPM環境へ持ち込み、致命的な設計ミスを引き起こしているコードに遭遇することが後を絶たない。
結論から言おう。PHP-FPM環境下において、Fiber単体でGo言語のGoroutineのような非同期並行処理の恩恵をフルに受けることはできない。 いや、正確に言えば、FPMという「1リクエスト＝1プロセス（またはプールによる再利用）」のアーキテクトニクスを無視してFiberを導入すれば、メモリリーク、リクエスト間の状態汚染（State Pollution）、そしてデバッグ不能なゾンビプロセスの温床となる。
今回は、Zend VMのメモリ管理とPHP-FPMのプロセスライフサイクルという低レイヤの現実を踏まえ、実務で安全にFiberを運用するための極限の知見を伝授する。
—
1. なぜPHP-FPMとFiberの相性は「最悪」になり得るのか
共有されざるメモリ空間と、再利用されるプロセス
PHP-FPMは、リクエストが完了してもプロセスを終了せず、次のリクエストのためにプロセスを保持し続ける（`pm.max_requests` に達するまで）。これは高速化のための優れた設計である反面、グローバルスコープや静的変数（`static`）、さらにはZendエンジン内部のシンボルテーブルに残存したデータが、次のリクエストに持ち越されるリスクを常に孕んでいる。
ここでFiberが登場する。Fiberは「中断された実行コンテキスト（コールスタックとローカル変数）」をオブジェクトとしてヒープ上に保持する。もし、このFiberのインスタンスや、その中で保持されているクロージャが静的プロパティやシングルトン、あるいは長期生存するオブジェクトに参照された場合、何が起きるか？
リクエストを跨いだメモリリークと、ユーザーAのコンテキスト（認証情報など）がユーザーBのリクエストに漏洩するセキュリティインシデントである。
FPMは「イベントループ」を持っていない
Node.jsやReactPHP、Ampなどの真の非同期ランタイムは、プロセス内に単一のイベントループ（epoll/kqueueのラッパー）常駐させ、I/Oの完了を待ち受ける。
しかし、PHP-FPMのライフサイクルはこうだ：
1. HTTPサーバー（Nginx等）からリクエストを受け取る
2. PHPスクリプトが起動し、トップから実行される
3. スクリプトが終了（`exit` または `main` の終端に到達）する
4. プロセスが次のリクエスト待ちに戻る
この「3」の時点で、プロセスが終了していなければイベントループは死ぬ。つまり、FPM上でFiberをサスペンド（中断）させたままリクエストを終了させることはできない。Fiberは、あくまで「1つのリクエストのライフサイクル内での複雑な制御フロー（ジェネレータの超強力版）」として完結させなければならないのだ。
—
2. 実務で耐えうるFiber設計の鉄則
PHP-FPM環境でFiberを安全に利用するための原則は以下の3つに集約される。
1. リクエスト境界を越えてFiberを持ち越さない（インスタンスの完全な破棄）
2. 静的変数やシングルトンにFiberやそのコールバックを格納しない
3. イベントループ（Amp v3やReactPHP等）と組み合わせる場合は、FPMの同期モデルとの境界を明確にする
これらを無視した設計は、コードレビューにおいて「即座のリジェクト対象」となる。
—
3. 【実装例】FPM環境下で安全に並行HTTPリクエストを処理する堅牢な実装
ここでは、非同期I/Oの恩恵を受けつつ、リクエスト終了時に完全に状態がクリーンアップされる、実務レベルの堅牢なコードパターンを示す。ReactPHPやAmpのような外部ライブラリのミニマライズされた挙動を想定し、単一リクエスト内で複数の外部APIをFiberで協調的に並行取得する例だ。
declare(strict_types=1);
namespace App\Concurrency;
use Fiber;
use Throwable;
/
- 簡易的なイベントループとFiberを統合した非同期HTTPクライアントマネージャー。
- リクエスト終了時に必ず全コンテキストが破棄されるようカプセル化されている。
/
class SafeFiberDispatcher
{
/ @var array
private array $fibers = [];
/ @var array
private array $results = [];
/
- 非同期で実行したいタスク（クロージャ）をFiberとして登録する
/
public function add(int $id, callable $task): void
{
$fiber = new Fiber(function () use ($task, $id) {
try {
// Fiber内での処理（ブロッキングなI/Oの代わりに模擬的な非同期処理）
$result = $task();
$this->results[$id] = [‘status’ => ‘fulfilled’, ‘value’ => $result];
} catch (Throwable $e) {
// 例外がFiber内でキャッチされない場合、FPMをクラッシュさせずにハンドリング
$this->results[$id] = [‘status’ => ‘rejected’, ‘reason’ => $e->getMessage()];
}
});
$this->fibers[$id] = $fiber;
}
/
- すべてのFiberを協調的に実行（イベントループのイテレーションを模倣）
/
public function run(): array
{
// 初回起動
foreach ($this->fibers as $fiber) {
if (!$fiber->isStarted()) {
$fiber->start();
}
}
// 協調的マルチタスクのシミュレーション（I/O待ちを想定したループ）
$active = true;
$loops = 0;
$maxLoops = 1000; // デッドロック防護壁
while ($active && $loops < $maxLoops) {
$active = false;
$loops++;
foreach ($this->fibers as $id => $fiber) {
if (!$fiber->isTerminated()) {
$active = true;
// 必要に応じてここでサスペンドからの再開を行う
if ($fiber->isSuspended()) {
$fiber->resume();
}
}
}
// CPUのスパイクを防ぐための極小ウェイト（実環境では非同期セレクターに置き換わる）
usleep(1000);
}
if ($loops >= $maxLoops) {
throw new \RuntimeException(‘Fiber execution timeout: Possible deadlock detected.’);
}
return $this->results;
}
/
- デストラクタ：リクエスト終了時にメモリリークを防ぐため確実に参照を切断する
/
public function __destruct()
{
$this->fibers = [];
$this->results = [];
}
}
// ==========================================
// 【コントローラー層での利用例】
// ==========================================
try {
$dispatcher = new SafeFiberDispatcher();
// タスクA: 外部API-1の呼び出しを模倣
$dispatcher->add(1, function () {
// 実務ではここにAmp HTTPクライアント等の非同期処理が入る
usleep(50000); // 50ms待機を模倣
return “API Response A”;
});
// タスクB: 外部API-2の呼び出しを模倣
$dispatcher->add(2, function () {
usleep(30000); // 30ms待機を模倣
return “API Response B”;
});
// 並行実行の開始と結果の回収
$responses = $dispatcher->run();
// レスポンスの処理
header(‘Content-Type: application/json’);
echo json_encode([
‘success’ => true,
‘data’ => $responses,
]);
} catch (Throwable $e) {
// 予期せぬエラーの捕捉
http_response_code(500);
echo json_encode([
‘success’ => false,
‘error’ => $e->getMessage(),
]);
} finally {
// PHP-FPM環境において、グローバルな汚染を残さないための明示的なGC誘導
unset($dispatcher);
gc_collect_cycles();
}
—
4. コードレビューの視点：なぜこの実装が安全なのか
上記のコードには、PHP-FPMの挙動を熟知したアーキテクトならではの防衛的プログラミングが組み込まれている。
1. `__destruct()` と明示的な `unset()`
PHP-FPMでは、スクリプトの実行が終了しても、プロセスが生きている限りインスタンスがメモリ上に残り続けることがある（グローバルスコープに変数が残った場合など）。デストラクタで `$this->fibers` や `$this->results` を空にし、さらにコントローラーの `finally` ブロックで `gc_collect_cycles()` を呼ぶことで、循環参照やFiberオブジェクトが保持するクロージャのスタックフレームが次のリクエストに漏れ出すのを物理的に遮断している。
2. デッドロック防護壁（`$maxLoops`）
協調的マルチタスクにおいて、サスペンドされたFiberが二度と再開（resume）されない実装ミス（ロジックバグ）を犯した場合、プロセスは無限ループに陥り、Nginxからのタイムアウト（504 Gateway Time-out）までFPMワーカーを1つ占有し続ける。この「ワーカー枯渇攻撃」を自ら引き起こさないために、ループ回数にハードリミットを設けることは、プロダクション環境では必須の防衛策である。
3. 例外のFiber内カプセル化
Fiber内でスローされた未処理例外は、親スコープの振る舞いを破壊する。これを `try-catch` で確実にキャッチし、結果ステータス（`rejected`）として正規化することで、イベントループ全体の崩壊を防いでいる。
—
結び：PHPの本質を見失うな
Fiberは強力な道具であり、適切に使えばI/O待ちの無駄を削ぎ落とした高スループットなAPIサーバーをPHPで構築できる。しかし、それは「PHPがプロセスモデルを捨てて常駐型（RoadRunnerやFrankenPHP、Swooleなど）として動いている場合」において、最も真価を発揮する。
もしあなたのシステムが依然としてトラディショナルな PHP-FPM で稼働しているのであれば、Fiberはあくまで「1リクエスト内の複雑な非同期処理を綺麗に記述するためのシンタックスシュガー・制御構文」として控えめに扱うべきだ。
フレームワークやライブラリが提供するマジックに頼るな。Zend VMがメモリをどう割り当て、FPMがプロセスをどうリサイクルしているか。その低レイヤの物理法則を理解した者だけが、真に堅牢で高速なWebシステムを構築できる。