WordPressの深淵へようこそ。コアコントリビューターの視点から、今日は「WordPressマルチサイト×Redis」という、多くのエンジニアが躓き、そしてここを制した者だけが「真のスケール」を手にできる領域についてお話しします。
WordPressの`Transient API`は、データベースへの直接アクセスを回避するための素晴らしい武器ですが、マルチサイト環境でこれを使うと、ある日突然「サイトAのキャッシュがサイトBに表示される」という悪夢が起こります。
なぜか？それは、Redisという「共有メモリ」の中で、キーが衝突（Collision）しているからです。
—
1. なぜRedisでのキャッシュ分離が必要なのか？
WordPressのマルチサイト（ネットワーク）は、一つのデータベースを共有し、テーブル名のプレフィックス（`wp_1_`, `wp_2_` など）で各サイトを識別しています。
しかし、Redis等のオブジェクトキャッシュは、デフォルトではネットワーク全体で共有されます。
もし、あなたが `set_transient(‘featured_posts’, …)` というコードを複数のサイトで実行したらどうなるでしょう？ 後から実行されたサイトのデータが、先ほど保存されたデータを上書きしてしまいます。これでは、キャッシュの効率化どころか、致命的な不具合の温床になります。
—
2. プレフィックスによる「名前空間」の設計戦略
この問題を解決する唯一の正解は、「サイトIDに基づいたキーの完全分離」です。
WordPressには `get_current_blog_id()` という関数がありますね。これを使って、キャッシュキーを動的に生成する戦略をとります。
推奨されるキー構造
{プレフィックス}:{サイトID}:{キャッシュ名}
例えば：
- サイトID 1 の場合: `wp_my_app:1:featured_posts`
- サイトID 2 の場合: `wp_my_app:2:featured_posts`
これなら、メモリ内でデータが衝突することは物理的にあり得ませんよね。
—
3. 実践コード：安全なTransient APIラッパー
それでは、実際にマルチサイト環境で安全にキャッシュを扱うためのラッパー関数を書いてみましょう。
/
- マルチサイト環境で安全なキャッシュ取得関数
/
function get_multisite_transient($key) {
// サイトIDを取得してキーに含める
$site_id = get_current_blog_id();
$prefixed_key = “site_{$site_id}_{$key}”;
return get_transient($prefixed_key);
}
/
- マルチサイト環境で安全なキャッシュ保存関数
/
function set_multisite_transient($key, $value, $expiration = 0) {
$site_id = get_current_blog_id();
$prefixed_key = “site_{$site_id}_{$key}”;
return set_transient($prefixed_key, $value, $expiration);
}
ここがポイント！
- `get_current_blog_id()` の活用: どのサイトから呼び出されても、常にそのサイト固有の識別子を付与することで、メモリ空間を論理的に切り分けています。
- プレフィックスの明示: `site_{$id}_` とすることで、Redisコンソールから覗いた時にも「どのサイトのデータか」が一目で判別できるようになります。
—
4. 陥りやすい罠と対策
初心者の頃、あるいは他の言語から移行してきた方がよくやってしまうミスがこちらです。
罠1：プレフィックスを忘れる
「面倒だから」とサイトIDを付与せずにRedisに保存すると、マルチサイト環境では必ずデータ破壊が起きます。これはバグではなく「仕様」ですので、コードレビューの段階で厳しくチェックしましょう。
罠2：オブジェクトキャッシュプラグインへの依存
`Redis Object Cache` などのプラグインを入れている場合、多くのプラグインは自動的に `wp_cache_` プレフィックスを内部で処理してくれます。しかし、プラグインが対応していない独自ロジックを組む場合は、上記のように自前で名前空間を制御する勇気が必要です。
—
最後に：WordPressをマスターするということ
WordPressの内部構造を理解するとは、「どこにデータが保存され、どのように展開されるか」のフローを脳内で可視化できるか、ということです。
Redisという強力な武器を、マルチサイトの複雑な構造の中でどう調和させるか。今日学んだ「キー設計による分離」は、単なるテクニックではなく、スケーラブルなシステムを構築するための「アーキテクチャの作法」です。
ここをクリアしたあなたは、もうWordPressの初心者ではありません。次の一歩として、`wp_cache_get` や `wp_cache_set` を直接叩いて、Transient APIを通さずにRedisを操作するレベルまで深掘りしてみてください。
世界最高峰のエンジニアたちは、常に「効率」と「整合性」の境界線で戦っています。皆さんも、ぜひその景色を見てください。応援しています！