「AWS Black Belt Tech Webinar 2014 – Amazon Route 53」レポート

こんにちは、虎塚です。

2014年9月24日(水)の夕方、「AWS Black Belt Tech Webinar 2014 - Amazon Route 53」を聴講しましたので、少し遅くなりましたがレポートします。

講師は、アマゾンデータサービスジャパンの荒木さんです。

• Webinarスライド: AWS Black Belt Techシリーズ Amazon Route53

Amazon Route 53への2014年の機能追加は、現在までに4件あるそうです。

• 2014年2月: HTTPSでのヘルスチェックサポート
• 2014年3月: CloudTrailサポート
• 2014年5月: ドメイン名でのヘルスチェックサポート
• 2014年8月: ドメイン登録サポート、Geo DNSルーティング

• 参考: Amazon Web Services ブログ: Amazon Route53

アジェンダ

• Amazon Route 53とは？
• ヘルスチェック機能
• Geo DNS
• ドメイン登録機能
• コスト
• まとめ
• Q＆A

Amazon Route 53とは？

• フルマネージドのDNSサービス
• AWSの各種サービス中、現時点で唯一のSLA 100%で提供
• 高い拡張性
• 「Route 53」の名前の由来は、DNSがポート53番で動作するから

動作

• ユーザがDNS Resolverに「www.example.com」がどこかを問い合わせる
• DNS Resolverは答えを知らないので権威サーバに問い合わせる
  • Route 53は権威サーバとしての役割を持つ。ユーザが直接参照するわけではない。
  • Route 53の直接のユーザはDNS Resolver
• 権威サーバがDNS ResolverにIPアドレスを返す
• DNS ResolverがユーザにIPアドレスを返す

Route 53の特徴的な機能

• 高可用性DNS
• エイリアスレコード
  • www.example.comとexample.comを一体として扱うための工夫を提供
• DNSフェイルオーバー
  • 訪問者のトラフィックを自動的に別の場所にルーティング
• 重みづけラウンドロビン
  • それぞれに頻度を定義して、異なるレスポンスを使える
• ルーティングカスタマイズ
  • レイテンシ、Geo DNSを使った誘導
• CloudWatchメトリックス
  • ヘルスチェックの結果をCloudWatchに投げる
  • （例）Route 53に停まっているサーバを検出させて、恒久的に外すことができる

Route 53を使用しない時の動作

BINDなどで自分でDNSサーバを立てている場合を考える。エンドユーザが使っているDNSサーバから、自分で立てたDNSサーバへ、世界中からアクセスがくる。

東京のエンドユーザが、東京のDNSサーバに問い合わせをすると、高速にresolveできる。しかし、ヨーロッパのエンドユーザが、東京のDNSサーバに問い合わせた場合、平気で1秒くらいかかってしまう。

Route 53使用時の動作

エンドユーザは、近いエッジロケーションに対してDNSのlookupをする。そのため、非常に高速。

これが実現できるのは、Anycast IPアドレスが使用されるため。同じIPアドレスで動いているサーバが、世界中にある。エッジロケーションが世界に53ヶ所ほどあり、それぞれの場所でも複数台のサーバが動いている。

DNS(Route 53)

1. クライアントからローカルのDNSに問い合わせ（example.com）
2. root DNSに問い合わせ
   • .comのアドレス情報を持つDNSを教えてもらう
3. .comのDNSに問い合わせ
   • example.comをホストしているサーバのIPアドレスをもらう
   • ここでは通常4つのIPアドレスが登録されている。4つのサーバで同じ情報が同期されている
4. example.comのDNSに問い合わせ
   • IP Anycastで見に行き、一番近くで動いているエッジロケーション上のサーバにアクセスする
   • レスポンスでexample.comのIPアドレスが返る

ホストゾーンとレコード

Route 53では、DNSの参照情報をホストゾーンとレコードセットとして提供する。

ホストゾーン

管理可能なレコードの集合。ドメインが異なるとレコードを分けなければならない

1ユーザあたり100個までゾーン（ドメイン）を登録できる

10000個までレコード（ホスト）を登録できる（これは上限緩和できる）

レコードセットには5つのルーティグポリシーを設定できる。

• Simple
• Weighted: 重みづけ
  • 100回のトラフィック中、10回はこちら、90回はあちら、と振り分けられる
