1. はじめに
プライム・ストラテジー「KUSANAGI」開発チームの謝です。
WordPressサイトを運用していると、アクセス数の増加とともにデータベースへの問い合わせ回数が増え、応答速度の低下を実感することがあります。ページキャッシュによる静的ファイル配信が有効な場面は多いですが、ログインユーザーが多いサイト・ECサイト・会員サイトなど、ページキャッシュが適用されないケースでは、データベースのクエリ回数そのものを減らすアプローチが重要になります。
そこで注目されるのが「Object Cache(オブジェクトキャッシュ)」です。本記事では、Redis を使った Object Cache の仕組みと、「Redis Object Cache」プラグインを用いた WordPress への導入手順を、前提確認からトラブルシュートまで順を追って解説します。
対象環境・対象読者
- KUSANAGI 9(AlmaLinux 9) 上で WordPress を運用している方
- KUSANAGI のfcache(FastCGI キャッシュ) 、bcache(ページキャッシュ)とは別に、DB 負荷を削減したい方
- Redis Object Cache の導入を検討しているサーバー管理者・エンジニア
2. Redis Object Cache とは
WordPress の Object Cache の仕組み
WordPress はリクエストごとにデータベースへクエリを発行し、投稿・設定・ユーザー情報などのデータを取得します。同一リクエスト内で同じデータが何度も必要になる場合、WordPress はデフォルトで「インメモリの一時キャッシュ(Non-Persistent Object Cache)」を使って重複クエリを避ける仕組みを持っています。
しかしこのキャッシュは リクエストが終わると破棄 されます。つまり次のリクエストでは再度データベースにクエリを投げる必要があります。
永続的な Object Cache(Persistent Object Cache)
Redis Object Cache プラグインを導入すると、WordPress の Object Cache バックエンドとして Redis を使用する object-cache.php を wp-content/ に設置します。これにより、キャッシュが リクエストをまたいで永続化 されます。
リクエスト A → Redis にデータが存在しない → DB にクエリ → Redis に保存
リクエスト B → Redis にデータが存在する → Redis から取得(DB クエリなし)
Redis はオンメモリのキーバリューストアであり、ディスク IO を伴うデータベースアクセスに比べて桁違いに高速です。
KUSANAGI の fcache・bcache との関係
KUSANAGI 9 には fcache と bcache という 2 種類のページキャッシュ機能が標準搭載されています。どちらもページ全体の HTML をキャッシュして再利用することで表示を高速化しますが、動作するレイヤーと仕組みが異なります。
fcache(FastCGI キャッシュ)は、nginx が PHP-FPM(FastCGI)のレスポンスをサーバーのメモリ・ディスクにキャッシュする仕組みです。PHP や WordPress のプロセス自体を起動せずに nginx が直接レスポンスを返すため、3 つのキャッシュの中で最も高速です。
bcache(WordPress ページキャッシュ)は、KUSANAGI 専用プラグインが WordPress の組み込みキャッシュ機構を利用してページ HTML をデータベースに保存する仕組みです。PHP レベルで動作するため fcache より処理コストはかかりますが、WordPress 側でキャッシュ制御(記事公開時のキャッシュ削除など)が可能です。
Redis Object Cacheは、これら 2 つとは根本的に異なる役割を担います。ページ全体をキャッシュするのではなく、MariaDB へのクエリ結果や PHP オブジェクトをリクエストをまたいで Redis に保持することで、DB への問い合わせ回数を削減します。
| - | fcache | bcache | Redis Object Cache |
|---|---|---|---|
| 動作レイヤー | nginx(FastCGI キャッシュ) | PHP / WordPress プラグイン | PHP / WordPress Object Cache |
| キャッシュ対象 | PHP が生成した HTML ページ全体 | PHP が生成した HTML ページ全体 | DB クエリ結果・PHP オブジェクト |
| キャッシュ保存先 | ディスク | MariaDB(WordPress DB 内) | Redis(オンメモリ) |
| 速度 | 最速(PHP・WordPress 不要) | 中速(PHP が処理) | ー(DB 負荷軽減が主目的) |
| 効果が出る場面 | 未ログインユーザーのフロント閲覧 | 未ログインユーザーのフロント閲覧 | 管理画面・ログインユーザー・動的ページ |
| ログインユーザーへの適用 | ×(Cookie 検出で自動バイパス) | × | 〇 |
fcache・bcache・Redis Object Cache はそれぞれ独立して動作し、競合しません。3 つを組み合わせることで WordPress の応答速度を最大限に引き上げることができます。
- 未ログインユーザー(fcache HIT 時):nginx が PHP・WordPress・Redis を一切介さずに直接レスポンスを返す。最速のパス。
- 未ログインユーザー(bcache HIT 時):WordPress が PHP で処理するが、DB には問い合わせずにキャッシュ済み HTML を返す。Redis Object Cache が DB 負荷の軽減を補完
- ログインユーザー・管理画面:fcache・bcache はともにバイパスされ WordPress がフル処理する。このリクエストで Redis Object Cache が DB クエリを削減し、レスポンス改善に貢献
3. 導入するメリット
| メリット | 説明 |
|---|---|
| DB クエリ削減 | 同一データの重複クエリを Redis が吸収し、MariaDB への負荷を大幅に低減 |
| 管理画面の高速化 | fcache、bcache が効かない管理画面のレスポンス向上に直結 |
| ログインユーザー対応 | EC サイトや会員サイトなど、ページキャッシュを使えない環境でも効果を発揮 |
| 高トラフィック耐性 | アクセス集中時に DB がボトルネックになるリスクを軽減 |
| KUSANAGI との相性 | KUSANAGI 9 には Redis パッケージが用意されており、追加リポジトリなしでインストール可能 |
⚠️ 会員サイトへ導入する場合の注意
Redis Object Cache は、ユーザーの権限やロールを区別せずにデータをキャッシュします。 このため、会員ランク・ロールごとにコンテンツを出し分けるサイトへ導入する際は以下の点に注意が必要です。
- 会員権限によって内容が変わるデータ(有料会員向けコンテンツ・ユーザー固有のオプション値など)をそのままキャッシュすると、異なる権限のユーザー間でデータが混在するリスクがある
- MemberPress・WooCommerce Memberships・Ultimate Member などの会員管理プラグインは独自のキャッシュグループを持つことが多く、プラグイン側の Object Cache 対応状況を事前に確認する必要がある
WP_REDIS_IGNORED_GROUPS定数を使って権限に関わるキャッシュグループをキャッシュ対象外にすることで、データ混在のリスクを低減できる(詳細は「13. 本番運用時の注意点」を参照)
会員サイトへの導入は、ステージング環境でロール別・ログイン状態別の表示内容を必ず検証したうえで本番適用を判断してください。
4. 導入前の前提条件
本記事の手順は KUSANAGI 9(AlmaLinux 9) 環境を前提としています。
| 項目 | 想定する環境・条件 |
|---|---|
| OS | AlmaLinux 9(KUSANAGI 9) |
| Web サーバー | Nginx(KUSANAGI デフォルト) |
| PHP | KUSANAGI 同梱の PHP 8.x(php-fpm で動作) |
| データベース | MariaDB(KUSANAGI デフォルト) |
| WordPress の配置 | /home/kusanagi/<プロファイル名>/DocumentRoot/ |
5. Redis サーバーの確認
KUSANAGI 9 での Redis インストール確認
KUSANAGI 9(AlmaLinux 9)では、AlmaLinux 標準リポジトリから Redis をインストールできます。まずインストール済みかどうかを確認します。
rpm -q redis
# 例: redis-7.2.x-x.el9.x86_64
インストールされていない場合は以下の手順でインストールします。
AlmaLinux 9 のデフォルトは Redis 6 系 です。Redis 7 を使用するには、インストール前に dnf モジュールストリームで Redis 7 を明示的に有効化する必要があります。
# Redis 7 のモジュールストリームを有効化
sudo dnf module -y enable redis:7
# Redis をインストール
sudo dnf install redis
補足: dnf module enable を省略すると Redis 6 系がインストールされます。Redis 7 では多くのパフォーマンス改善や新機能が含まれるため、特別な理由がない限り Redis 7 の使用を推奨します。インストール後に redis-cli --version でバージョンを確認してください。
なお、Redis の最新版は 8 系です。Redis 8 を使用する場合は AlmaLinux 標準リポジトリではなく Redis 公式の RPM リポジトリからのインストールが必要です。手順については公式ドキュメント(https://redis.io/docs/latest/operate/oss_and_stack/install/install-stack/rpm/)を参照してください。本記事では Redis 7 の構成を前提として解説します。
起動・自動起動の設定
# Redis を起動し、OS 再起動時にも自動起動するよう設定
sudo systemctl enable --now redis
# 起動状態を確認
sudo systemctl status redis
正常に起動していると Active: active (running) と表示されます。
疎通確認
redis-cli ping
# PONG と返れば正常
KUSANAGI 環境での Redis 接続情報
KUSANAGI 9 のデフォルト設定では Redis は TCP 接続で動作します。
| 項目 | デフォルト値 |
|---|---|
| ホスト | 127.0.0.1 |
| ポート | 6379 |
| データベース | 0 |
| 認証パスワード | なし |
| 設定ファイル | /etc/redis/redis.conf |
6. PHP Redis 拡張の確認
Redis Object Cache プラグインは、Redis との通信クライアントとして phpredis(PHP PECL 拡張)、Predis(PHP ライブラリ)、Relay のいずれかを使用します。phpredis が最もパフォーマンスが高く、インストール済みであれば自動的に優先選択されます。
KUSANAGI 9 最新版には phpredis があらかじめ同梱されています。 追加インストールは不要で、以下のコマンドで導入済みであることを確認できます。
php -m | grep redis
# redis と表示されれば OK
7. WordPress に Redis Object Cache プラグインをインストール
Redis Object Cache プラグインは Till Krüss が開発・公開しているオープンソースのプラグインです。管理画面のプラグイン検索または公式ページからインストールして有効化してください。
- WordPress プラグイン公式ページ: https://ja.wordpress.org/plugins/redis-cache/
有効化後、管理画面の左メニュー「設定」→「Redis」にプラグインの設定ページが表示されます。この時点では Object Cache はまだ有効ではなく、「Status: Not enabled」と表示されます。次の手順で接続設定を行います。
8. wp-config.php に Redis 接続設定を追加
Redis への接続情報を wp-config.php に定義します。KUSANAGI 環境での wp-config.php の場所は以下です。
/home/kusanagi/<プロファイル名>/DocumentRoot/wp-config.php
wp-config.phpに下記の定義を追加します。
// Redis 接続先ホスト
define( 'WP_REDIS_HOST', '127.0.0.1' );
// Redis ポート番号
define( 'WP_REDIS_PORT', 6379 );
// 使用するデータベース番号(0〜15)
define( 'WP_REDIS_DATABASE', 0 );
// キャッシュキーのプレフィックス(同一 Redis を複数サイトで共有する場合は必ず設定)
define( 'WP_REDIS_PREFIX', 'mysite:' );
// 使用するクライアントを明示的に指定(phpredis 推奨)
define( 'WP_REDIS_CLIENT', 'phpredis' );
// 接続タイムアウト(秒)
define( 'WP_REDIS_TIMEOUT', 1 );
// 読み取りタイムアウト(秒)
define( 'WP_REDIS_READ_TIMEOUT', 1 );
KUSANAGI マルチプロファイル構成の場合:
同一サーバー上に複数の KUSANAGI プロファイルを作成し、同じ Redis インスタンスを共有する場合は、プロファイルごとにWP_REDIS_PREFIXまたはWP_REDIS_DATABASEを必ず別の値にしてください。設定が重複するとキャッシュが混在します。
9. Object Cache を有効化する
管理画面から有効化
- 「設定」→「Redis」を開く
- 接続ステータスが「Connected」になっていることを確認
- 「Enable Object Cache」ボタンをクリック
有効化すると wp-content/object-cache.php(Drop-in ファイル)が設置され、WordPress の Object Cache バックエンドが Redis に切り替わります。
注意: 「Enable Object Cache」ボタンが有効されない場合、「12. よくあるトラブルと対処方法」を参照
10. Redisヒット率など確認
管理画面での確認
「設定」→「Redis」のプラグイン設定ページにアクセスすると、「metrics」タブで「Time、Bytes、Ratio、Calls」確認できます。
CLI での確認
# Redis に保存されているキー数を確認
redis-cli dbsize
# サーバー全体のヒット率を確認
redis-cli info stats | grep -E "keyspace_hits|keyspace_misses"
keyspace_hits と keyspace_misses の比率でサーバー全体のキャッシュヒット率を把握できます。
Query Monitor プラグインとの連携
「Query Monitor」プラグインを導入すると、ページごとのデータベースクエリ数と Object Cache のヒット数を管理バーから直接確認できます。Redis Object Cache 有効化の前後でクエリ数を比較すると効果が一目瞭然です。
11. キャッシュ削除方法
管理画面から削除
「設定」→「Redis」→「Flush Cache」ボタンをクリックします。
Redis CLI で直接フラッシュする場合は対象データベース番号を指定します。
# データベース 0 のみをフラッシュ(他サイトのデータに影響しない)
redis-cli -n 0 FLUSHDB
注意: FLUSHALL は Redis 上の全データベースを削除します。複数サイトで Redis を共有している場合は使用しないでください。
自動フラッシュのタイミング
Redis Object Cache プラグインは以下のタイミングで関連キャッシュを自動的に削除します。
- 投稿・固定ページを公開・更新したとき
- テーマ・プラグインを変更したとき
- WordPress のコアやプラグインをアップデートしたとき
- WordPress の設定を変更したとき
12. よくあるトラブルと対処方法
ステータスが「Not connected」のまま
まず Redis が起動しているかを確認します。
sudo systemctl status redis
次に PHP から Redis への疎通を直接確認します。
php -r "
\$r = new Redis();
var_dump(\$r->connect('127.0.0.1', 6379));
echo \$r->ping();
"
# bool(true)
1
wp-config.php のホスト・ポート・データベース番号が実際の Redis 設定と一致しているかも合わせて確認してください。
object-cache.php の書き込み権限エラー
wp-content/ の所有者と権限を確認
# wp-content/ の権限・所有者を確認
ls -la /home/kusanagi/<プロファイル名>/DocumentRoot/wp-content/
# 誤って操作した場合は所有者を修正する
sudo chown kusanagi:www /home/kusanagi/<プロファイル名>/DocumentRoot/wp-content/
sudo chmod 775 /home/kusanagi/<プロファイル名>/DocumentRoot/wp-content/
また、KUSANAGI のデフォルト設定では wp-config.php に以下の定数が設定されており、WordPress がファイルの書き込みに FTP 経由になります。
define('FS_METHOD', 'ftpext');
この状態で FTP_PASS が未設定の場合、プラグインの「Enable Object Cache」実行時に object-cache.php を wp-content/ へ書き込めできません。
# FTPパスワードに正しくパスワードに修正
# コメントアウトされた場合もコメントアウトを外す
define('FTP_PASS', 'FTPパスワード');
phpredis がインストール済みなのに Predis が使われる
wp-config.php でクライアントを明示的に指定します。
define( 'WP_REDIS_CLIENT', 'phpredis' );
指定後、プラグインの設定ページで「Client: PhpRedis」と表示されることを確認してください。
Redis のメモリ使用量が増大する
Object Cache 用途では Redis にメモリ上限とエビクションポリシーを設定しておくことを推奨します。
# 現在のメモリ使用量を確認
redis-cli info memory | grep used_memory_human
/etc/redis/redis.conf に以下を追記して Redis を再起動します。
maxmemory 256mb
maxmemory-policy allkeys-lru
sudo systemctl restart redis
allkeys-lru を指定すると、メモリが上限に達した際に最も参照が古いキャッシュエントリから自動削除されます。
13. 本番運用時の注意点
Redis の再起動とキャッシュのコールドスタート
Redis を再起動するとキャッシュデータは消失します。Object Cache として使用する場合、キャッシュが消えても WordPress が MariaDB から再取得するため 動作上の問題はありません。ただし再起動直後は DB 負荷が一時的に上昇します。メンテナンス時間帯での作業や、再起動後のアクセス状況の監視を推奨します。
セキュリティ設定
KUSANAGI 9 の Redis はデフォルトでローカルホスト(127.0.0.1)のみにバインドされています。設定を確認しておきましょう。
sudo grep "^bind" /etc/redis/redis.conf
# 出力
bind 127.0.0.1 -::1
KUSANAGI プロファイルを複数運用している場合
同一の Redis インスタンスを複数プロファイルで共有する場合は、プロファイルごとに WP_REDIS_PREFIX を一意に設定してください。
// プロファイル A の wp-config.php
define( 'WP_REDIS_PREFIX', 'site-a:' );
// プロファイル B の wp-config.php
define( 'WP_REDIS_PREFIX', 'site-b:' );
会員サイト・ロールベース表示サイトでのキャッシュグループ制御
会員ランクや権限(ロール)によって表示内容が変わるサイトでは、権限に関わるデータをキャッシュから除外する設定が必要になる場合があります。Redis Object Cache はユーザーのロールや権限を区別せずにキャッシュするため、適切な制御を行わないと以下のような問題が発生するリスクがあります。
- 有料会員向けコンテンツの情報が無料会員のキャッシュに混入する
- ユーザーごとに異なるカート情報・購入履歴などがキャッシュを通じて別ユーザーに見えてしまう
- ロール別のメニューや restricted コンテンツが意図しないユーザーに表示される
キャッシュから除外するグループを指定する方法
wp-config.php に WP_REDIS_IGNORED_GROUPS を定義することで、特定のキャッシュグループを Redis の保存対象から除外し、リクエストごとに DB から再取得させることができます。
// 会員情報・セッション・カートなど権限に関わるグループを除外する例
define( 'WP_REDIS_IGNORED_GROUPS', [
'users', // ユーザーオブジェクト
'user_meta', // ユーザーメタデータ
'user-queries', // ユーザー検索クエリ
'session', // セッション情報
'wc_session_id', // WooCommerce セッション
'cart', // カート情報
] );
補足: 除外するグループはサイトで使用している会員管理プラグインや WooCommerce などによって異なります。Query Monitor プラグインの「Object Cache」パネルで実際に使われているキャッシュグループを確認し、権限に関わるものを特定して除外グループに追加してください。
除外グループを増やすほどキャッシュの恩恵は減りますが、会員サイトの信頼性・セキュリティを優先した設定が重要です。パフォーマンスと安全性のバランスを取りながら、必要最小限のグループのみ除外するよう調整してください。
14. パフォーマンス確認の観点
Redis Object Cache 導入の効果を定量的に把握するため、以下の指標を確認します。
キャッシュヒット率(Hit Ratio)
プラグインの設定ページで確認できます。サイトが安定稼働している状態で 80〜90% 以上 を目標にします。ヒット率が著しく低い場合は、除外グループの設定やキャッシュ TTL の見直しを検討してください。
データベースクエリ数の変化
Query Monitor プラグインを使って、管理画面やフロントページのクエリ数を導入前後で比較します。ヒット率が高い環境では DB クエリが半減以上するケースも珍しくありません。
Redis 応答時間
# レイテンシーの継続測定
redis-cli --latency -h 127.0.0.1 -p 6379
TCP 接続では 2ms以下ことが望ましい
MariaDB への負荷変化
Redis 導入後の MariaDB の状態を確認よいでしょう。
確認コマンド例
-- クエリ実行数の確認
SHOW STATUS LIKE 'Questions';
-- スロークエリ件数の確認
SHOW STATUS LIKE 'Slow_queries';
導入前後でクエリ実行数の増加ペースが鈍化していれば、Redis Object Cache が有効に機能しています。
15. 無効化・切り戻し方法
問題発生時に素早く元の状態に戻せるよう、事前に手順を把握しておきましょう。
管理画面から無効化
- 「設定」→「Redis」→「Disable Object Cache」をクリック
- 必要に応じてプラグインを無効化
手動で即時切り戻す場合
wp-content/object-cache.php を削除するだけで、WordPress は即座にデフォルトの Non-Persistent Object Cache に切り替わります。
rm /home/kusanagi/<プロファイル名>/DocumentRoot/wp-content/object-cache.php
wp-config.php に追記した Redis 関連の定数も合わせて削除またはコメントアウトします。
ポイント:
object-cache.phpの削除は WordPress の動作を止めることなく即時反映されます。問題が発生した場合でも安全に切り戻せます。
16. まとめ
本記事では、KUSANAGI 9(AlmaLinux 9)環境における WordPress への Redis Object Cache プラグイン導入手順を解説しました。
導入のポイント整理:
- Redis のインストールと起動確認(
dnf install redis→systemctl enable --now redis) - phpredis 拡張の確認(
php -m | grep redis)。KUSANAGI 9 最新版には phpredis が同梱済みのため追加インストール不要 - プラグインのインストール・有効化(管理画面から)
wp-config.phpに接続定数を追記(ホスト・ポート・プレフィックス・クライアントを明示)- Object Cache の有効化(管理画面から)
- ヒット率・DB クエリ数で効果を定量確認
KUSANAGI 9 の fcache(FastCGI キャッシュ)・bcache(WordPress ページキャッシュ)と Redis Object Cache は役割が異なり、3 つを組み合わせることでお互いの弱点を補完できます。fcache・bcache が未ログインユーザーへの高速配信を担い、Redis Object Cache がページキャッシュの恩恵を受けられないログインユーザーや管理画面の DB 負荷を軽減する——という役割分担です。特にログインユーザーが多いサイトや管理画面のレスポンスが気になる場合に、Redis Object Cache の導入は有効な選択肢です。
設定はシンプルで切り戻しも容易なため、まずはステージング環境で動作を確認したうえで、本番環境への適用を検討してみてください。
会員サイト・権限別コンテンツのあるサイトを運用している場合は、 ステージング環境でロール別・ログイン状態別の表示内容を十分に検証し、必要に応じて
WP_REDIS_IGNORED_GROUPSでキャッシュ除外グループを設定することを強く推奨します。パフォーマンス向上と会員情報の安全性を両立させた運用設計を心がけてください。



