こんにちは。他の言語で高トラフィックなシステムを経験し、「PHPでも同じような非同期・並行処理を極めたい」と、一歩踏み込んだ壁にぶつかっているあなたへ。
世の中には「PHPはリクエストごとにすべてが破棄されるから非同期は無理だ」という古い常識がまかり通っていますが、それはZend Engineの進化を見落としている人の言葉です。PHP 8.1で導入された Fiber（ファイバー） は、その常識を根底から覆しました。
今回は、このFiberを武器にして、数千・数万のプレイヤーが同時接続するオンラインゲームのバックエンドサーバーをPHPでどう構築するか、その核心を一緒に覗いていきましょう。ここを理解すると、PHPの裏側が驚くほど美しく見えてきますよ。
—
1. なぜ「ゲームサーバー」にFiberなのか？
オンラインゲームのバックエンド、例えば「プレイヤーが移動し、周囲の敵や他プレイヤーにダメージを与え、その結果をブロードキャストする」という処理を考えてみてください。
これまでは、次のようなジレンマがありました。
- 従来の同期ブロッキングI/O:
1人のプレイヤーの通信やDBクエリを待っている間、PHPのプロセス（あるいはスレッド）全体が完全にブロックされます。これでは同時接続数が頭打ちになります。
- 純粋な非同期・イベント駆動（ReactPHPやAmpなど）:
ノンブロッキングなコールバックやPromisesの嵐になり、コードの制御フローがバラバラ（コールバック地獄）になってしまいます。「プレイヤーAの移動を処理し、DBを引いて、結果を待ってから返却する」というゲームのシーケンシャルなロジックを記述するのに、非常に高い認知負荷がかかりました。
協調的マルチタスク（Cooperative Multitasking）の美しさ
Fiberがもたらした最大の革命は、「書いているときは上から下の同期コードに見えるのに、実行時は完全に非同期（中断・再開可能）なイベントループで動く」という点です。
Zend VMのレベルで何が起きているかというと、Fiberは独自のコールスタック（実行コンテキスト）を持ちます。PHPスクリプトの途中で `Fiber::suspend()` を呼ぶと、エンジンは現在のZend実行状態（スタックフレーム、ローカル変数など）をヒープメモリ上に退避させ、処理の制御権を呼び出し元（イベントループ）に返却します。そして、I/Oの準備が整ったら `Fiber::resume()` で、まるで何事もなかったかのように同じ場所から処理を再開できるのです。
—
2. アーキテクチャの全体像：イベントループとFiberの融合
ゲームサーバーをPHPで実装する場合、PHP-FPMの枠組み（1リクエスト1プロセス）を離れ、Swoole / ReactPHP / Revolt などのイベントループをベースにした常駐型のCLIアプリケーションとして動作させます。
アーキテクチャの基本構造は以下のようになります。
1. メインイベントループ (Event Loop): ソケットからのパケット受信やタイマーを監視する。
2. ネットワークリスナー: プレイヤーからのTCP/WebSocket接続を受け付ける。
3. プレイヤーセッションFiber: 接続ごとに1つのFiberを生成し、その中でゲームのメインループ（移動、戦闘、チャット）を同期的な記述で実行する。
4. 非同期I/O: データベースや外部API、他プレイヤーへの送信を待つ際、自発的にFiberをサスペンド（中断）する。
—
3. 実装：Fiberを用いたゲームセッションハンドラ
それでは、実際にFiberを活用したゲームサーバーのコアロジックをコードで見てみましょう。
ここでは、イベントループの概念をシンプルに表現しつつ、プレイヤーの行動処理をFiberで非同期化する例を示します。
/
class GameServerLoop
{
private array $waitingFibers = [];
/
- 非同期タスク（Fiber）を登録して実行を開始する
/
public function spawn(callable $task): void
{
$fiber = new Fiber($task);
// 最初のサスペンド（または終了）まで実行
$this->step($fiber);
}
public function step(Fiber $fiber, mixed $value = null): void
{
try {
if (!$fiber->isStarted()) {
$fiber->start();
} else {
$fiber->resume($value);
}
// Fiberが終了していなければ、イベントループの管理下に置く
if (!$fiber->isTerminated()) {
// ここでは説明のため省略しますが、実際はソケットの読み込み完了や
// タイマーイベントと紐づけて resume() を呼び出します。
}
} catch (\Throwable $e) {
echo “エラー発生: ” . $e->getMessage() . “\n”;
}
}
}
/
- プレイヤーのゲームセッションを処理するクラス
/
class PlayerSession
{
private string $playerId;
public function __construct(string $playerId)
{
$playerId = $playerId;
}
/
- プレイヤーの行動を処理する（Fiber内で同期的に記述可能）
/
public function handleGameLoop(): void
{
echo “プレイヤー [{$this->playerId}] がサーバーに接続しました。\n”;
// 1. データベースからプレイヤーデータを非同期でロードする模擬処理
$playerData = $this->asyncDbQuery(“SELECT FROM players WHERE id = ‘{$this->playerId}'”);
echo “-> キャッシュロード完了: レベル {$playerData[‘level’]}\n”;
// 2. ゲーム内のメインループ（移動とアクション）
for ($i = 1; $i <= 3; $i++) {
// サーバーからのパケット受信を待つ（非同期サスペンド）
echo "-> プレイヤー [{$this->playerId}] の入力を待っています…\n”;
$inputCommand = $this->asyncReceivePacket();
echo “-> アクション実行: {$inputCommand}\n”;
// 3. 他のプレイヤーへのブロードキャスト（非同期ウェイト）
$this->asyncSleep(1000); // 1秒間のゲーム内ティック相当
}
echo “プレイヤー [{$this->playerId}] が切断しました。\n”;
}
/
- DBクエリの非同期化（Fiberのサスペンドを活用）
/
private function asyncDbQuery(string $sql): array
{
// 実際のアプリでは、ここでノンブロッキングソケットにクエリを流し、
// コールバックやDeferredで Fiber::suspend() の再開ハンドルを渡します。
return Fiber::suspend(function ($suspension) use ($sql) {
// 擬似的な非同期I/O（実際はループ側でタイマーやソケット監視後に resume を呼ぶ）
// ここでは即座に結果を返す代わりに、サスペンドの仕組みを解説しています。
swoole_timer_after(100, function() use ($suspension) {
$suspension->resume([‘level’ => 42]);
});
});
}
private function asyncReceivePacket(): string
{
// プレイヤーからの入力を待つ擬似処理
return Fiber::suspend(fn($s) => / ネットワークイベントで resume される / ‘MOVE_FORWARD’);
}
private function asyncSleep(int. $milliseconds): void
{
// 非同期スリープ
Fiber::suspend(fn($s) => usleep($milliseconds 1000));
}
}
// — 実行シミュレーション —
$server = new GameServerLoop();
// 2人のプレイヤーが同時に接続してきたケースを想定
$server->spawn(fn() => (new PlayerSession(‘Hero_A’))->handleGameLoop());
$server->spawn(fn() => (new PlayerSession(‘Mage_B’))->handleGameLoop());
コードの裏側で何が起きているか？
上記のコードにおける `Fiber::suspend()` は、まさにZend Engineのスタックフレームを切り替える瞬間です。
従来のPHPであれば、DBの応答を待つ間（`usleep` や同期I/O）、CPUコアはそのスレッド単位で完全にフリーズしていました。しかし、Fiberを使うことで、「待つ必要がある処理に到達した瞬間にコンテキストを退避し、別のプレイヤーの処理（Mage_Bの移動など）にCPUリソースを即座に割り当てる」という協調的マルチタスクが、PHPのコード上で美しく実現できるのです。
—
4. 低レイテンシを死守するためのメモリとガベージコレクションの知見
ゲームサーバーにおいて「ラグ（遅延）」は致命傷です。PHPで低レイテンシを維持するためには、Zend VMのメモリ管理の特性を理解しておく必要があります。
1. メモリリークの防止（リクエスト境界がない世界）
常駐型アプリケーションでは、FPMのように「リクエストが終われば全メモリがOSに返却される」という安全ネットがありません。
Fiber内で生成されたオブジェクトや、クロージャのuse構文でキャプチャされた巨大な変数は、Fiber自体のインスタンスが破棄されるまでメモリ（Zend Memory Manager）上に残り続けます。セッション終了時には必ず不要な参照を断ち切り、ガベージコレクション（GC）がスムーズに回収できるように設計しましょう。
2. 変数のスコープとキャプチャコスト
Fiberのコンテキストスイッチは非常に高速ですが、スタックに多くの巨大な配列やオブジェクトを抱えたままサスペンドを繰り返すと、ヒープ領域のメモリ断片化（Fragmentation）を招く原因になります。非同期処理の境界を越えるデータは、必要最小限のプリミティブな値やDTOに絞るのが、熟練アーキテクトのテクニックです。
—
まとめ
PHPのFiberは、単なる「ちょっとした新機能」ではありません。それは、PHPを「Webページのレンダリング言語」から「高パフォーマンスなリアルタイム・ネットワークサーバーの駆動エンジン」へと昇華させるための強力なパスポートです。
他の言語で培った非同期の知見を頭の中に持ちながら、PHPの美しいシンタックスとZend Engineの裏側の挙動をリンクさせれば、あなたの書くコードは見違えるほど洗練されたものになるはずです。
さあ、次のプロジェクトでは、Fiberを使ったモダンで低レイテンシなアーキテクチャに挑戦してみませんか？ PHPの底力は、あなたが思っているよりもはるかに深いところにありますよ。