Amazon Route 53による重み付けGSLB(Global Server Load Balance)

GSLB(Global Server Load Balance)とは？

GSLBとは、その名の通り地域的に離れたサーバーへ負荷分散する仕組みです。通常のロードバランサーは、同じ建物やラックの中で負荷分散をしますが、GSLBでは東京リージョンとシンガポールリージョンなど地域をまたいで負荷分散することができます。Amazon Route 53では、名前解決に重み付けをする形でGSLBを実現しています。

複数のリージョンにインスタンスを立てる

東京リージョンとシンガポールリージョンにインスタンスを立てます。

東京リージョンはこちら。動作が分かりやすいようにTokyo page!と表示させています。

続いてシンガポールリージョンにインスタンスを立てました。Singapore page!と表示させています。

Amazon Route 53でAレコードの重み付けをする。

2つのリージョンでインスタンスを立ち上げましたので、Route 53から重み付けを付けて振り分けを行います。 なお、それぞれのインスタンスには固定IP(Elastic IP)を設定しました。実運用を考えた場合にはELBをAlias設定するのが良いと思うのですが、今回はテスト用として直接AレコードでIP指定しています。

SingaporeリージョンのインスタンスのIPを122.248.248.74としました。TokyoリージョンのインスタンスのIPを46.51.241.24としました。

ここで重要となるのがSet IdentifierとWeightです。Set Identifierは、ユニークな名前を指定します。Weightは数字を指定します。今回の例では、www.akari7.netというNameのレコードを2つ設定して、異なるIdentifierを指定しました。Weightの計算の仕方ですが、以下の例ではTokyoに1、Singaporeに0を設定していますので、全てのリクエストが東京に行きます。1と1にすれば50%づつラウンドロビンで振り分けます。1と2にすれば1/3と2/3に振り分けられます。

全てのリクエストがTokyo Regionに向かっているかブラウザでリロードを繰り返してみましょう。

確かにTokyo Regionだけ表示されました。続いて、Weightを1と1にしてみます。

ブラウザでリロードしまくってみましょう。あら？なかなか変わりませんね。なぜでしょうか。あ、TTLですね。DNSの名前解決のキャッシュが効いていました。今回は900と設定してしまったので15分キャッシュしています。これをもっと振り分けたいようでしたらTTLを小さくしましょう。小さすぎるTTLはよくないといった記述がWEB上にはありますが、Route 53は60秒で全世界に反映されるDNSサービスですから多少短くても問題ないでしょう。さらに、OS側でDNSのキャッシュもしているようですね。強制的にOSのキャッシュをクリアして動作を確認してみましょう。

以下は、Mac OSX LionでDNSキャッシュを削除した後に最新の名前解決を表示する記述です。

$ dscacheutil -flushcache
$ dscacheutil -q host -a name www.akari7.net
name: www.akari7.net
ip_address: 46.51.241.24

キャッシュを削除して表示をもう１回やってみます。

$ dscacheutil -flushcache
$ dscacheutil -q host -a name www.akari7.net
name: www.akari7.net
ip_address: 122.248.248.74

思った通り名前解決で異なるIPアドレスを返してくれました！後で分かった事ですが、私の環境(Mac OS X Lion)では、DNSキャッシュのクリアは必要ありませんでした。皆さんの環境によって異なるかもしれませんので、必要に応じてキャッシュのクリアをしてください。ActiveDirectoryがキャッシュしているなんて話はよく聞きます。

現在のTTL値を確認するコマンドdig

digというコマンドをご存知でしょうか？これは、指定したドメインの現在のTTL値などを表示する便利なコマンドです。さっそく使ってみましょう。

$ dig www.akari7.net

; <<>> DiG 9.7.3 <<>> www.akari7.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46221
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 3

;; QUESTION SECTION:
;www.akari7.net.			IN	A

;; ANSWER SECTION:
www.akari7.net.		10	IN	A	122.248.248.74

;; AUTHORITY SECTION:
akari7.net.		169507	IN	NS	ns-1523.awsdns-62.org.
akari7.net.		169507	IN	NS	ns-40.awsdns-05.com.
akari7.net.		169507	IN	NS	ns-888.awsdns-47.net.
akari7.net.		169507	IN	NS	ns-1702.awsdns-20.co.uk.

;; ADDITIONAL SECTION:
ns-888.awsdns-47.net.	42847	IN	A	205.251.195.120
ns-1523.awsdns-62.org.	32850	IN	A	205.251.197.243
ns-1702.awsdns-20.co.uk. 151259	IN	A	205.251.198.166

;; Query time: 25 msec
;; SERVER: 192.168.11.1#53(192.168.11.1)
;; WHEN: Tue Sep 13 02:16:58 2011
;; MSG SIZE  rcvd: 232

digコマンド最高！繰り返し実行すると、TTLが減っていくのが分かります。そして、www.akari7.netのAレコードTTLが0になるとIPが変わる事を確認できます！

おまけ：SOAレコードって何だ？

Route 53は大変簡単にDNS設定ができるサービスであることは分かったのですが、そもそもDNSって何が設定されているのか詳細まで把握していませんでしたので、今回はおまけとしてSOAレコードでは何が設定されているか確認したいと思います。SOAとは、Start Of Authorityの略で、SOAレコードはDNSサーバーの動作を決めるための基本情報が含まれています。

digコマンドで確認してみましょう。

$ dig www.akari7.net SOA

; <<>> DiG 9.7.3 <<>> www.akari7.net SOA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18126
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;www.akari7.net.			IN	SOA

;; AUTHORITY SECTION:
akari7.net.		899	IN	SOA	ns-1523.awsdns-62.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 10 msec
;; SERVER: 192.168.11.1#53(192.168.11.1)
;; WHEN: Tue Sep 13 02:21:48 2011
;; MSG SIZE  rcvd: 117

ポイントはこの行です。

akari7.net.		899	IN	SOA	ns-1523.awsdns-62.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

akari7.netはホストゾーン名ですね。899とあるのはTTLが減っている値です。ns-1523.awsdns-62.org.はMNAMEと呼ばれるものでゾーンファイルの基となるデータを持つネームサーバの名前です。awsdns-hostmaster.amazon.com.はRNAMEと呼ばれるものでこのドメインの管理者のメールアドレスです。

続いて1はSERIALでバージョン番号を表します。7200(2時間)はREFRESHでゾーンの情報をリフレッシュするまでの時間を表します。900(15分)はRETRYでREFRESHでゾーン情報の更新ができなかった場合に、RETRYで指定された時間後に再度リフレッシュを試みます。1209600(14日)はEXPIREで何らかの理由でゾーン情報のリフレッシュができない状態が続いた場合、セカンダリネームサーバが持っているデータをどれだけの時間利用してもよいかを示します。86400(24時間)はMINIMUM（Negative cache TTL)で、存在しないドメイン名であるという情報のキャッシュを意味します。（ネガティブキャッシュの維持する時間）

まとめ

Amazon Route 53による重み付けGSLB(Global Server Load Balance)についていかがでしたでしょうか？異なるリージョンでリクエストを振り分けるにはGSLB、同じリージョンで異なるAZへ振り分けるのはELB(Elastic Load Balancing)と用途が分かってきましたね。AWSのサービスの特性を理解して正しく使いましょう！