前回は、Route53のPrivateHostedZoneにてDNSフェイルオーバー（Active-Passive）を設定する手順をご紹介しました。

今回は、Route53のPrivateHostedZoneにてDNSフェイルオーバー（Active-Active）を設定する手順をご紹介していきたいと思います。

構成の確認

現在の構成

現在の環境を構成図で確認します。
現在、VPC上にパブリックサブネットが一つ、プライベートサブネットが二つ存在します。
パブリックサブネット上には踏み台サーバーが、プライベートサブネット上には一台ずつWEBサーバーが存在します。
VPCにはRoute53のPrivateHostedZoneを紐づけ、「web-test.https-demo.com」というドメイン名でDNSフェイルオーバー（Active-Passive)の設定を行っています。

今回の構成

今回は、一度DNSフェイルオーバーのレコードを削除したうえで、
DNSフェイルオーバー（Active-Active）の設定を行います。
Active-ActiveのDNSフェイルオーバーを設定する場合は、Route53のルーティングポリシーを「加重ルーティング」「レイテンシーベースルーティング」などで設定します。

参考：フェイルオーバー（Active-Active)

今回はルーティングポリシーに加重ルーティングを使用し、WEB1/WEB2のサーバーそれぞれに同じ加重（加重10)を割り当てます。

こうすると、平常時はWEB1/WEB2に対して同じ比率でルーティングが行われます。

Active-Activeの場合のヘルスチェックについて

平常時の挙動

DNSフェイルオーバーをActive-Activeで設定する場合は、どちらのレコードにもRoute53ヘルスチェックを紐づける必要があります。
今回の場合は、WEB1のRoute53ヘルスチェックには、WEB1に対するStatusCheckFailed_systemのCloudWatchアラームを紐づけます。
WEB2のRoute53ヘルスチェックには、WEB2StatusCheckFailed_systemのCloudWatchアラームを紐づけます。
加重ルーティングの加重をWEB1/WEB2で同じ値にしているため、平常時（両サーバーに対するヘルスチェックが成功している時）は、WEB1/WEB2に同じ割合でルーティングされます。

異常検知時の挙動

ヘルスチェックが失敗したサーバーについては、次にヘルスチェックが成功するまでの間ルーティング対象から外れます。
下記画像の例では、WEB1のヘルスチェックが失敗し、ルーティング対象から外されています。

作業の流れ

作業は下記流れで行います。
今回はRoute53のレコード設定作業をメインにご紹介します。
Route53PrivateHostedZoneの作成やApacheの設定は前回の記事でご紹介しているので、手順が分からない場合はそちらをご参照ください。
また、VPCやサブネット・EC2の設定はこちらの記事群でご紹介しています。

1.Route53でPrivateHostedZoneを作成し、VPCに紐づける
 2.EC2（WEB1/2）にApacheをインストールし、テスト用ページを配置する
3.Route53のヘルスチェックを作成
4.Route53のフェイルオーバールーティング（Active-Active)を設定
5.動作確認

構築手順

Route53のヘルスチェックを作成

今回は、WEB1/WEB2両方のレコードに対してRoute53のヘルスチェックを紐づけます。
PrivateHostedZoneでRoute53のヘルスチェックを利用する場合は、CloudWatchアラームをヘルスチェックに紐づける形となります。
※詳しくは前回をご参照ください。

前回の記事でWEB1に対してのヘルスチェックを設定しているので、今回はWEB2に対するヘルスチェックを設定していきます。

WEB2に対してCloudWatchAlarmを設定

WEB2に対しても、CloudWatchアラームを作成していきます。
監視するメトリクスは、WEB1と同様に「StatusCheckFailed_System」を設定します。

CloudWatchのトップページに移動し、左メニューから「アラーム」を押下します。

メトリクスの選択画面が表示されます。
「メトリクスの選択」を押下します。

「EC2」を押下します。

「インスタンス別メトリクス」を押下します。

EC2のメトリクス一覧から、メトリクス名が「StatusCheckFailed_system」かつ「インスタンス名」がWEB2（この画像ではHTTPS_DEMO_02)となっているものを見つけ、チェックボックスにチェックを入れます。
「メトリクスの選択」を押下します。

メトリクスの監視条件設定画面が表示されます。
「統計」を「最大」に設定し、「期間」を「1分」に設定します。

「条件」のセクションまでスクロールします。
しきい値の種類は「静的」を選択します。
アラーム条件には「以上(>=しきい値)」を設定し、しきい値には「1」を設定します。

「StatusCheckFailed_system」メトリクスは、EC2が停止している間は記録されない状態となります。
メトリクスが欠落（記録されない）している状態でもDNSフェイルオーバーとなるよう、
「欠落データの処理」を「欠落データを不正（しきい値を超えている）として処理」に設定します。

全ての設定を終えたら、「次へ」を押下します。
アクションの設定画面が表示されます。
「アラーム通知トリガー」を「アラーム状態」にします。
SNSトピックを「既存のSNSトピックを選択」に指定し、プルダウンからSNSトピックを選択します。

その他のアクションは指定せず、「次へ」を押下します。

「名前と説明を追加」の画面が表示されます。
アラーム名を入力し、「次へ」を押下します。

プレビュー画面で設定内容を確認します。

設定に間違いがなければ、「アラームの作成」を押下します。

アラームが正常に作成されていることを確認します。

これで、WEB2に対するCloudWatchAlarmの設定が完了しました。

Route53のヘルスチェックを作成

ヘルスチェックのトップ画面が表示されたら、「ヘルスチェックの作成」を押下します。

