Route 53のフェイルオーバールーティングポリシーやってみた

はじめに

こんにちは、omkです。
私の記念すべき100記事目の投稿です！盛り上げていきましょう！！

Route 53のフェイルオーバールーティングポリシーって設定したことありますか？
知ってるけどやってことない、って方結構多いんじゃないでしょうか。
かくいう私もそうでしたが、先日触る機会があったので記事にしてみます💪💪

前回はCloudFrontとS3でCloudFrontのオリジングループを使ったフェイルオーバーを紹介していますのでよければこちらも見ていただければです。
CloudFrontとS3で簡単フェイルオーバー

やってみた

さてさて、今回は災害対策として複数のAWSリージョンに展開されたALBがあり、通常時は東京リージョンからコンテンツを配信して障害発生時にはホットスタンバイされているバージニア北リージョンのALBから配信するようなシナリオで検証してみます。

ALB設定

前回のS3の検証と同様に、東京リージョンとバージニア北部リージョンにそれぞれALBを作成し、リージョンに対応したページを配置します。

東京には「ap-northeast-1」と書かれた赤いページ、バー北には「us-east-1」と書かれた緑のページをALBのリスナールールで固定レスポンスとして設定しました。ステータスコードは200で返すようにしています。

Route 53設定

これでコンテンツが出来たので本題のRoute 53の設定をしていきます。

まずはヘルスチェックを作成していきます。
今回はALBから提供されるDNS名に対してそれぞれのALBをヘルスチェックします。
WEBのエンドポイントに突つきに行くだけでなく、CloudWatchアラームでチェックしたり他のヘルスチェックと組み合わせたりも出来るので要件に応じて細かく設定できそうですね。

ちなみにRoute 53のヘルスチェックで利用されるIPはマネージドプレフィックスリストで公開されていますので非公開系サービスでもインターネットに面しているのであればここだけ許可すれば問題なく利用出来ます。

そうこうしている内にヘルスチェックで正常と判断されました。

あとはフェイルオーバールーティングポリシーでDNSレコードを作成していきます。
同じレコード名で東京・バー北のレコードをそれぞれ作成し、東京をプライマリ・バー北をセカンダリにしてそれぞれに対応したヘルスチェックを設定します。

これで環境の構築が完了しました。

動作確認

対象のドメインにアクセスしてみます。

正常なので東京リージョンから応答がありました。

では、東京リージョンのALBを変更して固定レスポンスで503を返すようにします。

ヘルスチェックに失敗しました。

ログに出してくれるのが分かりやすくてありがたいです。

再度アクセスするとバージニア北部のALBにフェイルオーバーしてました。

設定を戻すとヘルスチェックが正常に戻り、東京のALBにフェイルバックしました。

おわりに

リクエスト間隔を高速にして失敗しきい値3回にしていましたが、これによりダウンタイムが30秒に抑えられました。
一瞬でも……！！というのはフェイルオーバールーティングポリシーでは難しいですが比較的高速にフェイルオーバー出来て良かったです。

以上、最後までお付き合いありがとうございました。