【入門編】CDNパージやキャッシュ無効化など、バックグラウンドタスクのFiber化と優先度制御 – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

こんにちは。PHPの裏側で何が起きているのか、気になったことはありませんか？

普段私たちが何気なく書いているPHPのコードは、Zendエンジンという名の仮想マシン上で実行されています。1つのHTTPリクエストが来ると、FPMプロセスが立ち上がり、スクリプトがパースされ、オペコードにコンパイルされ、Zend Executorへと流し込まれていく――この一連の流れは美しく効率的ですが、長年PHPが抱えてきた「ある宿命」がありました。それが「リクエスト・レスポンスの直列性」です。

「ユーザーからのレスポンスを返した後に、ちょっとCDNのパージや重いキャッシュの再構築を走らせたい」と思ったとき、あなたならどう実装してきたでしょうか？ `fastcgi_finish_request()` を使ってレスポンスを先に返しつつ裏で処理を続けさせたり、あるいはわざわざRabbitMQやRedisを挟んでワーカープロセスに投げたりしていませんでしたか？

もちろん、本格的なキューイングシステムは偉大な解決策ですが、中規模なアプリケーションや、インフラの複雑性を増やしたくない現場においては、オーバースペックになることも少なくありません。

そこで登場するのが、PHP 8.1で導入された Fiber（ファイバー） です。今回は、このFiberを駆使して、ユーザーリクエストのライフサイクルを汚さずにバックグラウンドタスク（CDNパージやキャッシュ無効化など）を非同期化し、さらにシステム負荷に応じた「優先度制御」までをPHPの内部挙動レベルから解き明かしていきましょう。

ここを理解すると、PHPの裏側がまるでNode.jsやGoのゴルーチンのように美しく、かつPHPらしいシンプルな文脈で動いていることが見えてきますよ。

—

1. Zendエンジンから見た Fiber の正体

まず、多くの開発者が誤解している点からクリアにしましょう。PHPのFiberは、Node.jsのような「OSスレッドを裏で大量に回すマルチスレッドモデル」ではありません。また、Go言語のGoroutineのような「ランタイムがスケジューリングするプリエンプティブ（強制割り込み）なコルーチン」とも違います。

PHPのFiberは、「スタックフルな協調型（ノンプリエンプティブ）コルーチン」です。

Zendエンジンの内部（C言語レベル）において、通常の関数コールはCのコールスタックをそのまま消費します。そのため、途中で実行を一時停止して別の処理にジャンプし、あとから元の場所に戻ってくるという「コンテキストスイッチ」が言語レベルでは不可能でした（Generatorは単一レベルのイテレーションしか持てません）。

しかし、Fiberはこの制限を打破しました。
Fiberを生成すると、PHPのヒープメモリ上に専用のコールスタック（`zend_fiber_context`）が割り当てられます。これにより、「任意の深さの関数コールスタックの状態を丸ごと一時停止（Suspend）し、メインの実行フローに戻り、後からその続きを再開（Resume）する」という神業が、PHPのコード上から制御できるようになったのです。

この仕組みを知っていれば、「なぜFiberを使うとノンブロッキングな非同期処理が書けるのか」の答えが自ずと見えてきます。OSのスレッドをブロックせず、CPUのコンテキストスイッチのオーバーヘッドも最小限に抑えながら、1つのプロセス内で複数の処理をインターリーブ（交互に実行）できるからです。

—

2. 実践：CDNパージとキャッシュ無効化をFiberで非同期化する

では、実際のWebアプリケーションの文脈に落とし込んでみましょう。
例えば、ECサイトで商品情報が更新されたとします。このとき、以下の3つのバックグラウンドタスクが発生するとします。

1. CDNのキャッシュパージ（HTTPリクエストを飛ばすためI/O待ちが発生する）
2. 内部HTMLキャッシュの削除（ローカルストレージやRedisへの書き込み）
3. 検索インデックスの再構築フラグの立て直し

これらをユーザーへのレスポンス前に行うと、APIの応答速度が低下してしまいます。かといって完全に切り離すとエラーハンドリングが面倒になる。ここでFiberを使ったミニ・イベントループを組み込んでみましょう。

以下のコードを見てください。現場でそのまま脳内トレースできるように、細かくコメントを入れています。

/
class TaskScheduler
{
private SplPriorityQueue $queue;

public function __construct()
{
// 優先度（整数値が大きいほど高優先）に基づいてタスクを処理するキュー
$this->queue = new SplPriorityQueue();
}

/

• タスク（Fiber）をキューに登録する
• @param callable $task 実行する処理
• @param int $priority 優先度（数値が高いほど先におよそ実行される）

/
public function addTask(callable $task, int $priority = 0): void
{
$fiber = new Fiber($task);
// SplPriorityQueueはデフォルトで最大値ヒープ
$this->queue->insert($fiber, $priority);
}

/

• キューに溜まったタスクを協調的に実行する（イベントループ）

/
public function run(): void
{
while (!$this->queue->isEmpty()) {
/ @var Fiber $fiber /
$fiber = $this->queue->extract();

if (!$fiber->isTerminated()) {
try {
// Fiberを起動、または中断したところから再開
if (!$fiber->isStarted()) {
$fiber->start();
} else {
$fiber->resume();
}

// まだ処理が完了していなければ（一時停止中なら）、再度キューに戻す
// これにより、重い処理を少しずつスライスして実行できる（協調的マルチタスク）
if (!$fiber->isTerminated()) {
// 継続時は優先度を少し下げる、あるいはそのまま維持するなどの制御が可能
$this->queue->insert($fiber, 0);
}
} catch (\Throwable $e) {
// バックグラウンドタスク内の例外をキャッチ（ユーザーリクエストを落とさない）
error_log(“[TaskScheduler Error]: ” . $e->getMessage());
}
}
}
}
}

