内容

この記事はAWS初学者を導く体系的な動画学習サービス
「AWS CloudTech」の課題カリキュラムで作成しました。
https://aws-cloud-tech.com
「基本的なブログサービスを構築する（シングル構成）」のレッスンに引き続き、
「冗長性のあるブログサービスを構築する（冗長構成）」のレッスンにて、より障害に強い冗長化の構成を学習しました。
前回のレッスン　https://qiita.com/zakinicof/items/e040e1eb343e4c6220e9

このレッスンのゴール

前回の構成

上記の構成だと、EC2に障害が発生した場合、サービス全体が停止してしまうため、AZ 1cに新たにEC2とRDSを構築する。
2台のEC2はRDS Masterのデータを参照しているため、クライアントはどちらのEC2に通信しても最新のブログ記事を閲覧できる。（下記画像）

実施の流れ

前回作成したEC2を停止した場合

EC2の画面から前回作成したEC2を選択
「インスタンスの状態」タブを選択し、「インスタンスの開始」を選択

RDSを削除した場合

RDSの画面の左メニューから「スナップショット」を選択
スナップショット名のチェックボックスにチェックを入れ、「アクション」タブを選択
「スナップショットを復元」を選択
エンジン：「MySQL Community」であることを確認
DB インスタンス識別子：前回設定したものを入力
VPC：前回作成したVPCを選択
「追加の接続設定」タブを選択
サブネットグループ：前回作成したサブネットグループを選択
パプリックアクセス可能：前回と同様「なし」を選択
VPCセキュリティーグループ：「既存の選択」を選択し、前回作成したものを選択（デフォルトは×を選択して削除しておく）
データベースポート：「3306」であることを確認
DBインスタンスクラス：「バースト可能クラス（tクラスを含む）」、「以前の世代のクラスを含める」を選択
ストレージタイプは「汎用SSD」、ストレージ割り当ては「20」であることを確認
マルチAZ配置：「スタンバイインスタンスを作成しないでください」が選択されていることを確認
アベイラビリティーゾーン：「ap-northeast-1a」を選択
データベース認証：「パスワード認証」を選択
「DBインスタンスの復元」を選択
復元したデータベースのステータスが「利用可能」となっていることを確認

ブラウザでブログが閲覧できることを確認

EC2インスタンスからパブリックIPアドレスを確認し、アドレスバーに貼り付けてEnterを押す。
正常に表示されればOK（表示に時間がかかったり、崩れたりする場合は、この後の項目の「データベースに保存されているURLを書き換える」の手順を先に実施してください）

トップページを編集(WebServer1)

Webサーバーを冗長構成するにあたり、どちらがWebサーバー1かWebサーバー2かを判断するために、トップページを編集して、Webサーバー1にどちらを表示しているか分かるようにする。

ターミナルを開き、EC2にSSH接続でログインする。(ssh -i キーペア名 ec2-user@WebServer1のパブリックIPアドレス)
sudo su -コマンドで管理者権限にスイッチ
cd /var/www/htmlでhtmlに移動
llで「index.php」ファイルがあることを確認
vi index.phpでファイルを開く
iを押してインサートモードに切り替え、define( 'WP_USE_THEMES', true );の下の行にecho 'Web Server 1';の一文を挿入（Webサーバー1と分かるようにするため）
control + c → :wqで保存

EC2をコピーする

EC2のAMIを取得して、取得したAMIをもう一方のAZで起動する。

