WordPressの深淵：wp_usermetaのEAV構造がもたらす権限チェックのボトルネックと、その「剥離」戦略
WordPressのアーキテクチャを語る上で、避けて通れないのがEAV（Entity-Attribute-Value）モデルの弊害だ。特に`wp_usermeta`テーブルは、柔軟性と引き換えに、スケーラビリティの観点からは「技術的負債の集積地」と化している。
本稿では、`get_userdata()`から始まる権限チェックの連鎖が、なぜ大規模トラフィック下でデータベースのI/Oを飽和させるのか。その内部メカニズムを解剖し、コアの振る舞いを制御するための最適化手法を提示する。
—
1. 権限チェックの物理的コスト：EAVモデルの罠
`wp_usermeta`は、ユーザーID、メタキー、メタ値というフラットな構造を持つ。一見シンプルだが、`get_userdata()`が呼び出されると、WordPressは以下のプロセスを強制する。
1. 単一クエリの限界: `get_userdata()`を呼ぶと、内部で`get_user_by()`が実行され、さらに`WP_User`クラスのインスタンス化に伴い、該当するユーザーの全メタデータが`get_metadata(‘user’, …)`経由で一括ロードされる。
2. JOINの欠如とフェッチの増大: メタデータが個別の行として保存されているため、権限（`wp_capabilities`）を一つ確認するだけでも、そのユーザーの全メタデータをオンメモリに展開する必要がある。
3. シリアライズのオーバーヘッド: `wp_capabilities`はPHPでシリアライズされた配列として格納されている。これを取得するたびに`maybe_unserialize()`が走り、CPUサイクルを消費する。
可視化：クエリの深淵を覗く
以下のクエリは、単一の`current_user_can()`が裏側でどれほど無防備にデータベースを叩いているかを露呈させる。
— wp_usermetaをスキャンし、特定のユーザーの全メタデータをメモリへ展開する
SELECT meta_key, meta_value FROM wp_usermeta WHERE user_id = %d;
これが数千リクエスト/秒の環境下で走れば、MySQLのクエリキャッシュが効かない場合、ディスクI/Oがボトルネックとなるのは自明だ。
—
2. 権限チェックのキャッシュ戦略：Object Cacheの最適化
我々が取るべき戦略は「データベースへの到達回数をゼロにする」ことだ。WordPressの`WP_Object_Cache`は、デフォルトではリクエスト内メモリにしか存在しない。これをRedisやMemcachedといった永続化層へオフロードするのは当然の前提として、さらに「権限チェックのバイパス」を実装する。
実装例：権限チェックのメモ化とオーバーライド
`user_has_cap`フィルタをフックし、`wp_usermeta`の読み取りを完全に遮断するアプローチを取る。
/
- 権限チェックをObject Cacheに直結させ、DBアクセスを排除する
/
add_filter(‘user_has_cap’, function($allcaps, $caps, $args, $user) {
if (empty($user->ID)) return $allcaps;
$cache_key = “user_caps_{$user->ID}”;
$cached_caps = wp_cache_get($cache_key, ‘permissions’);
if (false !== $cached_caps) {
return $cached_caps;
}
// キャッシュがない場合のみ計算し、永続化キャッシュへ格納
// ここでメタデータを取りに行くのは初回のみにする
wp_cache_set($cache_key, $allcaps, ‘permissions’, HOUR_IN_SECONDS);
return $allcaps;
}, 10, 4);
—
3. 低レイヤからの警告：注意すべき「キャッシュ汚染」
しかし、このアプローチにはリスクがある。`update_user_meta`が呼ばれた際、キャッシュのフラッシュを忘れると、ユーザーは古い権限情報を握り続けることになる。
コアの挙動を掌握するならば、以下のフックで「キャッシュの無効化」を強制するのが唯一の解だ。
add_action(‘updated_user_meta’, ‘clear_user_cap_cache’, 10, 4);
add_action(‘added_user_meta’, ‘clear_user_cap_cache’, 10, 4);
function clear_user_cap_cache($meta_id, $object_id, $meta_key, $_meta_value) {
if ($meta_key === ‘wp_capabilities’) {
wp_cache_delete(“user_caps_{$object_id}”, ‘permissions’);
}
}
—
結論：システムアーキテクトとしての視点
WordPressのデータベース構造は、黎明期のブログシステムとしての柔軟性を優先した結果、現代のハイパフォーマンス環境では「不整合」を引き起こしやすい。
- EAV構造を物理的に解決する: 大規模サイトでは、権限情報を`wp_usermeta`から抽出し、独自のフラットなテーブル（`wp_user_permissions`）へ分離し、`WP_User`クラスを継承してクエリ先をオーバーライドする「コア分離」を検討すべきだ。
- インメモリの極致へ: 権限チェックはアプリケーションの「ホットパス」である。このパスをディスクアクセスから切り離し、完全にメモリ（Redis等）のレイテンシに依存させる設計こそが、WordPressをCMSの枠を超えた「エンタープライズ・ミドルウェア」へと昇華させる唯一の道である。
コードがデータベースと語り合う回数を、極限まで減らせ。それが、システムを支配するということだ。