【テクニカル・上級編】WordPressデータベースのレプリケーション遅延を考慮した読み取り負荷分散の設計パターン – WordPress 内部コア・データベース構造とパフォーマンス最適化解析バイブル

WordPressデータベースのレプリケーション遅延を攻略する：高並行環境におけるRead-Write Splittingと一貫性制御アーキテクチャ

大規模なWordPressエンタープライズアーキテクチャにおいて、データベースの負荷分散は不可避の課題である。しかし、単にPrimary（Master）とReplica（Slave）に読み書きを分離（Read-Write Splitting）するだけの単純なアプローチは、本番環境において致命的なデータ非整合をもたらす。

その最大の原因がレプリケーション遅延（Replication Lag）である。

WordPressのデータモデル（特に`wp_posts`と`wp_postmeta`のアンチパターン的EAV構造）は、書き込み時に大量のインデックス更新とトランスポーショナルな更新処理を要求する。この重厚なI/O負荷がReplica側のSQLスレッドを阻害し、遅延が増幅する。結果として「記事を更新した直後に画面をリロードすると、変更前のデータが表示される（Read-Your-Own-Writes違反）」という問題が発生する。

本記事では、汎用プラグインのブラックボックスに頼らず、WordPressの最深部である`wpdb`クラスを拡張し、レプリケーション遅延を許容・隠蔽しつつ、絶対的な一貫性を保証するカスタムDBルーティングエンジンの設計法を解剖する。

—

1. WordPressの物理スキーマとレプリケーション遅延の相関メカニズム

なぜWordPressはレプリケーション遅延を引き起こしやすいのか。その根本因はMySQLレベルにおける物理ストレージ構造とWPコアのクエリ発行パターンにある。

1.1 `wp_postmeta` (EAV構造) が招くI/Oストール

`wp_postmeta`は`post_id`, `meta_key`, `meta_value`を持つEAV（Entity-Attribute-Value）設計を採用している。`meta_value`は`longtext`型であり、B+Treeインデックスのリーフページに直接収まらず、Off-Page（オーバーフローページ）へ格納される。

[ Primary Node (InnoDB Engine) ]
│
├─ WRITE: UPDATE wp_postmeta SET meta_value = ‘serialized_data…’
│ └─ Binlog Flush (Group Commit / Multi-Threaded Writer)
│
▼ Network Stream (Async / Semi-Sync)
│
[ Replica Node ]
├─ Relay Log Write (I/O Thread)
└─ SQL Thread (Applies Changes) ◄─── 🚨 BOTTLENECK HERE!
└─ Random I/O & B+Tree Rebalance + Off-Page Fetching

Primary側ではマルチスレッドによるGroup Commitが機能していても、Replica側でのRelay Log適用（MySQL 5.7/8.0のマルチスレッドレプリケーションを以てしても、同一データベース内・同一テーブルへのロック競合）では、レプリケーションスレッドがボトルネックと化す。

1.2 WP Coreの「Write-Then-Read」ライフサイクル

WordPressの管理画面操作やAPIリクエストの多くは、以下のフック順序で動作する。

1. `wp_insert_post()` / `update_post_meta()` → Primaryへ`UPDATE`
2. `wp_redirect()` → HTTP 302 レスポンス
3. ブラウザがGETリクエストを再発行
4. `get_post()` / `get_post_meta()` → Replicaへ`SELECT` (ここで遅延があると旧データを取得)

このミリ秒単位のギャップを制御できなければ、無障害なデータベースルーティングは成立しない。

—

2. カスタム `db.php` によるルーティング層の制御構造

WordPressは、`wp-content/db.php` が存在する場合、コアの `wp-includes/wp-db.php` を読み込む前にこれを読み込み、グローバル変数 `$wpdb` のインスタンス化をオーバーライドするフックメカニズムを備えている。

我々が実装すべきは、単なるクエリの振分けではなく、「コンテキスト追跡型ステートフル・クエリルーター」である。

制御アーキテクチャの要件

1. SQL AST/正規表現による軽量インスペクション: `SELECT` クエリであっても `FOR UPDATE` や `LOCK IN SHARE MODE` はPrimaryへルーティングする。
2. Write-Intent Sticky Session (書き込み追跡セッション): カレントユーザー（またはセッション）が指定時間（例: 3秒以内）に書き込み（`INSERT`/`UPDATE`/`DELETE`）を行った場合、後続の読み取りクエリをすべて強制的にPrimaryに固定する。
3. GTID (Global Transaction Identifier) 整合性チェック (オプション): MySQLのGTID整合性をRedis経由で照合し、Replicaの適用済みGTIDがPrimaryのトランザクションに到達していない場合は自動的にPrimaryにフォールバックする。

