内容
この記事は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 '<p>Web Server 1</p>';の一文を挿入（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の情報を新しいものに書き換えます。
- ターミナルを開き、EC2にSSH接続でログインする。(
ssh -i キーペア名 ec2-user@WebServer1のパブリックIPアドレス) -
mysql -h RDSのエンドポイント名 -u ユーザー名 -pでMySQLにログイン（エンドポイント名はRDSの画面でデータベース名を選択すると確認できます。ユーザー名はWordPressをインストールした際に指定したユーザー名です。） - 続けてパスワードを入力
-
USE データベース名コマンドを実行（前回はデータベース名をwordpressとしたのでUSE wordpress) - 続けて
SELECT * FROM wp_options WHERE option_name IN ('siteurl', 'home');を実行すると、現在設定されているサイトのURLが確認できる。 -
UPDATE wp_options SET option_value = 'http://xx.xx.xx.xx' WHERE option_name IN ('siteurl', 'home');コマンドを実行（'xx.xx.xx.xx'はWebServer1のパブリックIPアドレス） - 再度
SELECT * FROM wp_options WHERE option_name IN ('siteurl', 'home');を実行すると、EC2のパブリックIPアドレスに置き換わっていることが確認できる。 - WebServer1のパブリックIPアドレスをコピーし、ブラウザに貼り付ける。
- 正常に表示されれば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 '<p>Web Server 1</p>';の記述をecho '<p>Web Server 2</p>';に変更 -
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を削除する場合は、「アクション」タブから「削除」を選択してください。