Auto ScalingのAPIツールのバージョンアップを行なっておく
# yum list updates | grep apitools
アップデートコマンドの実行
# yum update aws-apitools-as
AutoScaling組み込み用インスタンスの設定
インスタンス作成時のコマンドと同じ引数を渡します。
# as-create-launch-config myapp-auto-scaling-config --key hoge-key --image-id ami-00000000 --group default --group ssh --instance-type t1.micro --region ap-northeast-1 --user-data "MY-APP"
確認コマンド
# as-describe-launch-configs
AutoScaling設定
このタイミングでauto-scalingのタグが付いたインスタンスが生成される（つまりインスタンスが起動して課金が始まるので注意。また、–load-balancersの指定が入っているとLoadBarancerへの組み込みも開始されます。）
grace-period：300秒間は起動処理・CPUの安定時間としてLoadBarancerへの組込までに猶予をもたせた設定をしています。アプリケーションの起動や初期化処理にかかる時間を予め見越して設定をしておきます。
min-size:最低4台を常時起動させる
max-size:最大10台を常時起動させる
タグ作成時のコマンドと同じタグを渡します。
なお、このあとのスケールイン設定・スケールアウト設定の際に、min-sizeとmax-sizeが同じだと新しいインスタンスが作成されないため、min-size < max-sizeに設定をしておく必要があります。またインスタンスの数はAZの倍数がバランスが良くなります。
health-check-type ELB を設定しておくことで、ELBに対してのヘルスチェックがフックになるので、ELBにぶら下がったEC2のインスタンスのApacheプロセスが停止した際などにTerminateして新しいインスタンスが生成されるようになります。
# as-create-auto-scaling-group myapp-auto-scaling-group --launch-configuration myapp-auto-scaling-config --availability-zones ap-northeast-1c,ap-northeast-1a --min-size 4 --max-size 10 --load-balancers myapp-load-balancers --health-check-type ELB --grace-period 300 --tag "k=Domain,v=myapp.com,p=true" --tag "k=Name,v=myapp,p=true"
確認コマンド
# as-describe-auto-scaling-groups
スケールアウト設定
adjustment=1：1台増やす
cooldown：増やしたあと300秒間は増減処理を行わない
# as-put-scaling-policy myapp-auto-scaling-policy-out --auto-scaling-group myapp-auto-scaling-group --adjustment=1 --type ChangeInCapacity --cooldown 300
スケールイン設定
adjustment=-1：1台減らす
cooldown：減らしたあと1800秒間は増減処理を行わない。インスタンス課金は1時間単位のため、長めの時間を設定する
# as-put-scaling-policy myapp-auto-scaling-policy-in --auto-scaling-group myapp-auto-scaling-group --adjustment=-1 --type ChangeInCapacity --cooldown 1800
以下の手順にそってコンソール画面からCloudWatchアラートの設定を行う
http://mtl.recruit.co.jp/blog/2011/10/amazon_webservice_autoscaling.html
スケールアウトのしきい値：5分間のCPU平均値が90%を超えた場合にインスタンスを増加
スケールインのしきい値：5分間のCPU平均値が30%以下になった場合にインスタンスを減少
などのように設定します。
スケールアウトのしきい値は先ほど設定したgrace-periodの時間分を見越した値にしておく必要があります。（しきい値を超えてからインスタンスを起動してgrace-periodの秒数待ってELBへの組み込みんあるため）
スケール員のしきい値もcooldownの時間分、無防備状態になるので、それを見越した値にしておく必要があります。
CPU平均値が40％の時にはアラートが常時1件ある状態になるのがちょっと違和感を感じますが。。。
スケールアウト・スケールインするタイミングでアラートメールを送るように設定することも可能です。
通常増減時と増減エラー時で送信先のメールを振り分けることが可能です。
正常時のメール送信設定
# as-put-notification-configuration myapp-auto-scaling-group --notification-types autoscaling:EC2_INSTANCE_LAUNCH,autoscaling:EC2_INSTANCE_TERMINATE,autoscaling:TEST_NOTIFICATION --topic-arn arn:aws:sns:ap-northeast-1:000000000000:myapp-mail-info
エラー時のメール送信設定
# as-put-notification-configuration myapp-auto-scaling-group --notification-types autoscaling:EC2_INSTANCE_LAUNCH_ERROR,autoscaling:EC2_INSTANCE_TERMINATE_ERROR --topic-arn arn:aws:sns:ap-northeast-1:0000000000:myapp-mail-alert
夜間のインスタンス縮小設定
日本時間 0時(UTC 15時） にスケールイン
# as-put-scheduled-update-group-action myapp-auto-scaling-action-in -g myapp-auto-scaling-group --region ap-northeast-1 --recurrence "0 15 * * *" -min-size 2 -max-size 4
日本時間 6時（UTC 21時）にスケールアウト
# as-put-scheduled-update-group-action myapp-auto-scaling-action-out -g myapp-auto-scaling-group --region ap-northeast-1 --recurrence "0 21 * * *" -min-size 4 -max-size 10
確認用コマンド
# as-describe-scheduled-actions
スケジューリングをして夜間だけインスタンスを減らす場合、
-min-size 4 -max-size 10
↓
-min-size 2 -max-size 4
のように設定します。
今4台稼働してるから、2台に減らない？と一瞬思いますが実は AWSのAuto Scalingには
--desired-capacity
なる引数が存在しており、
Auto Scalingが良い感じの台数にスケーリングしてくれるという設定になっており、
desired-capacityの引数を特に指定しない場合、
min-size=desired-capacity
になります。
そのため、
min-size
の台数に下がっていきます。
