Zend VMの深淵と常駐プロセス：PCNTLによるシグナル制御とGraceful Shutdownのアーキテクチャ
PHPは、本来「1リクエスト＝1プロセス（またはスレッド）」の短命なライフサイクルを前提として設計された言語である。Webの黎明期から現代に至るまで、この「リクエスト終了と共に全メモリが解放される」という強力なセーフティネットが、多くのプログラマをメモリリークやステート汚染の悪夢から救ってきた。
しかし、モダンなWebアプリケーションアーキテクチャにおいて、このパラダイムは時に足枷となる。WebSocketサーバ、高スループットな非同期キューワーカー、イベント駆動型のマイクロサービス。これらをPHPで実現する場合、我々はリクエストの境界を捨て、「常駐プロセス（Long-running Process）」の領域へと踏み込まなければならない。
常駐PHPプロセスを構築するということは、Zend VMの背後にあるOSのシグナル、プロセス間通信、そしてメモリ管理の生態系を完全に掌握することを意味する。本稿では、`ext-pcntl`を用いたシグナルハンドリングの極意から、Zend VMのメモリ空間を守り抜くGraceful Shutdownの設計図まで、極限の低レイヤ視点から解き明かす。
—
1. 常駐プロセスにおけるZend VMの宿命とメモリ管理
短命なリクエスト処理では見過ごされていた問題が、常駐プロセスでは致命傷となる。その筆頭がメモリリークとグローバルステートの汚染だ。
Zend VMは、リクエストの開始時に`request_startup`フェーズを実行し、終了時に`request_shutdown`を実行する。この過程で、スクリプト内で動的に生成された大半の変数は解放される。しかし、サードパーティ製拡張モジュールの不具合、あるいは静的プロパティ（`static`）やクロージャのバインドミスによって、Zendメモリマネージャ（zend_mm）外、あるいはプロセスヒープに残留するメモリが存在する場合、プロセスはループを回すたびに肥大化していく。
[Master Process]
│
└── [Worker Process (Zend VM)] ── (ループ実行) ──> メモリリークの蓄積
├── Request 1: 正常
├── Request 2: 微小なリーク
└── Request N: OOM Killerによる強制終了 (SIGKILL)
OSのOOM Killerにプロセスを屠殺される前に、自律的に安全な死（Graceful Shutdown）を迎えるためのアーキテクチャが不可欠となる。
—
2. PCNTL拡張とZend VMの非同期シグナル処理の罠
Linux環境において、プロセス制御の基本はシグナル（`SIGTERM`, `SIGINT`, `SIGHUP`など）である。PHPでこれを扱うのが `pcntl` 拡張だが、ここでZend VM特有の「非同期実行の罠」に直面する。
PHP 7.1以降、`pcntl_async_signals(true)` が導入された。これにより、C言語レベルのシグナルハンドラが捕捉した瞬間にPHP側のコールバックが即座に割り込み実行（Asynchronous Signal Handling）されるようになった。しかし、これがZend VMの実行中のオペコード（Opcode）の真っ只中に割り込むため、データベースのトランザクション中や、Zend内部のハッシュテーブル（HashTable）ポインタ操作中に割り込まれると、Segmentation Fault（SIGSEGV）を引き起こすリスクが常に伴う。
真に堅牢な常駐ワーカーを実装するには、非同期シグナルに頼らず、「Tick（ティック）」または「イベントループとの統合」を利用するか、あるいはシグナル発生フラグのみを立てて安全な地点（Safe Point）で処理する設計が求められる。
実践：極限まで堅牢なシグナルハンドリングを備えた常駐ワーカー
以下に、シグナルを安全に捕捉し、現在実行中のジョブを完遂してから華麗に散る（Graceful Shutdown）ワーカーの骨組みを示す。
setupSignals();
}
private function setupSignals(): void
{
if (!extension_loaded(‘pcntl’)) {
throw new \RuntimeException(‘PCNTL extension is required for daemon processes.’);
}
// 非同期シグナルを有効化（Zend VMの安全な割り込み制御）
pcntl_async_signals(true);
// SIGTERM (終了要求) のハンドラ登録
pcntl_signal(SIGTERM, [$this, ‘handleSignal’]);
// SIGINT (Ctrl+C) のハンドラ登録
pcntl_signal(SIGINT, [$this, ‘handleSignal’]);
// SIGHUP (設定リロード等) のハンドラ登録
pcntl_signal(SIGHUP, [$this, ‘handleSignal’]);
}
public function handleSignal(int $signo): void
{
switch ($signo) {
case SIGTERM:
case SIGINT:
echo sprintf(“[%s] [INFO] 終了シグナル (%d) を検知。Graceful Shutdownを開始します…\n”, date(‘Y-m-d H:i:s’), $signo);
$this->isTerminating = true;
// もし現在ジョブを実行中でなければ、即座にプロセスを終了
if (!$this->isBusy) {
$this->shutdown(0);
}
break;
case SIGHUP:
echo sprintf(“[%s] [INFO] SIGHUP検知。設定をリロードします…\n”, date(‘Y-m-d H:i:s’));
// 内部設定やコネクションの再確立処理
$this->reloadConfiguration();
break;
}
}
public function run(): void
{
echo sprintf(“[%s] [INFO] ワーカープロセス起動 (PID: %getmypid())\n”, date(‘Y-m-d H:i:s’), getmypid());
while (!$this->isTerminating) {
try {
// キューからのジョブ取得（ブロッキングまたはロングポーリング）
$job = $this->fetchNextJob();
if ($job === null) {
// ジョブがない場合はCPUを無駄に消費しないようスリープ
usleep(100000); // 100ms
continue;
}
$this->isBusy = true;
// ジョブの実行
$this->processJob($job);
} catch (Throwable $e) {
// 例外を捕捉し、ログに記録（プロセスは死なせない）
error_log(sprintf(‘[ERROR] Uncaught exception: %s in %s:%d’, $e->getMessage(), $e->getFile(), $e->getLINE()));
} finally {
$this->isBusy = false;
}
}
// 終了フラグが立ち、かつジョブの実行が完了していればここで終了
$this->shutdown(0);
}
private function fetchNextJob(): ?array
{
// 実際には Redis や SQS からのポップ処理が入る
// ここではシミュレーションとしてダミーを返す
return [‘id’ => mt_rand(1, 1000), ‘payload’ => ‘sample_data’];
}
private function processJob(array $job): void
{
echo sprintf(“[%s] [DEBUG] ジョブ処理開始 (ID: %d)\n”, date(‘Y-m-d H:i:s’), $job[‘id’]);
// 重い処理のシミュレーション
usleep(500000);
echo sprintf(“[%s] [DEBUG] ジョブ処理完了 (ID: %d)\n”, date(‘Y-m-d H:i:s’), $job[‘id’]);
}
private function reloadConfiguration(): void
{
// 設定ファイルの再読み込みや外部リソースの再接続ロジック
}
private function shutdown(int $exitCode): void
{
echo sprintf(“[%s] [INFO] プロセスを安全に終了します (PID: %d)\n”, date(‘Y-m-d H:i:s’), getmypid());
// データベースコネクションの切断、ファイルハンドルのクローズなど
// クリーンアップ処理をここに記述
exit($exitCode);
}
}
// 実行エントリーポイント
// $worker = new Worker();
// $worker->run();
—
3. OPcacheとプリローディングの物理構造：常駐プロセスのメモリ最適化
PHP 7.4で導入されたOPcache Preloading（プリローディング）は、常駐プロセスおよびフレームワーク駆動型のアプリケーションにとってパラダイムシフトであった。
従来、OPcacheは共有メモリ（SHM）上にコンパイル済みのOpcodeをキャッシュし、リクエストごとにZend VMがそれを共有メモリからプロセス空間へマッピング（あるいは参照）していた。しかし、クラスの依存関係解決、継承関係の構築、そしてシンボルテーブルへの登録コストは依然としてリクエストごとに発生していた。
プリローディングは、PHPの起動時（`php-fpm` の起動時や CLI のスクリプト実行時）に、指定したスクリプト群をあらかじめ完全にコンパイルし、永続的な共有メモリ領域へロードしきる技術である。
[Shared Memory (SHM)]
├── OPcache Shared Memory
│ ├── Preloaded Classes (完全に解決済み・永続化)
│ └── Runtime Cached Opcode
│
└── [Worker Process] ── (Zero-copyに近い状態でクラス定義を参照)
プリローディングのアーキテクチャ上の注意点
常駐プロセスでプリローディングを利用する場合、「一度ロードされたコードは、サーバ（あるいはFPMマスタープロセス）を再起動するまで絶対に更新されない」という鉄則がある。
開発環境でこれを有効にすると、コードを書き換えても古いクラス定義がメモリ上に残り続け、デバッグが不可能になる。本番環境の常駐ワーカーにおいて真価を発揮するためには、デプロイメントパイプラインに「ワーカースクリプトのGraceful Reload（例: `SIGUSR1` や `SIGHUP` によるプロセス置換）」を組み込むことが絶対条件となる。
—
4. プロセス間通信（IPC）とゾンビプロセスの駆逐
常駐マスタープロセスが複数のワーカープロセスを束ねる「Master-Worker型アーキテクチャ」を構築する場合、避けて通れないのがゾンビプロセス（Zombie Process）の発生である。
子プロセスが終了した際、親プロセスが `pcntl_waitpid()` や `pcntl_wait()` を用いて終了ステータスを回収（Reap）しない限り、OSのプロセス・テーブルにはプロセスIDと最小限のメタデータが亡霊のように残り続ける。これが蓄積すると、OSが新規プロセスを起動できなくなる（`Resource temporarily unavailable`）。
シグナル `SIGCHLD` の適切なハンドリング
子プロセスが終了すると、親プロセスに対して `SIGCHLD` シグナルが送信される。これを利用して、非同期にゾンビを回収する仕組みを組み込む必要がある。
// マスタープロセス側の擬似コード
pcntl_signal(SIGCHLD, function() {
// 停止した子プロセスをブロックせずに回収
while (($pid = pcntl_waitpid(-1, $status, WNOHANG)) > 0) {
// どのPIDの子プロセスがどのようなステータスで終了したかをログに記録
$exitCode = pcntl_wexitstatus($status);
// 必要に応じて新しいワーカーをフォークして補充 (Worker Poolの維持)
}
});
この非同期回収機構を備えることで、何千、何万というジョブを処理し、ワーカーが動的に再生成される堅牢なデーモン基盤が完成する。
—
結び：PHPを「システム言語」として使いこなすために
PHPは、単なる「HTMLを生成するテンプレートエンジン」ではない。Zend VMの内部構造を理解し、OSのシグナル、プロセスライフサイクル、メモリ管理の制約を完全にコントロール下置いたとき、PHPは極めて強力でスケーラブルなバックエンド・システム言語へと変貌する。
常駐プロセスの設計において妥協は許されない。ひとつのメモリリーク、ひとつのシグナルハンドリングの漏れが、深夜のシステム障害を引き起こす。Zend VMの鼓動を感じ取り、コードの1行1行がCPUとメモリ上でどう振る舞うのかを脳内トレースする――それこそが、真のWebシステムアーキテクトの境地である。