キャッシュミスは「事故」ではない。WordPressにおける堅牢なキャッシュ・フォールバック戦略
WordPressのパフォーマンスを語る上で、`wp_cache_get`を適切に扱うことは避けて通れない。特にRedisやMemcachedといったオブジェクトキャッシュを導入している環境において、`false`が返ってきた瞬間のハンドリングが、アプリケーションの堅牢性を決定づける。
「キャッシュがなければDBを叩く」――この単純なロジックを、高トラフィックな本番環境でそのまま実装してはならない。いわゆる「キャッシュ・スタンピード（Cache Stampede）」を引き起こし、DBサーバーをダウンさせる引き金になるからだ。
今回は、実務レベルで必ず実装すべき、競合を防ぎつつ効率的にデータを取得する設計パターンを伝授する。
—
1. なぜ「単純なif文」が危険なのか
よくあるアンチパターンはこれだ。
// 絶対にやってはいけない実装
$data = wp_cache_get(‘my_key’, ‘my_group’);
if (false === $data) {
$data = fetch_heavy_data_from_db(); // ここで重い処理が走る
wp_cache_set(‘my_key’, $data, ‘my_group’, 3600);
}
このコードの致命的な欠陥は、「同時に複数のリクエストがキャッシュミスした場合、全てのプロセスが並列して重いDBクエリを実行してしまう」点にある。キャッシュが存在しない最初の数秒間、サーバーはDBへのアクセス過多でスタックする。
これを防ぐためには、アトミックな排他制御、あるいはキャッシュの生存戦略を設計に組み込む必要がある。
—
2. 実務で採用すべき「堅牢なフォールバック設計」
中級者以上のエンジニアが採用すべきは、「ロック機構を用いた排他制御」または「キャッシュ更新の非同期化（またはバックグラウンド更新）」である。
今回は、小〜中規模のプロジェクトで即座に応用可能な、最もコストパフォーマンスの高い「ロック付き取得パターン」を提示する。
堅牢なコードパターン
/
- キャッシュ付きデータ取得：競合回避戦略
/
function get_robust_data(string $key, callable $callback, int $ttl = 3600) {
$group = ‘my_app_group’;
$data = wp_cache_get($key, $group);
// キャッシュヒット時は即座に返す
if (false !== $data) {
return $data;
}
// キャッシュミス時：ロックキーを生成して他のリクエストを抑制
$lock_key = $key . ‘_lock’;
// 5秒間の排他ロックを試みる（add はキーが存在しない時のみ真を返す）
if (wp_cache_add($lock_key, ‘1’, $group, 5)) {
// ロック獲得成功：DBから取得
$data = $callback();
wp_cache_set($key, $data, $group, $ttl);
wp_cache_delete($lock_key, $group); // ロック解除
} else {
// ロック獲得失敗：他のプロセスが取得中。
// ここで「古いキャッシュ」を返すか、少し待機して再試行する（今回は簡略化のため空を返す）
return null;
}
return $data;
}
// 利用例
$results = get_robust_data(‘user_stats_123’, function() {
global $wpdb;
return $wpdb->get_results(“SELECT … FROM heavy_table”);
});
—
3. なぜこのコードが美しいのか
この設計には、エンジニアが意識すべき3つのポイントが隠されている。
1. `wp_cache_add`によるアトミック操作: `wp_cache_set`ではなく`add`を使うことで、そのキーが存在しない場合にのみ値をセットできる。これが「ロック」として機能する。
2. 無駄なDBアクセスを排除: 他のリクエストがDBを叩いている間、後続のリクエストはロックによりDB負荷を回避できる。
3. 副作用の分離: 第2引数に`callable`を渡すことで、データ取得ロジックとキャッシュ管理ロジックを完全に分離している。これにより、単体テストも容易になる。
—
4. プロダクション環境における注意点
- ロックのタイムアウト値: 上記例では5秒としているが、DBクエリが5秒以上かかる場合はロックが解除されてしまい、再び競合が発生する。クエリの実行時間は事前に`EXPLAIN`等で検証しておくこと。
- フォールバックのフォールバック: もしキャッシュもDBも死んでいた場合、この関数は`null`を返す。呼び出し元では必ず`if (is_null($results))`のチェックを行い、ユーザー体験を損なわないようデフォルト値をセットする義務がある。
- Redisの永続化: WordPressの`wp_cache_set`は揮発性メモリへの保存が基本だ。再起動でキャッシュが消える前提の設計、つまり「キャッシュがなくてもシステムが止まらない」構成を維持することが、WordPressエンジニアの矜持である。
最後に：コードは「意図」を語るべきだ
「ただ動くコード」と「プロダクションで信頼できるコード」の差は、こうした「想定外の事態が起きた時にどう振る舞うか」という設計の深度に現れる。
キャッシュミスは、システムが最も脆弱になる瞬間だ。その瞬間にこそ、エンジニアとしての知見を詰め込み、システムを保護せよ。それが、WordPressという巨大なエコシステムの上で開発を行う者たちの責任である。