AWSでELBを利用しWEBサーバーを冗長化、ついでにRDSもマルチAZ構成にしてみました。
プロローグ
以下、前回の続きで、ここではEC2にapacheがインストール済み、RDSでmysqlを構築済み、オリジナルドメインをRoute53に登録済み、WEBサーバにwordpressがインストール済み、と仮定して話を進めます。
今回はELB(AWSのロードバランサ―）を利用し、WEBサーバーを冗長化、さらにRDS(DBサーバ)もマルチAZ構成（ホット・スタンバイ構成）しようと思います。
サブネットの作成
まずは異なるアベイラビリティゾーンに冗長用の新しいサブネットを作成します。
VPCのダッシュボードを開いて左ペインから「サブネット」を選択し、「サブネットの作成」ボタンを押してください。
「名前タグ」にはわかりやすい任意の名前を、「VPC」は自分で作成した「Virtual Private Cloud (VPC) 」を設定します。既存のネットからアクセスできるパブリックサブネットはアベイラビリティゾーン「1a」に作成したので、今回の「アベイラビリティゾーン」は「1c」を選択します。同様にCIDRブロックも「1a」のパブリックサブネットが「10.0.10.0/24」なので、今回の「1cのCIDRブロック」は「10.0.11.0/24」とする事にしました。最後に「作成」ボタンを押します。
サブネットが作成されました。「閉じる」ボタンを押します。
次にインターネット経由でアクセスできる様に設定していきます。
今回作成したサブネット「1c」を選択し、「ルートテーブル」タブにある「ルートテーブルの関連付けの編集」ボタンを押します。
すでに「1a」サブネットには今回作成したインターネットGWと関連付けられたルートテーブルが存在するはずです。それを今回も選択し「保存」ボタンを押します。
（※インターネットGWとルーティングに関しての説明は、今回、割愛させて頂きます。）
これで「1c」サブネットもインターネット経由でアクセスできる様になりました。
WEBサーバーの複製（AMIの作成）
次に既にwordpressが稼働中のWEBサーバー（AMI)を複製していきます。
まずはEC2ダッシュボードへ移動します。
次に左ペイン「インスタンス」を選択し、複製元のWEBサーバを選択したら「アクション」＞「イメージとテンプレート」＞「イメージを作成」を選択します。
「イメージ名」と「イメージの説明」に任意のわかりやすい名称を入力したら「イメージの作成」ボタンを押します。
左ペイン「AMI」を選択しステータスが「available」になるまで待って「起動」ボタンを押します。
学習用環境なので無料で使える「t2.micro」のまま、「次の手順」ボタンを押します。
次に「ネットワーク」に自分で作成した「VPC」を、「サブネット」には上記で作成した「1cのパブリックサブネット」を選択します。
また「自動割り当てパブリックＩＰ」は「有効」、「キャパシティーの予約」は「なし」を選択します。
なお、まだ設定は終わっていません。下の方までスクロールしていってください。
IPは自動割り当てでも良いのですがELBを嚙ますので固定してしまいます。サブネットの範囲から適切なIPを入力してください。最後に「次の手順」に進みます。
次のストレージは何も変更せず「次の手順」に進みます。
タグは1aのWEBサーバと同様に、「タグを追加」し「Name」にWEBサーバとわかる名称を入力しておきます。
「既存のセキュリティグループを選択する」から「1aのWEBサーバー構築時に作成したセキュリティグループ」を選択し「確認と作成」ボタンを押します。
内容を確認したら「起動」ボタンを押します。
ログイン時のsshキーが聞かれるので「既存のキーペアの選択」をし「チェックボックス」を入力し「インスタンスの作成」ボタンを押します。
以上でWEBサーバーの複製（AMIの作成）は完了です。
ELB(ロードバランサ―）の設定
次にロードバランサ―の設定を行っていきます。
EC2ダッシュボードに戻り、左ペインの下の方にある「ロードバランサ―」を選択し、「ロードバランサ―の作成」ボタンを押します。
「HTTP/HTTPS（アプリケーションロードバランサ―」の「作成」ボタンを押します。
「名前」には「aplication load balancer」とわかる様な名称を入力し、「VPC」は自分で作成した「Virtual Private Cloud (VPC) 」を設定します。アベイラビリティゾーンは今回、「1a」「1c」の二つが表示されますが両方にチェックを入れ、「サブネット」にはそれぞれのサブネットを選択します。そうしたら「次の手順」へ進みます。
ここは何もせず「次の手順」へ進みます。
ここでは「新しいセキュリティグループを作成」します。「HTTP」に対し「任意の場所」を選択し、ポート80のみインターネット上からアクセスできる様にします。そうしたら「次の手順」へ進みます。
LBのルーティングですが、基本デフォルトのままでいきます。「名前」のみわかりやすい名称を入力し、「次の手順」へ進みます。
ロードバランスするターゲットですが、現在動いている２つのWEBサーバを選択し「登録済みに追加」ボタンを押します。すると上段の「登録済みターゲット」に表示されるのを確認し、「次の手順」へ進みます。
次の確認画面で特に問題が無ければ「登録」ボタンを押します。
以上でロードバランサ―の作成は完了しました。状態が「active」になるまで暫く待ってください。
あとは図中の赤四角のURLをコピーし、ブラウザでアクセスしてみれば、ロードバランサ―経由でWEBサイトにアクセスされている事がわかります。
独自ドメインでアクセスできるようにDNS(Route53)を設定する
本番環境だった場合、上記の自動発行されたURLではサービスインできませんよね。そこで取得した独自ドメインでアクセスした際にロードバランスされる様、DNS(Route53)を設定していきます。
まずRoute 53ダッシュボードにアクセスします。
左ペイン「ホストゾーン」を選択し、登録してある「ドメイン名」を選択します。（※この時点でホストゾーンが未設定の場合はコチラの手順をご参照ください。）
現時点では「1aのWEBサーバに向いているAレコード」を「選択」し、「編集」していきます。
トラフィックのルーティング先として「Aplication Load Balancerへのエイリアス」を選択し、リージョンは「東京」、そして先ほど作成した「xxx-alb(アプリケーションロードバランサ―」を選択します。最後に「変更を保存」ボタンを押します。
以上でDNS（Rote53）の設定変更も完了です。
実際に独自ドメインでブラウザにアクセスしてみましょう。
無事、表示されました。
ELBのヘルスチェック確認
最後にヘルスチェックが動いているか確認してみます。Termコンソールより「1a」のWEBサーバのみ、apacheサービスを停止してみてください。
$ sudo systemctl stop httpd
$ sudo systemctl status httpd
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
Drop-In: /usr/lib/systemd/system/httpd.service.d
mqphp-fpm.conf
Active: inactive (dead) since Sun 2021-02-14 13:16:52 UTC; 24s ago
停止した直後は502 Bad Gatewayが表示される事があるかもしれません。
しばらくF5リロードし続けると、安定して「1c」サーバのみが表示される様になります。
RDSをマスタースレーブ構成に変更する
ついでにRDSのマルチAZ構成も有効にしてみます。なお料金がかかるので、試しにやってみる程度です。
RDSダッシュボードの左ペイン「データベース」から該当ＤＢを選択し、「変更」ボタンを押します。
可用性と耐久性の「スタンバイインスタンスを作成する」にチェックを入れ、最下部の「続行」ボタンを押します。
「すぐに適用する」を選択し「DBインスタンスを変更」ボタンを押します。
これでマスタースレーブ構成は完了です。学習用の場合は料金がかかるので、すぐ元の構成に戻しておきましょう。
なおフェールオーバーする際、WEBサーバからの接続で用いているエンドポイント名は変わらないので、運用側では特に意識することなく自動的に切り替わる、、らしいです。
以上、WEBサービスの冗長設定でした(^_-)-☆。
