マルチサイト環境におけるRedisキャッシュの「論理的完全分離」：メモリ空間の最適化とキー衝突の深層解剖
WordPressのマルチサイト（Network）構成において、デフォルトのRedisオブジェクトキャッシュ戦略をそのまま適用することは、スケーラビリティの観点からは「技術的負債」以外の何物でもない。
特に`wp_cache_`系の関数群が抽象化しているのは、単なるメモリ操作ではなく、背後にあるKey-Valueストアの「名前空間の競合」という物理的な課題である。本稿では、Redisという単一のコンテキストの中で、いかに各サイトのキャッシュを論理的・物理的に分離し、パフォーマンスのボトルネックを排除するかを解説する。
—
1. キャッシュ衝突の原罪：`wp_cache_key` とプレフィックスの脆弱性
WordPressのオブジェクトキャッシュは、`wp_cache_set` が呼ばれた際、キャッシュキーの先頭にプレフィックスを付与する。通常、これは `wp-config.php` の `WP_CACHE_KEY_SALT` に依存するが、マルチサイト環境では全サイトで同一のRedisインスタンスを共有している場合、このソルトがグローバルに固定されていると「キャッシュ汚染」が発生する。
さらに深刻なのは、WordPressコアが発行するクエリのキャッシュだ。`get_posts()` や `wp_get_nav_menu_items()` 等が生成するキャッシュキーは、データベースの `blog_id` を考慮しない場合がある。
解決策：`blog_id` を含めた名前空間の動的生成
`wp-config.php` に以下のロジックを注入し、`WP_CACHE_KEY_SALT` をサイト単位でハッシュ化させることで、論理的な分離を実現する。
/
- マルチサイト対応：サイトごとのユニークなキャッシュソルトの生成
- サーバー起動時のオーバーヘッドを最小化するため、定数定義時に評価する
/
if ( is_multisite() ) {
$current_blog_id = get_current_blog_id(); // 実際には定数定義段階でグローバル変数を参照
define( ‘WP_CACHE_KEY_SALT’, ‘site_’ . $current_blog_id . ‘_’ . md5( __FILE__ ) );
}
—
2. メモリ最適化：`wp_cache_flush` の代用とキーのライフサイクル管理
Redis上の全てのデータを `FLUSHALL` することは、マルチサイト環境において「他サイトのキャッシュまで破壊する」という致命的な運用ミスを招く。我々が管理すべきは、「サイト単位での論理的削除（Invalidation）」である。
推奨されるキー設計パターン
キーの設計には、`[Prefix]:[BlogID]:[Group]:[Key]` という階層構造を強制する。これにより、Redisの `SCAN` コマンドを用いたパターンマッチングによる削除が可能になる。
/
- 特定サイトの全キャッシュを安全にパージするロジック
- RedisのKEYSコマンドは本番環境ではブロッキングを引き起こすためSCANを使用する
/
function flush_blog_cache( $blog_id ) {
$redis = new Redis();
$redis->connect(‘127.0.0.1’, 6379);
$prefix = “site_{$blog_id}:”;
$iterator = null;
// SCANでメモリを保護しつつイテレーション
while ( $keys = $redis->scan( $iterator, $prefix ) ) {
foreach ( $keys as $key ) {
$redis->del( $key );
}
}
}
—
3. パフォーマンスの深層：シリアライズのオーバーヘッド
WordPressの `wp_cache_set` は、値をRedisに保存する前に `serialize()` を実行する。PHPのシリアライザは巨大なオブジェクトを扱う際にCPU負荷が跳ね上がる。
高負荷な環境では、以下の手法を検討すべきである。
1. igbinary の採用: PHPの標準シリアライザではなく、バイナリ形式で圧縮率の高い `igbinary` をRedis拡張で使用すること。これにより、メモリ占有率を40%〜60%削減できる可能性がある。
2. Transientの非同期化: 頻繁に更新されるメタデータは、`wp_cache_` ではなく、別のRedisテーブル（コネクション）へオフロードし、書き込みの排他制御（ロック）を軽減する。
—
4. チーフアーキテクトからの提言：レイテンシを極限まで削る
マルチサイト運用で真に恐れるべきは、Redisへのネットワーク・ラウンドトリップ・タイム（RTT）の増大だ。
- Unix Domain Sockets: Redisへの接続はTCP/IPではなく、`/var/run/redis/redis.sock` を通じてUnix Domain Socketを使用せよ。カーネルレベルでのコンテキストスイッチを最小化し、TCPスタックのオーバーヘッドをバイパスできる。
- Persistent Connections: `pconnect` を利用し、PHP-FPMのプロセス間での接続を維持せよ。接続ハンドシェイク（SYN/ACK）のコストは、大規模サイトにおいては無視できないレイテンシ要因となる。
まとめ
マルチサイトにおけるRedis戦略の要諦は、「グローバルな共有と、論理的な排他」の境界線をコードレベルで制御することにある。
プレフィックスを単なる文字列としてではなく、`blog_id` を軸とした「ネームスペース管理」として捉え直せ。そして、Redisを単なる「キー・バリューストア」として使うのではなく、PHPのプロセス寿命を超えて生存する「共有メモリセグメント」として扱い、メモリ配置とシリアライゼーションのコストを最適化せよ。
WordPressという抽象化レイヤーの底にある、生のバイト列を制御できるエンジニアだけが、この巨大なプラットフォームを「掌握」できるのである。