WordPressを極限までスケールさせる：Redis Clusterによるオブジェクトキャッシュの水平分散
WordPressの `wp_cache_` APIは、単なるデータベースの代替ではない。正しく設定されたオブジェクトキャッシュは、PHPの実行サイクルにおけるI/Oボトルネックを解消するための最後の砦だ。しかし、トラフィックが秒間数万リクエストを超え、データセットがギガバイト単位に達した瞬間、単一のRedisインスタンスは「単一障害点」かつ「メモリの限界点」へと変貌する。
本稿では、WordPressをRedis Clusterアーキテクチャへと拡張し、シャーディング（分散処理）によってスループットを限界まで引き上げるための深層設計を解説する。
—
1. WordPress Object CacheのボトルネックとRedis Clusterの必然性
デフォルトの `WP_Object_Cache` クラスは、`wp-content/object-cache.php` ドロップインを通じて外部キャッシュストアと通信する。標準的なRedisプラグインは単一ノード接続を前提としているが、これには致命的な制約がある。
- 垂直スケーリングの限界: メモリ容量を増やしても、CPUのシングルスレッド処理能力（特にRedisのイベントループ）が頭打ちになる。
- ネットワークI/Oの飽和: 接続数が数千を超えると、TCPスタックとRedisの接続管理（`maxclients`）がボトルネックとなる。
Redis Clusterは、ハッシュスロット（0-16383）に基づきデータを分散する。WordPress側でこのシャーディングを透過的に扱うには、`phpredis` 拡張のネイティブClusterサポートを介した実装が必須となる。
—
2. アーキテクチャの設計：透過的なシャーディングの実装
WordPressの `wp_cache_set` や `wp_cache_get` の内部で、Redis Clusterを正しく叩かせるには、`object-cache.php` の初期化プロセスを書き換える必要がある。
Redis Cluster接続の最適化（`object-cache.php`の断片）
/
- Redis Clusterへの接続を確立するクラスの簡略実装
- php-redisのRedisClusterクラスを活用し、接続をプールする
/
class WordPress_Redis_Cluster_Client {
private $cluster;
public function __construct() {
// Redis Clusterのシードノードを指定
$nodes = [
‘10.0.0.1:6379’,
‘10.0.0.2:6379’,
‘10.0.0.3:6379’
];
// 接続オプション: タイムアウトと永続化
// 接続負荷を抑えるためにpconnectを選択
$this->cluster = new RedisCluster(NULL, $nodes, 1.5, 1.5, true);
// シリアライズ設定: igbinaryを使用することでペイロードを圧縮し、メモリ効率を最大化
$this->cluster->setOption(Redis::OPT_SERIALIZER, Redis::SERIALIZER_IGBINARY);
}
public function get($key) {
return $this->cluster->get($key);
}
}
なぜ `igbinary` が重要なのか
WordPressのキャッシュデータ（`WP_Query`の結果や大規模なメタデータ）は、配列やオブジェクトが複雑にネストされている。標準のPHPシリアライズはテキストベースで肥大化するが、`igbinary` はバイナリベースで構造を保持するため、Redisのメモリ消費量を30-50%削減し、ネットワークパケットの断片化を防ぐ。
—
3. キャッシュキー設計と「ホットキー」問題の回避
Redis Clusterにおいて最も警戒すべきは、特定のハッシュスロットにアクセスが集中する「ホットキー」現象だ。
- プレフィックスの戦略:
`$wpdb->prefix` に依存するだけでなく、サイトIDやユーザーIDをキーに含めることで、ハッシュ値が分散しやすくなる。
- パイプライン処理の限界:
Redis Clusterでは、複数のキーを扱う操作（`MGET`など）は、すべてのキーが同一のハッシュスロットに存在しない限りエラーとなる。WordPressの `wp_cache_get_multiple` を実装する際は、スロットをまたぐリクエストを制御するロジックが必要だ。
—
4. パフォーマンス最適化の真髄：メモリとネットワークのチューニング
大規模環境でRedis Clusterを運用する場合、OSカーネルレベルのチューニングが欠かせない。
1. Transparent Huge Pages (THP) の無効化:
Redisのパフォーマンスを著しく低下させるため、必ずOSレベルで無効にする。
echo never > /sys/kernel/mm/transparent_hugepage/enabled
2. TCP Backlogの拡大:
接続数の急増に対応するため、`somaxconn` を引き上げる。
sysctl -w net.core.somaxconn=65535
3. クライアント側（PHP）の接続保持:
`pconnect` を使用し、FPMプロセスとRedis間のTCPハンドシェイク回数を極限まで減らす。これにより、PHPの実行サイクルにおけるレイテンシをマイクロ秒単位で短縮できる。
—
結論：システムは常に「分散」を前提とせよ
WordPressのオブジェクトキャッシュをRedis Clusterへ移行することは、単なるインフラの増強ではない。それは、「一つのデータベースに依存し、メモリという有限のリソースを奪い合う」というWordPressの旧来的な制約からの脱却を意味する。
ハッシュスロットの配置、`igbinary` による圧縮、そしてカーネルレベルでのチューニング。これらレイヤを跨いだ最適化こそが、WordPressを単なるCMSから、真のエンタープライズプラットフォームへと昇華させる唯一の道である。
次に構築するシステムでは、クエリの数ではなく、ハッシュスロットの偏りを監視せよ。それが、真のシニアエンジニアの視座である。