冗長性のあるブログサービスを構築する

#記事の目的
前回基本的なブログサービスを構築しました。
前回の記事：https://qiita.com/ShotaMo/items/905befe1f4f685f9e4bc

しかし、このままではEC2やRDSに異常が発生し停止するとブログサービスを閲覧できなくなってしまいます。
そこで今回ELBを設置し2台のEC2インスタンスに負荷分散、RDSのスタンバイを用意して冗長性をアップしていきます。

#構成図
完成形の構成図は以下のようになります。
第一段階

#実際に作成していく
■RDSの復元
前回作成したものを停止,削除していたため、スナップショットより復元していきます。
設定項目は以下のようになります。
・DBの使用：MySQL Community
・DBインスタンス識別子:database-1
　DBインスタンス識別子:どのDBなのかを判断するために利用者が任意に指定できる名前
・接続 VPCの選択：MyVPC
・追加の接続設定：mysubnetgroup,パブリックアクセス なし,VPC セキュリティグループ RDS-SG-1,データベースポート 3306
・DBインスタンスクラス：バースト可能クラス db.t2.micro
　（以前の世代のクラスを含めるをチェックしないと出ない）
・ストレージ：汎用SSD 20GB
・可用性と耐久性：スタンバイインスタンスを作成しない, AZ ap-northeast-1a
　（後で設定変更することでスタンバイ側のDBを作成するため、ここでは作成しない）
・データベース認証：パスワード認証
以上の設定でRDSを起動していきます。

■EC2を起動してブログサイトが閲覧できるか確認
EC2インスタンスを起動して、EC2上のブログサイトがRDSよりデータを持ってくることで、きちんと表示されるか確認していきます。
しかし私の場合うまく表示されませんでした。(表示に時間がかかった)

そうなる理由としては以下となります。
Wordpressの使用で、DBにサイトのURL情報が保存されるようになっています。
しかしEC2インスタンスを終了すると、IPアドレスが固定化されていない(ElasticIPで設定されていないなど)場合、パブリックIPが変わってしまいRDSに保存されているIPとEC2に接続するIPに不整合が生じてしまい、このようなことが起こってしまいます。

上記を解決するために、DB内の情報を修正する必要があるため、
EC2インスタンスにSSH接続し次のコマンドを実行しました。

#mysqlへ接続する
#-h ホスト名を指定(ここではRDSのエンドポイントドメイン名を指定）
#-u ユーザー名を指定
#-p パスワード指定(対話的にパスワードが問われる)
mysql -h database-1.cugxkyu5vnxr.ap-northeast-1.rds.amazonaws.com -u wordpress -p

#使用するDB名を指定する
USE wordpress

#wp_optionsテーブルのoption_nameカラム内の”siteurl”と”home”を出力する
SELECT * FROM wp_options WHERE option_name IN ('siteurl', 'home');

#以下コマンドでSELECT分で確認したURLを現在のIPアドレスに書き換えていく。(xx...を現在のパブリックIPにする)
UPDATE wp_options SET option_value = 'http://xx.xx.xx.xx' WHERE option_name IN ('siteurl', 'home');

#再度SELECT分で変換できているか確認する
SELECT * FROM wp_options WHERE option_name IN ('siteurl', 'home');

上記対応を取ることで、正常にブログサイトの閲覧が可能になりました。

■ブログサイトのトップページを編集しEC2のどちらを表示しているのかわかるようにする
EC2に接続し以下のコマンドを実行していきます。

#rootユーザーにスイッチする
sudo su -

#ディレクトリの移動
cd /var/www/html/

#ディレクトリ配下のファイル表示(ls -lの省略系)
ll

#指定したファイルを編集する(今回はindex.php)
#ここではviエディタの詳細は記載しないが操作で必要なのは以下
#iキー：入力モード
#ctrl + c：コマンドモード
#:wq：編集したファイルを保存し、viエディタを閉じる
vi index.php

#index.phpに記述する内容
echo '<p>Web Server 1</p>';

■AMIの取得・利用
同じ設定のEC2インスタンスを作成するため、AMIを取得していきます。
そのため一度EC2インスタンスの停止します。

AMI：Amazonマシンイメージのことで、この中にインスタンスの起動に必要な情報が用意されいる。利用することで、同一の設定のEC2インスタンスをすぐに起動できる。どのレベルまでAMI化するかも利用者側で決めることができる。

