Redis接続の深淵：高トラフィックサイトで「接続オーバーヘッド」を消し去る技術
WordPressのパフォーマンスを語る際、多くのエンジニアは「クエリの最適化」や「オブジェクトキャッシュの導入」で思考を停止する。しかし、月間数千万PVを超えるトラフィックを捌く環境において、真のボトルネックはそこではない。
「PHP-FPMのワーカーがRedisに対して毎回TCPハンドシェイクを繰り返している」ことこそが、レイテンシを増大させ、CPUを無駄に消費する最大の戦犯だ。
今回は、Redisとの接続を永続化（Persistent Connections）し、高トラフィック環境でサーバーを「余裕で」稼働させるための、コアレベルのチューニングについて解説する。
—
なぜデフォルトの接続は非効率なのか？
WordPressでRedisを利用する場合、`wp-redis`のようなクライアントライブラリを介すのが一般的だ。しかし、多くの構成ではリクエストのたびに`connect()`が実行される。
1. TCP接続の確立（3ウェイ・ハンドシェイク）
2. 認証（AUTH）
3. コマンド実行
4. 接続の終了（FIN）
これをPHP-FPMの数だけ、リクエストのたびに繰り返す。1秒間に数百のリクエストがあれば、RedisサーバーのCPU負荷は「コマンド処理」ではなく「接続処理」に奪われる。これを解決するのが`pconnect`（持続的接続）だ。
—
実践：Persistent Connectionsを適用したRedisオブジェクトキャッシュ
`wp-config.php`レベルや、自前で `Redis` クラスをインスタンス化する際、単に `connect` を使っていないか？ `pconnect` を使用する場合、接続状態はPHP-FPMのプロセスに紐付き、再利用される。
推奨される堅牢な接続パターン
以下は、自前のキャッシュラッパーや、`object-cache.php`をカスタマイズする際に用いるべき、「接続の永続化とリトライ制御」を意識した実装例だ。
/
- Redis接続を管理するシングルトン・ラッパーの断片
- 接続の永続化と、接続失敗時のフォールバックを考慮
/
class RedisClientFactory {
private static $instance = null;
public static function get_connection() {
if (self::$instance !== null) {
return self::$instance;
}
$redis = new Redis();
try {
// pconnectを使用することで、PHP-FPMプロセス間での接続を維持
// 引数: host, port, timeout, persistent_id
// persistent_idを統一することで、プロセス間で接続を共有可能
$connected = $redis->pconnect(‘127.0.0.1’, 6379, 1.0, ‘wp_persistent_connection’);
if (!$connected) {
throw new Exception(“Redis connection failed.”);
}
// 必要に応じて認証
// $redis->auth(‘your-password’);
// シリアライザをPHPネイティブからigbinaryに変更するとさらに軽量化
$redis->setOption(Redis::OPT_SERIALIZER, Redis::SERIALIZER_IGBINARY);
self::$instance = $redis;
} catch (Exception $e) {
// ログに記録しつつ、キャッシュなしとして処理を続行（またはDBへフォールバック）
error_log(‘Redis Connection Error: ‘ . $e->getMessage());
return false;
}
return self::$instance;
}
}
—
プロダクション環境で絶対に守るべき3つの鉄則
単に `pconnect` に書き換えるだけでは、時としてシステムを破壊する。以下のリスクを理解し、防壁を築く必要がある。
1. PHP-FPMのプロセス数とRedisの最大接続数（`maxclients`）のバランス
`pconnect` を使うと、PHP-FPMの各プロセスが接続を掴んだままになる。もし `pm.max_children = 200` の設定で、Redisの `maxclients` が100しかなければ、即座に「Connection refused」が多発する。
- 対策: `maxclients` を `PHP-FPMの全プロセス数 + α` に設定すること。
2. コネクションのクリーンアップ（ステートフルな弊害）
`pconnect` は接続を再利用するが、もし前のリクエストで何らかの異常が発生し、Redisの状態が汚染されていた場合、次のリクエストに悪影響を及ぼす可能性がある。
- 対策: 重要な操作の前には必ずコマンドを確認し、必要であれば `$redis->select(0)` でデータベースを明示的に切り替えるなどの防御的設計を行うこと。
3. トランザクションとマルチコマンドの厳密な管理
`pconnect` 環境下で、もし例外により処理が中断された場合、接続が「トランザクション中」の状態で放置される可能性がある。
- 対策: `try…catch…finally` ブロックを徹底し、異常時には必ず `$redis->discard()` を呼び出してセッションをクリーンな状態に戻すこと。
—
結論：エンジニアとしての設計思想
高トラフィックなWordPressサイトにおいて、インフラはコードの一部だ。
「動けばいい」というコードは、トラフィックが10倍になった瞬間にゴミへと変わる。
今回紹介した `pconnect` による接続の永続化は、単なるコードの書き換えではない。「リクエストのライフサイクルと、サーバーの物理リソースのライフサイクルを同期させる」という、システム設計における高度な抽象化の第一歩だ。
次にコードを書くとき、目の前の関数が「何回ネットワークを跨いでいるか」「その接続は再利用可能か」を自問してほしい。その視点を持ったエンジニアだけが、WordPressという巨大なエコシステムを完全に掌握できる。
さあ、コードをリファクタリングし、サーバーの負荷グラフが平坦になるのを楽しもう。