Amazon Route53の新機能 ELBをHealth Checkのターゲットにしてみた

2013.05.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ども、大瀧です。連投します。
今朝がたリリースされた、Route53の新機能(Amazon Route 53 on 2013-05-30)を早速試してみました!

従来のRoute53フェイルオーバー機能、設定方法については、福田さんの記事を参照ください。

Route53の新機能とは

従来、Route53ではEC2インスタンスにHealth Checkを行い、EC2が不調の場合にDNSレコードを書き換えるDNSフェイルオーバー機能がありました。以下のようなイメージです。

route53_healthcheck1

ただ、Health Checkのターゲットには、ELB(Elastic Load Balancing)が指定できないという、痛い制限がありました。今回のアップデートは、ELBをHealth Checkのターゲットにできるというものです。

あれ、ちょっと待ってください。Health Checkって、元々ELBがバックエンドのEC2を監視するために持っていたのでは?

と思う方もいるでしょう。実は今回のアップデート、ELBのHealth Checkと連動するとってもインテリジェントな機能なんです!

構成

まずは、Route53のPrimaryレコードにELBのアドレス(Alias)を指定できるようになりました。それに加えて、従来はRoute53のHealth Checkを使用していたのに対しELB構成の場合は、以下のようにELBのHealth Checkと連動します。

route53_healthcheck2

ELB配下の全インスタンスがOut of Serviceになると、Secondaryレコードにフェイルオーバーする仕掛けです。

route53_healthcheck3

設定方法

設定は、従来のRoute53のDNSフェイルオーバーよりも、むしろ簡単です。

1. Primaryレコードの登録

設定自体は、従来のフェイルオーバーのPrimaryレコードと変わりません。AliasでELBが設定します。
Evaluate Target HealthYesAssociate with Health CheckNoにします。そう、Route53のHealth Checkは不要なんです!!上述の通り、ELBのHealth Checkで監視することになります。
今回は、Zone ApexのAliasに指定してみました。

route53_primary

2. Secondaryレコードの登録

こちらは、従来と特に変わりません。TTLを短めにして登録しましょう。

route53_secondary

検証

では、試してみましょう。ELBのHealth Checkと連動するということなので、Primaryに設定しているELBのHealth Checkが、全インスタンスでOut of Serviceになると、Secondaryのレコードに変わるはずです。
今回は、digコマンドでAレコードがどう変わるかを見てみました。

平常時

$ dig @XXXX.awsdns-NN.XXX. example.com

; <<>> DiG 9.8.3-P1 <<>> @XXXX.awsdns-NN.XXX. example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26360
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;example.com.			IN	A

;; ANSWER SECTION:
example.com.		60	IN	A	XX.XX.XX.XX(Primary(ELB)のIPアドレス)

;; AUTHORITY SECTION:
example.com.		172800	IN	NS	XXXX.awsdns-NN.XXX.
example.com.		172800	IN	NS	XXXX.awsdns-NN.XXX.
example.com.		172800	IN	NS	XXXX.awsdns-NN.XXX.
example.com.		172800	IN	NS	XXXX.awsdns-NN.XXX.

;; Query time: 11 msec
;; SERVER: XX.XX.XX.XX#53(XX.XX.XX.XX)
;; WHEN: Fri May 31 10:55:29 2013
;; MSG SIZE  rcvd: 182

異常時

ELBのHealth Checkが全てOut of Serviceになるように、配下のEC2でHTTPサービスを停止してみました。

route53-elb

$ dig @XXXX.awsdns-NN.XXX. example.com

; <<>> DiG 9.8.3-P1 <<>> @XXXX.awsdns-NN.XXX. example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26360
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;example.com.			IN	A

;; ANSWER SECTION:
example.com.		60	IN	A	YY.YY.YY.YY(Secondary(EC2)のIPアドレス)

;; AUTHORITY SECTION:
example.com.		172800	IN	NS	XXXX.awsdns-NN.XXX.
example.com.		172800	IN	NS	XXXX.awsdns-NN.XXX.
example.com.		172800	IN	NS	XXXX.awsdns-NN.XXX.
example.com.		172800	IN	NS	XXXX.awsdns-NN.XXX.

;; Query time: 11 msec
;; SERVER: XX.XX.XX.XX#53(XX.XX.XX.XX)
;; WHEN: Fri May 31 10:55:29 2013
;; MSG SIZE  rcvd: 182

実際のアドレスは伏せていますが、Aレコードが変化しました!

まとめ

ELB対応は、Route53のフェイルオーバーの本命だと個人的には思っているので、これでRoute53フェイルオーバーが一気にメジャーな機能になるんじゃないかと、期待しています!