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

今回は、東京・大阪のマルチリージョン環境にて、Active-ActiveのDNSフェイルオーバーを設定する手順を確認していこうと思います。

構成の確認

現在、東京リージョン上に下記の構成が存在します。
10.0.0.0/21のVPCに対してRoute53のHostedZoneを紐づけています。
二つのWEBサーバーに対して、加重ルーティングとHealthCheckの設定を行い、単一リージョン上にてActive-Activeのフェイルオーバールーティングが設定されている状態です。

今回は、上記環境に大阪リージョンのVPCを追加し、東京・大阪の2つのリージョン上のWEBサーバーに対して加重ルーティングの設定を行います。
さらに、東京・大阪上のWEBサーバーが全台ダウンした場合にのみ、S3バケット上のSorryページを表示するよう設定を追加していきます。

NW構成の確認

まずは、東京・大阪上に存在するVPC・サブネット・EC2の各リソースについて確認します。
東京・大阪にそれぞれVPCを構築し、WEBサーバーを二台ずつ配置しています。
東京と大阪間のVPCにはVPCピアリングを設定し、あらかじめ相互に通信できる状態にしておきます。
さらに、静的WEBサイトホスティングを有効化したS3バケットを作成し、sorryページを用意しておきます。

Route53設定の確認

Route53のPrivateHostedZoneの設定内容を確認しておきます。
Route53PrivateHostedZoneは、東京・大阪リージョン上の各VPCに対して紐づけます。
この状態で、HostedZone内に各リージョン上のWEBサーバーに対する加重ルーティングのレコード設定を行います。

今回は、東京をプライマリリージョン・大阪をセカンダリリージョンとしてテストします。
東京に対して優先的にルーティングを行わせたいため、「web-test」というレコードに対して東京の加重を20、大阪の加重を10として設定をしています。
さらに、東京・大阪上のWEBサーバーが全台ダウンした場合にのみS3のSorryページにつながるよう、「web-test」というレコードに対してS3を加重0で設定します。

平常時の挙動

東京リージョンの加重を20に設定しているため、平常時はプライマリの東京側サーバーへ優先的にルーティングされます。
※大阪リージョン側も加重10で設定しているため、平常時は大阪リージョンにもルーティングされる点にご注意ください。

東京リージョン側が全台ダウンした場合

東京リージョン側のWEB1/WEB2が全台ダウンしヘルスチェックがUnhealthyとなった場合は、大阪リージョン側にのみルーティングが行われます。
S3バケットは加重0で設定されているため、この時はまだSorryページは表示されません。

東京・大阪リージョン両方のサーバーが全台ダウンした場合

東京・大阪リージョン上のWEB1/WEB2が全台ダウンし、すべてのサーバーに対するヘルスチェックがUnhealthyとなった際に、初めてS3バケットのSorryページが表示されます。

作業の流れ

作業は下記流れで行います。
長くなるため、VPC構築・Apacheの設定・S3バケットへのSorryページ設定などの事前準備手順については本記事内ではご紹介しません。
具体的な手順は別記事にてご紹介しているため、必要に応じてご参照ください。
また、各リージョンのWEBサーバーにはそれぞれテストページを配置しています。
それぞれのサーバーに配置したテストページのhtmlはこちらとなります。

WEBサーバーに配置したhtmlについて

東京・大阪上の各サーバーには下記内容のテストページを配置しています。

東京側WEB１のテストページ

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>WEB1</title>
  <style>
    body {
      font-family: Arial, sans-serif;
      margin: 20px;
      background-color: #f9f9f9;
    }
    h1 {
      color: #333;
    }
    p {
      color: #666;
    }
    a {
      color: #007BFF;
      text-decoration: none;
    }
    a:hover {
      text-decoration: underline;
    }
  </style>
</head>
<body>
  <h1>ここは東京のWEB1</h1>
  <p>これは東京のweb1。</p>
  <p>これは東京のWEB1のコンテンツ</p>
</body>
</html>

