【ハンズオン】WordPressの冗長化構成を構築してみよう！

ハンズオンの目的と対象

今回のハンズオンは以下のような方を対象に、WordPressの冗長化を進めていきます。

対象

WordPressサイトの開発や運用の経験がある方
PHPを用いたWebサイト開発の経験がある方

目的

WordPressを冗長化して、Webサーバーが1台落ちても接続し続けられる環境を構築します。

構築する環境

Webサーバー2台、データベース1台の冗長化したWordPress環境を構築します。

1つのRDSを2つのインスタンスで共有しているので、WordPressに記事を投稿したらELBによってどちらにアクセスされても、同じ記事を閲覧することが出来ます。

用語説明

EC2やRDSをざっくり説明します。

名称	説明
EC2	EC2とはAmazon Elastic Compute Cloudの略で、AWSが提供している仮想サーバーです。スペックも様々でたくさんのプランから選択して仮想サーバを構築することが出来ます。柔軟にスペックの変更が可能なルート権限つきのVPSのようなものです。
RDS	RDSとはAmazon Relational Database Serviceの略で、AWSが提供するデータベース専用のサーバーです。SQLServerやMariaDBなど様々なデータベースを利用することができます。今回はMySQLを選択しました。
ELB	ELBとはElastic Load Balancingの略で、AWSが提供するロードバランサです。ロードバランサはWebサーバーの手前でアクセスを複数のサーバーへ振り分けてくれます。サーバーの死活を監視するヘルスチェックの機能があり、稼働しているサーバーへのみ通信を流してくれるため、障害へ対策が可能となります。
Route53	Route53は、AWSが提供するDNSサービスです。ドメイン名とIP（サーバー）を紐付けてくれます。お名前.comやムームードメインをイメージしていただければなんとなく把握いただけると思います。

ハンズオン環境の前提条件

以下の環境を事前に用意させていただきました。

名称	説明
EC2（1台）	Amazon Linux2、PHP7.2、Apache、WordPressファイルの配置、EIP(固定のグローバルIPアドレス)
RDS	MySQL5.7.22、WordPress用DBの作成
Route53	xxx.wpadvisor.jpというドメイン名をEC2に紐付けてあります

EC2インスタンスの作成をご自身で試したい場合はこちらをご参照ください。 => AWSにEC2インスタンスを立ち上げよう
VPCはEC2インスタンスと同じにしないと使うことが出来ないのでご注意ください。

WordPressのインストール

ブラウザからWordPressのインストール画面にアクセスしてみましょう。

続いてWordPressにアクセスしてDBの情報を入力します。

項目	入力内容
データベース名	先程作成したもの(wpa001)
ユーザー名	RDS作成時に設定したユーザ名(wpa001)
パスワード	RDS作成時に設定したマスターパスワード(Hogehoge1234)
データベースのホスト名	RDSのエンドポイント
テーブル接頭辞	wp000_

あとはブログタイトル、ユーザ名、パスワード等をブラウザの指示に従って入力すれば、WordPressサーバの完成です。 WordPressがインストールできましたので、本題の「冗長化」を進めていきます。

EC2を複製して2台構成にする

今回の冗長化ではWebサーバーを2台構成にすることがゴールです。まずはEC2インスタンスを複製します。

AWSのコンソールにログインし、インスタンスを複製するために、EC2のコンソールからAMIを取得します。AMIはAmazonマシーンイメージの略で、複製するサーバーのもととなる情報が含まれたイメージです。先程作成したインスタンスを選択した状態で、 アクション > イメージ > イメージの作成 を選択します。

イメージ名などを入力して、イメージの作成をクリックします。
この時システムが稼働中で停止させたくないときは、再起動しない にチェックを入れます

AMIが作成出来たら左側のタブのイメージ > AMIから先程作成したAMIにチェックを入れ、 アクション > 起動をクリック。今回はコピーを取りたいので、元のインスタンスと同じように設定してください。
タグは違う名前をつけると良いです。

Elastic IPの割当

インスタンスが作成出来たら、先程同様Elastic IPを適用してください。

AWSコンソールのEC2のページで左側からElastic IPを選択します。
Elastic IPの割り当てを選択します

割り当てを選択します

このElastic IPを関連付ける を選択します

インスタンスを先程複製したもので設定します。
選択したら関連付ける

ELBを設定する

続いてELBの設定を行います。 ELBは、ユーザーのアクセスを複数サーバーへ分散してくれるロードバランサです。

EC2のコンソールの右側のタブから ロードバランシング > ロードバランサー をクリックします。
ロードバランサーの作成をクリックします。

Application Load Balancerを選択します。

名前は自分がわかりやすいような名前を入力しましょう。
今回はHTTPのみでテストをするため、HTTPSは追加しません。
VPCはEC2インスタンスと同じものを選択します。
サブネットを指定します。

セキュリティ設定の構成で警告が出ますが、これはHTTPSプロトコルを選択してないためです。
今回は使用しないので無視します。

セキュリティグループは通信の到達を許可する設定です。詳細な説明は割愛します。今回は新しいセキュリティグループを作成して、HTTP通信を許可する設定を以下のようにします。

