LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@tonkatsu_oishiin株式会社BeeX

Route53PrivateHostedZone内でマルチリージョンのDNSフェイルオーバー（Active-Active）を設定

Last updated at Posted at 2025-01-23

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

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

構成の確認

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

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

NW構成の確認

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

Route53設定の確認

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

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

image.png

平常時の挙動

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

image.png

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

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

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

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

image.png

作業の流れ

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

1.東京リージョン側作業

VPCの作成
EC2（踏み台サーバー、WEBサーバーなど）の構築
EC2にApacheをインストールする

2.大阪リージョン側作業

VPCの作成
EC2（踏み台サーバー、WEBサーバーなど）の構築
EC2にApacheをインストールする

3.東京・大阪側共通作業

東京リージョン・大阪リージョンのVPCをVPCピアリングで接続する
S3バケットの静的WEBサイトホスティングを有効化し、Sorryページを表示する
Route53のPrivateHostedZoneを作成し、各VPCに紐づける
各VPCの設定でDNSホスト名、DNS名前解決を有効化する
ヘルスチェック対象のサーバーにCloudWatchAlarmを設定する
Route53のヘルスチェックを作成する
Route53のPrivateHostedZoneにレコードを登録する
動作確認

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アラームのトップ画面を表示し、左メニューから「アラーム状態」を押下します。
画面上部の「アラームの作成」を押下します。
image.png
アラームの作成画面が表示されます。「メトリクスの選択」を押下します。
image.png
メトリクスの選択画面が表示されます。
「EC2」を押下します。
image.png
「インスタンス別メトリクス」を押下します。
image.png
今回は「StatusCheckFailed_System」というメトリクスに対してアラームを設定します。
検索ボックスに「StatusCheckFailed_System」を入力しメトリクスをソートしたうえで、対象のサーバーのチェックボックスにチェックを入れ、「メトリクスの選択」を押下します。
image.png
アラーム作成画面に戻ります。
統計は「最大」、期間は「1分」を選択します。

image.png
条件を設定します。
しきい値の種類には「静的」を選択し、アラーム条件には「以上」を選択します。
しきい値には「1」と入力し、欠落データの処理には「欠落データを不正」を選択し、「次へ」を押下します。
image.png
アクションの設定画面が表示されます。
「アラーム状態トリガー」を「アラーム状態」に設定します。
SNSトピックには「既存のSNSトピックを選択」を設定し、通知先を指定します。
他の設定は変更せず「次へ」を押下します。
image.png
画面上部に、「アラームが正常に作成されました」と表示されることを確認します。
同じ要領で、東京リージョン・大阪リージョンのWEBサーバーすべてに対してCloudWatchアラームを設定します。
image.png

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

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

image.png

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

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

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

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

「ヘルスチェックの作成に成功しました」と表示されます。
image.png
画面を更新すると、作成したヘルスチェックが確認できるようになります。
image.png
同じ要領で、東京・大阪リージョンのWEBサーバー全台に対してヘルスチェックを設定します。

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

ヘルスチェックの設定が完了したら、Route53HostedZoneに対してレコードの設定を行います。
まずは東京・大阪リージョンのWEBサーバーに対する設定を行います。
左メニューから「ホストゾーン」を押下し、対象のホストゾーン名のリンクを押下します。
image.png
ホストゾーンの詳細が表示されます。
「レコードを作成」を押下します。
image.png
レコード作成画面が表示されます。
レコード名に「web-test」と入力し、レコードタイプは「A」とします。
値は「10.0.5.4」を入力します。
image.png
TTLを60にします。
「ルーティングポリシー」は「加重」を設定し、重量を入力します。
ヘルスチェックを紐づけ、レコードIDを入力し、「レコードを作成」を押下します。
image.png

この工程の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のレコード名を同一の名前で作成しておく必要がある点にご注意ください。
image.png
ルーティングポリシーには「加重」を設定し、重量は「0」を入力します。
ヘルスチェックは紐づけません。レコードIDに一意のレコードIDを入力し、「レコードを作成」を押下します。

image.png

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

動作確認

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

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にした状態で再度確認してみます。
image.png

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

image.png

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の状態です。
image.png

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

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

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?