こんにちは。PHPの裏側を覗く旅へようこそ。
他の言語（GoのGoroutineやNode.jsのイベントループなど）を深く知っている優秀なエンジニアほど、PHPのコードを書くときに「このリクエスト終端型の世界観で、どうやって数万件もの同時I/Oをさばくんだ？」と、一種のモヤモヤを抱えたことがあるのではないでしょうか。従来のPHPは「1リクエスト＝1プロセス（または1スレッド）」の力技でスケールしてきましたが、モダンなPHPは違います。
今回は、PHP 8.1で導入されたFiber（ファイバー）と、SwooleやRoadRunnerといった現代のアプリケーションサーバーが持つイベントループ（epoll/kqueue）が裏側でどう組み合わさり、私たちのコードを極限まで高速化しているのか、その全貌を低レイヤの視点から解き明かしていきましょう。
ここを理解すると、PHPという言語の見え方がガラリと変わり、まるでC言語やGoを扱うかのように洗練された非同期アーキテクトの視点が手に入りますよ。
—
1. 従来のPHPの限界と「協調的マルチタスク」の本質
まず、私たちが普段書いているPHPコードが、Zendエンジンの中でどう実行されているかを思い出してください。
PHPスクリプトはパースされ、オペコード（Opcode）に変換され、Zend VM上で上から下へと実行されていきます。関数呼び出しやループはすべてコールスタックに積み上げられます。
従来の同期I/O（例: データベースへの問い合わせや、`file_get_contents`での外部APIコール）では、レスポンスが返ってくるまでの間、OSのスレッドやPHPプロセスは「待たされる（ブロックされる）」ことになります。CPUは膨大なクロックサイクルをドブに捨てている状態です。
プリプリエンプティブ vs 協調的（Cooperative）
- OSスレッド（プリプリエンプティブ）: カーネルが強制的にコンテキストスイッチを行い、CPU割り当てを切り替えます。安全ですが、メモリ消費（スタックサイズ）が大きく、数万ものスレッドは扱えません。
- Fiber（協調的マルチタスク）: カーネルは関知しません。「ここまで処理したら、自分でいったん止まって（Suspend）、制御をイベントループに返す」という協調動作を、ユーザーランド（PHPコード側）の意思で行います。
Fiberの本質は、「PHPの実行コンテキスト（コールスタック）をオブジェクトとして第一級市民（First-Class Citizen）に昇格させ、中断・再開を自在にコントロールする仕組み」に他なりません。
—
2. 裏側の舞台裏：epoll/kqueueとイベントループの協調
では、Fiberを単独で使えば高速になるかと言うと、実はそうではありません。Fiberは「中断と再開の機構」でしかないからです。「何をトリガーに再開させるのか？」を管理するのが、SwooleやRoadRunner（ReactPHPやAmp含む）の裏側でうごめくイベントループ（Epoll / Kqueue）です。
Linuxカーネルの `epoll` や macOSの `kqueue` は、数万のソケット記述子（File Descriptor）を監視し、「このソケットからデータが読めるようになったよ」「書き込み可能になったよ」という通知をカーネル空間からユーザー空間へ効率的に伝達する仕組みです。
理想的な非同期リクエストのライフサイクル
1. リクエスト発生: アプリケーションサーバー（Swooleなど）がイベントループ上でHTTPリクエストを受け取る。
2. Fiberの起動: リクエストごとに新しいFiberインスタンスを作成し、その中でビジネスロジックを実行する。
3. I/Oの非同期化（サスペンド）: データベースにクエリを投げる際、ソケットを非同期モード（Non-blocking）にし、イベントループに「このソケットにデータが来たら、このFiberを再開してくれ」と登録（登録完了後、現在のFiberは `Fiber::suspend()` で即座に中断）。
4. イベントループの巡回: Fiberが中断したことで、CPUは即座に別のリクエストのFiberの処理に移る（シングルスレッドまたはイベントドリブンなプールで高スループットを維持）。
5. 再開（レジューム）: カーネルから「データ到着」の通知を受けたイベントループが、該当するFiberに対して `Fiber::resume()` を呼び出し、停止した行から処理を復帰させる。
この一連の流れにより、「CPUを1秒たりとも遊ばせない、ノンブロッキングな並行処理」がPHP上で完結します。
—
3. 実践：Swoole環境下におけるFiberスケジューリングの最適化コード
言葉だけでは抽象的なので、Swooleのコルーチン（Swooleの内部でFiberを極限まで最適化したもの）や、モダンなイベントループ基盤で動くような、I/O多重化を意識した実践的なコードのイメージを見てみましょう。
/
class AsyncHttpDispatcher
{
private array $endpoints;
public function __construct(array $endpoints)
{
$this->endpoints = $endpoints;
}
/
- 複数の外部APIへ並行リクエストを送り、すべての結果を最短時間で回収する
/
public function fetchAll(): array
{
$results = [];
$fibers = [];
foreach ($this->endpoints as $key => $url) {
// 各リクエストごとに独立したFiberを生成
$fibers[$key] = new \Fiber(function () use ($url) {
// 1. ソケットをノンブロッキングでオープンし、非同期I/Oをイベントループに委譲
// （内部的にはここでFiberが中断され、レスポンス到着時に自動でレジュームされる）
$response = $this->asyncCurlGet($url);
return $response;
});
}
// すべてのFiberを起動（最初のサスペンドポイントまで実行される）
foreach ($fibers as $key => $fiber) {
$fiber->start();
}
// イベントループの擬似的な完了待機
// すべてのFiberが終了（Terminated）するまでCPUリソースを効率的に譲り合う
$active = true;
while ($active) {
$active = false;
foreach ($fibers as $key => $fiber) {
if (!$fiber->isTerminated()) {
$active = true;
// ※実際のフレームワークではイベントループが自動管理するため、
// ここで明示的にポーリングする必要はありません。
} else {
// 終了したFiberから結果を回収
$results[$key] = $fiber->getReturn();
}
}
// CPUのビジークロスを防ぐための微小なスリープ（イベントループのティック）
usleep(1000);
}
return $results;
}
/
- 非同期CURL通信のモック（内部でepoll等のイベント通知を待つ想定）
/
private function asyncCurlGet(string $url): string
{
// ここで実際の非同期通信ライブラリやSwoole\Coroutine\Http\Clientを使用する
// 処理が完了するまでこのFiberは停止し、他のFiberに処理のバトンが渡る
// シミュレーションとしての待機（実際にはイベントループがノンブロッキングで処理）
\Fiber::suspend();
return “Response from {$url}”;
}
}
// 実行イメージ
$dispatcher = new AsyncHttpDispatcher([
‘api_user’ => ‘https://api.example.com/users’,
‘api_order’ => ‘https://api.example.com/orders’,
‘api_item’ => ‘https://api.example.com/items’,
]);
// 従来の同期的処理であれば、3つのAPIのレイテンシが「直列（A + B + C）」に加算されますが、
// Fiberとイベントループの協調により「最遅のAPIのレイテンシ（max(A, B, C)）」へと劇的に短縮されます。
$startTime = microtime(true);
// $results = $dispatcher->fetchAll();
// echo “Executed in ” . (microtime(true) – $startTime) . ” seconds\n”;
—
4. アーキテクトが直面する罠と、パフォーマンスを極限まで引き出すチューニングの知見
実務でこのアーキテクチャを導入する際、Zend VMのメモリ管理とイベントループの特性上、いくつか絶対に知っておくべき「落とし穴」があります。ここを知っているかどうかが、プロのアーキテクトと単なるツールの使い手を分ける境界線です。
① ブロッキング関数の混入による「イベントループの凍結（Starvation）」
Fiberの内部やイベントループが稼働しているスレッド上で、もし伝統的な同期関数（例: `sleep()`, 従来の重い `PDO` によるブロッキングクエリ、ファイルシステムの同期読み込み）を呼び出してしまったらどうなるでしょうか？
答えは残酷で、その瞬間にPHPの実行スレッドそのものがブロックされ、同じスレッド上で動いている他のすべてのFiberが強制的に足止めを食らいます。
- 対策: 非同期対応のドライバ（Swoole拡張が提供するPDOプロキシや、Amp/ReactPHPのエコシステム、RoadRunnerのWorkerプール）を必ず採用してください。「コードの一部だけ同期処理だった」というミスが、システム全体のスループットを壊滅させます。
② メモリリーク（Garbage Collection）の意識
Fiberオブジェクトは、自身の実行コンテキスト（コールスタック内の変数、ローカルスコープのオブジェクトなど）をヒープ上に保持します。従来のPHPリクエストであれば、リクエスト終了時にプロセスごとメモリが解放されていましたが、Swooleなどの常駐型（Long-running）プロセス環境では、Fiberを適切に破棄しないとメモリリークの温床になります。
- 対策: クロージャ内で巨大な外部変数を不用意に `use` しないこと。また、Fiberが終了した後は参照を断ち切り、Zendのガベージコレクタが正常に回収できる状態を意識して設計してください。
—
まとめ
いかがでしたでしょうか？
Fiberとイベントループの統合は、単なる「新しい文法のおもちゃ」ではありません。それは、PHPという言語を「リクエスト終端型のスクリプト言語」から「高スループットな非同期アプリケーションプラットフォーム」へと昇華させるための極めて強力な武器です。
低レイヤのイベント駆動（epoll/kqueue）の仕組みと、ユーザーランドの協調的マルチタスク（Fiber）がどう噛み合っているのかが頭の中で一本の線で繋がれば、あなたの書くコードのパフォーマンスは劇的に変わります。
次のシステム設計では、ぜひこの「非同期並行処理の極意」をコードに落とし込んでみてください。PHPの裏側の美しさに、きっと驚くはずですよ。