Google Cloud（GCP）で WordPress を複数台のサーバーに分散させるには、外部アプリケーションロードバランサの背後にマネージドインスタンスグループを置き、HTTPS はロードバランサで終端します。ただし、ロードバランサを作るだけでは WordPress は正しく動きません。アップロード画像やデータベースを全台で共有し、HTTPS の判定と訪問者の IP アドレスを WordPress に正しく伝える設定が必要です。この記事では、gcloud コマンドでの構築手順と、WordPress 側で必要になる設定を順に説明します。
構成の全体像と前提
想定する構成は次のとおりです。
- 外部アプリケーションロードバランサ（グローバル）: HTTPS を受けて証明書を処理し、バックエンドへ HTTP で転送する
- マネージドインスタンスグループ: 同じインスタンステンプレートから作った Web サーバー（Nginx または Apache と PHP）を複数台並べる
- Cloud SQL: データベースを1か所にまとめる
- Cloud Storage または Filestore: アップロードされたメディアを全台で共有する
ここで一番大切なのは、Web サーバーを「どれが消えても困らない」状態にすることです。各サーバーのディスクに画像を保存したり、管理画面からプラグインを更新したりすると、その変更は1台にしか入りません。次のアクセスが別のサーバーに振られると、画像が表示されない、プラグインのバージョンが台ごとに違う、といった不整合が起きます。
以下のコマンドは、インスタンスグループ wp-mig が東京リージョンのゾーン asia-northeast1-a に作成済みで、各インスタンスにネットワークタグ wp-web が付いている前提です。名前やゾーンは自分の環境に合わせてください。GCP の画面表記やロードバランサの種類の呼び方は変わることがあります（2026年10月現在）。
ヘルスチェックを用意する
ロードバランサは、ヘルスチェックに成功したサーバーにだけリクエストを送ります。WordPress のトップページや wp-admin をチェック先にすると、うまくいかないことがよくあります。ヘルスチェックのリクエストには公開ドメインの Host ヘッダーが付かないため、WordPress が正規のドメインへ 301 リダイレクトを返し、200 以外の応答として「異常」と判定されるためです。
そこで、WordPress を通らない静的ファイルをチェック先にします。Web サーバーのドキュメントルートに healthz.html を置き、どの Host でも 200 を返すようにしておきます。
gcloud compute health-checks create http wp-hc \
--port=80 \
--request-path=/healthz.html次に、ヘルスチェックとロードバランサからの通信をファイアウォールで許可します。Google のヘルスチェックとロードバランサの送信元は 130.211.0.0/22 と 35.191.0.0/16 です。
gcloud compute firewall-rules create allow-lb-to-wp \
--network=default \
--direction=INGRESS \
--action=ALLOW \
--rules=tcp:80 \
--source-ranges=130.211.0.0/22,35.191.0.0/16 \
--target-tags=wp-webこの許可を忘れると、サーバーが正常でもすべて「異常」と表示され、ロードバランサが 502 エラーを返します。
バックエンドサービスを作成する
インスタンスグループに名前付きポートを設定し、バックエンドサービスに登録します。
gcloud compute instance-groups managed set-named-ports wp-mig \
--named-ports=http:80 \
--zone=asia-northeast1-a
gcloud compute backend-services create wp-backend \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTP \
--port-name=http \
--health-checks=wp-hc \
--timeout=60s \
--global
gcloud compute backend-services add-backend wp-backend \
--instance-group=wp-mig \
--instance-group-zone=asia-northeast1-a \
--global--timeout は、バックエンドの応答を待つ時間です。初期値は30秒で、プラグインの一括更新や大きなファイルのインポートのように時間のかかる管理画面の処理が途中で切れることがあるため、ここでは60秒にしています。
URL マップ・証明書・転送ルールを作成する
URL マップで振り分け先を決め、Google マネージド証明書と HTTPS プロキシを作ります。
gcloud compute url-maps create wp-url-map \
--default-service=wp-backend \
--global
gcloud compute ssl-certificates create wp-cert \
--domains=example.com,www.example.com \
--global
gcloud compute target-https-proxies create wp-https-proxy \
--url-map=wp-url-map \
--ssl-certificates=wp-cert \
--global
gcloud compute addresses create wp-ip \
--ip-version=IPV4 \
--global
gcloud compute forwarding-rules create wp-https-rule \
--load-balancing-scheme=EXTERNAL_MANAGED \
--network-tier=PREMIUM \
--address=wp-ip \
--target-https-proxy=wp-https-proxy \
--ports=443 \
--global作成した IP アドレスは gcloud compute addresses describe wp-ip --global --format="get(address)" で確認し、DNS で example.com と www.example.com の A レコードをこのアドレスに向けます。マネージド証明書は DNS がロードバランサを向いてから発行されるため、状態が ACTIVE になるまで数十分以上かかることがあります。
gcloud compute ssl-certificates describe wp-cert \
--global --format="get(managed.status)"HTTP でのアクセスを HTTPS へ転送するには、転送専用の URL マップを YAML で作り、ポート80用のプロキシと転送ルールを追加します。
# redirect.yaml
kind: compute#urlMap
name: wp-http-redirect
defaultUrlRedirect:
redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
httpsRedirect: truegcloud compute url-maps import wp-http-redirect \
--source=redirect.yaml --global
gcloud compute target-http-proxies create wp-http-proxy \
--url-map=wp-http-redirect --global
gcloud compute forwarding-rules create wp-http-rule \
--load-balancing-scheme=EXTERNAL_MANAGED \
--network-tier=PREMIUM \
--address=wp-ip \
--target-http-proxy=wp-http-proxy \
--ports=80 \
--globalWordPress 側で必要な設定
ロードバランサが HTTPS を終端するため、WordPress には HTTP でリクエストが届きます。このままだと WordPress は「HTTPS ではない」と判断し、管理画面へのリダイレクトがループしたり、画像の URL が http:// になったりします。wp-config.php の /* That's all, stop editing! */ より上に、ロードバランサが付ける X-Forwarded-Proto ヘッダーを見て HTTPS と判定する処理を加えます。
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
$_SERVER['HTTPS'] = 'on';
}この判定は、ファイアウォールで Web サーバーへの直接アクセスをロードバランサからに限っている前提で安全に使えます。外部から直接届く経路があると、ヘッダーを偽装されるおそれがあります。
訪問者の IP アドレスにも注意が必要です。REMOTE_ADDR にはロードバランサのアドレスが入り、本来の IP は X-Forwarded-For ヘッダーに「（クライアントが送った値）, 訪問者の IP, ロードバランサの IP」の順で入ります。先頭の値は訪問者が自由に書き換えられるので、ログやセキュリティ系プラグインで IP を扱う場合は、末尾から2番目の値を使うように設定してください。
複数台構成では、ほかに次の設定を揃えます。
define( 'DISALLOW_FILE_MODS', true );で管理画面からのプラグイン・テーマの更新を止め、更新はイメージやテンプレートの作り直しで全台に配るdefine( 'DISABLE_WP_CRON', true );で各サーバーの WP-Cron を止め、1か所からだけ定期実行する- メディアは Cloud Storage へのオフロード用プラグインか、Filestore の共有ディスクで全台から同じものを参照する
- オブジェクトキャッシュを使うなら、各サーバーのメモリではなく Memorystore などの共有のキャッシュを使う
WordPress のログインはクッキーで判定されるため、セッションアフィニティ（同じ訪問者を同じサーバーに振る設定）は通常は不要です。PHP のセッションを独自に使うプラグインがある場合だけ検討します。
動作を確認する
まず、各サーバーがヘルスチェックに通っているかを確認します。
gcloud compute backend-services get-health wp-backend --globalすべてのインスタンスが HEALTHY になったら、ブラウザで https://example.com を開き、ログイン、記事の投稿、画像のアップロードを試します。アップロードした画像が何度再読み込みしても表示されれば、メディアの共有ができています。表示されたりされなかったりする場合は、どこかのサーバーがローカルのディスクに保存しています。
最後に、インスタンスを1台停止してもサイトが表示され続けるかを確かめます。これが、複数台構成にした目的そのものの確認になります。
まとめ
- 外部アプリケーションロードバランサの背後にマネージドインスタンスグループを置き、HTTPS はロードバランサで終端する
- ヘルスチェックは WordPress を通らない静的ファイルにし、
130.211.0.0/22と35.191.0.0/16からの通信を許可する wp-config.phpでX-Forwarded-Protoを見て HTTPS と判定し、訪問者の IP はX-Forwarded-Forの末尾から2番目を使う- メディア、データベース、オブジェクトキャッシュは全台で共有し、プラグイン更新と WP-Cron は1か所から行う
- 1台を止めてもサイトが動き続けるかまで確認して完成とする