WordPressを掌握する極限の知見：RedisにおけるObject Cacheのメモリライフサイクル設計
WordPressにおいて、`wp_cache_` 関数群が触れるObject Cache層は、データベースへのIOを最小化するための最後の砦だ。しかし、多くのエンジニアは「Redisを入れておけば速くなる」という幻想に安住し、その背後で発生するメモリ枯渇のメカニズムを看過している。
今日は、Redisのメモリ制限下で、WordPressのObject Cacheがどのように生存し、あるいは崩壊するのか。その深層構造を解剖する。
—
1. Transient APIとオブジェクトキャッシュの「不都合な真実」
WordPressの `set_transient()` は、データベース（`wp_options`）への書き込みを伴う。しかし、`Redis Object Cache` プラグイン等を導入すると、この書き込みはメモリ上のKey-Valueストアへとバイパスされる。
ここで注意すべきは、WordPressのObject Cacheには「ハードな有効期限（TTL）」と「ソフトなデータ整合性」のトレードオフが存在する点だ。
RedisにおいてTTL（Time To Live）を設定しない（あるいは永続化する）設計は、メモリ枯渇の第一歩となる。WordPressの内部では、自動保存やセッションデータが頻繁に書き換えられるため、適切に破棄されないキーが蓄積されると、Redisの `maxmemory` 設定に到達し、Eviction Policy（逐出戦略）が発動する。
2. メモリ飽和時の制約と Eviction Policy の選択
Redisがメモリ制限に達した際、`allkeys-lru` か `volatile-lru` かを選択しなければならない。
- allkeys-lru: 全キーを対象にLRU（Least Recently Used）で削除する。WordPressの場合、永続的な設定値まで消えるリスクがある。
- volatile-lru: TTLが設定されているキーのみを対象にLRUで削除する。
結論：WordPress環境では `volatile-lru` 一択である。 しかし、これには前提条件がある。すべてのキャッシュエントリに適切なTTLが付与されていなければならない。
3. 実践：TTLの強制とメモリ効率の最適化
WordPressのデフォルトのキャッシュ実装は、一部のTransientを除き、常にTTLを保証するわけではない。以下のコードは、キャッシュ投入時にTTLを強制し、メモリ上の肥大化を抑制するためのフックの実装例である。
/
- Object Cacheのセット時にTTLを強制的に付与するラッパー
- 内部のRedis接続がvolatile-lruを尊重するように設計する
/
function force_cache_ttl_logic($key, $data, $group = ”, $expire = 0) {
// デフォルトでTTLがない場合、3600秒(1時間)を強制する
// これにより、Redis側でvolatile-lruが機能するキーを確実に作る
$ttl = ($expire === 0) ? 3600 : $expire;
return wp_cache_set($key, $data, $group, $ttl);
}
// フィルタを用いて、頻繁に更新されるキャッシュの生存時間を制御
add_filter(‘pre_set_site_transient_my_heavy_data’, function($value) {
// データの重要度に応じてTTLをチューニングする
return $value;
}, 10, 1);
4. なぜ「キャッシュの断片化」が致命的なのか
メモリの断片化は、Redisのパフォーマンスを物理的に低下させる。特に、シリアライズされた巨大なオブジェクト（`WP_Query` の結果セットなど）を頻繁にキャッシュすると、`jemalloc` や `libc` のアロケータがメモリを再利用できず、メモリフラグメンテーションが加速する。
回避策：Keyの命名規則とネームスペースの活用
大規模サイトにおいては、グループ化を意識し、`wp_cache_flush_group()` を適切に呼び出せる設計が不可欠だ。
// 特定のグループのみをクリアする設計
// サイト全体をflushするのは、O(N)の負荷がかかり、CPUをスパイクさせるため禁忌
function clear_specific_domain_cache($domain_id) {
// グループ単位でキャッシュを無効化し、メモリを解放する
wp_cache_delete(‘data_key’, ‘domain_’ . $domain_id);
}
5. 伝説的エンジニアからの提言：メトリクスの監視
最後に、システムエンジニアとして一つだけ強調したい。「RedisのINFOコマンドで `evicted_keys` を監視せよ」。
もし `evicted_keys` がゼロでないなら、あなたのWordPressは「必要なキャッシュ」をメモリ不足のために強制的に捨てていることになる。これはデータベースへのIOを再度発生させ、レスポンスタイムのジッター（揺らぎ）を引き起こす。
1. TTLが未設定のキャッシュを洗い出す
2. `volatile-lru` を有効にする
3. シリアライズされたデータのサイズを制限する
これらを徹底することで、WordPressのランタイムは初めて「安定した高速性」という地平に到達する。コードを信じるな、メモリマップとRedisの内部挙動を信じろ。
最適化とは、単なるコードの書き換えではない。システムが物理メモリの上でどう呼吸しているかを理解することそのものなのだ。