分散トランザクションの極限制御：FiberとZend VMスタックが織りなす補償トランザクションの設計パターン
PHPにおける非同期並行処理のパラダイムは、Fiber（PHP 8.1+）の導入によって根本から塗り替えられた。もはやPHPは「1リクエスト＝1プロセス（またはスレッド）で同期的にブロックし続ける言語」ではない。しかし、マイクロサービスアーキテクチャの隆盛に伴い、複数サービスを跨ぐ「分散トランザクション」の整合性を如何に担保するかという古くて新しい課題に、我々アーキテクトは直面している。
本稿では、分散トランザクション（Sagaパターン等）の文脈において、FiberがZend VM上でどのようにコンテキストをスイッチし、非同期I/Oを調停するのか。そして、障害発生時にいかにして整合性を巻き戻す「補償トランザクション（Compensating Transaction）」を安全かつ高速に実行すべきか。その内部挙動とセキュリティ要件を含めた極限の知見を紐解く。
—
1. Zend VMとFiber：スタックレスからスタッカブルへの進化
従来のPHPでは、コールスタックはOSのCコールスタック（あるいはプレーンな関数呼び出しスタック）に直接依存していた。そのため、外部APIやDBからのレスポンスを待つ間（I/Oブロック）、PHPのプロセスはそのスレッドを占有し続け、CPU資源をドブに捨てる挙動をとっていた。
Fiberの本質は、「ユーザーランドで制御可能な独立したコールスタック（zend_execute_dataと実行コンテキスト）の切り替え」にある。
[Main Request Context]
└── zend_execute_data (Controller)
└── Fiber::suspend() ──┐
▼
[Fiber Context A]
└── zend_execute_data (Service A Client)
Zend VMの内部において、Fiberは `zend_fiber` 構造体として表現される。通常の関数コールが単一のスタックフレームを積み上げるのに対し、Fiberは独自のヒープ割り当てスタックを持ち、`zend_fiber_switchContext()` によってレジスタ状態と実行ポインタ（`opline`）をダイナミックに入れ替える。
この仕組みにより、複数のリモートサービス呼び出しを「同期的な記述スタイルのまま、非同期（協調的マルチタスク）で並行実行」することが可能になる。
—
2. 分散トランザクションとFiberによるSagaパターンの実装
分散環境では、ACID特性を保証する2相コミット（2PC）はレイテンシと可用性の観点から実用的ではない。そこで採用されるのが、各ローカルサービスのトランザクションを順次実行し、失敗時には逆順で「補償トランザクション」を発火させて状態を打ち消す Sagaパターン である。
以下に、Fiberを用いたイベント駆動型の非同期Sagaオーケストレータの核心部を示す。
/
private array $compensations = [];
private bool $failed = false;
/
- ステップを実行し、対応する補償処理をスタックに積む
/
public function step(callable $action, callable $compensation): mixed
{
if ($this->failed) {
return null;
}
try {
$result = $action();
// 成功した場合のみ、巻き戻し用の補償クロージャをLIFO（後入れ先出し）で積む
array_unshift($this->compensations, $compensation);
return $result;
} catch (Throwable $e) {
$this->failed = true;
$this->rollback();
throw $e;
}
}
private function rollback(): void
{
// 逆順（LIFO）で補償トランザクションを実行
foreach ($this->compensations as $compensate) {
try {
$compensate();
} catch (Throwable $criticalException) {
// 補償トランザクションの失敗はシステム全体の致命的不整合（要アラート＆手動介入）
error_log(sprintf(
‘[CRITICAL] Compensation failed: %s’,
$criticalException->getMessage()
));
}
}
}
}
/
- Fiberベースの非同期Sagaランナー
/
class AsyncSagaOrchestrator
{
/
- @param array
$fibers
/
public function executeParallel(array $tasks): void
{
$fibers = [];
$context = new SagaTransactionContext();
foreach ($tasks as $task) {
$fibers[] = new Fiber(function () use ($task, $context) {
// 各Fiber内で非同期I/O（非同期HTTPクライアント等）を擬似再現
$task($context);
});
}
// 初期起動
foreach ($fibers as $fiber) {
$fiber->start();
}
// イベントループの簡易シミュレーション：すべてのFiberがサスペンドまたは終了するまで調停
while (count($fibers) > 0) {
foreach ($fibers as $index => $fiber) {
if ($fiber->isTerminated()) {
unset($fibers[$index]);
continue;
}
if ($fiber->isSuspended()) {
// イベントループ（RevoltやEvなど）がI/O完了を検知して再開させる想定
// ここではシンプルにresumeを呼び出す
$fiber->resume();
}
}
}
}
}
この設計の優位性
各サービスへのリクエストをFiber上で並行走査させつつ、共有の `SagaTransactionContext` を通じてトランザクションの順序と依存関係を厳密に管理する。万が一、途中のステップで例外がスローされた場合、Fiberコンテキストの切り替えを停止し、即座にLIFO順で補償処理がチェーン実行される。
—
3. OPcacheとプリローディングの物理構造がもたらす罠
高スループットな非同期・分散処理システムを構築する際、PHP 7.4以降で導入された OPcache Preloading（プリローディング） は必須の最適化技術である。ソースコードのパースとコンパイル（AST生成からopcode生成まで）を起動時に一度だけ行い、共有メモリ（SHM）上に永続化することで、リクエストごとのオーバーヘッドをゼロにする。
しかし、Fiberや分散トランザクションを実装する上で、プリローディングと状態の持ち越し（State Leakage）に関する致命的な罠が存在する。
プリローディング時の注意点
1. グローバル状態の凍結: プリロードされたクラスのプロパティ（特に`static`変数）は、すべてのFPMプロセス間で共有される。ここにトランザクション固有のコンテキストやFiberインスタンスを保持させると、別リクエスト間でデータが混濁する（深刻なセキュリティインシデントに直結）。
2. クロージャのバインド: 補償トランザクションで使用するクロージャ（無名関数）が外部の可変変数をキャプチャしている場合、それがプリロード対象に含まれると、Zend VMの永続メモリ上に不正な参照が残り、セグメンテーションフォルト（Segmentation Fault）を引き起こす原因となる。
// 【危険なアンチパターン】
// static変数にリクエスト固有のトランザクション情報を保持してはならない
class SharedSagaRegistry {
private static array $activeContexts = []; // FPMプロセス間で共有されてしまう！
}
アーキテクトは、Fiber内で使用するオブジェクトやコンテキストが完全にリクエストスコープ（またはFiberスコープ）内に閉じ込められていることを、Zend VMのメモリ管理モデルを意識して担保しなければならない。
—
4. セキュリティハック：オブジェクトインジェクションとGadget Chainの防衛
分散トランザクションのデータペイロードをメッセージキュー（RabbitMQやKafkaなど）経由で非同期に伝播させる際、最も警戒すべきは PHPオブジェクトインジェクション（PHP Object Injection） である。
非同期ワーカーがペイロードを復元する際に安易に `unserialize()` を使用した場合、攻撃者が細工したシリアライズデータを送り込むことで、マジックメソッド（`__destruct()`, `__wakeup()` 等）を起点とした Gadget Chain が構築され、リモートコード実行（RCE）を許すことになる。
脆弱なコード例（絶対に行ってはならない実装）
// ワーカープロセス側での危険な処理
$payload = $queue->pop();
$sagaCommand = unserialize($payload); // 攻撃者が任意のクラスのインスタンスを注入可能
極限の防御策：JSONおよびDTO（Data Transfer Object）の厳格な型強制
PHPにおける安全なデータ伝播の唯一の解は、バイナリシリアライゼーションを完全に廃止し、厳密なスキーマを持つJSONデシリアライゼーション + DTOのコンストラクタインジェクションを採用することである。
declare(strict_types=1);
namespace Architecture\Security;
readonly class SagaCommandDTO
{
public function __construct(
public string $transactionId,
public string $serviceName,
public array $payload
) {}
public static function fromJson(string $json): self
{
$data = json_decode($json, true, 512, JSON_THROW_ON_ERROR);
// スキーマ検証と型の強制
if (!isset($data[‘transactionId’], $data[‘serviceName’], $data[‘payload’])) {
setValueException(‘Invalid payload schema’);
}
return new self(
transactionId: (string) $data[‘transactionId’],
serviceName: (string) $data[‘serviceName’],
payload: (array) $data[‘payload’]
);
}
}
この設計により、Zend VMのデシリアライザが勝手にインスタンスを生成する余地を完全に断ち切り、意図しないマジックメソッドの呼び出し（Gadget Chain）を物理的に封じ込めることができる。
—
5. チーフアーキテクトからの提言
PHPにおけるFiberと分散トランザクションの融合は、もはや実験的な試みではない。大規模トラフィックを捌くモダンなWebシステムにおいて、I/O待ちの無駄を排除し、ミリ秒単位で整合性を制御するための強力な武器となる。
しかし、それはZend VMのメモリ管理、OPcacheの挙動、そしてシリアライゼーションに潜む脆弱性のメカニズムを骨の髄まで理解しているエンジニアにのみ、その真価を授ける。フレームワークの便利さに逃げることなく、エンジンの内側からコードを支配せよ。それこそが、真のハイパフォーマンス・アーキテクチャへの唯一の道である。