EC2の画面で前回作成したインスタンスを選択
「インスタンスの状態」タブを選択
「インスタンスの停止」を選択
「インスタンスの状態」が「停止済み」になったら、「アクション」タブから「イメージとテンプレート(Image and templates)」→「イメージを作成」を選択
「イメージ名」と「イメージの説明」を入力
「イメージを作成」を選択
画面左のメニューから「AMI」を選択
作成したAMIのステータスが「pending」から「available」になるまで待つ。
左のメニューからインスタンスを選択
「インスタンスを起動」を選択
左のメニューから「マイAMI」を選択
先ほど作成したものが表示されるので選択
インスタンスタイプ：「t2.micro」を選択、次のステップへ
ネットワーク：前回作成したVPCを選択
サブネット：「PublicSubnet2｜ap-northeast 1c」を選択
自動割り当てパプリックIP：「有効」とし、次のステップへ
ストレージは「8GiB」のままで次のステップへ
「タグの追加」を選択し、「キー」に「Name」、「値」に「WebServer2」とそれぞれ入力し、次のステップへ
セキュリティグループの割り当て:「既存のセキュリティグループを選択する」を選択し、コピー元のWebサーバーのセキュリティグループを選択し、「確認と作成」を選択
これまで設定した項目を確認し、「起動」を選択
キーペアはコピー元のWebサーバーと同じものを選択し、「インスタンスの作成」を選択
コピー元のインスタンスを選択し、「インスタンスの状態」→「インスタンスを開始」を選択

データベースに保存されているURLを書き換える

この後、再度ブログにアクセスしようとすると失敗してしまいます。
WordPressの仕様で、WordPressがインストールされた際に、データベースにサイトのURLの情報が保存されます。
先ほど、EC2のインスタンスを再起動した際にIPアドレスを固定化していなかったため、パブリックIPが変更されております。
このため、実際にサイトにアクセスするURLとデータベースに保存されているURLに不整合が生じたため、表示に時間がかかったり、レイアウトが崩れてしまう事象が発生するようです。
これを解決するために、データベースに保存されているURLの情報を新しいものに書き換えます。
1. ターミナルを開き、EC2にSSH接続でログインする。(ssh -i キーペア名 ec2-user@WebServer1のパブリックIPアドレス)
2. mysql -h RDSのエンドポイント名 -u ユーザー名 -pでMySQLにログイン（エンドポイント名はRDSの画面でデータベース名を選択すると確認できます。ユーザー名はWordPressをインストールした際に指定したユーザー名です。）
3. 続けてパスワードを入力
4. USE データベース名コマンドを実行（前回はデータベース名をwordpressとしたのでUSE wordpress)
5. 続けてSELECT * FROM wp_options WHERE option_name IN ('siteurl', 'home');を実行すると、現在設定されているサイトのURLが確認できる。
6. UPDATE wp_options SET option_value = 'http://xx.xx.xx.xx' WHERE option_name IN ('siteurl', 'home');コマンドを実行（'xx.xx.xx.xx'はWebServer1のパブリックIPアドレス）
7. 再度SELECT * FROM wp_options WHERE option_name IN ('siteurl', 'home');を実行すると、EC2のパブリックIPアドレスに置き換わっていることが確認できる。
8. WebServer1のパブリックIPアドレスをコピーし、ブラウザに貼り付ける。
9. 正常に表示されればOK

トップページを編集(WebServer2)

ターミナルを開き、EC2にSSH接続でログインする。(ssh -i キーペア名 ec2-user@WebServer2のパブリックIPアドレス)
sudo su -コマンドで管理者権限にスイッチ
cd /var/www/htmlでhtmlに移動
llで「index.php」ファイルがあることを確認
vi index.phpでファイルを開く
iを押してインサートモードに切り替え、define( 'WP_USE_THEMES', true );の下の行にあるecho 'Web Server 1';の記述をecho 'Web Server 2';に変更
control + c → :wqで保存

ELBを作成

