以前、Auto Scaling について触ってみた内容は以下のエントリーで書いた。
Amazon EC2 新機能 Monitoring, Auto Scaling and Elastic Load Balancing を一通り触ってみた – つれづれなる・・・
それ以降、実際に使ってみて、正しくない部分に気づいたので、前のエントリーの修正をしつつ追加で分かったことを含めて書いておく。
Auto Scaling の設定手順をまとめてみる
Auto Scaling の設定はいくつかの設定を依存させて動作させているので、その整理を行う。
設定すべき内容は以下3つになる。
- launch-config
- auto-scaling-group
- trigger
順番に設定する必要があり、依存関係は launch-config > auto-scaling-group > trigger となっている。
それぞれについて解説する。
launch-config
自動的にインスタンスが起動する際に必要な項目を設定する
-
設定する項目</p>
- LaunchConfigurationName: 名前
- AMI: 立ち上げたいAMIを指定する
- key pair: 必須ではない設定項目だが、これを設定しないと key を使った ssh login ができないため、設定した方がいい
- security group: 起動したインスタンスに適用する security group
- instance type: 起動するインスタンスのタイプ smallとかlargeとか
- 作成するコマンドは、as-create-launch-config
- 例:
as-create-launch-config TEST-CONFIG --image-id ami-89e809e0 --key temp-key --group Web-group --instance-type m1.small
- LaunchConfigurationName: TEST-CONFIG
- AMI: ami-89e809e0
- key pair: temp-key
- security group: Web-group
- instance type: m1.small
auto-scaling-group
起動したインスタンスを動作させるための全般的な設定
-
設定する項目</p>
- AutoScalingGroupName: 名前
- availability-zones: インスタンスをどの availability-zones で起動させるか
- launch-configuration: 適用させる launch-configuration 名
- min-size: 起動させるインスタンスの最小数。0以上で max と同じもしくは小さい値にすること。
- max-size: 起動させるインスタンスの最大数。10000より小さくて min と同じもしくは大きい値にすること。
- load-balancers: 起動したインスタンスを load balancer 配下に追加する。このオプションを付けない場合は load balancer 配下に入らずに起動される
- 作成するコマンドは、as-create-auto-scaling-group
- 例:
as-create-auto-scaling-group test-group1 --launch-configuration 1test --availability-zones us-east-1a --min-size 0 --max-size 2 --load-balancers Web-LB
- AutoScalingGroupName: test-group1
- availability-zones: us-east-1a
- launch-configuration: 1test
- min-size: 0
- max-size: 2
- load-balancers: Web-LB
trigger
auto-scaling-groupを発動させるしきい値の設定。(ちょっと分かりづらい。いまいち把握しきれていない。)
-
設定する項目</p>
- TriggerName: 名前
- auto-scaling-group: 適用させる auto-scaling-group 名
- measure: しきい値として用いるモニタリング項目。CloudWatchで取得できる項目が該当する。
- statistic: しきい値として用いる数字の Average, Sum, Minimum, Maximum のうちどれかを選ぶ
- dimensions: モニタリングで利用する設定を示す
- period: モニタリングする頻度
- lower-threshold: この値を下回った際にしきい値を超えた判断する。しきい値の下限
- upper-threshold: この値を上回った際にしきい値を超えた判断する。しきい値の上限
- lower-breach-increment: しきい値の下限をどれくらい下回ったらスケールするかを設定する。-1 を設定したときは「lower-breach-increment=-1」と書く
- upper-breach-increment: しきい値の上限をどれくらい上回ったらスケールするかを設定する。
- breach-duration: しきい値を超えた際にどれくらいの時間が継続したらtriggerを発動するか設定する
- 作成するコマンドは、as-create-or-update-trigger
- 例:
as-create-or-update-trigger WebApp-trigger1 --auto-scaling-group WebApp-group1 --measure CPUUtilization --statistic Average --dimensions "AutoScalingGroupName=WebApp-group1" --period 60 --lower-threshold 20 --upper-threshold 95 --lower-breach-increment=-1 --upper-breach-increment 1 --breach-duration 180
- TriggerName: WebApp-trigger1
- auto-scaling-group: WebApp-group1
- measure: CPUUtilization
- statistic: Average
- dimensions: “AutoScalingGroupName=WebApp-group1”
- period: 60
- lower-threshold: 20
- upper-threshold: 95
- lower-breach-increment: -1
- upper-breach-increment: 1
- breach-duration: 180
Auto Scaling で自動で増えたインスタンスを Elastic Load Balancing 配下に追加できた
オプションの見落としだったわけですが、以前は自動的に増えたインスタンスは Elastic Load Balancing 配下に自動的に追加されないと思っていたが、ちゃんと追加できるオプションがあった。Load Balancer 配下に自動的に追加されなければオートスケーリングの意味無いじゃんと思っていたけど、さすがアマゾン、ちゃんとサポートしていた。
オプションは、as-create-auto-scaling-group コマンドにある。ヘルプを見てみると、
SYNOPSIS as-create-auto-scaling-group AutoScalingGroupName --availability-zones value[,value...] --launch-configuration value --max-size value --min-size value [--cooldown value ] [--load-balancers value[,value...] ] [General Options] (snip) SPECIFIC OPTIONS --cooldown VALUE Time (in seconds) between a successful scaling activity and succeeding scaling activity. -l, --launch-configuration VALUE Name of existing launch configuration to use to launch new instances. Required. --load-balancers VALUE1,VALUE2,VALUE3... List of existing load balancers. Load balancers must exist in Elastic Load Balancing service, within the scope of the caller's AWS account.
「—load-balancers」というのがあり、Load Balancer 名を書くことでその配下に追加されることが可能になる。事前に Load Balancer は作成してあることが必要。
決して落ちないインスタンスを作ることができる
min-size 1以上であれば動作させることが可能。
例えば、min-size 1 にした場合、
- 意味としては「必ず1台立ち上がっている=決して落ちない」状況を作ることができる
-
Webサーバみたいな必ず立ち上がっていて欲しい時には —min-size 1 にしておくと良い
- この時は —load-balancers オプションを忘れずに。事前にWeb用ロードバランサを作成しておくこと
- Web用ロードバランサの FQDN を DNS で CNAME して、www.example.com とかと紐付けて置くこと前提
- この設定をした途端に自動的にインスタンスが立ち上がる。後述の trigger がなくても動作する
- 手動で立ち上がっているインスタンスを terminate して、0台の状態にしても自動的に起動してくる
決して落ちない状況で起動インスタンス数を0にしたい場合
- 「as-terminate-instance-in-auto-scaling-group」コマンドで —decrement-desired-capacity オプションを付けて実行してから、インスタンスIDを指定して実行する。その後、そのインスタンスを terminate すると自動起動せずに落ちる。
-
内容としてはオートスケーリングの設定範囲からこのインスタンスを外すという意味合い
- 例:
as-terminate-instance-in-auto-scaling-group i-f7e9859f --decrement-desired-capacity
実際 Auto Scaling がちゃんと動くかどうか試してみる
設定する
- webサーバのオートスケーリングを想定
- 起動したインスタンスは web-front という Elastic Load Balancer 配下に登録する
- min-size 1 として最低でも1台のインスタンスが起動させること
- トリガーのしきい値は、CPU平均利用率が95%を超えた場合に増えて、20%を下回った場合に減らす
- 上記の状態が180秒継続したらオートスケーリングが実施される
以下の順にコマンドを実行
$ as-create-launch-config TEST-CONFIG -i ami-654ea20c -t m1.small --group default,SSH,Web --key temp-key
$ as-create-auto-scaling-group test-group1 --launch-configuration TEST-CONFIG -z us-east-1a,us-east-1b,us-east-1c,us-east-1d --min-size 1 --max-size 10 --load-balancers web-front
このコマンドを入力した時点で、min-size 1 が有効になって1台インスタンスが起動した。
$ as-create-or-update-trigger WebApp-trigger1 --auto-scaling-group test-group1 --measure CPUUtilization --statistic Average --namespace "AWS/EC2" --dimensions "AutoScalingGroupName=test-group1" --period 60 --lower-threshold 20 --upper-threshold 95 --lower-breach-increment=-1 --upper-breach-increment 1 --breach-duration 180
設定完了。
実際CPUを回してオートスケーリングするかどうか確認してみる
1台起動したインスタンス内で stress コマンドを実施する。(事前にstressをインストールして利用可能な状況にしてある前提)
実行コマンドは以下
# stress -c 1 --timeout 360s
- 起動しているのはスモールインスタンスでCPUは1つなので、Load Average 1 を狙えばCPU利用率は100%になるだろう
- timeout 360s にしているのは、180sec でオートスケーリングされるはずなので、起動時間も考慮して若干長めにとった
AWS Management Console にて確認する。
- 1台目のインスタンスにsshログイン
- stressコマンドを実行
- 最初に起動しているインスタンスの CloudWatch でのモニタリングで、CPU利用率のグラフをみる。
- CPU利用率が100%近くになっていることを確認する
- 180秒くらい経過したときに自動的に1台のインスタンスが起動した
- Load Balancers より、web-front 配下に登録されているインスタンスが2台になっていることを確認
- stress コマンド実行が終了
- しばらく経過して、後から起動した2台目のインスタンスが自動的に terminate した
- 1台のインスタンスのみ起動した状態に戻る
- Load Balancers より、web-front 配下に登録されているインスタンスが1台になっていることを確認
- 確認終了
ちゃんと動いた。
Auto Scaling を使いこなせれば、運用の手間を省くことが出来そうな設定内容になっている。ただし、あくまでサーバの起動・停止をオートスケーリングで行うだけなので、内部のアプリケーションの整合性はユーザ側で事前にとっておく必要がある。
例えば、立ち上げるAMIは自動起動でプロセスが起動する状態で保存しておかなくてはいけないし、Load Balancer 配下に追加した場合、単純なラウンドロビンで分散するので、セッション維持など複数台構成をとっても問題が生じないようにしておく必要もある。
そういう意味ではユーザ側で事前の準備や検証が必要で、その後の運用状況もチェックするようにしておかないと実サービス運用は難しいだろう。
</div>