クラウドウォッチ

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

2009年05月25日

シェイクソウル深海様が、AWSの最新サービス「Monitoring, Auto Scaling and Elastic Load Balancing 」について、寄稿していただきました。オリジナルは深海様のブログで掲載されております。

《 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 両方のモニタリングが行える
o それぞれ取得できるパラメータは異なる
* Auto Scaling が動作するためには、CloudWatch が instance 上で有効になっていることが条件
* Elastic Load Balancing は起動している instance を指定して分散対象に加えることができる
* beta版ということで、すべてコマンドラインでの操作方法しか提供されていない
o 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 をコピーして好きな名前に変える
o 今回は credential-file とした
* このファイルに必要な情報を書く
o 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 のモニターを有効にする
* コマンドラインで -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 をみるコマンド

* --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 に設定する
o --availablitity-zone と --min-size/--max-size は必須
o min-size は最小構成 instance 数、max-size は最大構成 instance 数
o 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 に対する閾値設定

* test-group1 という auto-scaling group を使って、CPU利用率の1分間平均で 20%以下 or 80% 以上になった時に引っ掛ける test-trigger2 という閾値を設定する場合(設定内容的にちょっとおかしいですが、)

$ as-create-or-update-trigger test-trigger2 --auto-scaling-group test-grou
p1 --namespace "AWS/EC2" --measure CPUUtilization --statistic Average --dimensi
ons "AutoScalingGroupName=test-group01" --period 60 --lower-threshold 20 --lowe
r-breach-increment 1 --upper-breach-increment 1 --upper-threshold 80 --breach-d
uration 120

応用編 : auto-scaling group で min-size 1 にした場合

* 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 を作るコマンド
o 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]

o Load Balancer がサービスするポート番号と転送先ポート番号を設定する
o 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

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

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

確かにグローバルアドレスが振られている
* 2) elb-register-instances-with-lb : 作った ELB に instance を登録する
o すでにinstance name が分かっている(起動している)こと
o 先ほど設定した 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 を行っているので、確認
* 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 を登録した時点で、デフォルトで何がしかのチェックが行われている。設定内容は不明

# 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

これにて確認終了。

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

《ちょっとはまったこと》

* Load Balancer から instance への health check する際には、instance に適用している sercurity group(firewall) にて source CIDR に 0.0.0.0/0(any) が設定されていること

* health check packet がはじかれてしまい、OutService 扱いになってしまうため

* Load Balancer と instance に割り当てられていたグローバルアドレスより 174.129.197.0/24 を設定しても NG だったことから、異なる interface から通信していて、Amaozn EC2 内であってもすべて Security Group が適用されていると思われる

《気になったこと》

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

《全体通して分かったこと》

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

* 自動的に auto scaling から Load Balancer へ instance-ID 情報を渡すコマンドなりは見つけられなかった
* 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 ではないサービス提供会社が行える部分と思われる

Tags:Amazon, Auto Scaling, Elastic Load Balancing, Monitoring

上へもどる