Redisの限界を掌握せよ：WP_Object_Cacheの動的パージ戦略とメモリ管理の深淵
WordPressのパフォーマンスを語る際、`wp_cache_` APIを介したオブジェクトキャッシュの導入は、もはや議論の余地のない前提だ。しかし、多くのエンジニアが「Redisを導入した」という事実で満足し、その先の「メモリ枯渇によるLRU（Least Recently Used）アルゴリズムの暴走」という地獄を見落としている。
Redisのメモリ制限に達した際、`maxmemory-policy`が適切に設定されていない、あるいはデフォルトの`volatile-lru`が意図しないデータを追い出している場合、システムは「キャッシュの再生成」という高負荷なサイクルに陥る。これは、単なるパフォーマンス低下ではなく、データベースへのクエリ負荷が急増する「キャッシュ・スタンプピード現象」の引き金だ。
本稿では、WordPressからRedisのメモリ状態を直接監視し、閾値を超えた瞬間に「低優先度キャッシュ」を自律的にパージする、深層レベルの制御手法を解説する。
—
1. 内部アーキテクチャ：Transient APIとRedisの乖離を埋める
WordPressのTransient APIは、キー名にプレフィックスを付与し、有効期限（TTL）を管理するが、Redis側の実メモリ使用量とは切り離されている。Redisが`maxmemory`に到達すると、書き込みが拒否されるか、あるいは重要なセッション情報までLRUで消去される。
これを防ぐには、「Redisのメモリ使用率」と「WordPressのキャッシュ重要度」を同期させる戦略が必要だ。
2. Redisメモリ監視とパージの実装：低レイヤ制御コード
以下のコードは、WP-Cronをフックして動作する監視スクリプトのプロトタイプだ。`phpredis`拡張を利用し、Redisの`INFO memory`コマンドを解析して、メモリ占有率が特定の閾値（例: 80%）を超えた場合に、重要度の低いキャッシュ（非本質的なAPIレスポンス等）を先制的にパージする。
/
- Redisメモリ監視による自律パージエンジン
/
class RedisMemoryGuard {
private $threshold = 80; // メモリ使用率の閾値（%）
public function monitor_and_purge() {
$redis = new Redis();
$redis->connect(‘127.0.0.1’, 6379);
// Redisのメモリ情報を取得
$info = $redis->info(‘memory’);
$used_mem = $info[‘used_memory’];
$max_mem = $info[‘maxmemory’];
// メモリ使用率の算出
$usage_percent = ($used_mem / $max_mem) 100;
if ($usage_percent > $this->threshold) {
$this->purge_low_priority_cache($redis);
}
}
private function purge_low_priority_cache($redis) {
// ‘transient:api_response_’ で始まるキーを特定して削除
// 本来はSCANコマンドで逐次処理すべき（KEYSコマンドはO(N)でブロックするため厳禁）
$iterator = null;
while ($keys = $redis->scan($iterator, ‘transient:api_response_’, 100)) {
foreach ($keys as $key) {
$redis->del($key);
}
}
}
}
// 5分毎の監視サイクルを登録
if (!wp_next_scheduled(‘redis_memory_guard_event’)) {
wp_schedule_event(time(), ‘five_minutes’, ‘redis_memory_guard_event’);
}
add_action(‘redis_memory_guard_event’, [new RedisMemoryGuard(), ‘monitor_and_purge’]);
3. 設計上の重要な注意点：O(N)操作の回避
上記コードで最も注意すべきは、`KEYS`コマンドではなく`SCAN`コマンドを使用している点だ。大規模なRedisインスタンスで`KEYS `を実行すれば、シングルスレッドで動作するRedisは完全にフリーズし、その瞬間のすべてのWebリクエストがタイムアウトする。
- SCANコマンドの利点: カーソルベースのイテレーションにより、Redisの処理をブロックせずにデータセットを走査できる。
- メモリ解放の即時性: `DEL`は非同期（`UNLINK`）で実行するのが、コアエンジニアとしての作法だ。Redis 4.0以降であれば、`$redis->unlink($key)` を使用することを強く推奨する。これにより、メモリの解放をバックグラウンドスレッドで行い、メインスレッドへの影響を最小化できる。
4. 高度な最適化：Redis側でのメモリポリシー設定
コードによるパージは「最後の防衛線」であるべきだ。根本的な防御は`redis.conf`の最適化にある。
- maxmemory-policy: `volatile-lru` を強く推奨する。これは、有効期限が設定されているキーの中からLRUで削除を行う設定だ。有効期限なしの重要なキー（セッションや設定値）を保護しつつ、キャッシュを優先的に追い出すことができる。
- メモリ断片化の監視: `mem_fragmentation_ratio` が1.5を超える場合は、メモリの断片化が進行している。`activedefrag yes` を有効にし、Redisの自動デフラグ機能を活用せよ。
結び：システムは「予測可能」でなければならない
WordPressのキャッシュ運用において、「何が起きているか分からない」状態は、エンジニアとして敗北を意味する。Redisのメモリ使用率を監視し、アプリケーション側で制御を試みるこのアプローチは、単なるパッチではない。システムの挙動を制御下に置き、予測可能なパフォーマンスを維持するための、最も基本的かつ不可欠な設計思想である。
次回の記事では、`wp_object_cache`のバッキングストアとしてのRedisにおいて、`Redis Cluster`を用いた水平スケーリングと、キーの分散アルゴリズム（Consistent Hashing）がどのようにWordPressの内部整合性を崩し、どう再構築すべきかについて深掘りする。
現場からは以上だ。コードを書き、統計を読み、己の環境を掌握せよ。