Amazon Route 53のルーティングがすごすぎる件

はじめに

ルーティングとは経路制御の事を指します。前回、負荷分散装置の勉強をしている際にAWSのDNSラウンドロビンが俗にいうDNSラウンドロビンと比較してヘルスチェックを始めとして様々な機能があって凄すぎたので今回深堀りすることにしてみました。

DNSラウンドロビンの説明についてはこちらの記事になります　→ https://zenn.dev/seyama/articles/532abc66d5d72d

Route53のルーティングポリシーの種類

公式を調べてると下記のように多彩なものが用意されています。 公式ドキュメント

ポリシーの種類	公式ドキュメントの説明	調査した結果の個人的感想
シンプルルーティングポリシー	ドメインで特定の機能を実行する単一のリソースがある場合に使用します。たとえば、example.com ウェブサイトにコンテンツを提供する 1 つのウェブサーバーなどです。	これは一般的なDNSの設定になります。
フェイルオーバールーティングポリシー	アクティブ/パッシブフェイルオーバーを構成する場合に使用します。	こちらはアクティブ側がヘルスチェックによって死んだ場合、セカンダリに割り振られるので負荷分散というより、BCP対策やサイトが回線不通などによって不通になってしまった場合のsorryページ表示サーバに割り当てるなどが考えられました。普段は1:0で運用したい時に最適だと思います。
位置情報ルーティングポリシー	ユーザーの位置に基づいてトラフィックをルーティングする場合に使用します。	こちらは位置情報といっても大陸、国、アメリカでは州レベルになるので日本においてはあまり使うシーンが思いつきませんでした。グローバル展開される場合はかなり使い勝手が良いと思います。ただ、レイテンシールーティングなどの方が優れている気がします。
地理的近接性ルーティングポリシー	リソースの場所に基づいてトラフィックをルーティングし、必要に応じてトラフィックをある場所のリソースから別の場所のリソースに移動する場合に使用します。	今回は調査しませんでした。
レイテンシールーティングポリシー	複数の AWS リージョンにリソースがあり、レイテンシーの最も小さいリージョンにトラフィックをルーティングする場合に使用します。	こちらはAWSを使用しているならとてもいいかもしれません。AWSのリージョンまでのネットワークレイテンシーを割り出してレコードを返してくれます。日本では東京と大阪にリージョンがあるので、どちらも使う場合は是非使ってみたい機能です。
複数値回答ルーティングポリシー	ランダムに選ばれた最大 8 つの正常なレコードを使用して Route 53 が DNS クエリに応答する場合に使用します。	こちらは普通のDNSラウンドロビンにヘルスチェックがつくようなイメージになります。
加重ルーティングポリシー	指定した比率で複数のリソースにトラフィックをルーティングする場合に使用します。	加重を設定して単一の結果を返す事が出来ます。通常の負荷分散はもちろんカナリアリリースやなど色々使えると思います。

ルーティングの詳細について

下記からそれぞれのルーティングについて調査したものを書いていきたいと思います。BCPは今ホットな話題でもあるので、特にフェイルオーバールーティングポリシーや加重ルーティングは覚えておいて、色々なところで使っていくチャンスはあるな。と思いました。

シンプルルーティング

ここでポリシーを選択することができます。シンプルは本当にシンプルなので調査から省きます。

フェイルオーバールーティングポリシー

プライマリとセカンダリを一つずつ設定することができます。フェイルオーバーポリシーを作成するにはまず、ヘルスチェックのルールを作成する必要があります。

下記のようにヘルスチェックに欲しい機能がほぼ揃ってます。
例えば

• エンドポイントの監視、AWSを対象とした場合はCloudWatchのアラーム
• ヘルスチェックの間隔
• 失敗しきい値
• 文字列マッチング（ステータスコード以外でのチェックもできる）
  といった感じで機能モリモリです。
  また、Aレコードに複数IP書くことも可能なようです。
  
  今回のテスト用に２つ作成します。
  作成して暫く経つとステータスが正常になります。
  
  フェイルセーフを作成した後にレコードを作成していきます。
  まずはプライマリから設定し、作成後にセカンダリも登録します。
  
  作成されると下記のようにプライマリ、セカンダリが設定されます。
  
  試しにcurl叩いてみると無事にプライマリで設定したシステムが返ってきます！！
  
  digの結果もこんな感じでプライマリに設定した通りのものが返ってきます。
  
  次にプライマリのヘルスチェックを失敗させるためにGAEのサービスを停止してみます。
  サービスを停止すると無事ヘルスチェックで異常が検知されます。
  
  検知されるとDNSがセカンダリに切り替わり、curlやdigの結果もセカンダリに設定したものに変わります。
  dig
  
  すごい！

位置情報ルーティングポリシー

接続元の地域によって返却するIPを指定する事が出来ます。AP近くのサーバーを返すことが出来、安定したレイテンシを確保しやすいと思います。
とても良い！と思いましたが規模がグローバルすぎてグローバル展開するサービスしか使う価値はないと思いましたが、念の為使用感を調査してみました。
下記のようにルーティングポリシーを選択すると場所を選択することが出来ます。
これを選択することによってクライアントの場所に近い地域の設定を返すことが出来ます。
また、Aレコードに複数IP書くことも可能なようです。

設定を日本、米国にしてみました。

なお、マニュアルによるとクライアントの地域を割り出すのはこのような方法になっているらしいです。

