2026年8月9日

WordPressを高可用性クラスター構成で運用する方法

サーバー・ホスティング

はじめに

WordPressの商用サービスで「99.9%以上の可用性」を保証するには、単一サーバー構成では限界があります。Pacemaker/Corosyncを使った高可用性（HA）クラスター構成を採用することで、サーバー障害時に自動的にバックアップノードへ切り替わる仕組みを実現できます。本記事では、2ノードのHAクラスターでWordPressを運用するための実践的な手順を解説します。

症状・原因

サーバーの物理障害やOSクラッシュでサービスが完全停止する
メンテナンスのたびに計画停止が必要でSLAを満たせない
単一のNFSサーバーに依存しており共有ストレージが単一障害点になっている
仮想IPが固定されておりサーバー切り替え時にDNS変更が必要
ヘルスチェックが自動化されておらず障害検知が遅れる

解決手順

ステップ1：Pacemaker/Corosyncのインストールと基本設定

2台のノードにPacemaker/Corosyncをインストールします。

# 両ノードで実行（Ubuntu 22.04の場合）
sudo apt-get update
sudo apt-get install -y pacemaker corosync pcs fence-agents

# pcsdサービスを起動
sudo systemctl enable pcsd
sudo systemctl start pcsd

# haclusterユーザーのパスワードを設定（両ノードで同じパスワード）
sudo passwd hacluster

# ノード1から認証設定
sudo pcs host auth node1.example.com node2.example.com \
  -u hacluster -p 'HAClusterPass123!'

# クラスターのセットアップ（ノード1で実行）
sudo pcs cluster setup wordpress-ha \
  node1.example.com node2.example.com \
  --transport knet

# クラスターを起動
sudo pcs cluster start --all
sudo pcs cluster enable --all

# クラスターの状態確認
sudo pcs status

ステップ2：Corosyncの設定

/etc/corosync/corosync.conf を編集してクラスター通信を設定します。

# /etc/corosync/corosync.conf
totem {
    version: 2
    secauth: on
    crypto_hash: sha256
    crypto_cipher: aes256
    cluster_name: wordpress-ha
    transport: knet

    interface {
        ringnumber: 0
        bindnetaddr: 192.168.10.0   # クラスター専用NICのネットワーク
        mcastport: 5405
    }
}

quorum {
    provider: corosync_votequorum
    two_node: 1   # 2ノード構成の場合は必須
}

nodelist {
    node {
        ring0_addr: 192.168.10.11
        name: node1
        nodeid: 1
    }
    node {
        ring0_addr: 192.168.10.12
        name: node2
        nodeid: 2
    }
}

logging {
    to_logfile: yes
    logfile: /var/log/corosync/corosync.log
    to_syslog: yes
    timestamp: on
}

ステップ3：GFS2共有ストレージの設定

GFS2クラスターファイルシステムでWordPressのファイルを共有します。

# 両ノードにGFS2ツールをインストール
sudo apt-get install -y gfs2-utils dlm-controld

# 共有ディスク（/dev/sdb）にGFS2を作成（ノード1で1回だけ実行）
sudo mkfs.gfs2 -p lock_dlm \
  -t wordpress-ha:wordpress-data \
  -j 2 \
  /dev/sdb

# /etc/fstab に追加（両ノード）
# /dev/sdb /var/www/wordpress gfs2 defaults,_netdev,noatime 0 0

# マウント確認
sudo mount /dev/sdb /var/www/wordpress
df -h /var/www/wordpress

# WordPressのwp-contentを共有ストレージに配置
sudo rsync -av /var/www/html/wp-content/ /var/www/wordpress/wp-content/

# wp-config.phpをステートレスに設定
# アップロードパスを共有ストレージに向ける
sudo sed -i "s|define('UPLOADS'.*|define('UPLOADS', '/var/www/wordpress/wp-content/uploads');|" \
  /var/www/html/wp-config.php

ステップ4：仮想IP（VIP）とリソースの設定

Pacemakerで仮想IPとApache/Nginxをリソースとして管理します。

# STONITHを無効化（テスト環境用。本番では適切なフェンシングデバイスを使用）
sudo pcs property set stonith-enabled=false
sudo pcs property set no-quorum-policy=ignore

# 仮想IPリソースを作成
sudo pcs resource create wordpress_vip ocf:heartbeat:IPaddr2 \
  ip=192.168.1.100 \
  cidr_netmask=24 \
  op monitor interval=10s

# Apacheリソースを作成
sudo pcs resource create wordpress_apache ocf:heartbeat:apache \
  configfile=/etc/apache2/sites-enabled/wordpress.conf \
  statusurl="http://127.0.0.1/server-status" \
  op monitor interval=15s

# GFS2マウントリソースを作成
sudo pcs resource create wordpress_fs ocf:heartbeat:Filesystem \
  device=/dev/sdb \
  directory=/var/www/wordpress \
  fstype=gfs2 \
  op monitor interval=20s

# リソースグループ化（順序を保証）
sudo pcs resource group add wordpress_group \
  wordpress_vip wordpress_fs wordpress_apache

# コロケーション制約：同じノードで動作
sudo pcs constraint colocation add wordpress_apache with wordpress_vip score=INFINITY

# クラスター状態を確認
sudo pcs status resources

ステップ5：WordPressのステートレス設定とヘルスモニタリング

WordPressをステートレスに設定し、フェイルオーバー後も正常動作するように構成します。

<?php
// wp-config.php に追加するステートレス設定

// 仮想IPをサイトURLとして使用
define( 'WP_HOME',    'https://www.example.com' );
define( 'WP_SITEURL', 'https://www.example.com' );

// セッションはRedisに保存（どちらのノードでも共有）
define( 'WP_REDIS_HOST', '192.168.1.50' );
define( 'WP_REDIS_PORT', 6379 );

// ファイルキャッシュは共有ストレージに保存
define( 'WP_CONTENT_DIR', '/var/www/wordpress/wp-content' );
define( 'WP_CONTENT_URL', 'https://www.example.com/wp-content' );

// 一時ファイルは各ノードのローカルに保存
define( 'WP_TEMP_DIR', '/tmp/wordpress/' );

// HA環境でのデバッグ設定
define( 'WP_DEBUG',         false );
define( 'WP_DEBUG_LOG',     false );
define( 'SAVEQUERIES',      false );
define( 'AUTOMATIC_UPDATER_DISABLED', true ); // 自動更新無効（片方のノードで実行される危険）

// ノードを識別するためのカスタム定数
define( 'WP_HA_NODE_ID', gethostname() );

注意事項

本番環境では必ずSTONITHフェンシングデバイス（IPMI、iLO等）を設定すること。stonith-enabled=false はスプリットブレインによるデータ破損を招く
GFS2はクラスター全ノードが同時にマウントすることを前提としているため、ノード追加・削除時は慎重に手順を踏む必要がある
WordPressのプラグイン・テーマ更新は必ずメンテナンス時間を設けて行うこと。クラスター環境でのオンライン更新はファイル競合が起きる可能性がある
AUTOMATIC_UPDATER_DISABLED を true にすること。自動更新がアクティブノードでのみ実行されると、非アクティブノードとファイルの不整合が発生する
クラスターのクォーラム設定は2ノード構成と3ノード以上で異なる。two_node: 1 は2ノード専用設定

まとめ

Pacemaker/CorosyncとGFS2を組み合わせたHAクラスター構成により、WordPressの高可用性と自動フェイルオーバーを実現できます。この構成と「WordPressのデータベースをレプリケーションで冗長化する方法」を組み合わせることで、フルスタックの冗長化インフラが完成します。

Post Views: 2