Amazon EC2 新機能 Monitoring, Auto Scaling and Elastic Load Balancing を一通り触ってみた

5/18に Amazon AWS から発表になった Amazon EC2 の新機能は Auto Scaling や Load Blanacing など、今までユーザ側でなんとかしていた or 提供事業者が飯の種にしていた部分に Amazon がカバーしてしまった。と言う点で結構注目が集まっていた。

細かな点はさておき、ひとまず触ってみないことにはどこまでカバーされているかも分からないので触ってみた。以下、触ってみたときのメモ。

事前情報

設定の仕方やコマンドはそれぞれのページを参考にした。

• Amazon CloudWatch
• Auto Scaling
• Elastic Load Balancing

3機能概要

• CloudWatch は instance と Elastic Load Balancer 両方のモニタリングが行える</p>
  • それぞれ取得できるパラメータは異なる
• Auto Scaling が動作するためには、CloudWatch が instance 上で有効になっていることが条件
• Elastic Load Balancing は起動している instance を指定して分散対象に加えることができる
• beta版ということで、すべてコマンドラインでの操作方法しか提供されていない
  • Elasticfox 上だと今回の機能に対する情報は見えない

動作環境

• すでに EC2 コマンドが実施できる環境があることを前提
• mac 上でオペレーションしています

事前準備

• Amazon AWS web へログイン
• Amazon EC2 API Tools をダウンロードして、ローカルにて解凍
• EC2 コマンドへの PATH が通っている既存ディレクトリと置き換える
  • 今回の3機能追加にともなうもろもろのコマンドが増えている

CloudWatch を触る

事前準備

README.TXT をみつつ

• Amazon CloudWatch API Tools をダウンロードローカルに配置
• .bash_profile に PATH を追加
• credential-file-path.template をコピーして好きな名前に変える
  • 今回は credential-file とした
• このファイルに必要な情報を書く
  • key.id と secret key の情報は AWS web の my page よりコピペする
• .bash_profile に追記した中身

export AWS_CLOUDWATCH_HOME=~/Dropbox/AmazonAWS/CloudWatch

export PATH=$PATH:$AWS_CLOUDWATCH_HOME/bin

export AWS_CREDENTIAL_FILE=$AWS_CLOUDWATCH_HOME/credential-file

• 以下の記述があらかじめ入っていること

export EC2_PRIVATE_KEY=$EC2_HOME/pk-****.pem

export EC2_CERT=$EC2_HOME/cert-****.pem

• 確認 mon-** コマンドが実行できるようになっていること

動かしてみる

• EC2 の instance を起動する時に CloudWatch のモニターを有効にする</p>
  • コマンドラインで -m オプションを付けて起動
  • もしくは instance 起動後に instance-ID を指定して、

$ ec2-monitor-instances i-***

を実行する

• モニターできるパラメータ 09.05.24 現在

EC2 instance 用

CPUUtilization
DiskReadBytes
DiskReadOps
DiskWriteBytes
DiskWriteOps
NetworkIn
NetworkOut

Elastic Load Balancer 用

HealthyHostCount
Latency
RequestCount
UnHealthyHostCount

• stats を見るコマンド mon-get-stats

コマンドのヘルプをみると、

$ mon-get-stats -help



SYNOPSIS

mon-get-stats

MeasureName  --statistics  value[,value...] [--dimensions

"key1=value1,key2=value2..." ] [--end-time  value ] [--namespace  value

]

[--period  value ] [--start-time  value ] [--unit  value ]

[General Options]

何が必須なのかが分かりづらいのと、key とか value に何を入れるかが説明不足。。。

• instance の CPU utilization をみるコマンド</p>
  • —start-time, —end-time, —namespace を設定しないとエラーが出ずに何も出力されなかった
  • 日本時間で見たいときは +09:00 を加えれば OK

$ mon-get-stats CPUUtilization --start-time 2009-05-22T15:00:00+09:00 --end-time 2009-05-22T15:30:00+09:00 --period 60 --statistics "Average,Minimum,Maximum" --namespace "AWS/EC2" --dimensions "InstanceId=i-1183c678"

2009-05-22 06:00:00  1.0  0     0.0   4.9E-324  Percent

2009-05-22 06:01:00  1.0  0.38  0.38  0.38      Percent

2009-05-22 06:02:00  1.0  0     0.0   4.9E-324  Percent

