キャッシュスタンプピードを制する：WordPressオブジェクトキャッシュの「真の」最適化戦略
WordPressのパフォーマンスを語る際、`wp_cache_set` や `Transient API` を使えば十分だと思っていませんか？
もしあなたのシステムで、高負荷時にデータベースのCPU使用率がスパイクし、Redisのメモリが解放された瞬間に全リクエストがDBへ殺到する現象が起きているなら、それは「キャッシュスタンプピード（Cache Stampede）」という設計上の欠陥に直面しています。
本稿では、WordPressのオブジェクトキャッシュにおけるこの致命的な問題を、ロック機構を用いて根本から解決する「堅牢な設計」を伝授します。
—
なぜスタンプピードは発生するのか
キャッシュが期限切れ（TTL切れ）になった瞬間、複数のワーカープロセスが同時に「キャッシュがない」ことを検知し、一斉に高コストなクエリをDBに投げます。これがスタンプピードです。
特に `get_transient` の直後に `set_transient` を置くだけの単純な実装では、この競合を防げません。これを回避するには、「再計算は1つのプロセスにのみ許可し、他のプロセスはその間、古いキャッシュを使い続ける」という設計が必要です。
—
解決策：非同期ロックと「ソフトTTL」戦略
この問題を回避するための美しい設計パターンは、以下の2段階の処理です。
1. ソフトTTLの導入: 本来の有効期限よりも少し前に「再計算が必要」というフラグを立てる。
2. 排他ロック (Mutex): 再計算の権利を `wp_cache_add` を利用して原子的に取得する。
実装コード：堅牢なキャッシュラッパー
このコードは、高負荷サイトでもDBを保護しつつ、常にレスポンスを返すように設計されています。
/
- 高負荷環境向けの堅牢なキャッシュ取得ラッパー
- @param string $key キャッシュキー
- @param callable $callback データの再計算処理
- @param int $ttl キャッシュ保持秒数
- @param int $soft_ttl ソフトTTL（この時間を過ぎると再計算を開始）
/
function get_data_with_stampede_protection(string $key, callable $callback, int $ttl = 3600, int $soft_ttl = 3000) {
$data = wp_cache_get($key);
// キャッシュが存在し、かつソフトTTL内であればそのまま返す
if ($data !== false && $data[‘expires_at’] > time()) {
return $data[‘value’];
}
// 再計算が必要な場合：ロックの取得を試みる
$lock_key = $key . ‘_lock’;
// wp_cache_add はキーが存在しない時のみ true を返す（原子性）
if (wp_cache_add($lock_key, ‘locking’, ”, 10)) {
try {
// 再計算を実行
$new_value = $callback();
// 新しいキャッシュを保存
wp_cache_set($key, [
‘value’ => $new_value,
‘expires_at’ => time() + $soft_ttl,
], ”, $ttl);
wp_cache_delete($lock_key); // ロック解除
return $new_value;
} catch (Exception $e) {
wp_cache_delete($lock_key);
throw $e;
}
}
// ロックが取得できなかった場合：
// 古いキャッシュがまだあればそれを返し、なければDBへのクエリが完了するまで待機（または古いデータで凌ぐ）
return ($data !== false) ? $data[‘value’] : $callback();
}
—
この設計が優れている理由
1. `wp_cache_add` によるアトミック性
`wp_cache_set` は「上書き」ですが、`wp_cache_add` は「存在しない場合のみ追加」します。この特性により、分散環境（複数サーバー）においても、たった1つのプロセスだけがDBクエリの実行権を得ることが保証されます。
2. 「古いデータ」を捨てるな
スタンプピードの最大の悲劇は、キャッシュを空にしてから再計算することです。上記コードでは、再計算中でも古いデータを返し続けることで、ユーザーに空白のページや遅延を見せることがありません。
3. オブジェクトキャッシュ層でのロック
DB層（`SELECT FOR UPDATE` など）でロックをかけるのは、DB接続を保持し続けるため推奨しません。あくまでRedis/Memcachedのメモリ内で完結させることで、DB負荷を最小限に抑えます。
—
パフォーマンス最適化のチェックリスト
- Redisの永続化設定: Redisを使っている場合、`save` 設定（RDB）が有効だと、保存時にメモリがブロックされ、キャッシュスタンプピードよりも深刻な遅延を招くことがあります。高負荷環境では `appendonly yes` を検討してください。
- シリアライズコストの監視: キャッシュするデータ構造が巨大な配列の場合、PHPのシリアライズコストが無視できなくなります。必要に応じて `igbinary` 拡張を導入してください。
- 監視: `wp_cache_get` のミスヒット率だけでなく、`wp_cache_add` のロック成功率をPrometheus等で可視化すると、システムのボトルネックが明確に見えてきます。
最後に：コードは「防御的」であれ
プロダクション環境では、「キャッシュは必ずヒットする」という性善説を捨ててください。キャッシュが消えた瞬間、あなたのコードがDBを叩き落とさないか？その問いを常に持つことこそ、エンジニアとしての力量です。
このラッパー関数をベースに、あなたのプロジェクトのビジネスロジックをラップしてください。その瞬間から、あなたのWordPressは「アクセス集中で落ちる」という恥ずべき歴史から解放されます。