目次
1.はじめに
2.前提
3.トラフィックフローとは
4.トラフィックフローの設定
5.ルーティング状況の確認
6.まとめ
はじめに
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」の課題カリキュラムで作成しました。