👻

【Wordpress】AWS基盤のWebサイトを構築　～後編

2025/01/25に公開

 はじめにhttps://zenn.dev/unryu/articles/aef4fb5fc4d7c5

本記事は前編の続きです。前編の記事をご覧いただけていない方はまずはそちらをご覧ください。

前編でシングル構成だったWebサイトを後編では冗長構成に変更し、耐障害性や可用性が向上させます。また、後編では以下２つのテーマに沿って構築していきます。

 テーマ①　複数インスタンス間でデータを共有する前編ではEC2は1台だったのでEC2にアタッチしたストレージのデータを更新してもデータ不整合は起こらないため問題ありません。しかし複数のEC2による冗長構成ではEC2ごとに別々のストレージでデータを管理すると、データ更新の際に各EC2ごとにデータを更新する必要があり手間がかかります。さらにはユーザーによって書き込まれる情報もあるためデータ不整合が発生してしまいます。そこで共有ストレージのサービスであるEFSを使い、すべてのEC2のデータをEFSにまとめることでデータ更新の手間を省きデータ不整合を防止します。

 テーマ②　AutoScalingで負荷上昇に対応するWebサイトはアクセス集中が起きるとサーバはそのアクセスをさばききれずエラーとなってしまうケースがあります。そうなるとせっかくのビジネスチャンスを逃すことになります。AutoScalingはアクセス集中を検知したら自動でサーバの数を増やし突然の負荷上昇に対応します。そもそもAWSなどのクラウドサービスはこのような柔軟にサーバを増減させることができるというのが大きな強みです。本記事ではそのAutoScalingの設定をしていきます。

 構成の確認前編までの構成を見てみます。通常時は問題なくサイトを閲覧することができます。

しかし障害や高負荷な状態ではサイトダウンとなる可能性があります。

そこでEC2とRDSを冗長構成に変更し、さらにEFSを各EC2にマウントすることで冗長構成においてもデータ不整合が起こらない構成とします。


 EFSでコンテンツを共有するEFSを作成しEC2にマウントしていきます。

 セキュリティグループの作成AWSマネジメントコンソールより以下のように検索しセキュリティグループを作成していきます。

EC2 > セキュリティグループ > セキュリティグループを作成


セキュリティグループ名
対象リソース
インバウンドルール


[Name]-efs-sg
EFS用
タイプ：NFS, 送信先：[カスタム]EC2用セキュリティグループ


 EFSの作成AWSマネジメントコンソールより以下のように検索しEFSを作成していきます。

EFS > ファイルシステム > ファイルシステムの作成 > カスタマイズ
名前 ：[Name]-efs
自動バックアップ ：無効
VPC ：作成したVPCを
サブネットID ：作成した各AZのPublicサブネット
セキュリティグループ ：　作成したEFS用のセキュリティグループ
他はデフォルトのままでOK
EFSが作成できたら再度EC2にログインします。なお、以降の作業はすべてルートユーザーで行います。

 EFSパッケージのインストールEFSパッケージをインストールします。
yum -y install amazon-efs-utils

 マウントの実行作成したEFSをEC2にマウントします。
mkdir /efs
mount -t efs -o tls [ファイルシステムID]:/ /efs

 サーバ起動時の自動マウント設定自動マウントの設定をすることでAutoScalingで起動したEC2もEFSに自動マウントされるようになります。
cp -ipv /etc/fstab /etc/.fstab.org
sed -i '2a [ファイルシステムID]:/ /efs efs _netdev,noresvport,tls 0 0' /etc/fstab
diff -U0 /etc/.fstab.org /etc/fstab

 WordPressコンテンツをEFSに移動WordPressをマウント先のEFSに移動することでサーバ同士でデータ共有が可能になります。
mkdir /efs/html
mv -i /var/www/html/wordpress /efs/html
chown -R apache:apache /efs/html/wordpress

 Apache設定ファイルの修正ドキュメントルートとルートディレクトリをEFSのパスに向けます。
cp -ipv /etc/httpd/conf/httpd.conf /etc/httpd/conf/.httpd.conf.`date +%Y%m%d`
sed -i '/^DocumentRoot/s/DocumentRoot "\/var\/www\/html\/wordpress"/DocumentRoot "\/efs\/html\/wordpress"/' /etc/httpd/conf/httpd.conf
sed -i '/^<Directory/s/Directory "\/var\/www\/html\/wordpress"/Directory "\/efs\/html\/wordpress"/' /etc/httpd/conf/httpd.conf
diff -U0 /etc/httpd/conf/.httpd.conf.`date +%Y%m%d` /etc/httpd/conf/httpd.conf

 起動順の変更EFSがマウントされてからサービスが起動されるように起動順を変えます。
cp -ipv /usr/lib/systemd/system/httpd.service /usr/lib/systemd/system/.httpd.service.`date +%Y%m%d`
sed -i '/^After/s/$/ efs.mount/' /usr/lib/systemd/system/httpd.service
diff -U0 /usr/lib/systemd/system/.httpd.service.`date +%Y%m%d` /usr/lib/systemd/system/httpd.service

 反映設定を反映させます。
