データベースへの「殺到」を止める：WordPress Object CacheにおけるCache Stampedeの根絶
WordPressの `Transient API` は、一見すると便利で安全なキャッシュ層に見える。しかし、それは単なる「データベースの回避策」として利用している限り、高トラフィック環境では最も脆弱なボトルネックへと変貌する。
我々が直面すべきは、キャッシュの有効期限（TTL）が切れた瞬間に発生する「Cache Stampede（キャッシュの殺到）」という現象だ。
1. Stampedeのメカニズム：なぜシステムは崩壊するのか
キャッシュが期限切れになると、複数のワーカープロセスが同時に「キャッシュがない」と判断する。結果として、同じ重いクエリ（`WP_Query` や複雑なJOINを伴うSQL）がバックエンドのRDBMSに対して同時に発行される。
この現象が発生すると、以下の連鎖反応が起きる。
1. RDBMSの負荷急増: 同時実行される重いクエリによりCPU/I/Oが飽和する。
2. プロセスの枯渇: PHP-FPMのワーカーがクエリの完了を待機し続け、新規リクエストを処理できなくなる。
3. ダウンタイム: 最終的に接続エラー（`Too many connections`）が発生し、サイト全体が停止する。
Redisを導入している場合でも、`GET` がミスした直後に複数の `SET` が競合し、バックエンドを叩く事実に変わりはない。我々は「キャッシュミス」を「単一のプロセスのみが再生成を行う」という不可分な操作（Atomic Operation）に昇華させる必要がある。
2. ロック機構による排他制御の実装
単純な `set_transient` では不十分だ。我々が必要とするのは、キャッシュ生成の権利を制御する「分散ロック（Distributed Lock）」である。
以下の実装は、`wp_cache` を活用し、アトミックにロックを取得する手法だ。
/
- 堅牢なキャッシュ生成のためのロック機構付きラッパー
- @param string $key キャッシュキー
- @param callable $callback キャッシュ生成用ロジック
- @param int $ttl 有効期限
- @return mixed
/
function get_cached_data_with_lock(string $key, callable $callback, int $ttl = 3600) {
$data = wp_cache_get($key);
if (false !== $data) {
return $data;
}
$lock_key = $key . ‘_lock’;
// add() はキーが存在しない場合にのみ値をセットする。
// Redis/Memcachedの性質上、これはアトミックな操作となる。
if (wp_cache_add($lock_key, ‘1’, ”, 10)) {
try {
$data = call_user_func($callback);
wp_cache_set($key, $data, ”, $ttl);
} finally {
// ロックの解除
wp_cache_delete($lock_key);
}
} else {
// ロックが取得できない場合、他のプロセスが生成中であると判断。
// ここで再試行または古いキャッシュを返す（Soft TTLの考え方）。
usleep(100000); // 100ms 待機
return get_cached_data_with_lock($key, $callback, $ttl);
}
return $data;
}
3. 高度な最適化：Soft TTL（Probabilistic Early Recomputation）
ロックによる制御は確実だが、ロック待ちのプロセスが発生するというデメリットがある。これを回避する究極の策が Soft TTL だ。
キャッシュの有効期限を少しだけ「早めに」設定し、期限が切れる数秒前に、非同期（あるいはバックグラウンドプロセス）でキャッシュを更新する仕組みである。
- Hard TTL: キャッシュが完全に無効化される時間。
- Soft TTL: 「そろそろ更新すべき」と判断する時間。
これを実装するには、キャッシュデータ自体に `expires_at` を持たせ、現在時刻と比較して「更新の閾値」に達していれば、バックグラウンドで `WP-Cron` や `Action Scheduler` を叩き、その間は古いキャッシュをユーザーに返し続ける。これにより、エンドユーザーはキャッシュ生成の遅延に一切遭遇しなくなる。
4. システムアーキテクトからの助言
WordPressのObject Cache層を掌握するということは、「どのデータが揮発性で、どのデータが永続的か」をメタデータレベルで理解することと同義だ。
- Redisの `maxmemory-policy`: `allkeys-lru` に設定されているか確認せよ。`volatile-lru` ではTTLが設定されていない重要なフラグまで削除される可能性がある。
- Object Cacheの分離: セッションとTransient、そして永続的なオプションデータは、Redisのデータベース番号を分けるか、プレフィックスを厳格に管理すべきだ。
- シリアライズのオーバーヘッド: 大規模な配列を `set` する際は、`igbinary` の利用を検討せよ。PHP標準の `serialize` はメモリ消費が激しく、高トラフィック下ではGC（ガベージコレクション）の負荷を増大させる。
キャッシュとは、単なる「速くするための仕組み」ではない。システム全体を保護し、RDBMSという「神聖なる心臓部」を守るための最後の盾である。この盾を適切に運用できぬエンジニアに、大規模なWordPress環境を任せることはできない。
コードを書くとき、常に「その1行がデータベースへのクエリを1回減らせるか」を自問せよ。それが伝説的なパフォーマンスへの唯一の道だ。