• Latency: レイテンシーベースルーティング
  • レイテンシを計測して、実際に近い方に誘導する
• Geo: Geo DNSによるルーティング
  • 実際にかかったレイテンシーではなく、ポリシーで管理できる
  • （例）著作権保護などの目的で、日本からのアクセスにだけIPアドレスを返すことが可能

サポートするレコードタイプ

• A
• AAAA
• CNAME
• MX
• NS
• PTR
• SOA
• SPF
• SRV
• TXT

Route 53の始め方

たった5つのステップで始められる。

1. サインアップ
2. ドメインの購入
3. ホストゾーンを作成
4. DNSレコードを作成
5. ドメインレジストラにRoute 53のネームサーバを登録

ゾーンファイルのインポート手順

すでに動かしているDNSがあるなら、ゾーンファイルをRoute 53にインポートできる。ただし、ゾーンファイルを丸ごとインポートするため、RFC1034, RFC1035に準拠したゾーンファイルでなければならない。

インポートする前にホストゾーンを作成する。インポート先のホストゾーンは、自動的に作成されるSOA、NS以外は空の状態でなければインポートできないので注意する。

ゾーンファイル詳細

• ホストゾーン名とレコードに含まれるドメイン名を一致させる
• インポート元のゾーンファイルの$ORIGIN, $TTLキーワードをサポートする
• $GENERATE, $INCLUDEキーワードはインポートエラー
  • 最近（10数年前）に追加されたキーワード。DHCPでホストを並べるときに大量のエントリを並べる必要がないように、GENERATEを使ったりする。
  • インポートでは未サポートなので、1つ1つ追加する必要がある。もちろん、APIを使ってプログラムでループし、エントリを生成してもよい。
• インポート元のゾーンファイルのSOAレコードは無視される
• ホストゾーンと同じドメイン名のNSレコードは無視される
• インポートでは最大1000レコードまで。それ以上は手動で
  • ツールあります: BIND to Amazon Route 53 Conversion Tool

ゾーンアペックスの扱い

「エイリアス」タイプは、AWSの独自レコード。ELB、S3のWebサイト用バケット、CloudFrontのディストリビューションのDNS名を、ドメインだけの形にして割り当てるために使う。

これを使うことで、ルートドメイン（例: http://example.com）でWebサイトをホストできる。

ルートドメインへのクエリが課金されなくてよいように、上記（ELB、S3のWebサイト用バケット、CloudFrontのディストリビューション）にマッピングされたエイリアスレコードへのクエリは無料になっている。

重みづけラウンドロビン（WRR）

同じ名前と種類のレコードセットから、クエリーに返すレコードセットを選択する。

レコードセットの重み / 同じ名前・種類のレコードセットの重みの合計

• 重みは0〜255の間で設定する
  • Weight=10というレコードセットがあるとき、別のレコードに10と設定すると、重みの配分は1:1になる
  • 特定の1レコードにすべてのトラフィックを誘導したいときは、レコード1つにだけ数字を残して、あとは全部0にすれば、0にしたものへのルーティングが停止される

レイテンシベースルーティング（LBR）

ユーザからのアクセスを、レイテンシー最小のエンドポイントに誘導する。レイテンシを計測した結果を使うのが特徴。複数リージョンでアプリケーションを動作させる場合に利用する。

LBRレコードを作成し、どのリージョンでエンドポイントを動作させているか記述する。エンドポイントには、EC2のインスタンス、EIP、ELBを指定する。

特定のIPアドレスに近いと思われるアドレスを、あらかじめ手動で書いておく。すると、Route 53が推測するリージョンに近いと思われる方へ誘導する。

Geo DNS

ユーザからのアクセスを、東京のユーザは東京に、シンガポールのユーザはシンガポールに……というように誘導する。計測結果ではなく、ルールで誘導するのが特徴。クライアントが使うDNSサーバのIPアドレスから位置情報を推測する。ロケーションごとに緩く設定できる。

Q: 東京ユーザがシンガポールにVPNで接続するとどうなるの？

A: DNSまではVPNに入ってない場合が多いので、その場合は東京に誘導されます。

ヘルスチェック機能

DNSフェイルオーバーとは？

ヘルスチェック

