WordPressとRedis：メモリ溢れを許容するな。動的パージ戦略による「無停止」キャッシュ運用術
WordPressのパフォーマンスチューニングにおいて、Redisをオブジェクトキャッシュとして採用するのはもはやデファクトスタンダードだ。しかし、多くのエンジニアが陥る罠がある。「メモリ制限」を考慮しない設計だ。
Redisはメモリを使い切ると、設定された `maxmemory-policy` に従ってキーを削除する。もしこれが `allkeys-lru` であれば、重要度の高い永続キャッシュまで無慈悲にパージされる。かといって `noeviction` にすれば書き込みエラーが発生し、WordPressは500番台を吐き出す。
我々が目指すべきは、「Redisのメモリ状況をWordPress側から掌握し、限界が来る前に『重要度の低いデータ』から自律的に排除する」という、能動的なメモリ管理だ。
—
1. なぜ「WordPress側」で制御すべきなのか
Redisの `maxmemory-policy` は強力だが、WordPressのデータコンテキスト（どのデータが重要で、どのデータが再生成容易か）を理解していない。
例えば、`site-transient-updates`（更新チェック）のような「消えても即座に再計算できるデータ」と、複雑なクエリ結果をキャッシュした「再計算コストが極めて高いデータ」を同列に扱うのは愚策だ。
我々は、Redisの `INFO memory` コマンドをフックし、閾値を超えた瞬間に特定のキーをWP-CLIまたはPHPから削除するという、アプリケーションレベルのインテリジェント・パージを実装する。
—
2. プロダクションコード：Redisメモリ監視・自動パージエンジン
以下は、`wp-cron` または外部の監視プロセスから実行することを想定した、堅牢なパージ実装だ。
/
class RedisMemoryGuard {
// 閾値：80%を超えたらパージを開始
const MEMORY_THRESHOLD = 0.8;
/
- メモリ使用率をチェックし、必要ならパージを実行
/
public static function monitor_and_purge() {
$redis = new Redis();
$redis->connect(‘127.0.0.1’, 6379);
$info = $redis->info(‘memory’);
$used = $info[‘used_memory’];
$max = $info[‘maxmemory’];
if ($max > 0 && ($used / $max) > self::MEMORY_THRESHOLD) {
self::purge_low_priority_keys($redis);
}
}
/
- 重要度の低い（再生成が容易な）キャッシュのみを狙い撃ちする
/
private static function purge_low_priority_keys(Redis $redis) {
// 重要度の低い transient 接頭辞を定義
$patterns = [
‘wp_site_transient_update_’,
‘wp_transient_timeout_external_api_’,
];
foreach ($patterns as $pattern) {
$keys = $redis->keys($pattern);
if (!empty($keys)) {
$redis->del($keys);
error_log(“Redis Memory Guard: Purged ” . count($keys) . ” transient keys.”);
}
}
}
}
—
3. 実装上の「3つの鉄則」
① `KEYS` コマンドの多用は禁忌である
本番環境で `KEYS ` を実行すれば、Redisはシングルスレッドで動作しているため、ブロッキングが発生しサイトが凍結する。`SCAN` コマンドを使用するのが正解だ。上のサンプルは簡略化しているが、本番投入時は必ず `SCAN` を用いたイテレータパターンへ書き換えること。
② キャッシュキーの設計（名前空間）
パージを容易にするため、WordPressのオブジェクトキャッシュキーには明確な命名規則を設けるべきだ。
- `PERM_`: 永続キャッシュ（ユーザーセッション等）
- `TEMP_`: 再生成容易なキャッシュ（APIレスポンス等）
このように接頭辞を付けておけば、`SCAN` 時のフィルタリングコストを劇的に下げられる。
③ 実行トリガーの最適化
`wp_cron` は信頼性に欠ける。理想は、Redisのイベント通知（Keyspace Notifications） を受信するサイドカープロセスを常駐させ、メモリ警告を受け取った瞬間にWebhookでWordPressのAPIを叩き、パージを実行するアーキテクチャだ。
—
4. 最後に：エンジニアとしての矜持
Redisを単なる「高速な箱」として扱うな。WordPressのデータベース構造とRedisのメモリ管理戦略を統合し、システム全体をオーケストレーションする。それが、真にパフォーマンスを追求する者の仕事だ。
今回のコードは、あくまで「守りの基盤」に過ぎない。この設計をベースに、各アプリケーションのキャッシュヒット率や再生成コストを分析し、より動的な重み付けパージアルゴリズムを実装してほしい。
「動く」ことは最低条件だ。高負荷下で「倒れない」設計をこそ、我々は追求し続ける必要がある。