AWSのDNSフェイルオーバーについて

Amazon Web Services（AWS）のDNSサービスである「Route53」にて、フェイルオーバー機能がサポートされたとのことでしたので、早速調査を行いました。

【AWS発表】Route53にDNSフェイルオーバー機能が追加。S3のウェブホスティング機能と連携したバックアップサイトを作成可能に。

詳しい設定手順などは上記ブログに任せるとして、ここではこの機能の概要と、設定する際の注意点についてまとめます。

図１ Route53によるDNSフェイルオーバー

まずはこの機能の概念図を見てください（クリックして拡大）。

この図では、架空のドメイン（hoge.com）をRoute53（DNS）で管理しています。通常のDNS運用では、たとえば「www.hoge.com」というウェブサイトに対して、Aレコードを定義しています。

DNSフェイルオーバーでは、この通常のAレコードをプライマリとし、プライマリのAレコードに新設された「Health Check」という機能を紐付けます。「Health Check」とは、その名のとおり死活監視をする機能で、世界中のAmazonロケーションから定期的にターゲットサイトを監視します。
監視方法は、HTTPかTCPによるもので、HTTPを使った場合は400番より小さいレスポンスを2秒以内に返さないとエラーと判断します（TCPの場合は4秒以内にバーチャルサーキットが開設できないとエラーとなるようです）。

実際に構築してみたところ、約16箇所から60秒/箇所間隔でパケットが届きました。なので、すくなくとも16アクセス/分となります。上記の公式サイトでは30秒間隔とあるので、実際はもっと増える可能性もあります。

エラーになった場合に利用されるのが、フェイルオーバー機能により新設されたセカンダリのAレコードです。これは、プライマリのAレコードのエイリアスとして定義するもので、通常は存在していないので、フェイルオーバーを設定する際に追加する必要があります。

セカンダリのAレコードでは、飛び先としてS3の静的ウェブサイトの他、EC2なども選択が可能です（エイリアスターゲットと呼びます）。S3の静的ウェブサイトでは、運用コストを非常に安くすることができるので、ここにお詫びのコンテンツをいれておくことで、Health Checkにてエラーと判断された場合に、自動的にそのコンテンツが表示されるという仕組みです。

S3で静的なウェブサイトを作成する方法については、下記のリンクが役に立ちます。

【AWS発表】 Amazon S3で静的なWebサイトの運用が可能に

なお、Health Checkは前述のとおり、かなり細かい間隔で行われるため、DNSの返答先の切り替え自体は早いのですが、プライマリのAレコードに指定したTTL（情報の生存時間）が有効なため、フェイルオーバーを設定する際は、プライマリAレコードのTTLを60秒にする（通常は300秒など）ことを推奨しているようです。

最後に注意点です。

1. エイリアスターゲットにS3を利用する場合、SSLが使えません。
   これはS3側の静的ウェブサイトに起因しますが、S3の静的ウェブサイトでは現在SSLに非対応なため、DNSがS3に切り替えたとしても接続ができず、接続エラー（サーバーが見つからない）になります。
2. 同じくエイリアスターゲットにS3を利用する場合、バケット名はターゲットサイトと同じ名前にしておくこと。
   上の図でいうと、www.hoge.comという名前のバケットを作成しておく必要があります。これは、セカンダリAレコードのエイリアスターゲットの指定画面では、バケット名までは指定することができず、暗黙的にターゲットサイトの名前のバケットが利用されるからです。
   この制限によって、たとえば、複数のサイトを管理している場合に、同じエラー画面を１つのS3バケットで使い回しすることができないことを意味します。

サーバが何らかの理由によって（たとえば正規のメンテナンスも含む）停止する場合、DNSでフェイルオーバーができるのはかなり強力な機能といえます。今回紹介したようなお詫びコンテンツをS3で運用するだけでなく、たとえばバックアップサイトをEC2で構築しておき、そちらに切り替える（LBでやればいいじゃんって話もありますが）などの利用方法が考えられます。