Amazon Elastic Load Balancing (ELB)の内部構造および拡張・障害時の動き

　諸般の理由により、AWSの各サービスの挙動を改めて復習中です。まずは、Amazon Elastic Load Balancing 、通称ELBについてです。ELBの内部の動作については、公開されている公式ドキュメントが割とあります。是非一度しっかりと目を通しておくとよいですよ。少なくともAWSマイスターシリーズのELBについては、読んでおくべきです。簡潔にかつ詳しく説明されているので、理解が格段に進むでしょう。というところで、現段階で私が理解しているELBのアーキテクチャをまとめてみました。

ELBの内部構造

　ELBは、ELBエンドポイントとELBインスタンス（仮称）によって構成されます。ELBインスタンス（仮称）の正式名称は知らないので、その名前で呼ぶことにします。ELBインスタンスには、グローバルIPが付与されます。ELBエンドポイントは、myLB-xxx.elb.amazonaws.comのようなDNS名を持ちます。このELBのDNS名を名前解決すると、ELBインスタンスのグローバルIPが返されます。ELBインスタンスが複数ある場合は、複数のIPを返します。ELBインスタンスは、利用するAZに少なくとも1つ存在します。MultiAZ構成の場合であれば、少なくとも2つのIPが返されます。
　クライアントからアクセスがあった場合は、DNSのラウンドロビンでELBインスタンスのIPアドレスが返されます。ELBインスタンスは、配下のインスタンスに振り分けられます。恐らくELBインスタンス内にリバースプロキシのような機能があるのでしょう。

　nslookupとdigをすると、次のようになります。

$ nslookup ELB-Test-869539816.ap-northeast-1.elb.amazonaws.com 
Server:		192.168.11.1
Address:	192.168.11.1#53

Non-authoritative answer:
Name:	ELB-Test-869539816.ap-northeast-1.elb.amazonaws.com
Address: 54.250.186.157
Name:	ELB-Test-869539816.ap-northeast-1.elb.amazonaws.com
Address: 54.199.196.182

$ dig ELB-Test-869539816.ap-northeast-1.elb.amazonaws.com

; <<>> DiG 9.8.5-P1 <<>> ELB-Test-869539816.ap-northeast-1.elb.amazonaws.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1343
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;ELB-Test-869539816.ap-northeast-1.elb.amazonaws.com. IN	A

;; ANSWER SECTION:
ELB-Test-869539816.ap-northeast-1.elb.amazonaws.com. 48	IN A 54.199.196.182
ELB-Test-869539816.ap-northeast-1.elb.amazonaws.com. 48	IN A 54.250.186.157

;; AUTHORITY SECTION:
ap-northeast-1.elb.amazonaws.com. 166 IN NS	ns-54.awsdns-06.com.
ap-northeast-1.elb.amazonaws.com. 166 IN NS	ns-1683.awsdns-18.co.uk.
ap-northeast-1.elb.amazonaws.com. 166 IN NS	ns-982.awsdns-58.net.
ap-northeast-1.elb.amazonaws.com. 166 IN NS	ns-1325.awsdns-37.org.

;; ADDITIONAL SECTION:
ns-54.awsdns-06.com.	166659	IN	A	205.251.192.54
ns-982.awsdns-58.net.	166660	IN	A	205.251.195.214
ns-1325.awsdns-37.org.	166660	IN	A	205.251.197.45
ns-1683.awsdns-18.co.uk. 166660	IN	A	205.251.198.147

;; Query time: 24 msec
;; SERVER: 192.168.11.1#53(192.168.11.1)
;; WHEN: Tue Feb 11 16:45:22 JST 2014
;; MSG SIZE  rcvd: 301

ELBのスケーリング

　一定以上の負荷が掛かりELBの処理能力を上げる必要が出た場合に、自動的にELBのスケールアップもしくはスケールアウトが行われます。このELBのスケーリングも、DNSの名前解決を利用して行います。スケールアップの場合は、より処理能力の高いELBインスタンスを立ちあげてIPに切り替えます。スケールアウトの場合は、同等の処理能力のELBインスタンスを立ちあげてIPアドレスに追加します。いずれにせよIPアドレスが変わるのでご注意ください。
　ちなみにスケールアウトかスケールアップのどちらを選ぶのかは、AWSが自動的に選択します。そのアルゴリズムは公開されていません。想像ですが、トラフィック数が多い場合はスケールアウト、リクエスト辺りのトラフィック量が多い場合はスケールアップを選ぶのではないでしょうか？全くの想像なので、いつか試してみたいです。

障害時の動作

　障害時の動作も、基本的にはDNSを利用します。ELBインスタンス配下のインスタンスが全滅した場合、そのELBインスタンスのIPアドレスは削除されます。そのIPアドレスが最後の１つの場合は、そのまま残ります。ELBインスタンス自身の障害の際も、DNSの切り替えで対処します。

ELBのCloudWatchのMetrics

　ついでにELBのCloudWatchのメトリクスを見てみましょう。

メトリクス名	概要
HealthyHostCount	ELB配下の正常稼働している（healthy）インスタンス数です
UnHealthyHostCount	ELB配下の異常稼働している（unhealthy）インスタンス数です
RequestCount	ELBで処理されたリクエスト数です。HTTPCode_Backend_XXXの合計です
Latency	ELBからバックエンドインスタンスに渡されて返ってくるまでの時間です
HTTPCode_ELB_4XX HTTPCode_ELB_5XX	ELB自身が返すステータスコードです
HTTPCode_Backend_2XX HTTPCode_Backend_3XX HTTPCode_Backend_4XX HTTPCode_Backend_5XX	ELB配下のバックエンドインスタンスで生成されたレスポンスコードです
SurgeQueueLength	ELBで処理待ちの待ち行列(surge queue)の数です
SpilloverCount	待ち行列(surge queue)から溢れたリクエスト数です

　ポイントとしては、SurgeQueueLength及びSpilloverCountをみておけば、ELBで処理出来なかったリクエストが解るという点でしょうか。あとは、HTTPCode_ELB_5XX系のHTTP 503: Service Unavailableなどを見ていれば、ELBのキャパオーバ等の検出も出来る可能性があります。
　Amazonさん、ついでにELBの流量を監視するメトリクスも作ってくれませんかね？

まとめ

　公開されている資料の中でのELBの動作をまとめてみました。もしかしたら誤解している部分があるかもしれませんので、その際は是非ご指摘ください。ちなみにこのELBの動作のように、DNSを切り替えて行うというのはAWSの基本思想だと思います。他のサービスも色々利用していますし、たぶんそうなんだろうなぁというところもあります。Googleのクラウド（Google Cloud Platform）はまた違ったように見受けられるので、そのうち調べて対比させてみたいと思います。