ヘルスチェックの設定が表示されます。
ヘルスチェックの名前を入力します。
「モニタリングの対象」は「CloudWatchアラームの状態」を設定します。
「CloudWatchリージョン」を対象のサーバーが存在するリージョン（今回は東京リージョン）に設定します。
「CloudWatchAlarm」には、先ほど作成したCloudWatchAlarmを設定します。

下にスクロールします。
ヘルスチェックステータスについて、「アラームが不足状態にある場合、そのステータスは正常です」を選択します。
全ての設定を完了したら、「次へ」を押下します。

ヘルスチェックが失敗した際の通知についての設定画面が表示されます。
「アラームの作成」は「いいえ」を選択し、「ヘルスチェックの作成」を押下します。

「ヘルスチェックの作成に成功しました」と表示されます。

画面を更新すると、作成したヘルスチェックが確認できるようになります。

Route53PrivateHostedZoneの状況確認

前回Active-Passiveフェイルオーバールーティングの設定を行ったため、Route53PrivateHostedZoneは画像のような状態となっています。

「web-test.https-demo.com」のフェイルオーバールーティングレコードが残っている状態だと加重ルーティングの設定が行えないため、該当のレコードを削除していきます。

削除が完了した状態です。

Route53のフェイルオーバールーティング（Active-Active)を設定

今回は、このタイミングでDNSフェイルオーバーのレコード設定も行います。

WEB1のレコード作成

「レコードを作成」を押下します。

レコード作成画面が表示されます。
レコード画面が表示されます。
「レコード名」は「web-test」と入力します。
「レコードタイプ」は「A」に設定します。
「値」は10.0.1.4を設定します。

「TTL」は「60」を指定します。
「ルーティングポリシー」には「加重」を選択し、「重量」は「10」に設定します。
「ヘルスチェックID」のプルダウンメニューから、WEB01用のRoute53ヘルスチェックを選択します。
「レコードID」には「web-test-01」を入力します。
レコードの設定入力が完了したら、「別のレコードを追加」を押下します。

WEB2のレコード作成

WEB02のレコードも、同じ要領で作成します。レコード名は先ほどと同様「web-test」を設定します。
「値」にはWEB2のIPアドレス（10.0.5.4）を設定します。

TTL・ルーティングポリシー・加重については、WEB01と同様に設定します。
「ヘルスチェックID」のプルダウンメニューから、先ほど作成したWEB02用のヘルスチェックを選択します。
「レコードID」は「web-test-02」を入力し、「レコードを作成」を押下します。

レコードの作成が完了した状態です。

動作確認

平常時

接続確認を行います。
踏み台サーバー（Windows)にログインし、ブラウザを立ち上げます。
ブラウザに「http://web-test.https-demo.com 」と入力すると、タイミングによってWEB1とWEB2のテストページがランダムに表示されます。

今回は、加重ルーティングでWEB1/WEB2を同じ割合にしています。
re:postの記事を参考に、Linuxの踏み台サーバーから加重ルーティングポリシーの設定が本当に動作しているかテストしてみます。

Linuxサーバーにて下記コマンドを実行してみます。

for i in {1..20000}; do domain=$(dig web-test.https-demo.com. @10.0.0.2 +short); echo -e  "$domain" >> RecursiveResolver_results.txt; done

for i in {1..20000}; do……ループを1から10000回実行
domain= \$(dig web-test.https-demo.com. @10.0.0.2 +short)……10.0.0.2のDNSリゾルバに対して「web-test.https-demo.com」を問い合わせ、結果を簡易表示したものを変数「domain」に格納
echo -e "$domain" >> RecursiveResolver_results.txt……変数「domain」を「RecursiveResolver_results.txt」に書き込み

上記コマンドを実行すると、「dig web-test.https-demo.com. @10.0.0.2 +short」を2万回実行し、結果を「RecursiveResolver_results.txt」に書き込みます。

「RecursiveResolver_results.txt」には画像のような形で、digコマンドの実行結果が書き込まれています。

下記コマンドを実行し、「RecursiveResolver_results.txt」に記録されているdigコマンドの実行結果を、IPアドレス別に集計します。

sort RecursiveResolver_results.txt | uniq -c | sort -nr

sort RecursiveResolver_results.txt……「RecursiveResolver_results.txt」ファイルの内容をソートする
uniq -c……ファイル内の重複する行を削除し、各行の前に出現回数を出力する
sort -nr……データを降順にソートする

コマンドを実行してみると、「web-test.https-demo.com」に対して10.0.1.4が返された回数が7934回、10.0.5.4が返された回数が12066回のようです。

何度かdigコマンドを実行して集計してみました。
タイミングによってばらつきはありますが、「web-test.https-demo.com」に対して10.0.1.4と10.0.5.4の両方が返されており、Active-Activeの状態であることが分かります。

フェイルオーバーの確認

WEB2のサーバーを落とし、WEB1のみにルーティングされるのか確認してみます。
踏み台サーバー（Windows）でWEB2の画面を表示しておきます。
この状態でWEB2のインスタンスを停止させます。

Route53のヘルスチェックが失敗状態になるまで待機してから踏み台サーバー（Windows）のブラウザを更新すると、WEB1の画面が表示されます。

逆に、WEB2を起動させてWEB1を停止した状態にしてみます。

Route53のヘルスチェックステータスが更新されるまで待ってから踏み台サーバー（Windows）のブラウザを更新すると、WEB2の画面が表示されます。

これで、今回ご紹介する手順は以上となります。
ここまでお読みいただきありがとうございました。