こんにちは。PHPの裏側で何が起きているか、気になって夜も眠れない時期ってありますよね。
普段私たちが何気なく書いているPHPコードは、ApacheやNginxの裏側で動くPHP-FPMによって「1リクエスト＝1プロセス（またはスレッド）」のライフサイクルで綺麗に使い捨てられてきました。リクエストが終わればメモリは解放され、グローバルステートもきれいに消え去る。この「完全なリセット性」こそが、長年PHPを最も安全で手軽なWeb言語たらしめてきた理由です。
しかし、その「安全な使い捨て」こそが、モダンなマイクロサービスアーキテクチャや極限のパフォーマンスを追求する現場において、最大のボトルネックになることがあります。毎回数メガバイトのフレームワークブートストラップ（autoloadの解決、設定ファイルのパース、DIコンテナの構築）をZend VM上でゼロからやり直すのは、CPUキャッシュの観点からも、メモリ帯域の観点からも、実にもったいない話なのです。
そこで登場するのが、Go言語製的高速アプリケーションサーバーである RoadRunner です。
今回は、RoadRunnerを用いたPHPのマイクロサービス化において、プロセス間通信（IPC）がZend VMとOSのレイヤでどう処理されるか、そして常駐化に伴う状態管理の闇と解法を、低レイヤの視点を交えながら紐解いていきましょう。ここを理解すると、PHPの見え方がガラリと変わりますよ。
—
1. PHP-FPMの呪縛とRoadRunnerのメモリ常駐革命
まず、従来のPHP-FPMとRoadRunnerの実行モデルを、Zend VMのメモリ空間というミクロな視点で比較してみましょう。
PHP-FPMモデル：リクエストごとの「全破棄」
PHP-FPMでは、Webサーバーからリクエストを受け取ると、子プロセスが `fork()` されるか、プールされたプロセスがそのままリクエスト処理に入ります。
1. スクリプトの読み込みとパース（Opcacheが効いていればバイトコードは共有メモリから取得）
2. Zend Executorによるシンボルテーブルの構築、オブジェクトのインスタンス化、DIコンテナの静的解析
3. レスポンスの返却
4. プロセス終了（またはリクエスト終了時）に伴う、割当ヒープメモリの完全な一括解放（`zend_mm_heap` のリセット）
この仕組みはメモリリークを構造的に防いでくれますが、毎リクエスト数千〜数万のZendツリーを構築・破棄するため、CPUのL1/L2キャッシュミスが多発します。
RoadRunner（Goridge IPC）モデル：プロセスの「永続化」
一方、RoadRunnerはGo言語（Goridge）で書かれたマスタープロセスがHTTP等のリクエストを受け付け、あらかじめ起動しておいた複数のPHP workerプロセスへTCPソケットやUnixドメインソケット（IPC）を通じて処理を委譲（Proxy）します。
[クライアント]
↓ (HTTP)
[RoadRunner (Go Master)]
↓ (Goridge IPC / Unix Domain Socket)
[PHP Worker (Zend VM 常駐プロセス)]
このPHP Workerは、一度起動したらリクエストが終わっても終了しません。
最初のブートストラップ（フレームワークの初期化やDIコンテナのビルド）は最初の1回だけで済み、2回目以降のリクエストは、すでにメモリ上に展開されているZend VM上のオブジェクトや関数テーブルをそのまま使い回して処理されます。
結果として、フレームワークの起動コストがほぼゼロになり、レイテンシは劇的に改善されます。しかし、ここに大きな罠が潜んでいます。それが「状態管理（State Management）」です。
—
2. 常駐化の代償：「共有非同期空間」としてのPHPプロセス
PHP-FPMでは「リクエストをまたいでグローバル変数を汚染する心配がない」という前提が成り立っていましたが、RoadRunnerのWorkerプロセスでは、一度書き換えた静的プロパティやグローバル変数は、次のリクエストの処理時にもそのまま残ります。
例えば、認証情報をシングルトンや静的プロパティに保持する古い設計のライブラリがあったとしましょう。
class SessionContext {
private static ?User $currentUser = null;
public static function setUser(User $user): void {
self::$currentUser = $user; // ここに保持したデータが次のリクエストに漏れる！
}
public static function getUser(): ?User {
return self::$currentUser;
}
}
もしWorker Aが「ユーザーA」のリクエストを処理した後に `SessionContext` をクリアし忘れた場合、次に同じWorker Aに割り振られた「ユーザーB」のリクエストで、ユーザーAのデータが引けてしまうという致命的なセキュリティインシデント（クロス・コンテキスト・データ汚染）が発生します。
対策：Zend VMのメモリリークと明示的なクリーンアップ
RoadRunner環境下でPHPを書くときは、「すべての変数はリクエスト終端時に破棄されるとは限らない」という前提でコードを書く必要があります。
フレームワーク（SymfonyのRoadRunner IntegrationやLaravel Octaneなど）は、リクエストの終端（`Worker::waitPayload()` のループの隙間）で次のようなクリーンアップ処理をフックしています。
// RoadRunner Workerのライフサイクルを模した概念コード
use Spiral\RoadRunner\Worker;
$worker = Worker::create();
while ($req = $worker->waitPayload()) {
try {
// 1. リクエストのハンドリング
$response = $app->handle($req);
$worker->respond($response);
} catch (\Throwable $e) {
$worker->error((string)$e);
} finally {
// 2. 極めて重要：リクエスト毎のステータスリセット
$app->terminate(); // DIコンテナのスコープ破棄、エンティティマネージャーのクリア等
gc_collect_cycles(); // 循環参照によるメモリリークの強制回収
}
}
このように、`finally` 句の中でミュータブルな状態をすべて初期化し、必要に応じて `gc_collect_cycles()` を適切に呼んでZendメモリマネージャーのヒープ肥大化を防ぐのが、プロとしての腕の見せ所です。
—
3. RoadRunnerを用いたマイクロサービス間のIPCとRPCの極意
RoadRunnerが優れているのは単なるHTTPサーバーとしてだけでなく、複数のPHPプロセス間、あるいはGoとPHPの間でシームレスなRPC（Remote Procedure Call）を行える点にあります。
例えば、重い画像処理や外部APIとの同期を伴う処理を、メインのWebワーカーから切り離してマイクロサービス化する場合を考えてみましょう。
RoadRunnerのRPC設定（`.rr.yaml` の例）
version: ‘3’
rpc:
listen: ‘tcp://127.0.0.1:6001’
server:
command: “php worker.php”
relay: “pipes”
burst: 100
http:
address: “0.0.0.0:8080”
middleware: [“static”]
pool:
num_workers: 4
max_jobs: 64 # メモリリーク対策として64リクエスト処理したらWorkerを安全に再起動
ここで注目すべきは `max_jobs: 64` という設定です。PHPのコードベース（特にサードパーティ製ライブラリ）に潜む微細なメモリリークを完全にゼロにすることは難しいため、一定数のジョブを処理したタイミングで、RoadRunnerのマスタープロセスが自動的に古いPHPプロセスを安全に `SIGTERM` で殺し、新しいプロセスを立ち上げます。これにより、メモリ使用量を常に一定に保つことができるのです。
PHP側から別のサービスを呼び出すRPCクライアントの実装
RoadRunnerのRPC機能を使うと、PHPからGoのネイティブサービスや別のPHPワーカーへ、高速なバイナリプロトコル（Goridge）でメッセージを飛ばすことができます。
use Spiral\Goridge\RPC\RPC;
// RoadRunnerのRPCサーバー（Go）へ接続
$rpc = RPC::create(‘tcp://127.0.0.1:6001’);
// 別サービスのメソッド「mailer.send」を呼び出す
$result = $rpc->call(‘mailer.send’, [
‘to’ => ‘architect@example.com’,
‘subject’ => ‘マイクロサービスからの通知’,
‘body’ => ‘Zend VMは今日も絶好調です。’
]);
if ($result[‘status’] === ‘success’) {
echo “メール送信ジョブが正常にキューイングされました。\n”;
}
この通信は、内部的にはTCPソケットやUnixドメインソケットを介したバイナリシリアライゼーション（Goridge）で行われるため、HTTP経由のREST通信に比べてオーバーヘッドが圧倒的に小さく、プロセス間の密結合を綺麗に断ち切ることができます。
—
4. アーキテクトとしての総括
RoadRunnerを活用したPHPのマイクロサービス化は、単に「アプリが速くなる」という表面的なメリットにとどまりません。
- Zend VMのライフサイクルを理解し、メモリの常駐化とクリーンアップを制御する力
- プロセス間通信（IPC）のオーバーヘッドを意識したトポロジー設計
- `max_jobs` や `gc_collect_cycles()` を駆使した、長期稼働に耐える堅牢なメモリ管理
これらを自分のものにしたとき、あなたの書くPHPコードは、もはや「スクリプト言語の枠にとらわれた泥臭いもの」ではなく、GoやJava、Rustのハイパフォーマンスなサーバー群と肩を並べる、洗練されたモダンバックエンドシステムそのものへと昇華されます。
「リクエストのたびにすべてを捨てる」というこれまでの常識を一度アンロックし、「メモリ上で生き続けるプロセスをどう美しく調律するか」という視点を持ってみてください。PHPの裏側の世界が、これまで以上にクリアに見えてくるはずです。