Fiberの永続化とZend VMの深淵：非同期コンテキストのシリアライゼーションと脆弱性の境界線
PHP 8.1で導入された`Fiber`（ファイバー）は、PHPにおける非同期プログラミングのパラダイムを根本から書き換えた。スタックフルな協調的マルチタスク（Cooperative Multitasking）を実現するFiberは、I/O待ちのブロッキングを回避し、コールバック地獄（Pyramid of Doom）からコードを解放した。
しかし、ここでエンジニアリングの根源的な問いが生まれる。
「HTTPリクエストのライフサイクルという、短命な境界線を超えてFiberの実行状態（コンテキスト）を保存し、別プロセスや未来のタイムラインで再開することは可能なのだろうか？」
本稿では、Zend VMのメモリ管理、シリアライゼーションの限界、そしてPHPオブジェクトインジェクション（Object Injection）が引き起こすセキュリティ上の致命的な罠に至るまで、PHPエンジンの深層を暴きながらFiberの状態永続化の極限を解き明かす。
—
1. Zend VMにおけるFiberの物理構造：何がメモリ上にあるのか
PHPの通常の関数実行はコールスタック（CスタックおよびZend VMの実行スタック）に依存し、関数がリターンすればその文脈（ローカル変数、実行ポインタ、オペコードのインデックス）は消滅する。
しかし、`Fiber::suspend()`がコールされると、Zend VMはその時点での実行コンテキスト（zend_execute_data、ローカル変数、レジスタ状態、評価スタック）をヒープ上に切り出す。これがFiberの正体である。
[通常のライフサイクル]
Request Start -> Execute Opcode -> Return/Exit -> Memory Freed (Zend Memory Manager)
[Fiberのライフサイクル]
Request Start -> Fiber::suspend() -> zend_execute_data spilled to Heap -> Request End
│
Future Request/Event Loop <--- Fiber::resume() <--- Serialized/Persisted State
しかし、このヒープ上に退避された状態は、あくまで単一のPHPプロセス（SAPIプロセス）のメモリ空間内に閉じている。FPM（FastCGI Process Manager）のプロセスが終了すれば、プロセス空間とともにこのメモリはOSに返却される。したがって、複数リクエスト間にまたがる永続化やサーバー再起動への耐性を持たせるには、この非同期コンテキストをシリアライズし、外部ストレージ（Redis, DBなど）へ退避させる必要がある。
—
2. Fiberインスタンスのシリアライゼーションの壁
結論から述べよう。PHPの標準機能である`serialize()`や`json_encode()`を使い、実行中の`Fiber`インスタンスをそのままシリアライズすることは不可能である。
なぜなら、Fiberの内部構造体には、現在の実行位置を示すポインタ（OPコードへのメモリ上の実アドレス）、Cレベルのコールスタックへの参照、そしてリソース（データベース接続やファイルハンドルなど）といった、プロセス固有の volatile なポインタが深く絡み合っているからだ。これらをそのままバイト列に変換しても、別プロセスで復元した際にメモリ上のアドレスが無効となり、即座にセグメンテーションフォルト（Segmentation Fault）を引き起こすか、Zendエンジンによって安全に例外がスローされる。
では、どうするか？
「Fiber自体のシリアライズ」を諦め、「Fiberを構成する状態（State）とクロージャのクロージャ変数（Lexical Scoping）」を永続化し、復元時にFiberを再構築するというアーキテクチャを採用しなければならない。
以下のコードは、状態を保持し、永続化・復元可能な非同期タスクの設計パターンを示す。
/
interface PersistentTaskInterface
{
public function getState(): array;
public function setState(array $state): void;
public function execute(): void;
}
class OrderProcessTask implements PersistentTaskInterface
{
private int $step;
private string $orderId;
private float $amount;
public function __construct(string $orderId, float $amount, int $step = 1)
{
$this->orderId = $orderId;
$this->amount = $amount;
$this->step = $step;
}
public function getState(): array
{
// 永続化対象となるプリミティブな状態のみを抽出
return [
‘step’ => $this->step,
‘orderId’ => $this->orderId,
‘amount’ => $this->amount,
];
}
public function setState(array $state): void
{
$this->step = $state[‘step’];
$this->orderId = $state[‘orderId’];
$this->amount = $state[‘amount’];
}
public function execute(): void
{
// Fiber内で実行されるロジック
switch ($this->step) {
case 1:
echo “Step 1: 注文 {$this->orderId} の在庫を仮確保中…\n”;
// 外部API呼び出しやI/O待ちを模してサスペンド
Fiber::suspend(‘waiting_for_inventory’);
$this->step = 2;
// breakせず続行可能なら続ける、あるいは次のリクエストで再開
case 2:
echo “Step 2: 注文 {$this->orderId} の決済処理（金額: {$this->amount}）…\n”;
Fiber::suspend(‘waiting_for_payment’);
$this->step = 3;
case 3:
echo “Step 3: 注文 {$this->orderId} の確定処理完了。\n”;
$this->step = 99; // 完了
break;
}
}
}
このアプローチでは、`Fiber`そのものを保存するのではなく、`OrderProcessTask`の持つ純粋な配列データ（State）だけをRedisやRDBにシリアライズして保存する。そして、次のリクエストやイベントループのタイミングで、新しいFiberインスタンスを生成し、状態を復元して再開（Resume）させる。
—
3. 永続化ストレージとシリアライゼーションの暗黒面：オブジェクトインジェクションの脅威
ここで、セキュリティアーキテクトとして警鐘を鳴らさなければならない致命的な罠がある。
「状態の永続化」のために `serialize()` / `unserialize()` を安易にデータベースやセッションストレージと組み合わせた瞬間、アプリケーションはPHP Object Injection（オブジェクトインジェクション）の地雷原と化す。
脆弱性のメカニズム
攻撃者が悪意あるペイロードをRedisやデータベースの該当レコードに書き込むことに成功した場合、PHPがそれを `unserialize()` する際、任意のクラスのインスタンスが復元される。その過程で、以下のマジックメソッドが自動的に（かつ暗黙的に）実行される。
- `__wakeup()`
- `__destruct()`
- （PHP 8以降では廃止傾向にあるが）`__toString()` など
もしアプリケーション内に、デストラクタやウェイクアップメソッド内で危険な操作（例：ファイルの自動削除、任意のコマンド実行、ガジェットチェーンを構成する既存ライブラリのメソッド呼び出し）を行うクラス（Gadget Class）が存在すれば、攻撃者はRCE（Remote Code Execution：リモートコード実行）を達成できる。
防御策：安全なシリアライゼーションの強制
非同期コンテキストやFiberの状態を永続化する際、生の `serialize()` を使用してはならない。必ず以下のいずれかの厳格なルールを適用せよ。
1. JSONの強制: 永続化データはプレーンな配列またはDTO（Data Transfer Object）に限定し、`json_encode()` / `json_decode(…, true)`（連想配列モード）のみを使用する。JSONは任意のオブジェクトインスタンスを勝手に復元しないため、オブジェクトインジェクションの脆弱性を根本から断つことができる。
2. 安全なカスタムシリアライザ: やむを得ずオブジェクト構造を保持する場合は、`Serializable`インターフェースや `__serialize()` / `__unserialize()` を実装し、復元時に厳格なホワイトリスト検証（Allowed Classes）を行う。
/
public static function persist(PersistentTaskInterface $task, \Redis $redis): void
{
$payload = [
‘class’ => get_class($task),
‘state’ => $task->getState(),
];
// 厳格にJSON形式で保存。オブジェクトインジェクションを物理的に阻止。
$redis->set(‘task:’ . get_class($task), json_encode($payload, JSON_THROW_ON_ERROR));
}
/
- 安全にタスクを復元
/
public static function restore(string $className, \Redis $redis): ?PersistentTaskInterface
{
$data = $redis->get(‘task:’ . $className);
if (!$data) {
return null;
}
$payload = json_decode($data, true, 512, JSON_THROW_ON_ERROR);
// ホワイトリスト検証（型安全性の担保）
$targetClass = $payload[‘class’];
if (!class_exists($targetClass) || !is_subclass_of($targetClass, PersistentTaskInterface::class)) {
throw new \SecurityException(“不正なクラスの復元が試行されました: {$targetClass}”);
}
/ @var PersistentTaskInterface $task /
$task = new $targetClass();
$task->setState($payload[‘state’]);
return $task;
}
}
—
4. OPcacheプリローディングとFiberの協調
高負荷な非同期・永続化アーキテクチャを構築する際、見落とされがちなのがOPcacheプリローディング（Preloading）の影響である。
PHP 7.4以降、OPcacheはスクリプトを共有メモリ（SHM）に事前コンパイルし、リクエストごとのファイルI/Oとパースコストをゼロにするプリローディング機能を提供している。Fiberを利用したタスク管理クラスやイベントループのコアロジックは、必ず `php.ini` の `opcache.preload` を通じてプリロード領域に常駐させるべきである。
; php.ini の極限チューニング例
opcache.enable=1
opcache.memory_consumption=512
opcache.interned_strings_buffer=64
opcache.max_accelerated_files=20000
opcache.preload=/var/www/html/config/preload.php
opcache.preload_user=www-data
プリロードされたクラスは、全FPMプロセス間でメモリが共有（Copy-on-Writeのベースとなる）されるため、Fiberのインスタンス生成やコンテキストスイッチにおけるメモリオーバーヘッドを極限まで低減できる。
—
結び：エンジニアの責務としての低レイヤ理解
Fiberは魔法の杖ではない。それを非同期処理の銀の弾丸として雑に扱うことは、Zend VMのメモリモデルやPHPのSAPIの境界を無視した危険な設計を生む。
Fiberの状態を永続化するということは、「実行コンテキストの抽象化、シリアライゼーションの限界の把握、そしてオブジェクトインジェクションというセキュリティリスクとの闘い」の三位一体を制圧することに他ならない。
フレームワークが隠蔽する抽象のレイヤを剥ぎ取り、CPUキャッシュ、OPcacheの共有メモリ、そしてZend VMのオペコード実行のダイナミクスまで見通す視座を持って初めて、真に堅牢で爆速な非同期Webシステムが構築できる。コードの裏側で何が起きているか、その全容を把握してコードを書け。