• Elastic Load Balancer の RequestCount をみるコマンド

$ mon-get-stats RequestCount --namespace "AWS/ELB" --statistics "Average,Minimum,Maximum" --start-time 2009-05-25T12:00:00+09:00 --end-time 2009-05-25T13:30:00+09:00

2009-05-25 03:00:00  3.0  1  1.0  1.0  Count

2009-05-25 03:01:00  3.0  1  1.0  1.0  Count

2009-05-25 03:02:00  6.0  1  1.0  1.0  Count

2009-05-25 04:05:00  3.0  1  1.0  1.0  Count

出力結果の数値はこの場合 Samples, Average, Minimum, Maximum のようだ

auto scaling を触る

準備

• CloudWatch の時と同じ
• auto scaling API tools をダウンロードして、.bash_profile で PATH 指定

動かしてみる

• コマンドは as-** という形式

• 1) as-create-launch-config : スケールアウトする時(増やす際)にどの AMI を増やして行くのかあらかじめ指定する
• 2) as-create-auto-scaling-group : 先に設定した launch-config を group に設定する
  • —availablitity-zone と —min-size/—max-size は必須
  • min-size は最小構成 instance 数、max-size は最大構成 instance 数
  • 1test という launch-config を使って、最小0/最大2 instance の test-group1 を作成する場合

$ as-create-auto-scaling-group test-group1 --launch-configuration 1test --availability-zones us-east-1a --min-size 0 --max-size 2

• 3) as-create-or-update-trigger : auto-scaling-group に対する閾値設定</p>
  • test-group1 という auto-scaling group を使って、CPU利用率の平均で 20%以下 になった際にインスタンスを減らす、80% 以上になった時にインスタンスを増やす、120秒状態が継続した場合に発動する test-trigger2 という閾値を設定する場合

$ as-create-or-update-trigger test-trigger2 --auto-scaling-group test-group1 --namespace "AWS/EC2" --measure CPUUtilization --statistic Average --dimensions "AutoScalingGroupName=test-group01" --period 60 --lower-threshold 20 --lower-breach-increment=-1 --upper-breach-increment 1 --upper-threshold 80 --breach-duration 120

• 応用編 : auto-scaling group で min-size 1 にした場合</p>
  • group 内のすべての instance を terminated したら、自動的に 1 instance が起動する
  • この時は launch-config で指定した AMI が起動する
  • すべて落ちても自動的に立ち上げてくれるので、web のフロントや front proxy 的な動きをするものになどに使えそう
  • 手動ですべて落としたいときは

$ as-terminate-instance-in-auto-scaling-group i-**** --decrement-desired-capacity

を実行すると指定したサイズに関係なく落ちてくれるので、自動起動はなくなる

load blancer を触る

準備

• CloudWatch の時と同じ
• Elastic Load Balancing API Tools をダウンロードして、.bash_profile で PATH 指定

動かしてみる

• コマンドは elb-** という形式
• 1) elb-create-lb : Load Balancer を作るコマンド
  • elb-create-lb -help をみる

SYNOPSIS

elb-create-lb

LoadBalancerName  --availability-zones  value[,value...]  --listener

"protocol=value, lb-port=value, instance-port=value" [ --listener

"protocol=value, lb-port=value, instance-port=value" ...]

[General Options]

• Load Balancer がサービスするポート番号と転送先ポート番号を設定する
• test-lb4 という名で、http 80 番でサービスして、http 80 番へ転送する Load Balancer を作成

$ elb-create-lb test-lb4 --availability-zones us-east-1a --listener "lb-port=80,instance-port=80,protocol=http"

DNS-NAME  test-lb4-1200388198.us-east-1.elb.amazonaws.com

• 出力結果に Load Balancer に割り当てる FQDN が発行される
• 実際オリジナルドメインに結びつける時には、オリジナルドメインの DNS サーバ上で CNAME する必要があるだろう
• 確かめてみると

$ host test-lb4-1200388198.us-east-1.elb.amazonaws.com

test-lb4-1200388198.us-east-1.elb.amazonaws.com has address 174.129.197.180

確かにグローバルアドレスが振られている

• 2) elb-register-instances-with-lb : 作った ELB に instance を登録する</p>
  • すでにinstance name が分かっている(起動している)こと
  • 先ほど設定した test-lb4 という Load Balancer に3つの instance を登録する