EC2の画面の左メニューから「ロードバランサー」を選択
「ロードバランサーの作成」を選択
「Application Load Balancer」の作成を選択
「名前」を入力
スキーム：「インターネット向け」を選択
IP アドレスタイプ：「IPv4」を選択
VPC：作成したVPCを選択
アベイラビリティーゾーン：「ap-northeast-1a」と「ap-northeast-1c」を選択
サブネット：それぞれパブリックサブネットを選択し、次の手順へ
「HTTPS プロトコルをお使いください。」と警告が出るが、一旦次の手順へ進む。
セキュリティグループの割り当て：「新しいセキュリティグループを作成する」を選択、「セキュリティグループ名」、「説明」を入力し、次の手順へ
ターゲットグループの名前を入力
ターゲットの種類：「インスタンス」を選択
プロコトルは「HTTP」、ポート：「80」、プロコトルバージョンは「HTTP1」を選択
ヘルスチェック/パス：「/readme.html」と入力
「ヘルスチェックの詳細設定」タブを開き、「正常のしきい値」を「2」、「間隔」を「10」とし、次の手順へ
WebServer1とWebServer2にチェックを入れ、「登録済みに追加」を選択し、次の手順へ
設定に問題がなければ「作成」を選択
左メニューの「ターゲットグループ」を選択
作成したターゲットグループを選択し、「Targets」タブを選択
WebServer1,2の「Health status」が「initial」から「healthy」に変わるのを確認

RDSに設定されているサイトアドレスを書き換え

ターミナルを開き、rootユーザーでhtmlディレクトリにいる状態でmysql -h RDSのエンドポイント -u WordPressインストール時のユーザー名 -pを実行
パスワードを入力
USE データベース名を実行
SELECT * FROM wp_options WHERE option_name IN ('siteurl', 'home');を実行、WebServer1のパブリックIPアドレスが設定されていることを確認
UPDATE wp_options SET option_value = 'http://ロードバランサーのDNS名' WHERE option_name IN ('siteurl', 'home');を実行（ロードバランサーのDNS名は、EC2の左メニュー「ロードバランサー」を選択すると確認できます）
再度SELECT * FROM wp_options WHERE option_name IN ('siteurl', 'home');を実行し、アドレスが変更されていることを確認

ロードバランサーの機能を確認

先ほどのDNS名をコピーし、アドレスバーに貼り付ける。
何度か更新ボタンを押すと左上の表示が変わることを確認できる。（ロードバランサーがWebServer1と2に振り分けている。）

セキュリティーグループの設定を変更

現状だと、Webサーバーのセキュリティグループが全ての接続元からの80番通信が許可されているため、ロードバランサーのセキュリティグループからの通信のみOKとするよう設定を変更する。

EC2の画面のどちらかのインスタンスを選択し、「セキュリティ」タブから「セキュリティグループ」を選択
「インバウンドルールを編集」を選択
ポート範囲「80」のソースにロードバランサー作成時に設定したセキュリティグループを選択する。
「ルールを保存」を選択
再度ブラウザに戻り、更新ボタンを押し、表示に問題がないことを確認する。

障害テスト

1.EC2インスタンスのWebServer1を選択し、「インスタンスの状態」→「インスタンスの停止」を選択
1.ブログが閲覧できるか確認する。

RDSを冗長化

RDSの画面に移動し、左メニューの「データベース」を選択、ラジオボタンを選択した状態で「変更」を選択
下にスクロールし、「マルチAZ配置」を「スタンバイインスタンスを作成する (本稼働環境向けに推奨)」に変更する。
「続行」を選択
変更を適用するタイミング：「すぐに適用」に変更
「DBインスタンスを変更」を選択
データベースのステータスが「利用可能」、マルチAZが「あり」になるまで待つ。

RDSがマルチAZでフェイルオーバーするか確認

「アクション」タブから「再起動」を選択
「フェイルオーバーで再起動しますか?」にチェックを入れ、「確認」を選択
ブログが問題なく閲覧できることを確認する。
データベースの「ログとイベント」タブを選択し、「最近のイベント」を確認
「DB instance restarted」、「The user requested a failover of the DB instance.」、「Multi-AZ instance failover completed」のログを確認する。（マルチAZフェイルオーバーがスタートし、DBインスタンスがリスタート、フェイルオーバーが完了した）

今回はここまでになります。RDSが稼働したままだと料金がかかってしまいます。RDSを削除する場合は、「アクション」タブから「削除」を選択してください。