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


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

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

事前情報

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

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 ではないサービス提供会社が行える部分と思われる