ブラウザまたは他のビューアが edns-client-subnet をサポートしない DNS リゾルバーを使用している場合、
Route 53 は DNS リゾルバーのソース IP アドレスを使ってユーザーの場所を近似し、位置情報クエリに対してリゾルバーの場所の DNS レコードを使って応答します。

日本からだと日本で設定したIPが返却されます。

アメリカから名前解決した場合、アメリカで設定したIPが返却されます。

注意点

位置を指定した場合、その位置以外からの問い合わせには答えられなくなってしまう模様。
位置を日本→韓国にすると名前解決できなくなりました。

それを防ぐためにはデフォルトを用意しておくといいみたいです。


デフォルトを指定しておくと、日本からの名前解決も可能になりました。

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

トラッフィクポリシーでしか使えないようなのでまた別途調査したいと思います。また、位置情報と同じようにグローバルレベルのようです。

レイテンシールーティングポリシー

こちらに関しては問い合わせ地点から設定したAWSのリージョンへのネットワークレイテンシーを計測し、一番近いところを返す機能の模様。つまり、こちらに関してはAWSを使用していないシステムへの振り分けにはあまり向いていないといえると思います。
また、Aレコードに複数IP書くことも可能なようです。
AWSを使用していなくても設定することは出来るが、あくまでAWSのリージョンへのネットワークレイテンシーを測った結果になるので実際との差異が発生してしまう。
公式の記事にはこのように記載されています。

たとえば、米国西部 (オレゴン) リージョンと アジアパシフィック (シンガポール) リージョンに ELB ロードバランサーがあるとします。あなたは各ロードバランサ―のレイテンシーレコードを作成しました。ロンドンのユーザーがブラウザにあなたのドメイン名を入力した場合は次のようになります。

DNS がクエリを Route 53 ネームサーバーにルーティングします。

Route 53 は、ロンドンとシンガポールリージョン間のレイテンシーおよびロンドンとオレゴンリージョン間のレイテンシーに基づいて、そのリクエストのデータを参照します。

ロンドンとオレゴンリージョン間のレイテンシーのほうが低い場合、Route 53 はオレゴンのロードバランサーの IP アドレスとともにクエリを返します。ロンドンとシンガポールリージョン間のレイテンシーのほうが低い場合、Route 53 はシンガポールのロードバランサーの IP アドレスとともにクエリを返します。

実際に設定してみます。
一方には東京、一方には大阪を選択します。


このような形で２つ出来上がります。

実際にdigを打ってみると大阪からだと大阪リージョンで設定したものが返ってきます。
東京リージョンの中の端末からだと東京で設定したものが返ってきます。
東京の設定を消すと、、東京の端末でdigしても大阪で設定したレコードが返ってきます。
AWSを使ってるなら結構使えそうです。

複数値回答ルーティングポリシー

複数回答ルーティングはその名の通り、複数値を問い合わせ元に返せる設定です。
それぞれのレコードで返せるIPは単一かつCNAMEは使えないっぽい。
一般的なDNSラウンドロビンにヘルスチェックがついた印象を持ちました。
一度に返せるIPは８つまでとなっています。
ただし、登録できるIPは8つ以上も可能になっています。8つ以上登録された場合はヘルスチェックで検証された正常なレコードをランダムに8つ返すようです。

上記のような設定を２レコードすると下記のようになります。

この状態でdigをするとこんな感じで複数値返ってきます。
つまり２レコードをマージして複数値返してくれます。

例えば、一方にヘルスチェックを仕込み、サービスを止めてみます。

すると、ヘルスチェックで失敗している方のレコードが複数値から消えます。

公式によると注意点は下記のようです。

ヘルスチェックを複数値回答のレコードと関連付けている場合、Route 53 はヘルスチェックの結果が正常である場合にのみ DNS クエリに対応する IP アドレスを返します。
ヘルスチェックを複数値回答レコードと関連付けない場合、Route 53 は常にレコードを正常であるとみなします。
8 つ以下の正常なレコードがある場合、Route 53 はすべての DNS クエリに正常なすべてのレコードを返します。
すべてのレコードが異常である場合、Route 53 は DNS クエリに最大 8 つの異常なレコードを返します。

8つ以上登録した場合

下記のように9つ登録してみました。

digでは下記のようにランダムに8つの正常なIPが返却されます。登録されたものから211以外が返ってることがわかると思います。ある時は212が抜けるいった形でランダムのようです。

加重ルーティングポリシー

加重ルーティングポリシーとはその名の通り、複数のリソースを関連付け、加重をつけてルーティングさせることができます。負荷分散はもちろんカナリアリリースなど様々な用途で使えると思います。
加重ルーティングの割り当てられる計算は下記になります。

レコードの重み / 全てのレコードの重みの合計

例えば、サーバーAに10、サーバーBに30と設定した場合、サーバーAには1/4のトラッフィクが行くこととなります。
なお、リソースへのトラフィックを停止する場合はレコードの重みを0にすると停止できます。
下記のように加重ルーティングを選択することで使用することが出来ます。


このような設定でdigのリクエストを送ると大体、加重の通り、サーバーAは1/4くらいでサーバーBのアドレスは3/4くらいのIPが返ってきました。

また、加重を0にすると全くIPが返ってこなくなりました。カナリアリリースなど色々使用することができると思います。