東京側WEB2のテストページ

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>WEB2</title>
  <style>
    body {
      font-family: Arial, sans-serif;
      margin: 20px;
      background-color: #d7f3e3;
    }
    h1 {
      color: #006400;
    }
    p {
      color: #228B22;
    }
    a {
      color: #006400;
      text-decoration: none;
    }
    a:hover {
      text-decoration: underline;
    }
  </style>
</head>
<body>
  <h1>ここは東京のWEB2</h1>
  <p>これは東京のweb2。</p>
  <p>これは東京のWEB2のコンテンツ</p>
</body>
</html>

大阪側WEB1のテストページ

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>WEB1 - Orange Theme</title>
  <style>
    body {
      font-family: Arial, sans-serif;
      margin: 20px;
      background-color: lightyellow;
      color: lightyellow;
    }
    h1 {
      color: darkorange;
    }
    p {
      color: orange;
    }
    a {
      color: orangered;
      text-decoration: none;
    }
    a:hover {
      text-decoration: underline;
    }
  </style>
</head>
<body>
  <h1>ここは大阪のWEB1</h1>
  <p>これは大阪のweb1。</p>
  <p>これは大阪のWEB1のコンテンツ</p>
</body>
</html>

大阪側WEB2のテストページ

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>WEB1 - Blue Theme</title>
  <style>
    body {
      font-family: Arial, sans-serif;
      margin: 20px;
      background-color: lightblue;
      color: blue;
    }
    h1 {
      color: darkblue;
    }
    p {
      color: blue;
    }
    a {
      color: navy;
      text-decoration: none;
    }
    a:hover {
      text-decoration: underline;
    }
  </style>
</head>
<body>
  <h1>ここは大阪のWEB2</h1>
  <p>これは大阪のweb2。</p>
  <p>これは大阪のWEB2のコンテンツ</p>
</body>
</html>

構築

ヘルスチェック対象のサーバーにCloudWatchAlarmを設定する

Route53のヘルスチェックはインターネット経由で行われます。
プライベートサブネット上のリソースに対してRoute53のヘルスチェックを使用する場合は、CloudWatchAlarmを設定し、CloudWatchAlarmに対してヘルスチェックを紐づけることになります。
まずは対象のリソースに対してCloudWatchAlarmを設定します。
今回は、東京・大阪上に2台ずつ存在するWEBサーバーに対してCloudWatchAlarmを設定していきます。

CloudWatchアラームのトップ画面を表示し、左メニューから「アラーム状態」を押下します。
画面上部の「アラームの作成」を押下します。

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

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

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

今回は「StatusCheckFailed_System」というメトリクスに対してアラームを設定します。
検索ボックスに「StatusCheckFailed_System」を入力しメトリクスをソートしたうえで、対象のサーバーのチェックボックスにチェックを入れ、「メトリクスの選択」を押下します。

アラーム作成画面に戻ります。
統計は「最大」、期間は「1分」を選択します。

条件を設定します。
しきい値の種類には「静的」を選択し、アラーム条件には「以上」を選択します。
しきい値には「1」と入力し、欠落データの処理には「欠落データを不正」を選択し、「次へ」を押下します。

アクションの設定画面が表示されます。
「アラーム状態トリガー」を「アラーム状態」に設定します。
SNSトピックには「既存のSNSトピックを選択」を設定し、通知先を指定します。
他の設定は変更せず「次へ」を押下します。

画面上部に、「アラームが正常に作成されました」と表示されることを確認します。
同じ要領で、東京リージョン・大阪リージョンのWEBサーバーすべてに対してCloudWatchアラームを設定します。

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

CloudWatchアラームの設定が完了したら、Route53ヘルスチェックを作成します。
Route53のサービス画面に移動し、左メニューから「ヘルスチェック」を押下します。

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

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

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

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

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

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

同じ要領で、東京・大阪リージョンのWEBサーバー全台に対してヘルスチェックを設定します。

Route53のPrivateHostedZoneにレコードを登録する

ヘルスチェックの設定が完了したら、Route53HostedZoneに対してレコードの設定を行います。
まずは東京・大阪リージョンのWEBサーバーに対する設定を行います。
左メニューから「ホストゾーン」を押下し、対象のホストゾーン名のリンクを押下します。

