こんにちは。普段はJavaやGo、あるいはNode.jsといった、いわゆる「プロセス常駐型」の世界からやってきて、モダンなPHPの高速化や非同期I/Oの世界に足を踏み入れたあなたなら、一度はこんな疑問を抱いたことがあるはずです。
「リクエストごとにプロセスが破棄される従来のPHP-FPMならいざ知らず、SwooleやRoadRunnerを使ってメモリ上にアプリケーションを常駐させた途端、データベースのコネクションが枯渇したり、`MySQL server has gone away`という見慣れたエラーに悩まされるのはなぜだろう？」と。
他の言語であれば、コネクションプールという仕組みがフレームワークやランタイムの裏側でいい感じに管理してくれますよね。しかし、PHPでそれをやろうとすると、Zend VMのメモリ空間の特性や、Swooleのようなコルーチンベースの並行処理ランタイム特有の「罠」を正しく理解していないと、途端にアプリケーションが不安定になります。
今回は、Swoole等の常駐環境におけるデータベース接続のステート管理と、切断検知・再接続のメカニズムを、PHPの裏側の挙動まで掘り下げて紐解いていきましょう。ここをクリアできれば、PHPの実行モデルに対する解像度が劇的に上がりますよ。
—
1. なぜ常駐型PHPでデータベース接続が「問題」になるのか？
従来のPHP-FPMモデルは、非常にシンプルでした。1つのHTTPリクエストが来ると、Zend Engineが初期化され、スクリプトが実行され、レスポンスを返した瞬間にプロセスが終了します。プロセス終了と同時に、OSレベルでソケットは破棄され、データベースの接続も自動的にクローズされます。つまり、開発者は「ステートのリーク」を気にする必要がほとんどありませんでした。
しかし、SwooleやRoadRunnerを用いた常駐環境（Daemon / Workerモデル）では話が全く変わります。
一度起動したWorkerプロセスはメモリ上に常駐し続け、次々とやってくるリクエストをループで処理し続けます。
ここで何が起きるか？
[ Workerプロセス起動 ]
├── データベース接続 (Persistent Connection / Global Pool)
├── リクエストA処理 ──> DB操作 (接続保持)
├── リクエストB処理 ──> DB操作 (接続保持)
├── （数分間アイドル状態… MySQL側がタイムアウトで切断）
└── リクエストC処理 ──> 💥 「MySQL server has gone away」
Workerが保持しているデータベースのソケットは、長時間アイドル状態が続くと、MySQLサーバー側の `wait_timeout` 設定によって強制的に切断されてしまいます。しかし、PHP側のWorkerは「自分は接続を持っている」と勘違いしたままその古いソケットを使い続けようとするため、容赦なくエラーが返ってくるわけです。
—
2. Swooleコルーチン環境における「ステートの共有」という罠
さらに問題を複雑にするのが、Swooleに代表されるコルーチン（Coroutine）の存在です。
Swooleは、1つのOSスレッド上で数千ものリクエストを非同期に並行処理（Co-operative multitasking）させます。
ここでやってはいけない最悪のアンチパターンが、「グローバル変数や静的プロパティ（Static Property）に単一のPDOインスタンスを保持し、それを複数のコルーチンから同時に使い回すこと」です。
class BadDatabaseManager
{
// ❌ 危険：すべてのコルーチンでこのインスタンスが共有されてしまう
public static ?PDO $pdo = null;
public static function getConnection(): PDO {
if (self::$pdo === null) {
self::$pdo = new PDO(‘mysql:host=localhost;dbname=test’, ‘user’, ‘pass’);
}
return self::$pdo;
}
}
PHPのPDOオブジェクトはスレッドセーフ（あるいはコルーチンのコンテキストセーフ）ではありません。コルーチンAがクエリを発行している最中に、コンテキストスイッチが発生してコルーチンBが同じPDOインスタンス経由で別のクエリを投げると、内部の通信バッファやトランザクション状態がめちゃくちゃになり、予期せぬデータ混信（Data Race）を引き起こします。
では、どうすればよいのでしょうか？答えは「コルーチンごとに、あるいはリクエストごとに安全にコネクションをプールし、生存確認（Keep-alive）を行う仕組み」を構築することです。
—
3. 実装：堅牢なコネクションプールと生存確認メカニズム
ここからは、常駐環境において安全にデータベース接続を維持・再利用するための実践的な設計を見ていきましょう。
Swooleには標準で `Swoole\Coroutine\Channel` を使ったコネクションプールの仕組みが用意されていますが、本質を理解するために、そのコアロジックをシンプルにした実装アプローチを解説します。
コネクションプールの要件
1. 枯渇防止: プールの最大数を制限する。
2. 鮮度確認（Keep-alive）: プールから取り出した際、その接続がまだ生きているか（Pingが通るか）を確認する。
3. 自動再接続: 死んでいれば、速やかに新しい接続を確立して差し替える。
以下に、その核心部分のコード例を示します。
class SafeConnectionPool
{
private \Swoole\Coroutine\Channel $pool;
private string $dsn;
private string $username;
private string $password;
private int $maxConnections;
public function __construct(string $dsn, string $username, string $password, int $maxConnections = 10)
{
$this->dsn = $dsn;
$this->username = $username;
$this->password = $password;
$this->maxConnections = $maxConnections;
// Swooleのチャネルを使い、コルーチン間で安全にコネクションを出し入れする
$this->pool = new \Swoole\Coroutine\Channel($maxConnections);
}
/
- プールからコネクションを取得する（必要に応じて生存確認・再接続）
/
public function acquire(): PDO
{
$pdo = null;
// プールに空きがあれば取得、なければ空くまでコルーチンが一時停止（Yield）する
if ($this->pool->length() > 0 || $this->pool->stats()[‘producer_num’] < $this->maxConnections) {
$pdo = $this->pool->pop(0.001); // タイムアウト付きポップ
}
if (!$pdo instanceof PDO) {
// プールが空、または新規作成が必要な場合
$pdo = $this->createConnection();
} else {
// 【重要】プールから取り出したコネクションの生存確認（Keep-alive）
if (!$this->isAlive($pdo)) {
// 接続が切れていた場合は破棄して新規作成
$pdo = $this->createConnection();
}
}
return $pdo;
}
/
- 使い終わったコネクションをプールに返却する
/
public function release(PDO $pdo): void
{
// トランザクションが中途半端に残っている事故を防ぐためロールバックしておく
if ($pdo->inTransaction()) {
$pdo->rollBack();
}
// プールに戻す（満杯なら破棄される）
if (!$this->pool->push($pdo, 0.001)) {
// チャネルがいっぱいの場合は明示的に破棄（ガベージコレクションに委ねる）
unset($pdo);
}
}
private function createConnection(): PDO
{
$pdo = new PDO($this->dsn, $this->username, $this->password, [
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
PDO::ATTR_TIMEOUT => 3, // 接続タイムアウト（秒）
]);
return $pdo;
}
/
- 接続が生きているか軽量なクエリで確認する
/
private function isAlive(PDO $pdo): bool
{
try {
// MySQLの場合、軽量なクエリまたはgetAttributeで生存確認
//getAttribute(PDO::ATTR_SERVER_INFO)はネットワークを伴わない場合もあるため、
//確実に確認したい場合は簡単なクエリを投げるのが確実です。
$pdo->query(‘SELECT 1’);
return true;
} catch (\Throwable $e) {
// 接続断、タイムアウト、その他のエラーを検知
return false;
}
}
}
—
4. この設計がZend VMとメモリ空間に与える恩恵
上記のコードがなぜ優れているのか、PHPの内部（Zend Engine）の目線から考えてみましょう。
1. メモリリークの防止:
常駐アプリケーションで最も怖いのは、リクエストを処理するたびにオブジェクトがメモリ上に残り続ける「メモリリーク」です。プールサイズを固定（`maxConnections`）し、オブジェクトを適切に再利用・循環させることで、Zend VMのヒープメモリ（ZendMM）の増減を安定させることができます。
2. 無駄なTCPハンドシェイクの削減:
毎回 `new PDO()` を呼ぶと、TCPの3ウェイ・ハンドシェイク、MySQLの認証プロトコル、SSL/TLSハンドシェイク（利用している場合）など、膨大なオーバーヘッドが発生します。コネクションをプールして維持（Keep-alive）すれば、すでに確立されたソケットを使い回せるため、レスポンスタイムを劇的に短縮できます。
3. 安全なコンテキスト分離:
グローバル変数ではなく、コルーチンチャネルを経由してローカルスコープにコネクションを貸し出すため、異なるリクエスト間でデータやトランザクションが混信する事故を完全に防ぐことができます。
—
5. 先輩アーキテクトからのアドバイス
常駐型PHPの世界は、従来の「リクエストごとに全てを忘れてくれる優しい世界」ではありません。その代わり、マシンの限界を極限まで引き出し、GoやNode.jsに匹敵する爆速のWebアプリケーションを構築できるという圧倒的なロマンがあります。
今回解説した「ステート管理」と「コネクションの生存確認」は、その常駐型アーキテクトとしての第一歩です。
「動けばいいや」ではなく、「この1行のコードが、Zend VMのメモリ空間とOSのソケットにどう影響しているか」を常に頭の片隅に置きながらコードを書いてみてください。
きっと、PHPという言語の奥深さと、エンジニアとしての確かな手応えを感じられるはずですよ。さあ、次のボトルネックを華麗に解決しに行きましょう！