WordPressを掌握する：Object CacheとDB整合性を守る「分散ロック」の深淵
こんにちは。WordPressの内部構造を深く愛するエンジニアの皆さん。今日は、中級者から一歩先へ進むための「高負荷環境におけるキャッシュ戦略」について、核心を突いた話をしましょう。
WP_Queryの結果をキャッシュするのは基本ですが、「同時に複数のプロセスが同じキャッシュを生成しようとする（Cache Stampede）」という現象に直面したことはありますか？
今日は、Object Cache（RedisやMemcached）とデータベースの整合性を守るための「分散ロック」設計について解説します。ここを理解すれば、あなたのサイトは数万PVのアクセスにも涼しい顔をして耐えられるようになりますよ。
—
1. なぜ「キャッシュの整合性」が崩れるのか？
まず、イメージしてください。データベース上の `wp_posts` テーブルに対して、複雑な `WP_Query` を実行するとします。
1. プロセスAが「キャッシュがない！」と判断し、重いクエリをDBに投げようとする。
2. その瞬間にプロセスBも「キャッシュがない！」と判断し、同じ重いクエリを投げる。
3. DBに負荷が集中し、結果として同じデータが何度もキャッシュエンジンへ書き込まれる。
これが典型的な「キャッシュ雪崩（Cache Stampede）」です。最悪の場合、整合性が取れなくなり、古いデータがキャッシュされ続けるといった事態に陥ります。
—
2. 分散ロックの実装：`wp_cache_add` の活用
この問題を解決する鍵は、WordPressの `wp_cache_add` メソッドにあります。実は、この関数は「キーが存在しない場合にのみ値をセットする」というアトミック（不可分）な性質を持っています。これを利用して、「今から自分がこのクエリを生成するぞ」という通行手形（ロック）を発行するのです。
実装コード例
/
- データベースの整合性を守るロック付きWP_Query実行
/
function get_optimized_posts_with_lock() {
$cache_key = ‘my_complex_query_result’;
$lock_key = $cache_key . ‘_lock’;
// 1. まずはキャッシュを確認
$data = wp_cache_get($cache_key);
if (false !== $data) return $data;
// 2. ロックを取得（10秒間有効）
// wp_cache_addはキーが存在しない時だけtrueを返す
if (wp_cache_add($lock_key, ‘locked’, ”, 10)) {
// — ここで初めて重いクエリを実行 —
$query = new WP_Query([‘post_type’ => ‘post’, ‘posts_per_page’ => 10]);
$data = $query->posts;
// キャッシュに保存
wp_cache_set($cache_key, $data, ”, 3600);
// ロックを解除
wp_cache_delete($lock_key);
} else {
// 3. ロックが取れなかった場合：誰かが生成中なので少し待つか、古いキャッシュを返す
usleep(200000); // 0.2秒待機して再帰呼び出し
return get_optimized_posts_with_lock();
}
return $data;
}
—
3. 解説：コードの裏側で何が起きているのか？
このコードで重要なポイントを整理しましょう。
- `wp_cache_add` のアトミック性:
これが最も重要です。PHPの `if (isset())` でチェックして `set` するのでは遅いんです。`wp_cache_add` はバックエンド（Redisなど）の仕組みを使って「競合なし」を保証します。
- デッドロックの回避:
ロックキーには必ず有効期限（TTL）を設けます。もし生成中にサーバーが落ちても、10秒後にはロックが自動解除されるように設計するのがプロの作法です。
- 再帰呼び出しの罠:
`usleep` を使って待機していますが、極端に短い間隔で回しすぎるとCPUを浪費します。本番環境では最大リトライ回数を設けるのが安全です。
—
4. 陥りやすい罠：ここだけは注意！
初学者がよくやってしまうミスが、「DBの更新処理とキャッシュ削除のタイミング」です。
WordPressでは `save_post` フックを使いますが、ここで「キャッシュを削除」するだけでは不十分な場合があります。データベースのトランザクションが完了する前にキャッシュがクリアされ、直後に別のプロセスが「まだ更新されていない古いDBの値」をキャッシュしてしまう、いわゆる「競合状態（Race Condition）」が起こります。
解決策のヒント
データベースの更新処理（`wp_update_post`など）の直後ではなく、`transition_post_status` フックを利用するか、あるいはDBのクエリキャッシュを無効化する仕組みを併用するなど、「DB更新の確定」を待ってからキャッシュを無効化する意識を持つことが、安定稼働への近道です。
—
最後に：WordPressを掌握するということ
WordPressは単なるブログツールではなく、巨大なデータベースを動的に扱う「アプリケーションフレームワーク」です。内部構造を知り、キャッシュの整合性を自らコントロールできるようになれば、あなたはもう「WordPressを使わせてもらっている側」から「WordPressを意のままに操る側」へ進化しています。
難しい概念に感じるかもしれませんが、一つひとつ噛み砕いていけば必ず理解できます。次はぜひ、Redisの永続化設定や、クエリの実行計画（`EXPLAIN`）の確認にも挑戦してみてください。
また現場でお会いしましょう。あなたのコードが、世界中のユーザーに最高のパフォーマンスを届けることを願っています！