Hatena::ブログ(Diary)

つれづれなる・・・ RSSフィード Twitter

2010/03/05 (Fri)

[][] Amazon EC2 Elastic Load Balancing をもう少し詳しく見てみた  Amazon EC2 Elastic Load Balancing をもう少し詳しく見てみたを含むブックマーク

Amazon EC2 の Elastic Load Balancing について、最初にまず触ってみたことは以下のエントリーに書いた。

Amazon EC2 新機能 Monitoring, Auto Scaling and Elastic Load Balancing を一通り触ってみた - つれづれなる・・・

(このエントリーで分かったことを元に修正しています。)

この時に疑問に思った点とか新しく気づいたことをのせます。

Load Balancer からのヘルスチェックがHTTP GETに対応していた

今までは単なるポートレベルでのチェックだったのが、html指定できるようになっている。

Amazon Management Console から Load Balancer の設定ができるようになっているが、ヘルスチェックの画面でHTTP用にURLパスが設定できるようになっていた。

Ping Path」という部分が該当する。デフォルトは「index.html」になっている。

f:id:d_sea:20100308123659p:image

ちなみに、プルダウンを「TCP」にすると、「Ping Path」が消える。HTTP以外で単純にポート番号に対してヘルスチェックを行う場合はこっちで設定する。

f:id:d_sea:20100308123658p:image

Load Balancer のヘルスチェックは AWSローカルネットワーク内から任意のインスタンスで行われていた

通常、security group に最初に設定されている default には全てのポート番号に対して source IP address に default group が設定されている。これで自分が立ち上げたインスタンス間の通信は何でも通って、外部からのアクセスからは守られる状況が簡単に作れている。

Amazon Management Console からは以下の画面で分かる。

f:id:d_sea:20100308160819p:image

Elastic Load Balancing を利用するときに悩ましかったのが、ヘルスチェックパケットを送ってくる誰かは default group に該当しないらしく、Security Groupアドレスを追加して accept する必要があるけども、ヘルスチェックパケットを送ってくる source IP が画面上やコマンド上では分からないこと。

Web用で利用するときは、0.0.0.0/0 で開けてしまうので問題ないのだけど、例えば MySQLレプリケーションスレーブ複数台を分散するために使いたい場合は any であけるのは、これはセキュリティ的によろしくない。

実際、どの source IP から送ってくるのか tcpdump してみた。

[root@ip-10-242-119-83 ~]# tcpdump -n port 80

22:03:42.962921 IP 10.212.66.130.55786 > 10.242.119.83.http: S 1970301109:1970301109(0) win 5840 <mss 1460,sackOK,timestamp 1108158 0,nop,wscale 3>
22:03:42.962970 IP 10.242.119.83.http > 10.212.66.130.55786: S 2350734762:2350734762(0) ack 1970301110 win 5792 <mss 1460,sackOK,timestamp 1345800047 1108158,nop,wscale 2>
22:03:42.962981 IP 10.212.66.130.55776 > 10.242.119.83.http: F 1:1(0) ack 1 win 730 <nop,nop,timestamp 1108158 1345793614>
22:03:42.963169 IP 10.242.119.83.http > 10.212.66.130.55776: F 1:1(0) ack 2 win 1448 <nop,nop,timestamp 1345800047 1108158>
22:03:42.963410 IP 10.212.66.130.55786 > 10.242.119.83.http: . ack 1 win 730 <nop,nop,timestamp 1108158 1345800047>
22:03:42.963454 IP 10.212.66.130.55776 > 10.242.119.83.http: . ack 2 win 730 <nop,nop,timestamp 1108158 1345800047>

10.212.66.130 がヘルスチェックパケットを送って来ていた。10.242.119.83 は自分インスタンス

AWS 内で名前を引くと、

[root@ip-10-242-119-83 ~]# host 10.242.119.83
83.119.242.10.in-addr.arpa domain name pointer ip-10-242-119-83.ec2.internal.

EC2インスタンスにつけるホスト名のような感じに見える。なので、ヘルスチェックするのは Load Balancer 用に立ち上げられているインスタンスが行っているようだ。

ちなみに、Load Balancer のローカルアドレスでは?と思ってインスタンス上から Load Balancer の FQDN を引いてみると、

[root@ip-10-242-119-83 ~]# host web-load-balancer-833540296.us-east-1.elb.amazonaws.com
web-load-balancer-833540296.us-east-1.elb.amazonaws.com has address 184.73.238.21

グローバルアドレスが返ってきているので、ヘルスチェックしているのは Load Balancer とは別物のインターナル側のIPアドレスのようだ。(追記: ヘルスチェックしているのは別物ではなく同一インスタンスだった、というコメントからの指摘があったので修正)

ヘルスチェックを通すために security group を広くあけるのが嫌だなぁと思っている方は、このホストだけを accept するように security group を設定すればいい。このアドレスはおそらく動的には変わらないと思うので。条件は tcpdump のようなパケットキャプチャができることになるけど。のだけど、ELBがEC2と同じようにアドレスが変わる可能性もありそうという話もあるので、10.0.0.0/255.0.0.0の広めにあけておくのが無難になりそう。(追記: こちらもコメントからの指摘があったので修正)

Load Balancer はネットワークレベルでの分散を簡単に行えるので、使いようによっては結構便利。今回のこのティップスでひとまずanyで開けない程度の環境で利用できる。

ApplePedlarApplePedlar 2010/10/28 14:38 記事が書かれた当時はどうだったか今となっては不明ですが、先ほど試してみたところ、ヘルスチェックアクセス(HTTP)とロードバランサーからのウェブアクセスはどちらも同じプライベートIPアドレスからのアクセスでした。また、そのプライベートIPアドレスに対してEC2インスタンスからHTTPアクセスを行った場合、ロードバランサーに接続されました。つまり、ヘルスチェックはロードバランサー自身が行っているのではないかと思います。とすると、ロードバランサーのプライベートIPアドレスはたぶん固定ではない(少なくともグローバルIPアドレスは固定ではない)ので、そのプライベートIPアドレスだけを許可するといずれヘルスチェックが通らなくなるような気がします。

d_sead_sea 2010/10/28 22:21 情報いただきありがとうございます。
1つのELBはインスタンスと同じようにexternal/internalそれぞれアドレスを持っているようですね。
私も今のところ事象を捉えていませんが、internalのプライベートIPアドレスは変わってしまうかもしれませんね。
内容を書き換えておきます。

トラックバック - http://d.hatena.ne.jp/d_sea/20100305