PHP FiberとPromise/Futureの融合：Zend VMのコンテキストスイッチを支配する非同期合成の極意
PHP 8.1における `Fiber`（ファイバー）の導入は、言語の歴史におけるパラダイムシフトであった。長年にわたり、PHPの非同期処理といえば、`ext-async` や `ReactPHP`、`Amp` といったイベントループベースのライブラリが、コールバックやジェネレータ（`Generator`）のyieldを駆使して「スタックlessなコルーチン」をエミュレートするものでしかなかった。
しかし、スタックフルなコルーチンである `Fiber` の登場により、我々は任意の深さのコールスタックを中断（Suspend）し、別コンテキストへ処理を委譲し、任意のタイミングで再開（Resume）する能力を手に入れた。
本稿では、この `Fiber` を低レイヤのプリミティブとして使い捨てにするのではなく、現代の非同期アーキテクチャの根幹である Promise/Futureパターン と統合し、複雑な依存関係を持つ非同期処理の合成（Composition）をZend VMのメモリ効率とオーバーヘッドの限界まで最適化して実装する手法を解説する。
—
1. Zend VMにおけるFiberの物理構造とコンテキストスイッチのコスト
PHPの通常の関数呼び出しは、Zend VMの実行スタック（`zend_execute_data` の連結リスト）上で線形に処理される。関数が呼び出されるたびに新しいスタックフレームが割り当てられ、リターンアドレスやローカル変数が積まれていく。
`Fiber::suspend()` が呼び出されると、Zendエンジン内部で何が起きるのか。
1. スタックの退避: 現在の `zend_execute_data` チェーン、およびCレベルのコールスタックの一部がヒープ上に退避される。
2. VMレジスタの切り替え: 実行コンテキスト（`zend_fiber_context`）が別のファイバーの構造体にスワップされる。
3. 制御の返還: 親スコープ（通常はイベントループや呼び出し元）へ処理が戻る。
このメカニズムは強力だが、OSのスレッド切り替えに比べれば圧倒的に軽量（ユーザースペースのコンテキストスイッチ）とはいえ、ヒープアロケーションとZend VMの状態退避のオーバーヘッドがゼロではない。無秩序なFiberの乱立は、CPUキャッシュのヒット率を下げ、かえってスループットを悪化させる。
したがって、数千の非同期タスクを効率的に制御するためには、ファイバーを直接バラバラに管理するのではなく、Future/Promiseという抽象化層を挟み、イベントループと協調動作させる設計が不可欠となる。
—
2. Promise/Futureパターンによる非同期処理の合成
非同期プログラミングの本質は「未来の値（Future）」に対する「約束（Promise）」の連鎖と依存関係の解決にある。Fiberを内部に隠蔽し、外部からは標準的なPromiseインターフェースに見えるクラス群を設計する。
以下のコードは、Zend VMのメモリ構造と例外安全性を意識した、ゼロから構築する高パフォーマンスなPromise/Futureの実装骨子である。
namespace Architecture\Async;
use Fiber;
use Throwable;
class Future
{
private mixed $value = null;
private ?Throwable $exception = null;
private string $state = ‘pending’; // pending, fulfilled, rejected
/ @var array
private array $onFulfilled = [];
/ @var array
private array $onRejected = [];
public function __construct(callable $resolver)
{
// Promise構築時に即座に実行コンテキストを渡す
$resolve = function (mixed $value): void {
if ($this->state !== ‘pending’) return;
$this->value = $value;
$this->state = ‘fulfilled’;
foreach ($this->onFulfilled as $callback) {
$callback($this->value);
}
};
$reject = function (Throwable $reason): void {
if ($this->state !== ‘pending’) return;
$this->exception = $reason;
$this->state = ‘rejected’;
foreach ($this->onRejected as $callback) {
$callback($this->exception);
}
};
try {
$resolver($resolve, $reject);
} catch (Throwable $e) {
$reject($e);
}
}
/
- 現在のコンテキストを中断し、このFutureの解決を待機する（Fiber連携の核心）
/
public function await(): mixed
{
if ($this->state === ‘fulfilled’) {
return $this->value;
}
if ($this->state === ‘rejected’) {
throw $this->exception;
}
$fiber = Fiber::getCurrent();
if ($fiber === null) {
throw new \LogicException(‘Fiberの外部からawaitすることはできません。’);
}
// 状態が解決した際に、中断していたFiberを再開（Resume）するコールバックを登録
$this->onFulfilled[] = static fn($val) => $fiber->resume($val);
$this->onRejected[] = static fn(Throwable $err) => $fiber->throw($err);
// 処理を中断し、イベントループや親スコープへ制御を戻す
return Fiber::suspend();
}
public static function all(array $futures): self
{
return new self(function (callable $resolve, callable $reject) use ($futures) {
$count = count($futures);
if ($count === 0) {
$resolve([]);
return;
}
$results = [];
$completed = 0;
foreach ($futures as $index => $future) {
// 各Futureを非同期に解決させるためのサブFiberまたはチェーン
// ここでは簡略化のためコールバック連鎖を使用
$successCallback = function ($value) use ($index, &$results, &$completed, $count, $resolve) {
$results[$index] = $value;
$completed++;
if ($completed === $count) {
$resolve($results);
}
};
// 実際のプロダクションコードでは、ここでPromiseのthenチェーンを構築する
if ($future instanceof self) {
// 内部状態に応じたハンドリング
$future->onFulfilled[] = $successCallback;
$future->onRejected[] = $reject;
} else {
$successCallback($future);
}
}
});
}
}
この実装における最も重要なポイントは、`await()` メソッド内での `Fiber::suspend()` の利用である。これにより、開発者はコールバック地獄（Pyramid of Doom）に陥ることなく、同期コードと全く同じ見た目で非同期処理の結果を待機できる。
—
3. 依存関係管理とトポロジカルソートによるタスクグラフの構築
実際のエンタープライズWebシステムでは、単なる並行実行（`all`）だけでなく、「タスクBとタスクCが完了しなければ、タスクDを実行できない」といった DAG（有向非巡回グラフ）に基づく複雑な依存関係の解決 が求められる。
Promise/FutureとFiberを組み合わせることで、この依存関係の解決を極めて直感的なDSL（ドメイン固有言語）として表現できる。
namespace Architecture\Async;
class TaskGraph
{
/ @var array
private array $nodes = [];
/ @var array
private array $dependencies = [];
public function add(string $id, callable $task, array $dependsOn = []): void
{
$this->dependencies[$id] = $dependsOn;
$this->nodes[$id] = new Future(function (callable $resolve, callable $reject) use ($id, $task, $dependsOn) {
// 依存している全てのタスクが完了するのをFiber内で待機
$fiber = new Fiber(function () use ($id, $task, $dependsOn, $resolve, $reject) {
try {
// 依存タスクの解決を待つ
foreach ($dependsOn as $depId) {
if (!isset($this->nodes[$depId])) {
throw new \RuntimeException(“依存タスク ‘{$depId}’ が存在しません。”);
}
// 依存先のFutureをawaitすることで、自らの中断と再開をイベントループに委譲
$this->nodes[$depId]->await();
}
// 全ての依存がクリアされたため、自身を実行
$result = $task();
$resolve($result);
} catch (Throwable $e) {
$reject($e);
}
});
// Fiberの初回起動
$fiber->start();
});
}
public function get(string $id): Future
{
if (!isset($this->nodes[$id])) {
throw new \InvalidArgumentException(“タスク ‘{$id}’ は登録されていません。”);
}
return $this->nodes[$id];
}
}
実行例とZend VMの挙動
// イベントループの模擬的なエントリーポイント
$graph = new TaskGraph();
// タスクA: データベースからのユーザー情報取得（モック）
$graph->add(‘fetch_user’, function() {
// 実際にはここでNon-blocking I/O（ext-uvやSocket非同期読み込み）でsuspendする
Fiber::suspend();
return [‘id’ => 1, ‘name’ => ‘Architect’];
}, []);
// タスクB: ユーザーの権限取得（タスクAに依存）
$graph->add(‘fetch_permissions’, function() {
return [‘read’, ‘write’, ‘execute’];
}, [‘fetch_user’]);
// タスクC: 外部APIからのログ取得（独立）
$graph->add(‘fetch_audit_logs’, function() {
return [‘login_success’, ‘token_refresh’];
}, []);
// タスクD: 最終的なレスポンス構築（タスクBとタスクCの両方に依存）
$graph->add(‘build_response’, function() {
return “Response Ready with full permissions and logs.”;
}, [‘fetch_permissions’, ‘fetch_audit_logs’]);
// まとめて待機
$finalFuture = $graph->get(‘build_response’);
この構造の美しさは、コールバックのネストが完全に排除されている点にある。PHPの通常の制御構文（`try-catch` やループ、条件分岐）がそのまま非同期処理のフローコントロールとして機能する。Zend VMは通常のサブルーチン呼び出しと同じように例外のハンドリングやスコープの管理を行えるため、デバッグ時のコールスタックも非常にクリーンに保たれる。
—
4. OPcacheプリローディングとメモリ空間の最適化
大規模な非同期フレームワークやPromise/Futureライブラリをプロダクション環境（PHP-FPM）で運用する際、避けて通れないのが OPcacheプリローディング（Preloading） の活用である。
PHP 7.4以降で導入されたプリローディングは、サーバー起動時（`php.ini` の `opcache.preload`）に指定したスクリプトを読み込み、AST（抽象構文木）からオペコード（Opcode）へコンパイルした上で、共有メモリ（SHM: Shared Memory）上に永続化する機能である。
アーキテクチャ上の注意点：永続メモリとFiberの相性
Fiberのインスタンスや、動的に変化するPromiseの状態（`$value`, `$state`）はリクエスト毎のローカルヒープ（Zend Memory Manager）上に存在すべきであり、プリロードされたクラスの静的プロパティ（Static Properties）に非同期の実行コンテキストやコールバックキューを保持させてはならない。
もし静的プロパティにリクエスト固有のFutureやFiberインスタンスが混入した場合、複数のPHP-FPMワーカープロセス間でデータが汚染される（Data Race / State Bleed）という致命的なセキュリティ・整合性バグを引き起こす。
したがって、非同期ライブラリを設計する際は以下の鉄則を遵守する必要がある：
1. ステートレスなクラス設計: クラスのメソッドと定義のみをプリロード対象とし、状態はすべてインスタンスプロパティ（各リクエスト固有のZend Heap）に閉じ込める。
2. クロージャのバインド: プリロードされたクラス内で生成されるクロージャが、予期せずグローバルスコープや静的変数をキャプチャしないようにする。クロージャは極力 `static` 宣言（`static function()`）を付与し、バインドされたオブジェクト（`$this`）の暗黙的なキャプチャを防ぐ。
—
5. セキュリティハック：非同期コンテキストとオブジェクトインジェクションの脅威
高度な非同期処理やPromise/Futureを実装する際、オブジェクトのシリアライゼーション（`serialize()` / `unserialize()`）や、ユーザー入力をダイレクトにオブジェクトのプロパティへバインドする処理が混入すると、PHP Object Injection（オブジェクトインジェクション） のアタックサーフェイスが劇的に広がる。
特に、FiberやPromiseは内部に `callable`（クロージャや配列形式のコールバック）を保持するため、攻撃者が細工されたシリアライズデータを送り込んだ場合、マジックメソッド（`__destruct` や `__wakeup`）を起点とした Gadget Chain（ガジェットチェーン） の構築に極めて好都合なターゲットとなる。
脆弱性のメカニズムと防御
例えば、次のようなコードが存在すると仮定する：
// 【危険な実装例】不安全なデシリアライゼーションと非同期タスクの復元
class AsyncJob
{
private $taskCallback;
public function __destruct()
{
// デストラクターで勝手にコールバックを実行する設計は極めて危険
if (is_callable($this->taskCallback)) {
call_user_func($this->taskCallback);
}
}
}
攻撃者が `unserialize()` に不正な文字列を注入した場合、`AsyncJob` の `$taskCallback` にシステムコマンドを実行する関数（`system`, `exec` 等）や任意のクラスのメソッドを仕込むことで、RCE（Remote Code Execution）が成立する。
極限の防御策（Hardening）
1. シリアライゼーションの禁止: 非同期タスクのキューイングやFutureの内部状態を、信頼できない入力ソース（Cookie, HTTPリクエストボディ等）から直接 `unserialize()` しない。データの伝送には必ず JSON や MessagePack などのプレデータ構造を使用し、型安全なマッパーを通す。
2. `__wakeup` / `__sleep` の厳格なバリデーション: やむを得ずシリアライズを伴う場合は、マジックメソッド内で必ずクラスの整合性検証（HMAC等による署名検証）を行う。
3. 安全なコールバックのホワイトリスティング: クロージャや動的なコールバックをオブジェクトのプロパティとして永続化・復元することは避け、識別子（IDやハンドラー名）のみを保持し、コンテナから安全に解決するデザインパターンを徹底する。
—
6. チーフアーキテクトからの提言
PHPにおける Fiber と Promise/Future の統合は、もはや「動けばいい」おもちゃの非同期処理ではない。適切に設計されたイベントループと組み合わせることで、I/OバウンドなWebアプリケーションの限界スループットを何倍にも跳ね上げる強力な武器となる。
しかし、Zend VMの低レイヤ挙動、メモリ管理のライフサイクル、そしてオブジェクトインジェクションに代表されるセキュリティの脅威を理解せずして、真に堅牢な非同期アーキテクチャを構築することは不可能である。
コードの1行がどのようなオペコードに翻訳され、どのメモリ空間にアロケートされ、コンテキストスイッチの瞬間にCPUとVMがどう動くのか――常にその解像度を高く持ち続け、PHPという言語の限界をコードの美しさと強靭さで超越し続けろ。