【入門編】Swoole CoroutineとPHPネイティブFiberのパフォーマンス比較と使い分け – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

こんにちは。普段からJavaやGo、あるいはNode.jsといった他の高水準言語の非同期モデルに触れ、「PHPでもっとスマートな並行処理ができないものか」と頭を悩ませているころだと思います。

伝統的なPHPのライフサイクルは、1リクエスト＝1プロセス（または1スレッド）という極めてシンプルな「Shared-Nothing（共有なし）」アーキテクチャに基づき構築されてきました。リクエストが終わればメモリは全解放され、グローバル変数の汚染も、複雑なスレッドセーフティの呪縛も、すべてZendエンジンが綺麗にリセットしてくれます。この圧倒的なシンプルさこそがPHPの強みですが、現代のリアルタイムWebアプリケーションやマイクロサービスにおいて、I/O待ちのたびにプロセスを止めるコストは無視できないボトルネックになりますよね。

そこで登場するのが、Swooleのコルーチン（Coroutine）であり、PHP 8.1でコアに導入されたネイティブFiberです。

今回は、これら2つの非同期・並行処理モデルがPHPの内部エンジン（Zend VM）の裏側でどのように実行され、何が違うのかを、低レイヤのメモリ管理やスケジューリングの視点から紐解いていきましょう。ここを理解すると、PHPの裏側がスッと綺麗に見えるようになりますよ。

—

1. Zend VMのスタック構造と「非同期」の壁

まず、PHPの伝統的な実行モデルを思い出してください。PHPのコードは、パーサによって抽象構文木（AST）に変換され、Zendオプコード（Opcodes）へとコンパイルされます。そして、Zend VM（仮想マシン）がそれを実行します。

通常、PHPの関数呼び出しはC言語と同様にコールスタック（Call Stack）を消費します。
関数Aが関数Bを呼び出すと、Zend VMの実行コンテキスト（`zend_execute_data`）がスタックに積み上げられ、CPUのレジスタやメモリ上のスタックポインタが移動します。もしこの途中でMySQLへのクエリやHTTPリクエスト（I/Oブロック）が発生すると、OSのプロセスやスレッド自体がカーネル空間でサスペンド（停止）し、コンテキストスイッチの重いコストを支払うことになります。

この「コールスタックの制約」をユーザースペースで巧妙に回避し、数万件ものリクエストを単一プロセス上で擬似並行処理させる仕組みが、協調的マルチタスク（Cooperative Multitasking）、すなわちコルーチンとFiberです。

—

2. PHPネイティブ Fiber（PHP 8.1+）の正体

PHP 8.1で導入されたFiberは、一言で言えば「スタックを持つ非同期処理のプリミティブ（構成要素）」です。

Node.jsのasync/awaitが「言語仕様としてのPromiseチェーン（コールバックの糖衣構文）」であるのに対し、Fiberはコールスタックの保存と復元をプログラマブルに制御できる点が決定的に異なります。

Fiberの内部挙動イメージ

Fiberの内部では、通常のコールスタックとは別に、ヒープ上に独自のスタック領域（Execution Context）が確保されます。

start();
echo “メイン側: {$output}\n”;

// Fiberを再開（Resume）し、値を送り込む
$fiber->resume(‘メインからの贈り物’);

このコードを実行すると、`Fiber::suspend()` の地点で、Zend VMの現在の実行状態（`zend_execute_data`のポインタやローカル変数など）がヒープ上に退避し、制御がメインのスコープに戻ります。そして `resume()` が呼ばれると、退避した状態が復元され、停止した行の続きから実行が再開されます。

Fiberの限界と位置づけ

非常に強力に見えるFiberですが、極めて重要な注意点があります。PHPのネイティブFiber自体には、I/O多重化（epollなど）を自動でハンドリングするイベントループが含まれていません。

Fiberはあくまで「中断と再開ができる関数の皮」です。もしFiberの中で通常の `PDO` や `file_get_contents()` を呼んでしまうと、その瞬間に対象のOSスレッド全体がブロックされてしまいます。そのため、ReactPHPやAmpといった非同期イベントループライブラリと組み合わせて、「I/O待機状態になったら自動でFiberをサスペンドし、I/O完了時にレジュームする」という仕組みを自前（あるいはライブラリ経由で）構築する必要があります。

