WordPressの「キャッシュの墓場」を回避せよ：高負荷環境における整合性を保証する分散ロック設計
WordPressの `WP_Query` は強力だが、スケールするシステムにおいて「キャッシュとDBの整合性」を盲信するのは素人の所業だ。
高負荷なトラフィックが押し寄せる環境では、`wp_cache_get` が `false` を返した瞬間に複数のリクエストが同時にDBへクエリを投げ、結果を競ってキャッシュに書き込む「キャッシュ・スタンピード（キャッシュ雪崩）」が発生する。これに対処せず、整合性を担保せずに運用すれば、ユーザーには古い情報が、DBには過剰な負荷が蓄積される。
今日は、WordPressの内部構造を理解した上で、「分散ロック機構」を用いた堅牢なキャッシュ戦略を実装するアーキテクチャを伝授する。
—
1. なぜ WP_Query のキャッシュは「危険」なのか
`WP_Query` の結果セットを `wp_cache_set` で保存することは一般的だが、ここには2つの大きな落とし穴がある。
1. データ不整合: 記事の更新（`transition_post_status`）時にキャッシュ削除が漏れると、DBとキャッシュで情報が乖離する。
2. 競合状態（Race Condition）: 複数のワーカーが同時にキャッシュミスを検知し、同一クエリをDBに発行。結果、DB負荷が跳ね上がり、最後に書き込まれたものが正となる不確定な状態に陥る。
これらを解決するには、「排他ロック」の概念をWordPressのオブジェクトキャッシュ層に持ち込む必要がある。
—
2. 実装：分散ロックを用いた安全なクエリ実行パターン
Redis等の永続化キャッシュ（`wp_cache_`）を前提とし、`wp_cache_add` が持つ「キーが存在しない場合のみ作成する」というアトミック性を利用してロックを形成する。
プロダクションコード例：Distributed Cache Locker
/
- 高負荷環境下でWP_Queryのキャッシュ更新を排他制御するクラス
/
class QueryCacheManager {
const LOCK_TIMEOUT = 5; // ロックの生存時間（秒）
public static function get_query_result(string $cache_key, callable $query_callback) {
$data = wp_cache_get($cache_key, ‘custom_group’);
if (false !== $data) {
return $data;
}
$lock_key = $cache_key . ‘_lock’;
// 1. 分散ロックの取得 (wp_cache_addはアトミック)
if (wp_cache_add($lock_key, ‘1’, ‘custom_group’, self::LOCK_TIMEOUT)) {
try {
// 2. キャッシュミス後のDBクエリ実行
$data = $query_callback();
wp_cache_set($cache_key, $data, ‘custom_group’, HOUR_IN_SECONDS);
} finally {
// 3. 処理終了後に必ずロックを解放
wp_cache_delete($lock_key, ‘custom_group’);
}
return $data;
}
// 4. ロック取得失敗時は少し待機して再試行 or 既存キャッシュの微細な許容
// ここでは便宜上、再帰呼び出しを避けてnullを返すか、スリープして再試行を実装する
usleep(100000); // 100ms待機
return self::get_query_result($cache_key, $query_callback);
}
}
この設計の肝
- アトミックなロック: `wp_cache_add` は、キーが存在する場合 `false` を返す。これにより、並行リクエストのうち「最初に到着した1つ」だけがDBへアクセス権を持つ。
- finally構文: 例外が発生しても必ず `wp_cache_delete` が呼ばれる設計にしている。これがないとロックが解除されず、システムがデッドロック状態に陥る。
—
3. インデックスチューニング：DB側で勝負を決める
いくらキャッシュが優秀でも、キャッシュミス時のDBクエリが遅ければ全てが台無しだ。`WP_Query` を発行する際は、必ず `EXPLAIN` で実行計画を確認せよ。
特に `meta_query` や `tax_query` を組み合わせる場合、MySQLはしばしばインデックスを無視したフルテーブルスキャンを試みる。
- カスタムフィールドのインデックス: `wp_postmeta` の `meta_key` と `meta_value` は型が `LONGTEXT` であるため、そのままではインデックスが効きにくい。高頻度で検索するフィールドは、専用のカスタムテーブルを切り出し、適切なB-Treeインデックスを張るのが「伝説的エンジニア」の常識だ。
- クエリの最適化: `WP_Query` の引数に `’no_found_rows’ => true` を指定するのを忘れるな。`SQL_CALC_FOUND_ROWS`（ページネーションのための全件カウント）は、大規模テーブルにおいては死刑宣告に等しいパフォーマンス劣化を招く。
—
4. 結論：コードは「状態」を意識せよ
WordPressのキャッシュ戦略において最も重要なのは、「整合性」と「可用性」のトレードオフをどうコントロールするかだ。
1. 書き込み時: `transition_post_status` フックをフックして、該当するキャッシュキーを確実に削除する。
2. 読み込み時: 上記の分散ロックを用いて、高負荷時のDBスパイクを抑制する。
この2段構えができて初めて、あなたのWordPressサイトは「大規模環境に耐えうるシステム」へと昇華する。
エンジニアよ、`WP_Query` を単なる関数の呼び出しとしてではなく、背後で走るSQLの重みと、メモリ上に展開されるオブジェクトのライフサイクルとして捉えよ。それが、WordPressの内部を知り尽くした者だけが見える景色だ。