はじめに

Route53とはAWSで提供されているDNSサービスであり、ユーザからのリクエスト通信でドメイン名とIPアドレスの変換を行った上、効率的に通信先のインフラストラクチャにルーティングをします。ルーティングの方法としていくつか種類がありますので、以下の表にまとめますが、複数のルーティングポリシーを組み合わせる等、複雑なルーティングを実装する場合は設定や管理が煩雑になります。そこで今回、「トラフィックフロー」という複雑なルーティングの設定/管理をサポートする機能を使ってみましたので、概要と設定の流れを簡単に整理します。

項番	ルーティングポリシー	内容
1	シンプルルーティング	単一のリソースへトラフィックをルーティングする
2	フェイルオーバールーティング	プライマリとセカンダリでリソースを指定し、プライマリのリソースが正常でない場合はセカンダリへトラフィックをルーティングする
3	位置情報ルーティング	ユーザの地理的場所(DNSクエリの送信元の場所)に基づいて、リソースを選択し、ルーティングする
4	地理的近接性ルーティング	ユーザ(DNSクエリの送信元)とリソースの地理的場所に基づいて、トラフィックをルーティングする ※トラフィックフローの機能を用いる必要がある
5	レイテンシールーティング	複数のAWSリージョンでアプリケーションがホストされている場合、ネットワークレイテンシーが最も低いAWSリージョンに基づいて、トラフィックをルーティングする
6	複数値回答ルーティング	ルーティング先として複数のリソースを設定できる(最大8つ) ※各リソースに対して、正常かどうかの確認をし、正常なリソースに対してルーティングする
7	加重ルーティング	ルーティング先として複数のリソースを設定し、各リソースへのルーティングの割合を指定してトラフィックを分散させる

前提

今回は上表にある項番2「フェイルオーバールーティング」と項番7「加重ルーティング」をトラフィックフロー機能を用いて、組み合わせてみました。トラフィックフローを設定する上で構築したAWS構成は以下の通りとなります。

構築における補足は次の通りです。

無料で使用できるドメインプロバイダ「Freenom」で独自ドメイン「aws-uni.ga」を取得しました。
Freenomのマイドメイン管理画面でNameServerにAWS Route53のDNSサーバを指定しました。
フェイルオーバールーティングで、通常時はALBへトラフィックをルーティングし、EC2インスタンスからWebページを返します。
フェイルオーバールーティングで、EC2インスタンス障害時等はS3バケットに保存されたSorryページを返します。
S3バケットでは静的Webサイトホスティング機能の有効化、読み取り専用のバケットポリシーを設定しました。
加重ルーティングを使用し、通常時のトラフィックを2つのVPCに7:3の割合で分散します。
構築したVPC/サブネット/EC2インスタンス/ALB/S3バケット/Route53の基本設定をまとめます。

■ VPC

■サブネット

■EC2インスタンス

■ALB

■S3 　

■Route53
Freenomで取得したドメイン「aws-uni.ga」に対するパブリックホストゾーンの作成

上記のような構成のもと、トラフィックフローを設定していきましたので、以降、概要と設定の流れをまとめておきたいと思います。

トラフィックフローとは

Route53でのDNSレコード設定について、レイテンシー、フェイルオーバー、加重などの複数のルーティングポリシーを組み合わせて使用する場合、複雑な階層構造となり、レコードの管理が難しくなることがあります。このような複雑なルーティングのサポートをしてくれるのがトラフィックフローであり、主に次のような機能を提供します。

ビジュアルエディタ

トラフィックフロービジュアルエディタを使用すると、簡単なGUI操作でレコードの複雑な階層構造をトラフィックポリシーとして定義し、レコード間の関係を視覚的に管理することができます。また、トラフィックポリシーの作成数に上限はありません。

バージョニング

作成したトラフィックポリシーはバージョン管理をすることができます。そのため、ポリシーに変更が発生した際も最初から作成し直す必要もありません。また、デフォルトでは1つのトラフィックポリシーに対し、1000バージョンまで管理することができます。

