Redisを「ただの高速化ツール」と呼ぶのは素人の証だ：WordPressキャッシュの真髄
WordPressの `wp_cache_` 関数群は、一見するとただのキー・バリュー・ストアだが、大規模トラフィック下ではシステム全体の生命線を握る心臓部だ。特にRedisを外部オブジェクトキャッシュとして導入した際、多くのエンジニアが陥る罠がある。「メモリが足りなくなったら勝手に消えてくれるだろう」という安直な期待だ。
だが、Redisのデフォルトの設定とWordPressのデフォルトの挙動を放置すれば、高負荷時に「重要なキャッシュ」が追い出され、DBへのクエリがスパイクしてシステムが共倒れする。今日は、Redisのメモリ制限下でWordPressを安定稼働させるための、堅牢なキャッシュ戦略を伝授する。
—
1. エビクション戦略（Eviction Policy）の選定
Redisには `maxmemory-policy` という設定がある。WordPressにおいてデフォルトの `noeviction`（メモリ不足時に書き込みエラー）は論外だが、`allkeys-lru` を安易に選ぶのも危険だ。
- 推奨設定: `volatile-lru`
- 理由: WordPressのキャッシュには、「永続化すべきデータ（セッションや設定）」と「再生成可能なデータ（WP_Queryの結果など）」が混在する。`volatile-lru` は、TTL（有効期限）が設定されたキーのみを対象にLRU（Least Recently Used）アルゴリズムを適用する。
- 設計指針: キャッシュを保存する際、必ず適切なTTLを設定することを強いる設計にすべきだ。
—
2. TTL管理の「美しい」設計パターン
WordPressの `wp_cache_set` には、コアの仕様上TTLを細かく制御するためのラッパーが必要だ。`object-cache.php` の実装に依存せず、アプリケーション層で「キャッシュの寿命」を明示的に管理する設計パターンを導入しよう。
以下は、保守性を担保しつつ、Redisのメモリ枯渇を防ぐための堅牢なキャッシュラッパーの実装例だ。
/
- 高度なキャッシュ管理クラス
- TTLを強制的に管理し、キャッシュの汚染を防ぐ
/
class RobustCacheManager {
const DEFAULT_TTL = 3600; // 1時間
/
- キャッシュの取得・再生成を抽象化する
- @param string $key キャッシュキー
- @param callable $callback データ生成用クロージャ
- @param int $ttl 秒数
- @return mixed
/
public static function remember(string $key, callable $callback, int $ttl = self::DEFAULT_TTL) {
$data = wp_cache_get($key, ‘myapp_group’);
if (false !== $data) {
return $data;
}
$data = $callback();
// 重要なのは、ここでTTLを明示的にRedisへ渡すこと。
// 第3引数にTTLを渡せるobject-cacheプラグインを利用している前提。
wp_cache_set($key, $data, ‘myapp_group’, $ttl);
return $data;
}
}
// 利用例：複雑なWP_Queryの結果をキャッシュする
$posts = RobustCacheManager::remember(‘recent_posts_list’, function() {
return get_posts([‘posts_per_page’ => 10]);
}, 1800); // 30分で期限切れにする
—
3. なぜこの設計が必要なのか？
A. キーのグループ化とメモリの断片化防止
`wp_cache_set` の第3引数にグループ名を指定することで、キャッシュの管理が容易になる。`wp_cache_flush_group()` を適切に呼び出せるようになれば、メモリが逼迫した際、特定のグループだけを破棄するという「外科手術」のようなメモリ管理が可能になる。
B. 「stampede effect（キャッシュ雪崩）」の回避
高負荷時にキャッシュが一斉に期限切れになると、DBにアクセスが集中する。プロダクションコードでは、`$ttl` にランダムなジッター（例えば ±10% の秒数）を付与することで、期限切れのタイミングを分散させるのがプロの定石だ。
—
4. 運用エンジニアへの警告：モニタリングの義務
もしあなたがシステム運用も担当しているなら、以下のコマンドは毎日叩くべきだ。
Redisのメモリ使用状況とエビクション発生率を監視
redis-cli INFO memory
redis-cli INFO stats | grep evicted_keys
もし `evicted_keys` が右肩上がりで増え続けているなら、それはメモリ不足の兆候ではない。「TTLの設定が甘い」か「キャッシュのキー設計が冗長である」ことの証明だ。
結論
WordPressにおけるRedis運用は、単なるプラグインのインストールで完結しない。「どのデータがどれだけ長く生きるべきか」をコード内で言語化すること。 それこそが、数億PVを捌くWordPress構築の第一歩だ。
コードは嘘をつかない。キャッシュ戦略を疎かにするエンジニアは、いつかDBの悲鳴と共に眠れぬ夜を迎えることになる。美しい設計で、システムに休息を与えよ。それが、真のフルスタックエンジニアの矜持だ。