Amazon Route53の新機能 ELBをHealth Checkのターゲットにしてみた
ども、大瀧です。連投します。
今朝がたリリースされた、Route53の新機能(Amazon Route 53 on 2013-05-30)を早速試してみました!
従来のRoute53フェイルオーバー機能、設定方法については、福田さんの記事を参照ください。
Route53の新機能とは
従来、Route53ではEC2インスタンスにHealth Checkを行い、EC2が不調の場合にDNSレコードを書き換えるDNSフェイルオーバー機能がありました。以下のようなイメージです。
ただ、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と連動します。
ELB配下の全インスタンスがOut of Serviceになると、Secondaryレコードにフェイルオーバーする仕掛けです。
設定方法
設定は、従来のRoute53のDNSフェイルオーバーよりも、むしろ簡単です。
1. Primaryレコードの登録
設定自体は、従来のフェイルオーバーのPrimaryレコードと変わりません。AliasでELBが設定します。
Evaluate Target HealthはYes、Associate with Health CheckをNoにします。そう、Route53のHealth Checkは不要なんです!!上述の通り、ELBのHealth Checkで監視することになります。
今回は、Zone ApexのAliasに指定してみました。
2. Secondaryレコードの登録
こちらは、従来と特に変わりません。TTLを短めにして登録しましょう。
検証
では、試してみましょう。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サービスを停止してみました。
$ 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フェイルオーバーが一気にメジャーな機能になるんじゃないかと、期待しています!