$ elb-register-instances-with-lb test-lb4 --instances i-fb155392,i-ff155396,i-f315539a

INSTANCE-ID  i-fb155392

INSTANCE-ID  i-ff155396

INSTANCE-ID  i-f315539a

• 3) Load Balancer は分散対象となる instance の health check を行っているので、確認</p>
  • Load Balancer 名 test-lb4 での health check 結果

$ elb-describe-instance-health test-lb4

INSTANCE-ID  i-fb155392  InService

INSTANCE-ID  i-ff155396  InService

INSTANCE-ID  i-f315539a  InService

• instance が生きていれば InService、死んでいれば OutService となる
• instance を登録した時点で、デフォルトで何がしかのチェックが行われている。設定内容は不明
• 4) さらにオリジナルの health check設定を入れてみる
  • Load Balancer test-lb4 にて登録した instance に対して TCP 80 番ポートのチェック、interval 5sec(これが最小値)、timeout 3sec、死活の閾値 2回続いた時

$ elb-configure-healthcheck test-lb4 --target "TCP:80" --interval 5 --timeout 3 --unhealthy-threshold 2 --healthy-threshold 2

HEALTH-CHECK  TCP:80  5  3  2  2



$ elb-describe-instance-health test-lb4

INSTANCE-ID  i-fb155392  InService

INSTANCE-ID  i-ff155396  InService

INSTANCE-ID  i-f315539a  InService

これにて確認終了。

• 分散方式は不明 ソースIP縛りなのか、完全なラウンドロビンなのか
• 設定内容的に L4 スイッチとしての振る舞いまで、L7レベルは設定できない

ちょっとはまったこと

• Load Balancer から instance への health check する際には、instance に適用している sercurity group(firewall) にて source CIDR に 0.0.0.0/0(any) ヘルスチェックしてくる source IP address が設定されていること
• health check packet がはじかれてしまい、OutService 扱いになってしまうため
• Load Balancer と instance に割り当てられていたグローバルアドレスより 174.129.197.0/24 を設定しても NG だったことから、異なる interface から通信していて、Amaozn EC2 内であってもすべて Security Group が適用されていると思われる
• => 任意のローカルアドレスからチェックされていることが分かった。tcpdump などしてアドレスを特定して security group に追加すれば広く設定する必要はない( Amazon EC2 Elastic Load Balancing をもう少し詳しく見てみた – つれづれなる・・・ より)

気になったこと

• 直接 instance に割り当てられた FQDN にブラウザからアクセスしてもみれる
• Load Balancer に割り当てられた FQDN にブラウザからアクセスしてもみれる
• instance のデフォルトゲートウエイが変わっていないことから、Load Balancer の動作は route 方式でなくて、おそらく NAT 方式なのだろう

全体通して分かったこと

( Amazon EC2 Auto Scaling をもう少し詳しく見てみた – つれづれなる・・・より、正しくない部分を修正)

auto scaling と Load Balancer の連携は 今のところできてないようだ 可能

• 自動的に auto scaling から Load Balancer へ instance-ID 情報を渡すコマンドなりは見つけられなかった —load-balancers オプションを用いる
• Load Balancer の分散対象を設定するときはあらかじめ起動してある instance-ID を指定するので、auto scaling が立ち上げた instance-ID は手動で設定する必要がある
• Load Balancer 配下への追加は手動になるので、Load Balancer を使うケースは auto scale のメリットが発揮できない
• これができると web のフロントエンドの負荷分散を自動的にできて、auto scaling のメリットがでるが今回の機能追加ではカバーできていない
• 今回の機能追加 auto scaling は instance が落ちてしまった際、自動的に起動できる対障害性のアップにはなりそう

Amazon EC2 が制御できる範囲はあくまでネットワーク～電源 ON/OFF まで

• Load Balancer は既存の L4 スイッチと変わらない基本動作をする
• ネットワーク機能的にはこれでもう整ったといっていいのでは
• AMI ベースで auto scaling するので、立ち上がった際の不整合は起きない環境で AMI 保存しておく必要がある
• auto scaling はあくまで instance の起動/終了になるので、OS 内でのオペレーションは関与できない
• バックエンドや DB のスケーリングをする際には OS 内のでのオペレーションが必要なので、ここは Amazon ではないサービス提供会社が行える部分と思われる