地理的近接性ルーティングポリシー

Route53の地理的近接性ポリシーはトラフィックフローを使用する場合のみに使用できます。

※AWS公式によると、トラフィックフローの料金は「50.00USDポリシー記録ごと/月」でした。割と高めの料金かなと思いますので、設定した場合、不要であれば削除を忘れないようにしましょう。

トラフィックフローの設定

それでは、「前提」で記載したAWS構成を構築するにあたり、トラフィックフローの設定の流れをまとめていきます。

Route53の管理画面から「トラフィックポリシー」を押下します。
「トラフィックポリシーの作成」を押下します。
「ポリシー名」と適宜「バージョンの説明」を入力し、「次へ」を押下します。
次のようなエディタ画面が表示されます。DNSタイプはいくつかの選択肢から選べますが、今回はAレコードを指定します。
「＋...に接続」を押下します。
「フェイルオーバールール」を選択します。
プライマリとセカンダリに分岐されるので、プライマリの方で「加重ルール」を選択します。
分散させるウェイトを入力した上で、加重70%の方の「新しいエンドポイント」を選択します。
様々なエンドポイントを指定できますが、今回は「ELB Applicationロードバランサー」を選択します。
既に作成済のALBを指定します。
同様の手順で加重30%の方のエンドポイントも指定します。
続いて、フェールオーバールーティングのセカンダリの方のエンドポイントとして「S3ウェブサイトエンドポイント」を選択します。
「値」の欄で既に作成済のS3バケットを指定します。
トラフィックフローの全体図を作成できましたので、右下の「トラフィックポリシーの作成」を押下します。
トラフィックポリシーがバージョン番号1として作成されましたので、続いて「ポリシーレコードの作成」を押下します。
「ホストゾーン」にFreenomで取得したドメイン名を入力、またポリシーレコードDNS名を入力し、「ポリシーレコードの作成」を押下します。
ポリシーレコードが作成されたことを確認します。

以上により、ポリシーレコードDNS名「blog.aws-uni.ga」を用いたフェイルオーバールーティング、加重ルーティングの組み合わせをトラフィックフローによって設定することができました。

ルーティング状況の確認

最後に、上記で設定したルーティング状況の確認をしてみます。

加重ルーティング

ブラウザにて「blog.aws-uni.ga」で接続したところ、2つのVPCへトラフィックが分散され、EC2インスタンス内のWebページが表示されることを確認できました。
○加重70%の方のEC2インスタンスから返されたWebページ


○加重30%の方のEC2インスタンスから返されたWebページ

フェイルオーバールーティング

「前提」で記載した構成図上のEC2インスタンス4台を全て停止し、擬似的な障害を発生させた上で、ブラウザにて「blog.aws-uni.ga」で接続したところ、S3バケットに格納したSorryページが表示されることを確認できました。

まとめ

以上より、Route53のトラフィックフローを使用して、フェイルオーバールーティングと加重ルーティングの組み合わせを体験してみました。ルーティングポリシーの連携を簡単なGUI操作で設定でき、かつ視覚的にも管理できるため、非常に便利でした。

また今回はトラフィックフローの概要、設定にフォーカスをあてた為、以下の点については妥協しておりますので、また別の記事としてまとめていけたらなと思います。

フェイルオーバールーティングのプライマリから返されるWebページが静的であり、S3バケットに格納したSorryページと同等なものがレスポンスされている。
⇨今後、オリジナルアプリを作成し、EC2インスタンスへのデプロイを試したいなと思っています。
HTTPS通信での暗号化
加重ルーティングのBlue/Greenデプロイメントでの利用。 Elastic Beanstalk やCodePipeline 等を組み合わせたBlue/Greenデプロイメント環境の構築も面白そうです。

以上、最後まで読んで頂きありがとうございました！

※この記事はAWS初学者を導く体系的な動画学習サービス「AWS CloudTech」の課題カリキュラムで作成しました。

Route53 トラフィックフローでルーティングポリシーを組み合わせてみた

目次