アプリケーションのエンドポイントのup/downwを、世界中のAWSのリージョンからチェックしている

たとえば、東京にアプリケーションを1つ立ち上げて観測対象にすると、合計8つのリージョンからそれぞれ最低2つのIPアドレスで（つまり合計16個のIPアドレスから）、動いているかをチェックされる

フェイルオーバー

到達できるリソースだけを返答する

ダウンを検出したら、ユーザをリダイレクトする

DNSフェイルオーバー: 用語解説

エンドポイント

インターネット上のロケーション。インターネット上からリーチできる場所ならどこでもOK

IPアドレス、URL、またはELB名で指定

ヘルスチェック

Route 53のコンソール、またはAPIで作成できる

チェック結果によってHealthy、またはUnhealthyというステータスを持つ

単純フェイルオーバー

ヘルスチェックを使って、単純なフェイルオーバーができる。

プライマリにEC2、セカンダリにS3のWebサイトがあるとする。EC2がアクセス過多で落ちたり、メンテナンスでhttpdを停めたりすると、ヘルスチェックの状態がUnhealthyになり、S3に誘導される。

マルチリージョンフェイルオーバー

リージョンを2つ使い、それぞれをレイテンシベースルーティング（LBR）で両方Activeにしておく。アクセスは両方に振り分けられ、ユーザにより近い方へ誘導される。

片方のサーバを停めるとヘルスチェックがUnhealthyになり、LBRがInACtiveになる。

DNSフェイルオーバーの動き

DNSフェイルオーバーのタイムラグを認識しておく必要がある。

1. AWS各リージョンからヘルスチェックを実施する（前述）
   • Route 53は、指定したエンドポイントに要求を送信。成功応答を受け取るとヘルスチェック成功、さもなければ失敗
2. ヘルスチェックが失敗したら、関連づけられたDNSレコードがInactiveになり、バックアップとして構成されたレコードがActiveになる
   • ヘルスチェック対象のエンドポイントがfailしてからDNSフェイルオーバーまで3分程度

ヘルスチェックの内容

• ヘルスチェックを追加した瞬間、最初は「Healthy」と推定する
• データセンターのヘルスチェッカーが、デフォルト30秒ごとにエンドポイントにリクエスト送信
• ヘルスチェックが失敗すると「Unhealthy」に変更
• ヘルスチェックが成功すると「Healthy」に変更

各データセンターにあるヘルスチェッカーは、全世界のRoute 53 DNSサーバに、ヘルスチェック結果を伝搬する。

ヘルスチェックグラフ

上記のおおざっぱなヘルスチェックの結果は、CloudWatchにパブリッシュされる。Management ConsoleのRoute 53タブでグラフ表示できる。

• グラフ縦軸の1の水平線は、正しく動作している状態を示す
• 0は、すべてのリージョンからのアクセスが失敗している状態を示す

フェイルオーバー利用時の連鎖的障害の回避

• 全部のレコードセットがUnhealthyのときは、Route 53は逆にすべてをHealthyとみなす
  • ユーザのリクエストがシャットアウトされる状態を避けるため
• （例）3つのエンドポイントの1つが停止すると、残り2つにリクエストを割り振る。万が一、残りの2つも停止したときは、3つのエンドポイントすべてにリクエストを割り振る状態に復帰する

フェイルオーバー利用時のインターネット切断時への対応

Route 53の各ロケーションが、エンドポイントのヘルスチェックについて、異なるステータスを持つ場合がある。各地域からのアクセス可能性に応じて、レコードを応答する。

たとえば、南米への接続が切断された場合。

• サンパウロのヘルスチェッカーは、自リージョン内のエンドポイントををHealthyとみなす
• サンパウロのRoute 53 DNSサーバは、自リージョン内のエンドポイントのレコードを返す
• 米国東海岸のヘルスチェッカーは、サンパウロリージョン内のエンドポイントをUnhealthyとみなす
• 米国東海岸のRoute 53 DNSサーバは、サンパウロリージョン以外のエンドポイントのレコードを返す

結果として、サンパウロリージョン内の接続は生きているが外部への接続は死んでいる場合、サンパウロの住人は海外との通信をしない限り、自リージョン内で問題なくアクセスできる。その他の地域の住人はサンパウロ以外のリージョンを使うことで、こちらも問題なく使い続けることができる。

