WordPressをRedis Clusterでスケールさせる：単一障害点を超越するアーキテクチャ設計
WordPressの `wp_cache_` 関数群は、スケーラビリティを語る上で避けて通れない聖域だ。多くのエンジニアは `WP_REDIS_HOST` を単一のRedisサーバーに向けることで満足するが、トラフィックが秒間数千リクエストを超えた瞬間、そのボトルネックは即座にシステムの死を招く。
本稿では、単一Redisの限界を突破し、`Redis Cluster` を用いて水平スケールさせるための設計指針と、堅牢な実装パターンを伝授する。
—
1. なぜ「単一Redis」ではスケールしないのか
WordPressの `Object Cache` は、`wp_options` テーブルへのクエリを抑止するための救世主だ。しかし、`wp_cache_set` や `wp_cache_get` が集中すると、RedisのシングルスレッドIOが飽和する。
Redis Clusterを導入する最大のメリットは、「ハッシュスロットによる自動シャーディング」だ。しかし、WordPressのコアはRedis Clusterをネイティブでサポートしていない。ここで我々が介入すべきは、Redisクライアントの抽象化レイヤーである。
2. アーキテクチャの核心：クライアントの選定
`phpredis` 拡張（`Redis` クラス）は、`RedisCluster` クラスを標準で備えている。これを利用するのが最短経路だ。自前でラッパーを書くのではなく、WordPressのオブジェクトキャッシュドロップイン（`object-cache.php`）を、Cluster対応のものに差し替える必要がある。
堅牢なコネクション管理の設計
Redis Clusterへの接続は、接続コストが高い。毎回接続を確立するのではなく、永続接続 (`pconnect`) を利用しつつ、ノードの再配置（Move/Askリダイレクト）を適切にハンドリングしなければならない。
/
- Redis Clusterへの接続ファクトリー
- 堅牢性を高めるため、接続タイムアウトと再試行回数を明示する
/
class RedisClusterFactory {
public static function create() {
$nodes = [
‘10.0.0.1:6379’,
‘10.0.0.2:6379’,
‘10.0.0.3:6379’,
];
try {
// RedisClusterクラスによる自動シャーディング
// コンストラクタの第3引数はタイムアウト、第4引数はRead/Writeの重み付け
$client = new RedisCluster(NULL, $nodes, 1.5, 1.5, true);
// 重要: シリアライザをPHPネイティブからigbinaryに変更することで
// メモリ効率と転送速度を劇的に向上させる
$client->setOption(Redis::OPT_SERIALIZER, Redis::SERIALIZER_IGBINARY);
return $client;
} catch (RedisClusterException $e) {
// ここでログを吐き、セーフモード（キャッシュ無効化）へ遷移させる設計が必要
error_log(‘Redis Cluster Connection Failed: ‘ . $e->getMessage());
return null;
}
}
}
—
3. 実務上の「地雷」と回避策
Redis Clusterを利用する際、エンジニアが陥りやすい罠が2つある。
A. キーの生存期間（TTL）とキーの分散
`wp_cache_set` で特定のキーにアクセスが集中する場合、シャーディングの意味がなくなる。Redis Clusterにおいてキーはハッシュ値でノードに振り分けられるため、プレフィックス設計が重要だ。
- 推奨: `wp_cache_set( ‘user_123_meta’, … )` ではなく、関連するキーに一貫したハッシュタグ（`{user_123}:meta`）を含めることで、関連データを同一ノードに配置する戦略を検討せよ。
B. フラッシュ（Flush）の注意点
WordPress標準の `wp_cache_flush()` は、Redisの `FLUSHALL` を叩く実装が多い。Cluster環境で `FLUSHALL` を実行すると全ノードのデータが消滅する。
- 対策: 実装において `flush` は `FLUSHDB` に制限するか、あるいは名前空間（Namespace）を用いた論理削除を採用すべきである。
—
4. プロダクションコード：キーの取り扱い
以下は、保守性を担保しつつ、Redis Clusterの利点を活かすためのキャッシュ操作のラッパー例だ。
/
- 堅牢性を考慮したキャッシュ取得ラッパー
/
function get_cached_data(string $key, callable $callback, int $ttl = 3600) {
$client = RedisClusterFactory::create();
// Redisダウン時はデータベースへ直接フォールバックする（サーキットブレーカー）
if (!$client) {
return $callback();
}
$data = $client->get($key);
if ($data !== false) {
return $data;
}
// キャッシュミス時は計算して再設定
$data = $callback();
$client->setex($key, $ttl, $data);
return $data;
}
—
5. 最後に：伝説のエンジニアからの提言
Redis Clusterの導入は、単なる「インフラの強化」ではない。「WordPressの書き込み負荷をいかにしてCPUとメモリの線形スケーリングに乗せるか」という設計思想の転換だ。
- 監視を怠るな: `CLUSTER INFO` コマンドでノードの状態とスロットの割り当てを常に監視せよ。
- シリアライザの選択: 前述の通り、`igbinary` は必須だ。これだけでRedisのメモリ使用量を30%〜50%削減できる。
- コアの挙動を疑え: WordPressのクエリキャッシュは `wp_options` に依存している。`wp_cache_flush` がシステム全体に与える影響を常に計算に入れておくこと。
この設計を導入した瞬間、あなたのWordPressサイトは、単なるCMSから「秒間数万リクエストを捌くプラットフォーム」へと進化する。コードは美しく、そして確実に。それがプロフェッショナルの仕事だ。