// — 実際の利用シーン —

$scheduler = new TaskScheduler();

// タスク1: 優先度「高」 – CDNのパージ（I/Oバウンドな処理の模擬）
$scheduler->addTask(function() {
echo “1. [高優先度] CDNパージのリクエスト送信を開始します…\nCURLハンドル初期化…\n”;

// 内部で一時停止（Suspend）を挟むことで、他のタスクにCPU権を譲る（協調動作）
Fiber::suspend();

echo “1. [高優先度] CDNパージのレスポンスを受信しました。完了。\n”;
}, priority: 10);

// タスク2: 優先度「低」 – 検索インデックスの再構築用メタデータ更新（CPU/ディスクI/Oバウンド）
$scheduler->addTask(function() {
echo “2. [低優先度] 検索インデックスのメタデータ更新チャンク 1/2…\n”;
Fiber::suspend();
echo “2. [低優先度] 検索インデックスのメタデータ更新チャンク 2/2。完了。\n”;
}, priority: 1);

// イベントループの駆動
echo “=== バックグラウンドタスクの実行開始 ===\n”;
$scheduler->run();
echo “=== すべてのバックグラウンドタスクが完了しました ===\n”;

このコードが内部でやっていることの美しさ

上記のコードを実行すると、コンソールには優先度（Priority 10 と Priority 1）に基づき、かつ `Fiber::suspend()` によって綺麗に処理がインターリーブ（交互に実行）されて出力されるのが分かります。

ここで重要なのは、「PHPはシングルスレッドで動いているにもかかわらず、まるで非同期プログラミング言語のように複数の処理の断片をスイッチングしながら実行できている」という点です。

外部のAPI（CloudflareやFastlyなどのCDN）へパージリクエストを投げる際、ネットワークの往復待ち（I/O Wait）が発生します。本来、同期的なコードではその間PHPのプロセスは完全にブロックされますが、Fiberと組み合わせた非同期HTTPクライアント（AmpやReactPHPなどのエコシステム、あるいは自前のCurlマルチハンドルのラッパー）と連携させると、「待ち時間に別のキャッシュ無効化処理を進める」という、極めて効率的なリソース活用が可能になります。

—

3. システムリソースに応じた優先度制御のアーキテクチャ

さて、実務でこれを運用する上で最も重要なのが「システムリソースの保護」です。
バックグラウンドタスクが暴走して、肝心のユーザーリクエストを処理するFPMプールのCPUやメモリを食いつぶしてしまっては本末転倒ですよね。

アーキテクトとして推奨する設計は、「システムの負荷状態（CPUロードアベレージやメモリ空き容量）をモニタリングし、Fiberのスケジューリング粒度や実行スロットを動的に制御する仕組み」を組み込むことです。

思考のフレームワーク：負荷に応じたスロットル制御

1. 高負荷検知（例: 5分間のロードアベレージがCPUコア数を超えている）:

• `優先度: 低` のタスクの実行を完全に一時停止（キューに保持したままスリープ）。
• `優先度: 高`（CDNパージなどのクリティカルなキャッシュ無効化）のみ、実行チャンクを小さくして細々と継続。

2. 通常負荷:

• すべてのタスクを並行（協調的）に高速消化。

これをPHPで表現する場合、`sys_getloadavg()` やメモリー使用量を取得する `memory_get_usage(true)` をイベントループの各イテレーションで監視し、閾値を超えたら `usleep()` を挟んで意図的にバックプレッシャー（負荷抑制）をかけるのが、シンプルかつ確実なアプローチです。

// イベントループのrun()メソッド内での負荷監視のイメージ
$load = sys_getloadavg();
if ($load[0] > 4.0) { // サーバー負荷が高い場合
// タスクの実行スピードを落とし、Webリクエストへの影響を最小化する
usleep(50000); // 50msスリープ
}

この泥臭いまでのリソース配慮こそが、大規模トラフィックを支えるWebシステムアーキテクトの腕の見所です。綺麗なコードを書くだけなら誰でもできますが、「本番環境のハードウェア制約の中でどう行儀よく振る舞わせるか」がプロの仕事です。

—

4. アーキテクトからのメッセージ

PHPにおけるFiberは、魔法の杖ではありません。古いレガシーな同期型関数（例えば、内部でブロッキングする従来の `PDO` や `file_get_contents()` など）をそのままFiberで囲っても、肝心のI/O待ち部分でプロセスがブロックされてしまうため、真の非同期恩恵は受けられません。

しかし、今回紹介したような「タスクの分割」「優先度付きキューイング」「レスポンス返却後のバックグラウンド処理のオーケストレーション」においては、外部の複雑なキューサーバーを持ち込む前の「第一歩の最適解」として、驚異的なポテンシャルを発揮します。

PHPの裏側――Zendエンジンのメモリ管理やコールスタックの仕組みに思いを馳せながらコードを書くと、見慣れたPHPが全く違った、洗練されたシステム言語に見えてくるはずです。

ぜひ、次回のキャッシュ無効化や重いバッチ処理の実装の際には、このFiberを使った優先度制御の設計を思い出してみてください。あなたのアプリケーションが、一段上のステージへと進化することを約束します。