対象プロトコル

• TCPのポート番号向け
• HTTP/HTTPS向け
  • HTTPステータスコード200以上400未満を正常と判断

対象先およびレスポンス指定

• ドメイン指定
• 文字列マッピング
  • 独自のヘルスチェック用ページを用意して、特定の文字列をマッチする。ページ先頭から5KB以内に、最大255文字で記述する
  • アプリケーション開発者が自分のサービスを停止したい時、HTTPのレスポンスまで制御しなければならないのは面倒な場合がある。この方法によって、アプリケーションレイヤーで制御できる

対象間隔

ヘルスチェック間隔

10秒間隔を選択可能（これまでは30秒間隔固定だった）

失敗回数しきい値

1〜10回の間で選択可能（これまでは3回固定だった）

上記のように細かい指定ができるようになったことで、フェイルオーバー時間を制御可能になった。

フェイルオーバー時間 = TTL + ( 間隔 * 失敗回数しきい値 )

その他管理機能

• ヘルスチェック設定は後から編集できる
  • 従来は新規作成/削除しかできなかった
• ヘルスチェック設定にタグ付けができる
  • どのヘルスチェックかが分かりやすい
  • 特に、APIで扱う際に便利

Geo DNS

Geo DNSの設定

• ［Routing Policy］で「Geoolocation」を選択する
• どこまで細かい設定ができるか: 大陸名、国名、アメリカの州、カナダの州。タヒチなどの一部の飛び地は、国名とは別に指定できる

Geo DNS設定Tips

• デフォルトを必ず指定する
  • 指定しないと、マッチするものがないときにクエリが返らない
  • （例）Geo DNSでJapanと設定して、デフォルトを設定しなかった場合、他の地域からアクセスしたユーザにクエリが返らない
  • 「（この地域からのアクセスは）サポートしません」といったページを用意した方がよい
• レコードタイプを統一する必要がある
  • （例）AWS内のサーバもAWS外のサーバもGeo DNSに入れられる。そこで、中国やベトナムからのアクセスは（AWS外の）現地で動いているサーバに誘導するためVPSのCNAMEで指定し、日本からのアクセスはAWS内のサーバに誘導するためAレコードで指定する、といったことはできない
• Aliasを使うと余計なクエリが不要になるので高速化する

ドメイン登録機能

ドメインをRoute 53で購入して設定できる。このサービスは、ドメインレジストラとAWSが提携することで提供されている。

ドメインの選択

ドメイン候補を入力すると、取得可能/不可能なドメイン名が表示される。取得可能なドメイン名は、価格も表示される。

• 今のところ1年単位でしか買えない
• ドメインごとに値段が異なる
• 提供価格は最安に近いと思うが、保証はしていない
  • Route 53でドメインを買うかどうかは自己判断で

登録者の情報入力

連絡先を必ず入力する。

プライバシー保護機能を「Yes」にすると、ドメインをwhoisで引かれた時に、ドメインレジストラが設定したアドレスが表示される。プライバシーガードと一般に呼ばれる同等の機能を提供する他社と比べると、AWSの価格は安い。

ドメイン移管はドメイン名を入れるだけ

ドメイン名を入力するだけで、ドメインの移管ができる。

ただ、移管時には移管元のドメインレジストラでもするべき作業があるはずなので、忘れずに実施すること。

コスト

Amazon Route 53の料金

• Amazon Route 53 料金表
• ホストゾーンあたりの料金
  • 大量の利用に対してディスカウントが効く
  • 25ホストゾーンを超える場合、25ホストゾーンまでの値段の5分の1になる
• クエリあたりの料金
  • 最初の10億クエリは安い高い（最初の10億クエリを超えた後は約半額になる）

標準でないクエリは値段が異なる。

• レイテンシーベースルーティングのクエリ
• Geo DNSのクエリ

ヘルスチェックにはクエリとは別に料金がかかる。（詳細は発表資料を参照ください）

• DNSフェイルオーバーヘルスチェック
• AWS内部のエンドポイントへのヘルスチェックと、AWS外部のエンドポイントへのヘルスチェックに、それぞれ値段が設定されている。
• HTTPS, レスポンス照合、高頻度（10秒ごとのヘルスチェッック）などを設定すると料金が上がる（上記への追加料金ではなく、個別に値段設定されている）
• 件数ごとに料金がかかるので、エンドポイントが10ヶ所あるとそれぞれにかかる