名前は自分わかりやすい名前を入力しましょう。
その他は特に変更せず次へ

EC2インスタンス２つにチェックを入れて[登録済みに追加]を押して次へ

一通り確認したら作成をクリック

ロードバランサーから先程作成したロードバランサーを選択して、説明タブを選択して、DNS名をブラウザに入力してアクセスしてみましょう。

Route53でELBを指定する

今までブラウザからWordPressへのアクセスは直接EC2でしたが、DNSの設定を変更してアクセス先をELBとします。

handson【自分の番号】.wpadvisor.jpを選択し、エイリアスをはいにチェックを入れて、エイリアス先は先ほどのELBを候補から選択します。

冗長化環境の動作確認

これで当初想定した冗長化構成が完成しました。早速アクセスしてみましょう。

WordPressが表示できたら続いて、http://xxx.wpadvisor.jp/check.php へアクセスしてみてください。サーバーの内部IPアドレスが表示されます。何度かアクセスすることで、複数のマシンへアクセスが分散されていることが確認できたでしょうか。分散していない場合は、DNS設定変更の反映に時間がかかっている可能性があります。少し待ってみます。
もしくはシークレットウインドウを試してみてください。

これで片方のインスタンスに障害が発生したときでもWordPressは動作させることが可能になりました。最初に準備してあったサーバーを停止してもWordPressが動作可能か確認してみましょう。

(補足)check.phpのコード

<?php
$header_keys = array( 'SERVER_NAME', 'SERVER_ADDR', );
foreach($header_keys as $key) {
  printf("%s = %s<br>", $key, $_SERVER[$key]);
}
?>

WordPressの動作確認

続いて、WordPressへログインして記事を投稿してみます。適当なメディアファイルを含めて投稿して、その記事ページを確認してみましょう。何度かアクセスしてみて、画像が表示されないことがあれば成功（？）です。問題なく表示されている場合は、ブラウザキャッシュにより表示している可能性があるため、シークレットモードでアクセスしてみてください。原因は、WordPressはメディアファイルをデータベースではなくWebサーバーに格納するため、片方のサーバーにしかファイルが存在しないためです。

メディアファイル分散への対策

対策は様々ありますが、シンプルな方法をご紹介します。

管理者画面へのアクセスを1台に寄せる
サーバー間でファイルを同期する

管理者画面へのアクセスを1台に寄せる

ELBの機能に特定のURLへのアクセスを、指定したサーバーへ振り分ける仕組みがあります。WordPressの管理者画面のURLは /wp-admin/ などと決まっていますので、このルールを追加することで管理画面へのアクセスを1台に寄せることができます。

ここでは、コピー元のインスタンスに寄せる設定をしていきましょう。
EC2のコンソールから、ターゲットグループをクリックして、ターゲットグループの作成をクリックします。

ターゲットグループ名は先程作ったターゲットグループ名の頭にorg-などをつけて、コピー元だということがわかりやすくしましょう。
入力したら作成をクリック

先程作成したターゲットグループを選択した状態で、ターゲットタブから編集をクリックします。

コピー元になるインスタンスを選択して登録済みに追加をクリックします。

続いてロードバランサーをクリックして先程作成したロードバランサーを選択した状態でリスナータブをクリックしてルールの表示/編集をクリックします。

上の方の+ボタンを押してルールの挿入をクリックします。

ルールにはパスが/wp-admin/*転送先を先程作成したorg-handson01などに設定します。

これでwp-admin/のパスへのアクセスはコピー元のインスタンスに向くように設定されました。
実際に確かめる方法としては、sshログインしてアクセスログを確かめるなどの方法があります。

サーバー間でファイルを同期する

サーバー間でファイルを同期するにはrsyncというコマンドを利用します。

rsyncは、UNIXシステムにおいて、差分符号化を使ってデータ転送量を最小化し、遠隔地間のファイルやディレクトリの同期を行うアプリケーションソフトウェアである。

rsyncをcronを用いて1分間隔など定期的に実行することでファイルの同期を行えます。よりリアルタイムなファイル同期が必要な場合は、rsyncとlsyncdを用いる方法がありますが、今回は割愛させていただきます。

cronでrsyncのサーバー間ファイルを同期するスクリプト例

#!/bin/bash
# 同期元となるファイルパス
RSYNC_SRC="/var/www/vhosts/xxxxxxxxx/public_html/wp-content/uploads/"
# 同期先のサーバーとファイルパス
RSYNC_DEST="filesync@172.16.1.xxx:/var/www/vhosts/xxxxxxxxx/public_html/wp-content/uploads/"
ionice -c 2 nice -n 19 rsync -e "ssh -i /root/sync.pem" -avz $RSYNC_SRC $RSYNC_DEST

まとめ

冗長化する際は、WebサーバーとDBサーバーを分離する
Webサーバーを冗長化するにはELBで振り分けをする
データの登録処理には注意してELBで1台に寄せることを検討する
ファイルの同期にはrsyncが使える
（補足）データベースも冗長化する場合はMulti-AZ構成のRDSを選ぶ