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

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

前回の構成

![スクリーンショット 2021-06-21 13.48.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/790886/0580918a-5c77-f8a5-d044-54016605381a.png)
上記の構成だと、EC2に障害が発生した場合、サービス全体が停止してしまうため、AZ 1cに新たにEC2とRDSを構築する。
2台のEC2はRDS Masterのデータを参照しているため、クライアントはどちらのEC2に通信しても最新のブログ記事を閲覧できる。（下記画像）
![スクリーンショット 2021-06-22 12.32.26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/790886/797ea0af-0c8b-982b-6c59-1e771a68f554.png)


# 実施の流れ
## 前回作成したEC2を停止した場合
1. EC2の画面から前回作成したEC2を選択
1. 「インスタンスの状態」タブを選択し、「インスタンスの開始」を選択

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

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

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

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

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

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

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

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

##セキュリティーグループの設定を変更
##### 現状だと、Webサーバーのセキュリティグループが全ての接続元からの80番通信が許可されているため、ロードバランサーのセキュリティグループからの通信のみOKとするよう設定を変更する。
1. EC2の画面のどちらかのインスタンスを選択し、「セキュリティ」タブから「セキュリティグループ」を選択
1. 「インバウンドルールを編集」を選択
1. ポート範囲「80」のソースにロードバランサー作成時に設定したセキュリティグループを選択する。
1. 「ルールを保存」を選択
1. 再度ブラウザに戻り、更新ボタンを押し、表示に問題がないことを確認する。

## 障害テスト

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

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

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

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

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