ホストゾーンの詳細が表示されます。
「レコードを作成」を押下します。

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

TTLを60にします。
「ルーティングポリシー」は「加重」を設定し、重量を入力します。
ヘルスチェックを紐づけ、レコードIDを入力し、「レコードを作成」を押下します。

この工程のRoute53のレコードについて、レコード名・IPアドレス・加重・TTL・ヘルスチェックは下記内容を設定しています。

レコード名	レコードタイプ	値	TTL	重量	ヘルスチェック
web-test	A	10.0.1.4（東京のWEB1のIP）	60	20	東京WEB1に対応するHealthCheckを紐づける
web-test	A	10.0.5.4(東京のWEB2のIP）	60	20	東京WEB2に対応するHealthCheckを紐づける
web-test	A	172.31.1.5(大阪のWEB1のIP）	60	10	大阪WEB1に対応するHealthCheckを紐づける
web-test	A	172.31.5.5（大阪のWEB2のIP）	60	10	大阪WEB2に対応するHealthCheckを紐づける

次に、S3バケットに対して加重0のレコード設定を行います。
Route53でS3バケットを紐づける際は、エイリアスレコードでS3のエンドポイントを指定する必要があります。
レコード作成画面で、レコードタイプを「Aレコード」にします。
「エイリアス」のチェックを入れて、トラフィックのルーティング先を「S3ウェブサイトエンドポイントへのエイリアス」に指定します。
リージョンには、S3バケットを作成時に指定したリージョンを選択します。
エンドポイント名には、「s3-website-ap-northeast-1.amazonaws.com.」と入力します。
※静的WEBサイトホスティングを有効化したS3をRoute53のレコードに紐づける場合は、S3のバケット名とRoute53のレコード名を同一の名前で作成しておく必要がある点にご注意ください。

ルーティングポリシーには「加重」を設定し、重量は「0」を入力します。
ヘルスチェックは紐づけません。レコードIDに一意のレコードIDを入力し、「レコードを作成」を押下します。

全てのレコード設定が完了した状態がこちらです。
東京リージョンのWEBサーバー2台の加重が20、大阪リージョンのWEBサーバー2台の加重が10、S3バケットの加重が10で設定されています。

動作確認

踏み台サーバーにログインし、接続確認を行ってみます。
平常状態だと、東京リージョン・大阪リージョンのサーバーに対してルーティングが行われている状態です。
踏み台サーバーからブラウザを立ち上げドメイン名を入力すると、ランダムで東京・大阪の各ページが表示されます。

digコマンドを複数回実行し、「web-test.https-demo.com」というドメイン名に対してどのIPアドレスが返ってくるか確認してみます。
下記コマンドを実行すると、digコマンドの実行結果を「RecursiveResolver_results_20241230_1.txt」というファイルに書き込みます。

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

下記コマンドを実行すると、「RecursiveResolver_results_20241230_1.txt」に書き込まれたIPを集計できます。

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

結果にばらつきはありますが、東京・大阪の各IPに対して名前解決されている状態でした。

   7436 172.31.1.5
   5000 10.0.5.4
   4990 172.31.5.5
   2574 10.0.1.4

東京リージョン側のWEB1/WEB2を停止させ、ヘルスチェックのステータスをUnhealthyにした状態で再度確認してみます。

踏み台からブラウザを立ち上げ確認してみると、今度は大阪のテストページのみが表示されます。

digコマンドで確認してみても、大阪リージョン側のIPにのみ名前解決されていることが確認できました。

for i in {1..20000}; do domain=$(dig web-test.https-demo.com. @10.0.0.2 +short); echo -e  "$domain" >> RecursiveResolver_results_20241230_2.txt; done
sort RecursiveResolver_results_20241230_2.txt | uniq -c | sort -nr
  17515 172.31.1.5
   2485 172.31.5.5

今度は東京・大阪のWEBサーバーを全台停止させ、Sorryページが表示されるか確認してみます。
Route53のヘルスチェックは全てUnhealthyの状態です。

この状態で踏み台からブラウザを立ち上げ確認してみると、S3のSorryページが確認できます。

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