—

3. Swoole Coroutine：エコシステム全体が非同期化された怪物

一方、C言語の拡張モジュールとして動作するSwoole（および後継のOpenSwoole）は、PHPの枠組みを根底から拡張するアプローチを取っています。

Swooleのコルーチンは、PHPネイティブFiberと同様にユーザースペースでのスタック管理を行っていますが、決定的な違いは「PHPのコア関数や主要なドライバ（PDO, Redis, HTTP Clientなど）をすべてフックし、非同期I/O（Reactorモデル）と完全に統合している点」にあります。

Swooleのコード例

connect([
‘host’ => ‘127.0.0.1’,
‘user’ => ‘root’,
‘password’ => ‘secret’,
‘database’ => ‘test’,
]);
$res = $pdo->query(‘SELECT SLEEP(1)’);
echo “タスク1完了\n”;
});

Co::go(function () {
// 同時に別の処理を実行
Co::sleep(0.5);
echo “タスク2完了\n”;
});
});

Swooleのすごさは、開発者が「普段通りの同期的コードの書き方」をしているにもかかわらず、エンジン側（C言語層）で勝手にソケットをノンブロッキングモードに切り替え、epollベースのイベントループで裁いてくれる点にあります。Zend VMの実行コンテキストの切り替えはすべてC言語のレイヤーで超高速に行われます。

—

4. 徹底比較：Swoole Coroutine vs PHPネイティブ Fiber

実務でどちらを採用すべきか、アーキテクチャ、パフォーマンス、運用の観点から比較表にまとめました。

—

5. アーキテクトが教える「適材適所」の選び方

では、私たちが実際のプロダクト設計で直面したとき、どのように選択すべきでしょうか。

A. 「PHPネイティブ Fiber」を選ぶべきケース

標準的なPHP-FPM環境で動作させたい場合

従来のShared-Nothingのアーキテクチャを大きく崩したくない、あるいはインフラの制約で常駐プロセス（Daemon）が許されない場合。

特定の部分的な非同期化を行いたい場合

例えば、バッチ処理の中で外部APIへのリクエストを並列化（Fan-out）したいだけの場合、重厚なSwooleを導入するよりも、ReactPHP等とFiberを組み合わせた軽量なアプローチの方がデプロイの心理的ハードルが低くなります。

B. 「Swoole Coroutine」を選ぶべきケース

極限のスループットと低レイテンシが求められるAPIサーバー

WebSocketサーバー、リアルタイムチャット、IoTのデータ収集基盤など、1台のサーバーで数万の同時接続を捌く必要がある場合、Swoole（あるいはHyperfなどのフレームワーク）のパフォーマンスは他の追随を許しません。

「常駐型アプリケーション」のメモリ管理をコントロールできるスキルがある場合

Swooleはプロセスが常駐するため、「リクエストを跨いだ静的変数へのデータの蓄積（メモリリーク）」やデータベース接続の切断・再接続（Connection Pooling）の管理をエンジニア自身が意識し、コードを書く必要があります。ここを疎かにすると、徐々にメモリが枯渇する恐怖のプロダクトになってしまいます。

—

まとめ

PHPの非同期・並行処理の進化は、ここ数年で劇的な飛躍を遂げました。「PHPは遅い、リクエストごとに重い」というかつての常識は、Zendエンジンの最適化と、今回解説したFiberやSwooleのようなコルーチン技術によって完全に覆されています。

Fiberは、PHPのコアに組み込まれた、コンテキストスイッチの美しいプリミティブ。
Swooleは、そのプリミティブをエコシステム全体で実用的な超高速I/Oエンジンに昇華させたモンスター。

それぞれの裏側の仕組み（Zend VMのスタック退避、イベントループの有無、メモリ空間のライフサイクル）を正確に把握していれば、流行り廃りに惑わされず、目の前のプロジェクトに最適なアーキテクチャを自信を持って選択できるようになります。

あなたのプロダクトが、次世代の高速なWebシステムへと進化するヒントになれば幸いです。