ドメイン登録年間費用は、ドメインごとに異なる。.jpドメインが最も高く、.beドメインなどは安い。

利用料金例（あくまで一例です）

東京とアイルランドに配置したWebサーバに、3000万/日のリクエストがあるとすると、

• 1ホストゾーン: 0.50USD
• 月間10億Geo DNSクエリ: 0.70USD * 1000 = 700USD
• ヘルスチェック: 0.50USD * 2ヶ所

ほとんどのケースで利用料金は月額1ドルに達しない。多いケースでも10ドル程度。

ただし、ヘルスチェックの数が多い場合は、値段が上がるので気をつける。

まとめ

Amazon Route 53の特長まとめ

• 高可用性および高信頼性
• スケーラブル
• 他のAmazonサービスと併用可能: ELB, S3, CloudFront
• シンプル: 数分で開始
• 迅速: 全世界のGlobal Anycast Network
• 経済的
• セキュア: IAMとの統合
• 高い柔軟性

特に、ELB, S3, CloudFrontとの併用については、外部DNSを使った場合は不可能だが、Route 53ならできる。

Route 53利用のFAQ

Q: IPv6対応は？

A: AAAA、PTRレコードはIPv6に対応しているが、Route 53にIPv6で問い合わせても返答しません

Q: プライベートIPアドレス目的の利用

A: 設定は可能ですが、誰からも参照できるのでそういった使い方はあまり想定していません

Q: デフォルトのTTLは？

A: すべてのレコードに対して設定する必要があります。Management Consoleから設定する場合、デフォルト値の300秒が最初から入っています

Appendix: 参考資料

• Amazon Route 53 Developer Guide
• Amazon Route 53 FAQ
• Amazon Route 53 料金
• Amazon Route 53 SLA（サービスレベルアグリーメント）

Q＆A

Q: ヘルスチェックの文字列マッチは完全一致ですか？ 正規表現は使えますか？

A: 正規表現は使えません。部分一致です。マッチの指定が「生きてます」のとき、実際の文字列が「生きてますFooBar」でも一致します。

Q: Route 53のエイリアスにCloudFrontを指定したら、AlterNameは不要ですか？

A: CloudFrontのCNAME（xxxx.cloudfron.net）を指定して、といいましたが、その必要はありません。エイリアスでCloudFrontを選べば、Aレコードが一発で返ります。CNAMEとAレコードが2セット返るのでなく、いきなりAレコードが返ります。ですので、高速ですし、レスポンスデータ量を抑えることができます。

Q: ドメインを買う時、プライバシー保護をオンにすれば個人情報が公開されませんか？

A: Yes.

Q: プライベートIPアドレスの登録が問題になるケースは？

A: 思いつきません。DNSは歴史のあるプロトコルなので、外部から参照されないことを前提に使われているわけではありません。たとえば、DNSでLDAPの代わりをするようなバッドノウハウの利用はよくないでしょう。妙な用途に使わないほうがよいと思います。

Q: フェイルオーバー先のセカンダリのS3バケットも、FQDNと同じ名前にしなければならないでしょうか？

A: はい。フェイルオーバー時にS3へルーティングまではしますが、バケットが同じ名前でないとアクセスはできないため、S3まできて蹴られることになります。

Q: FQDNにベーシック認証がかかってるときは？

A: 非対応です。

最後に一言

裏技の紹介。Route 53だけでは可用性に限界があると思った人向け。

Route 53を使えば4つのIPアドレスがセットで返るが、もっと可用性を高めたいときは、オンプレミスのDNSサーバのIPアドレスを5つ目なり1つ目なりに加えて動かすこともできる。ただし、Route 53とオンプレミスのDNSサーバを自動的に同期させる仕組みはないので、APIを活用するとよい。

感想

ヘルスチェックの詳細な仕様を聴けたことと、個人的にまだ使ったことのないGeo DNSの話が聴けたことが非常によかったです。

Route 53は、一度設定した内容を変更できるようになったり、従来は固定だった設定値が可変になったりと、いつの間にか細かいアップデートがされていたのですね。

これからもRoute 53を活用していこうと思います。

それでは、また。