AMI作成方法
・EC2インスタンス停止後、アクション→Image and template→イメージを作成を選択する。
・イメージ名、イメージの説明は任意のものを指定。(ここではWebServerとする)
・作成ボタンを押下し、左ペインのAMIより作成されていることを確認する。

AMI利用
・EC2の作成ボタンを押下
・左ペインのマイAMIを選択すると作成したAMIがある(WebServer)ため、これを選択肢起動する。
・基本的にあとのストレージの設定などは前回同様
　セキュリティグループはWebサーバー同士同じものを適用すること(Web-SG-1)
・新規で起動したEC2インスタンスのトップページも編集しておく。
　(基本操作は同じのため、違う箇所のみ記載する)

#index.phpに記述する内容
echo '<p>Web Server 2</p>';

■ELBの作成
続いてELBロードバランサーの作成をしていきます。
・作成ボタンを押すと、ALB、NLB、CLBとあるが、今回作成するのはALBのためそちらを選択する。
・名前：LB-1
・スキーム：インターネット向け
・IPアドレスタイプ：IPv4
・リスナー：HTTP 80
・アベイラビリティゾーン
　VPC：MyVPC
　AZ：ap-northeast-1a　publicsubnet1
　AZ：ap-northeast-1c　publicsubnet2
・セキュリティ設定の構成：HTTPS使用の警告メッセージが出力されるが現段階ではこのまま進める。
・セキュリティグループ：80 すべてのIPからの接続を受け付ける(LB-SG-1)
・ターゲットグループの設定
　-名前：TG-1
　-ターゲットの種類：インスタンス
　-プロトコル：HTTP
　-ポート：80
　-プロトコルバージョン：HTTP1
　-ヘルスチェック：HTTP　/readme.html
　 ヘルスチェックの詳細設定(EC2インスタンスのヘルスチェック間隔など設定できる)
　-ヘルスチェックの間隔：正常の閾値：2　間隔：10s
　 上記設定で10秒ごとにヘルスチェックを行い、2回正常であればインスタンスは正常であると判断される。
　-ターゲットグループに追加するEC2インスタンスを指定する。

以上の手順で作成し、ロードバランサーのターゲットグループ内にあるTargetsタブを開くとサーバーのステータスを確認できます。
その後、RDS内に保存してあるサイトURLをロードバランサーのDNS名に変更し、接続ができるように上書きしていきます。（手順は上記と同じで、接続するEC2インスタンスは1,2側のどちらでもよい。）

この状態でサイトにアクセス(ロードバランサーのDNS名)し、リロードを数回行うと、アクセスしているサイトが1 or 2で切り替わっていることが確認できました。

■セキュリティグループの再設定
しかし現在の状態だと、IGWからのすべて80ポートでのアクセスが強化されている状態のため、ロードバランサーからの通信のみを許可するように設定していきます。
・セキュリティグループを選択する(Web-SG-1)
・インバウンドルールの編集もともと設定していたHTTP通信のルールを削除し、ここにロードバランサーのセキュリティグループ(LB-SG-1)を設定する。

■障害テスト
RDSの内容変更後に期待する動きをするのか、EC2インスタンスを片側削除し、サイトが閲覧できるか確認をしました。
実際に1側を停止すると、2側のサイトが表示されアクセスが可能であることを確認できました。

■RDSの冗長化
RDSをマスタースレーブ構成にして冗長化をとっていきます。
・対象のDBを選択し、変更ボタンを押下する。
・可用性と耐久性にある「マルチAZ 配置」の「スタンバイインスタンスを作成する」にチェックを入れ、次へを押下。
・変更スケジューリングの今すぐを選択し、変更ボタンを押下する。
　（今回はデモのため）

確認のためにRDSを再起動しサイトの閲覧が継続して可能かを確認していきます。(このときフェイルオーバーして再起動にチェックを入れておくこと）
→実際に閲覧は継続できました。（RDSのログからもフェイルオーバーされていることを確認できた）

今回は以上となります。
しかしこの構築ではまだ単一障害点があり、障害発生時にはブログの閲覧ができなくなる可能性があります。
そのため、AutoScalingを設定することでより冗長性を高めていこうと思います。

#最後に
この記事はAWS初学者を導く体系的な動画学習サービス
　「AWS CloudTech」の課題カリキュラムで作成しました。
　https://aws-cloud-tech.com