systemctl daemon-reload
systemctl restart httpd

 AutoScalingによる負荷分散と自動スケーリングAutoScalingの設定をしていきます。

 StressのインストールAutoScalingのスケールテストで使用するstressをインストールします。
dnf install -y stress

 AMIの作成AWSマネジメントコンソールより以下のように検索しAMIを作成していきます。

EC2 > インスタンス > 対象EC2をチェック > アクション > イメージとテンプレート > イメージを作成
イメージ名　：任意
インスタンスの再起動　：チェックを外す
他はデフォルトでOK

 起動テンプレートの作成AWSマネジメントコンソールより以下のように検索し起動テンプレートを作成していきます。

EC2 > 起動テンプレート > 起動テンプレートを作成
起動テンプレート名　：[Name]-lt
Amazon マシンイメージ　：作成したAMI
インスタンスタイプ　：t2.micro
キーペア名　：作成したキーペア
セキュリティグループ　：作成したEC2用のセキュリティグループ
他はデフォルトでOK

 AutoScalingグループの作成AWSマネジメントコンソールより以下のように検索しAutoScalingを作成していきます。

EC2 > AutoScalingグループ > AutoScalingグループを作成する
AutoScalingグループ名　：[Name]-autoscaling
起動テンプレート　：作成した起動テンプレート
VPC　：作成したVPC
アベイラビリティーゾーンとサブネット　：作成した各Publicサブネット
ロードバランサー　：既存のロードバランサーにアタッチする
既存のロードバランサーターゲットグループ　：作成したターゲットグループ
ヘルスチェックタイプ　：Elastic Load Balancing のヘルスチェックをオンにする
希望するキャパシティ　：2
最小の希望する容量　：2
最大の希望する容量　：4
自動スケーリング　：ターゲット追跡スケーリングポリシー
ターゲット値　：30
他はデフォルトでOK

 元のEC2をターゲットから解除アクセスされるホストはすべてAutoScalingで管理したいので元々あったEC2はターゲットグループから解除します。

EC2 > ターゲットグループ > 対象のターゲットグループをチェック > ターゲット > 対象のインスタンスをチェック > 登録解除

 RDSを冗長構成に変更シングル構成で作成したRDSを冗長構成に変更していきます。

 RDSの設定変更AWSマネジメントコンソールより以下のように検索しRDSを冗長構成に変更します。

RDS > データベース > 対象のRDSをチェック > アクション > マルチAZ配置への変換 > すぐに適用

 テストEFSとAutoScalingの設定を行いましたのでそれぞれ問題なく設定できているのかテストしていきます。なお、RDSはAWSマネジメントコンソールからマルチAZになっていることが目視で確認できるため不要とします。

 テスト前にテストの前に現在の構成を改めて解説します。
EC2は2台起動しておりAZ間をまたがってAutoScalingによって管理されています。アクセスはALBによって均等に分散され、負荷上昇するとEC2が増えます。
EFSはEC2にマウントしておりデータ更新を行う場合にはEFSにあるデータを更新することですべてのEC2に更新された内容を反映します。またAutoScalingによって新しく起動したEC2も自動マウントされるためデータ不整合は起こらない構成になっています。
RDSは普段はプライマリの方で読み込み、書き込みを行いますが障害発生時にはスタンバイの方に自動で切り替わります。



 データ共有テストEFSのデータ共有をテストします。テストといっても非常に簡単なのですがAutoScalingによって起動した2台のEC2に接続してtail -f /var/log/httpd/access_logのコマンドを実行します。そうするとリアルタイムでのアクセス状況が確認できます。試しにブラウザからWebサイトにアクセスするとそのログが更新されてアクセスされたことが確認できます。

それではWordPressを更新し、その更新が2台のEC2に反映されるかを確認します。WordPress管理者サイトにアクセスし、左ペインより投稿 > クイック編集としタイトルを更新します。私の場合は「Hello world」から「おはよう」に更新します。

更新が完了したらユーザーサイトにアクセスし投稿内容が更新されていることを確認します。この時ブラウザを何度かリロードしても投稿内容が更新された内容で表示されること、2台のEC2のターミナルでWebサイトからアクセスがあったことを確認できれば別々のサーバであるEC2が同じ更新したデータを共有していることが確認できます。


 自動スケールテストAutoScalingの自動スケールテストします。ターミナルで意図して負荷をかけるコマンドstress -c 1 -q &を実行するとCPUの負荷が上昇します。上昇していることはtopとコマンド入力すると確認できます。画面ではCPU使用率が99％になっていることが確認できます。

しばらく待ってAWSマネジメントコンソールのAutoScaling画面よりEC2が増えていることが確認できればOKです。

スケールアウトが確認できたら次はスケールインです。pkill stressを実行するとstressをkillするためCPU使用率が下がります。CPU使用率が下がることでAutoScalingの通常時の2台に戻ればOKです。


 まとめ2回に分けてAWS基盤のWebサイト構築を実施しました。ECサイトのようなセキュアな情報を取り扱う場合にはもう少しセキュリティを、予約サイトのような急なアクセス集中があるようなサイトであればキャッシュの考慮も必要になります。ブログや簡単なHPであれば本記事の内容で問題ないですがどのような構成にするかはWebサイトにニーズによってカスタマイズしてみてください。