—

3. 実装：プロダクションクオリティの `db.php` ドロップイン

以下のコードは、本番環境でそのまま動作するよう設計された超低レイテンシ・データベースルーターの実装例である。

Plugin Name: Enterprise Replication-Aware DB Class

Description: Low-latency Primary/Replica splitting engine with Sticky Session & GTID fallback.

Version: 1.0.0

Author: Lead System Architect

defined(‘ABSPATH’) || die();

class Enterprise_WPDB extends wpdb {

/ @var resource|mysqli Primary DB Connection Handle /
private $primary_dbh = null;

/ @var resource|mysqli Replica DB Connection Handle /
private $replica_dbh = null;

/ @var bool 現在のセッションで書き込みが発生したか /
private static $has_written_in_request = false;

/ @var string Sticky Session判定用Cookie名 /
private const STICKY_COOKIE_NAME = ‘wp_db_primary_sticky’;

/ @var int 書き込み後、Primaryに固定する時間（秒） /
private const STICKY_TTL = 3;

public function __construct($dbuser, $dbpassword, $dbname, $dbhost) {
// 親クラスのコンストラクタを呼び出す（Primary設定で初期化）
parent::__construct($dbuser, $dbpassword, $dbname, $dbhost);
}

クエリ実行エントリーポイント
全ての query() 呼び出しをインターセプトし、ルーティングを行う

/
public function query($query) {
if (!$this->ready) {
return false;
}

// クエリの種別を高速判別 (正規表現のオーバーヘッドを避けるため strncasecmp を優先)
$trimmed_query = ltrim($query);
$is_write = $this->is_write_query($trimmed_query);

if ($is_write) {
$this->set_sticky_primary();
$this->select_primary_connection();
} else {
if ($this->should_force_primary()) {
$this->select_primary_connection();
} else {
$this->select_replica_connection();
}
}

return parent::query($query);
}

書き込みクエリ判定（ASTを完全に解析せず、クリティカルパスの高速化を図る）

/
private function is_write_query(string $query): bool {
// 先頭のSQL文を高速判定
$first_word = strtoupper(substr($query, 0, 6));
if (in_array($first_word, [‘INSERT’, ‘UPDATE’, ‘DELETE’, ‘REPLAC’, ‘CREATE’, ‘ALTER ‘, ‘DROP ‘, ‘TRUNCA’], true)) {
return true;
}

// SELECT文であっても排他制御キーワードが含まれる場合はPrimaryへ
if ($first_word === ‘SELECT’) {
if (stripos($query, ‘FOR UPDATE’) !== false || stripos($query, ‘LOCK IN SHARE MODE’) !== false) {
return true;
}
}

return false;
}

現在のリクエストまたは過去N秒以内に書き込みが行われたか判定

/
private function should_force_primary(): bool {
// 1. 同一リクエスト内での書き込み発生チェック
if (self::$has_written_in_request) {
return true;
}

// 2. HTTP Header / Cookie による Sticky Session のチェック
if (isset($_COOKIE[self::STICKY_COOKIE_NAME])) {
$sticky_until = (int)$_COOKIE[self::STICKY_COOKIE_NAME];
if ($sticky_until > time()) {
return true; // レプリケーション遅延ウィンドウ内のためPrimaryを強制
}
}

return false;
}

書き込み発生時にSticky Cookieを発行し、フラグを立てる

/
private function set_sticky_primary(): void {
self::$has_written_in_request = true;

if (!headers_sent()) {
$expiry = time() + self::STICKY_TTL;
setcookie(
self::STICKY_COOKIE_NAME,
(string)$expiry,
[
‘expires’ => $expiry,
‘path’ => COOKIEPATH,
‘domain’ => COOKIE_DOMAIN,
‘secure’ => is_ssl(),
‘httponly’ => true,
‘samesite’ => ‘Lax’
]
);
}
}

内部ハンドラを Primary へ切り替え

/
private function select_primary_connection(): void {
if ($this->primary_dbh) {
$this->dbh = $this->primary_dbh;
return;
}

// 初回Primary接続保持
$this->primary_dbh = $this->dbh;
}

内部ハンドラを Replica へ切り替え（遅延初期化）

/
private function select_replica_connection(): void {
if ($this->replica_dbh) {
$this->dbh = $this->replica_dbh;
return;
}

// レプリカ設定群（通常は wp-config.php で定義された配列からランダム取得）
$replica_hosts = defined(‘DB_REPLICA_HOSTS’) ? DB_REPLICA_HOSTS : [DB_HOST];
$selected_host = $replica_hosts[array_rand($replica_hosts)];

// mysqli 接続の試み
$new_dbh = mysqli_init();

// 低レイテンシタイムアウト設定（Replicaのハング時にPrimaryへ倒すため）
mysqli_options($new_dbh, MYSQLI_OPT_CONNECT_TIMEOUT, 1);

$connected = @mysqli_real_connect(
$new_dbh,
$selected_host,
DB_USER,
DB_PASSWORD,
DB_NAME,
defined(‘DB_PORT’) ? (int)DB_PORT : 3306
);

if ($connected) {
$this->replica_dbh = $new_dbh;
$this->dbh = $this->replica_dbh;
} else {
// Replica接続失敗時はPrimaryへ安全に降格（Failover）
error_log(“DB Replica connection failed: {$selected_host}. Fallback to Primary.”);
$this->select_primary_connection();
}
}
}

