Transient APIの死と再生：ユーザーを待たせない「バックグラウンド更新」のアーキテクチャ
WordPressの`set_transient()`を「単純なキャッシュ保存」と捉えているなら、それは大規模トラフィックの門前で足止めを食らうことになる。
標準的なTransient APIは、期限が切れた瞬間に`false`を返す。その結果、次のリクエストが重い外部API叩きや複雑な`WP_Query`を実行し、ユーザーを数秒間待たせることになる。いわゆる「キャッシュ・スタンピード（Cache Stampede）」現象だ。
プロフェッショナルなエンジニアであれば、「期限切れ＝即時再計算」という安直な設計を捨て、ユーザー体験を犠牲にしない非同期更新（Background Refresh）パターンを実装しなければならない。
—
1. なぜ「期限切れ待ち」が発生するのか
Transientが期限切れになると、WordPressは `get_transient` で `false` を返し、アプリケーション側は「再取得」という重い処理を開始する。これが高負荷時のボトルネックだ。
私たちが目指すべきは、「キャッシュが切れる直前に裏側で更新を走らせ、ユーザーには常に古い（が、表示可能な）キャッシュを出し続ける」というアーキテクチャである。
—
2. 実装パターン：Lazy Refresh with Background Job
このパターンの肝は、Transientの保存期間を2つ管理することにある。
1. TTL（生存期間）: `get_transient` が有効な期間。
2. Soft TTL（更新トリガー期間）: この期間を過ぎたら、裏で更新処理を走らせる閾値。
堅牢な実装コード
以下のクラスは、高負荷サイトでも安定して動作する「非同期更新」のテンプレートだ。
/
public static function get_or_refresh(string $key, callable $callback, int $ttl = 3600) {
$soft_ttl = $ttl – 300; // 5分前に更新トリガーを引く
$data = get_transient($key);
if (false !== $data) {
// 更新フラグがあるか確認（競合防止）
if (!get_transient($key . ‘_updating’)) {
$last_updated = get_option($key . ‘_last_updated’, 0);
// Soft TTLを過ぎていたら非同期で更新ジョブを投げる
if (time() > ($last_updated + $soft_ttl)) {
self::trigger_background_update($key, $callback, $ttl);
}
}
return $data;
}
// キャッシュが完全に消滅している場合は、同期的に取得するしかない
return self::force_update($key, $callback, $ttl);
}
private static function trigger_background_update($key, $callback, $ttl) {
set_transient($key . ‘_updating’, true, 60); // 1分間のロック
// WP-Cronへタスクを投げる（非同期実行の定石）
if (!wp_next_scheduled(‘bg_update_event_’ . $key)) {
wp_schedule_single_event(time(), ‘bg_update_event_’ . $key, [$key, $callback, $ttl]);
}
}
public static function force_update($key, $callback, $ttl) {
$data = call_user_func($callback);
set_transient($key, $data, $ttl);
update_option($key . ‘_last_updated’, time());
delete_transient($key . ‘_updating’);
return $data;
}
}
// 使い方
add_action(‘bg_update_event_my_api_data’, [‘BackgroundTransients’, ‘force_update’], 10, 3);
$data = BackgroundTransients::get_or_refresh(‘my_api_key’, function() {
return wp_remote_get(‘https://external-api.com/data’);
}, 3600);
—
3. 現場で押さえるべきパフォーマンスの急所
この設計を採用するにあたり、以下の3点を意識しなければ「自爆」する。
① Redisの活用（Object Cacheの最適化）
WordPress標準のDBベースのTransientは、高負荷時にはDBの書き込み競合（`wp_options`テーブルの行ロック）を引き起こす。必ずRedisやMemcachedのようなインメモリキャッシュを導入せよ。`wp-config.php`で `WP_REDIS_DISABLE_RELATE` などの設定を適切にチューニングし、`options`テーブルへのI/Oを極限まで減らすのが鉄則だ。
② 競合ロックの重要性
`trigger_background_update` 内で `_updating` フラグを立てているのは、同時に複数のリクエストが飛んできた際に、同じAPIを何度も叩くのを防ぐためだ。これがないと、キャッシュ切れの瞬間にスパイクが発生し、外部APIのレートリミットに即座に抵触する。
③ WP-Cronの限界
`wp_schedule_single_event` を使用しているが、WP-Cronはページ閲覧時にしか実行されない。アクセスが極端に少ないサイトでは更新が滞る可能性がある。トラフィックがある程度あるサイトであれば問題ないが、厳密なリアルタイム性を求めるなら、サーバーサイドのCrontabから `wp-cli` を叩く構成へ切り替える準備をしておくべきだ。
—
結論：システムを支配せよ
キャッシュ戦略は、単なる「高速化」の手段ではない。ユーザーのレスポンス時間を一定に保つための「防波堤」である。
今回紹介したバックグラウンド更新パターンは、大規模メディアサイトの基盤設計において必須のテクニックだ。コードをコピペするだけでなく、自身のプロジェクトの「キャッシュTTL」と「更新コスト」を計測し、このロジックを最適化してほしい。
システムは設計した通りの挙動しか示さない。その設計に魂を込めるかどうかは、君たちエンジニアの裁量に委ねられている。