Fiberを用いたリアルタイム監視システム：イベント駆動型アーキテクチャと状態同期
PHPによるWebアプリケーション開発において、「非同期処理」といえば、かつては`pcntl_fork()`を用いたマルチプロセッシングや、`ReactPHP` / `Amp`といったサードパーティ製イベントループライブラリによる協調マルチタスキングを意味していた。
しかし、PHP 8.1で導入されたFiber（ファイバー）によって、言語コアレベルでのスタックlessな（正確にはサスペンド可能なスタックを持つ）コルーチンが利用可能になった。これにより、コールバック地獄に陥ることなく、手続き型の直感的な記述を維持したまま、効率的な非同期・イベント駆動型アーキテクチャを構築できる。
今回は、プロダクション環境のサーバーリソースやアプリケーションの状態をリアルタイムで監視し、異常検知時に瞬時にアラートを発信するシステムを例に、Fiberを活用したイベント駆動型アーキテクチャと状態同期の極意を解説する。
—
1. なぜ「Thread」ではなく「Fiber」なのか：Zend VMとメモリ空間の真実
まず前提として、PHP（Zend VM）の実行モデルの本質を理解しなければならない。
PHPの実行スレッドは基本的にシングルスレッド（Shared-Nothing architecture）であり、リクエストライフサイクルごとに関数スタックやシンボルテーブル（`HashTable`）がアロケートされ、リクエスト終了とともに破棄される。
従来のマルチスレッド言語（JavaやGoなど）とは異なり、PHPで真のOSスレッドを乱立させると、Zend Memory Manager（ZMM）のコンテキストや拡張機能のグローバルステート（TSRM）が衝突し、セグメンテーションフォルトの温床となる。
一方、Fiberは同一OSスレッド（同一プロセス）上で動作する協調型（Cooperative）の実行単位である。
- 各Fiberは独自のコールスタックを持つが、メモリ上のヒープ領域やシンボルテーブルは親コンテキストと共有される。
- OSのコンテキストスイッチ（数マイクロ秒〜数十マイクロ秒のオーバーヘッド、CPUキャッシュのフラッシュ）が発生せず、純粋なユーザー空間でのジャンプ（`zend_fiber`構造体の切り替え）のみで動作する。
この特性を活かし、「I/O待ち」や「タイマー待ち」が発生した瞬間にFiberをサスペンド（`Fiber::suspend()`）させ、イベントループへ制御を返却することで、シングルスレッドでありながら数千の監視ターゲットを同時並行でハンドリングできる。
—
2. 堅牢なイベント駆動型監視エンジンの設計
リアルタイム監視システムにおいて最も避けるべきは、無限ループ内でのCPUビジーループ（CPUの無駄遣い）や、ブロッキングI/Oによるイベントループの凍結である。
ここでは、「非同期タイマー」「ノンブロッキングI/O（あるいは模擬的なストリーム監視）」「状態同期（共有メモリ/プロセス間通信）」を統合したイベント駆動型エンジンを構築する。
実務に耐えうるリファレンスコード
以下のコードは、複数の監視ターゲット（HTTPエンドポイント、ログファイル、システムリソース）をFiberで非同期に並行監視し、状態の変化をイベント駆動で検知・同期するコアエンジンの実装である。
/
class MonitoringEngine
{
/ @var array
private array $fibers = [];
/ @var array
private array $listeners = [];
/ @var array 監視対象の共有状態ストレージ /
private array $sharedState = [];
/
- 監視タスク（Fiber）をエンジンに登録する
/
public function registerTask(string $taskId, callable $taskLogic): void
{
$fiber = new Fiber(function () use ($taskId, $taskLogic) {
try {
// タスクロジックを実行し、必要に応じてサスペンドを繰り返す
$taskLogic(function ($mixed = null) {
// 処理を中断し、イベントループへ制御を戻す（yield）
return Fiber::suspend($mixed);
});
} catch (Throwable $e) {
// 例外がバブリングした場合、プロセス全体を落とさずイベントとして発火
$this->emit(‘error’, [‘task_id’ => $taskId, ‘exception’ => $e]);
}
});
$this->fibers[$taskId] = [
‘fiber’ => $fiber,
‘status’ => ‘init’,
‘next_run’ => microtime(true),
];
}
/
- イベントリスナーの登録
/
public function on(string $eventName, callable $listener): void
{
$this->listeners[$eventName][] = $listener;
}
/
- イベントの発火（Pub/Subパターン）
/
public function emit(string $eventName, mixed $data): void
{
if (!isset($this->listeners[$eventName])) {
return;
}
foreach ($this->listeners[$eventName] as $listener) {
$listener($data, $this->sharedState);
}
}
/
- イベントループの駆動（メインループ）
/
public function run(): void
{
echo “[Engine] リアルタイム監視エンジンを起動します…\n”;
// 初期状態のファイバーを開始
foreach ($this->fibers as $taskId => &$info) {
if ($info[‘status’] === ‘init’) {
$info[‘status’] = ‘running’;
$result = $info[‘fiber’]->start();
// 初回サスペンド時の戻り値やウェイト時間をハンドリング
if ($result && is_numeric($result)) {
$info[‘next_run’] = microtime(true) + $result;
}
}
}
unset($info);
// イベントループ本体
while (!empty($this->fibers)) {
$now = microtime(true);
$minSleep = 0.05; // デフォルトのアイドルスリープ (50ms)
foreach ($this->fibers as $taskId => &$info) {
/ @var Fiber $fiber /
$fiber = $info[‘fiber’];
// Fiberが終了している場合
if ($fiber->isTerminated()) {
unset($this->fibers[$taskId]);
continue;
}
// サスペンド中で、かつ再開時間が来ていない場合はスキップ
if ($fiber->isSuspended()) {
if ($now < $info['next_run']) {
$diff = $info['next_run'] - $now;
if ($diff < $minSleep) {
$minSleep = $diff;
}
continue;
}
// Fiberを再開（Resume）
try {
$resumeValue = null; // 必要に応じて外部からの入力を渡せる
$result = $fiber->resume($resumeValue);
// 次回の実行ウェイト秒数（float）を受け取る設計
if (is_numeric($result)) {
$info[‘next_run’] = microtime(true) + (float)$result;
} else {
$info[‘next_run’] = microtime(true) + 1.0; // デフォルト1秒後
}
} catch (Throwable $e) {
$this->emit(‘error’, [‘task_id’ => $taskId, ‘exception’ => $e]);
unset($this->fibers[$taskId]);
}
}
}
unset($info);
// CPUのスパイクを防ぐため、イベントがない隙間時間は微小スリープを入れる
if ($minSleep > 0) {
usleep((int)($minSleep 1_000_000));
}
}
echo “[Engine] すべての監視タスクが終了しました。\n”;
}
}
// ==========================================
// 実践：監視エンジンの初期化とタスク投入
// ==========================================
$engine = new MonitoringEngine();
// 1. 状態変化やアラートを検知した際の共通リスナー
$engine->on(‘alert’, function (array $data) {
printf(“[ALERT] [%s] 異常検知: %s (値: %s)\n”,
date(‘Y-m-d H:i:s’),
$data[‘target’],
$data[‘value’]
);
// ここでSlack WebhookやPagerDutyへの送信処理を非同期で行う設計が望ましい
});
$engine->on(‘error’, function (array $data) {
printf(“[ERROR] タスク [%s] で例外発生: %s\n”,
$data[‘task_id’],
$data[‘exception’]->getMessage()
);
});
// 2. 監視ターゲットA：API死活・レイテンシ監視タスクを登録
$engine->registerTask(‘api_health_check’, function (callable $suspend) use ($engine) {
$endpoint = ‘https://api.example.com/health’;
while (true) {
$start = microtime(true);
// 【重要】プロダクションではここを curl_multi や非同期HTTPクライアントに置き換える
// 今回は模擬的にシミュレーション
$isHealthy = (rand(1, 10) > 2); // 80%の確率で正常
$latency = (microtime(true) – $start) 1000;
if (!$isHealthy || $latency > 500) {
$engine->emit(‘alert’, [
‘target’ => $endpoint,
‘value’ => $isHealthy ? “高レイテンシ ({$latency}ms)” : “ダウン”,
]);
}
// 次回チェックまで「3秒間」Fiberをサスペンド（この間、他のタスクがCPUを占有できる）
// 戻り値として「3.0」を渡すことで、スケジューラ側に次回実行までのウェイトを伝える
$suspend(3.0);
}
});
// 3. 監視ターゲットB：システムリソース（ディスク使用量など）監視タスク
$engine->registerTask(‘disk_usage_check’, function (callable $suspend) use ($engine) {
while (true) {
// 実際の環境では disk_free_space / disk_total_space を使用
$usagePercent = rand(50, 95);
if ($usagePercent > 90) {
$engine->emit(‘alert’, [
‘target’ => ‘/var/log ディスク容量’,
‘value’ => “{$usagePercent}% 逼迫”,
]);
}
// 10秒ごとにチェック
$suspend(10.0);
}
});
// エンジン起動（無限ループへ突入）
// $engine->run();
—
3. 実務における設計上の罠とアンチパターン
コードレビューで必ず指摘すべき、Fiber利用時の致命的なアンチパターンを整理する。
1. サスペンド境界を跨いだブロッキング関数の実行
Fiberの最大にして唯一の弱点は、「PHPのコアや拡張機能が提供するブロッキングI/O（例: 素の `file_get_contents()` や `PDO::query()` など）」を呼び出した瞬間、OSスレッド全体がブロックされるという点である。
これにより、同じスレッド上で動いている他のすべてのFiberが完全に停止（凍結）する。
> 解決策:
> ネットワークI/Oを行う場合は、必ず非同期対応のネットワーククライアント（AmpのHTTPクライアントや、`stream_select` をベースにしたノンブロッキングストリーム）を使用し、I/O待ちの間に `Fiber::suspend()` を挟まなければならない。
2. 例外のバブリングとFiberコンテキストの喪失
Fiber内部で未キャッチの例外が発生した場合、そのFiberは即座に `terminated` 状態になり、例外は `Fiber::resume()` を呼び出した親スコープ（イベントループ側）へ伝播する。
もしイベントループ側で適切に `try-catch` でガードしていない場合、監視システム全体がクラッシュする。
> 解決策:
> 上記のリファレンスコードのように、Fiberのクロージャ内部で必ず `try-catch` を記述し、エラーイベントとして安全に外へ通知する設計（Error Boundaryの構築）が必須である。
3. メモリリーク（閉包による参照の肥大化）
Fiberは明示的に破棄（あるいはガベージコレクト）されるまで、内部のクロージャ（`Closure`）が保持しているスコープ内の変数をメモリ上に維持し続ける。監視タスクが数千・数万と動くシステムにおいて、巨大な配列やデータベースコネクションをクロージャ内にキャプチャし続けると、Zend Memory Managerのヒープが肥大化し、OOM（Out of Memory）を引き起こす。
> 解決策:
> クロージャに渡す変数は最小限（必要なIDや設定値のみ）に絞り、オブジェクトのライフサイクルを厳密に管理する。
—
4. チーフアーキテクトからの総括
PHPにおけるFiberは、Node.jsのasync/awaitやGoのgoroutineとは異なる。あくまで「手続き型の記述力を保ったまま、言語ランタイムに協調型マルチタスクを組み込むためのプリミティブ」である。
リアルタイム監視システムのような、膨大なターゲットに対する定期的な死活・リソース確認を行うシステムにおいて、Fiberを適切にイベントループと統合することは、プロセス資源を極限まで節約しつつ、リアルタイム性を担保するための極めて強力な武器となる。
「なぜ今、この処理をサスペンドさせる必要があるのか」「このI/Oは本当にノンブロッキングか」。この問いを常にコードの行間に持ち続け、Zend VMの挙動を脳内でトレースしながら設計を極めてほしい。