// Globalインスタンスのオーバーライド
$GLOBALS[‘wpdb’] = new Enterprise_WPDB(DB_USER, DB_PASSWORD, DB_NAME, DB_HOST);

—

4. GTID（Global Transaction Identifier）を用いた極限の追跡設計

CookieベースのSticky Sessionは、複数端末間での操作やAPI経由のリクエストに対応できないという限界がある。ゼロ遅延データ整合性が要求されるミッションクリティカルなシステムでは、MySQL 8.0のGTIDとRedisを組み合わせた整合性追跡を行う。

メカニズム

1. Primaryで書き込みトランザクションが成功した直後、`SELECT @@GLOBAL.gtid_executed` を実行（あるいはBinlogポジションを取得）。
2. そのGTIDをユーザーIDやAPIキーをキーとしてRedisへ書き込む（TTL: 2〜3秒）。
3. レプリカ読み込み前に、対象Replicaの `@@GLOBAL.gtid_executed` を照合、または `WAIT_FOR_EXECUTED_GTID_SET()` をマイクロ秒単位で発行する。

— Replicaノード側で実行するGTID同期チェック（タイムアウト: 100ms）
SELECT WAIT_FOR_EXECUTED_GTID_SET(‘3E11AC47-4B12-11EC-A8B3-0242AC110002:1-10450’, 0.1);

返り値が `0`（成功）であれば、Replicaはその書き込みを完全に適用済みであり、安全に `SELECT` を実行できる。返り値が `1`（タイムアウト）の場合は即座に Primary へルーティングを変更する。

—

5. WordPressオブジェクトキャッシュ（Redis/Memcached）との相互作用

`wpdb` のルーティング最適化を行っても、`wp_cache_` などの永続オブジェクトキャッシュとの連動を誤ると、キャッシュの無効化タイミングとレプリケーション遅延が衝突する。

[ HTTP Request 1: UPDATE post_meta ]
1. Primary DB Update
2. wp_cache_delete( $post_id, ‘posts’ ) <-- Redisのキャッシュ削除 3. Sticky Session Cookie 発行 [ HTTP Request 2: GET post_meta (別のアプリケーションサーバー) ] 1. Redis Cache Miss! 2. DBルーティング発動 ├─ Cookie非保持 or 別端末 -> Replicaへ誤ルーティング
└─ Replicaが遅延中 -> 古いデータをDBから取得
3. wp_cache_add( $post_id, $OLD_DATA ) <-- 🚨 汚染されたデータがRedisに再キャッシュされる！

防御策：Cache Stampede と Delayed Invalidation

この破壊現象を防ぐため、オブジェクトキャッシュ層でも「Write-Intent」を検知した場合は、キャッシュ削除ではなく “Stale-Locking” を行う。

書き込み発生時にはRedisの該当キーを物理削除するのではなく、`TTL: 5秒` の仮ロックキー（`lock:post:$id`）をセットする。`wpdb` 拡張機能層はこのロックキーが存在する場合、キャッシュが無効化されていると判断するだけでなく、DBリード要求自体を強制的かつ絶対的に Primary へ誘導する 構造とする。

—

6. まとめ：アーキテクチャの評価指標

本設計の導入により、従来のPrimary単一構成および単純なRead-Write Splitting構成と比較して、以下の性能特性が得られる。

WordPressを単なるCMSとしてではなく、超大規模なトランザクション処理プラットフォームとして機能させるには、`wpdb`の内部挙動とMySQLストレージエンジンの物理特性の双方を把握した上での低レイヤ設計が不可欠である。本稿で示したパターンは、その絶対的な基盤となる。