AWS
Auto Scalingの薄い運説
2013/06/19 JAWS 新宿鮫
株式会社サイバーエージェン
ト
上原 誠
2
株式会社サイバーエージェント
自己紹介
・ ~2012年2月 某SIerでインフラ周りに従事
・ 2012年3月 サイバーエージェント入社
- Amebaスマフォプラットフォームの構築
- 統合ログ解析基盤やオンラインデータベースの
インフラミドルウェア部分を担当
- Hadoop、HBase、Flume
・ 上原 誠 (@pioho07)
【名
前】
【経歴】
3
株式会社サイバーエージェント
4
株式会社サイバーエージェント
5
株式会社サイバーエージェント株式会社サイバーエージェント
スマートフォンサービス
6
株式会社サイバーエージェント
Auto Scalingとは
Auto Scaling により、お客様が定義する条件に応じて、Amazon EC2 の能力を、
自動的に縮小・拡張することができます。Auto Scaling では、お客様が使用中の
Amazon EC2 インスタンスの数を、需要が急上昇した時はシームレスに増やして
パフォーマンスを維持し、需要が弱まる時に自動的に減らすことにより、コスト
を最小化する ことができます
※AWSウェブページより抜粋
ようは、事前に定義したメトリックの閾値や
インターバル等に基づいて、
自動的にインスタンスがスケールする
7
株式会社サイバーエージェント
本日の内容
Auto Scalingの基本的な2つのシナリオで動
かすのと、いくつかの運用TIPSを紹介
※Auto Scalingと連携するサービス
8
株式会社サイバーエージェント
本日の内容
・シナリオ1:負荷を掛けてスケールアウト
・シナリオ2:負荷が減らしてスケールイン
・今回の設定
・シナリオ3:運用TIPS
9
株式会社サイバーエージェント
前提条件①
API接続用のクライアント環境設定
本スライドでは割愛してるが、以下のサーバワークスさんのURL参照
http://blog.serverworks.co.jp/tech/2011/01/17/amazonautoscaling%E6%A9%9F%E8%83%
BD%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/
1.APIを準備する
2.証明書ファイルを作成する
3.APIを利用できるようにする
1~3を実施し、クライアント端末からAuto ScalingとCloudWatchのAPIを叩けるようにして
おく
10
株式会社サイバーエージェント
前提条件②
Auto Scaling概念説明
Auto Scalingの概念はやや複雑。本スライドではシナリオに沿った動作部分に着目してい
る為、概要は以下サーバワークスさんの”Auto Scalingの薄い説明書”が非常にわかり易
いので、事前に読んでおく。
http://www.slideshare.net/serverworks/auto-scaling-
17149997?ref=http://blog.serverworks.co.jp/tech/2013/03/13/auto_scaling_introduction
s/
11
株式会社サイバーエージェント
本日の内容
・シナリオ1:負荷を掛けてスケールアウト
・シナリオ2:負荷が減らしてスケールイン
・今回の設定
・シナリオ3:運用TIPS
12
株式会社サイバーエージェント
Auto Scaling Group内のインスタンス台数を下限2台上限8台の2~8台とする
AutoScaleGroup全体のCPUが閾値65%以上が1~2分程続くと、指定したAMIとインスタンスタイプで、新
しいインスタンスを1台Launchする(増やす)
SNSでAutoScalingのLaunchの旨をメール通知する
MultiAZの場合は、AZへ均等台数配置する
AMIはApache自動起動済みのイメージとする
指定したLBへ自動的に組み込まれる
Launch完了後さらに3分(cooldown)待って、1分(period)ごとのCPU使用率モニタで65%超えてたらさらに1
台インスタンスをLaunchする(増やす)。さらに3分(cooldown)待ってCPU閾値超えていたら1台Launchす
る。
CPU使用率が40%以下になった状態が1分続いたらインスタンスをterminateする(減らす)
SNSでAutoScalingのTerminateの旨をメール通知する
今回のAuto Scaling設定内容説明
・grace-period
インスタンスが起動してヘルスチェックを
始めるまでの待ち時間
アプリの起動時間などを考慮した猶予時間
・cooldown
次のアクションまでのインターバル
・period
CloudWatchのkなしインターバル
13
株式会社サイバーエージェント
①LaunchConfig
起動するEC2の設計書(AMI、インスタンスタイプ、SSHキー、セキュリティグループ)
②AutoScalingGroup
Auto Scaling全体設計(Launch Config、最大台数、最小台数、AZ、ELB、VPC、ヘルスチェック)
③ScaleOutPolicy
スケールアウト設計書(増加させる台数、スケール後の待機時間)
④ScaleOutAlarm
監視閾値とアクション設計(CloudWatchの監視間隔、監視対象、監視メトリクス、閾値、アクション実行まで
の評価回数、アクション内容(アクションはScaleInPolicy))
⑤ScaleInPolicy
スケールアウトの設計書(減少させる台数、スケール後の待機時間)
⑥ScaleInAlarm
監視閾値とアクションの設計(CloudWatchの監視間隔、監視対象、監視メトリクス、閾値、アクション実行ま
での評価回数、アクション内容(アクションはScaleInPolicy))
Auto Scalingに必要なモノ(コンフィグ)
14
株式会社サイバーエージェント
①LaunchConfig
as-create-launch-config test-lc --image-id ami-0969exxx --instance-type t1.micro --key test_key --group sg-bd819xxx
②AutoScalingGroup
as-create-auto-scaling-group test-as-group --launch-configuration test-lc --availability-zones ap-northeast-1a,ap-northeast-1c --desired-
capacity 2 --min-size 2 --max-size 8 --load-balancers “test-lb01" --health-check-type ELB --grace-period 60 --vpc-zone-identifier "subnet-
52be4xxx,subnet-51be4xxx" --tag "k=Name,v=AutoScale01,p=true"
③ScaleOutPolicy
as-put-scaling-policy test-scaleout-policy --auto-scaling-group test-as-group --type ChangeInCapacity --adjustment=1 --cooldown 180
④ScaleOutAlarm
mon-put-metric-alarm test-scaleout-alarm --period 60 --dimensions "AutoScalingGroupName=test-as-group" --namespace "AWS/EC2" --
metric-name CPUUtilization --evaluation-periods 1 --statistic Average --threshold 65 --comparison-operator GreaterThanThreshold --alarm-
actions arn:aws:autoscaling:ap-northeast-1:302441370xxx:scalingPolicy:77a01658-98c7-48e1-bb0b-2430e79f2xxx:autoScalingGroupName/test-as-
group:policyName/test-scaleout-policy
⑤ScaleInPolicy
as-put-scaling-policy test-scalein-policy --auto-scaling-group test-as-group --type ChangeInCapacity "--adjustment=-1" --cooldown 180
⑥ScaleInAlarm
mon-put-metric-alarm test-scalein-alarm --period 60--dimensions "AutoScalingGroupName=test-as-group" --namespace "AWS/EC2" --
metric-name CPUUtilization --evaluation-periods 1 --statistic Average --threshold 40 --comparison-operator LessThanThreshold --alarm-actions
arn:aws:autoscaling:ap-northeast-1:302441370xxx:scalingPolicy:2aecb2cf-ad81-4e33-b4e0-a2778feadxxx:autoScalingGroupName/test-as-
group:policyName/test-scalein-policy
実際の設定コマンド(①~⑥の実設定)②のTagは付けないとあとで訳
分からなくなるので必須かな
15
株式会社サイバーエージェント
SNS詳細は以下suz-labさんのサイト参照
http://blog.suz-lab.com/2012/09/auto-scalingec2sns.html
まずはSNSのトピック作成です。"Auto Scaling"のコマンドで通知先を設定するときにこのトピックを指定。
次に作成したトピックに対して、サブスクリプションを設定します。
サブスクリプションはトピックに投げられたメッセージの通知先(メール)となります。
設定だけでは有効にならず、下記のメールが届くので本文中の確認用のリンクをクリックする必要があります。
通知できるアクションの種類は下記の通りです。
# as-describe-auto-scaling-notification-types
NOTIFICATION-TYPE autoscaling:EC2_INSTANCE_LAUNCH
NOTIFICATION-TYPE autoscaling:EC2_INSTANCE_LAUNCH_ERROR
NOTIFICATION-TYPE autoscaling:EC2_INSTANCE_TERMINATE
NOTIFICATION-TYPE autoscaling:EC2_INSTANCE_TERMINATE_ERROR
NOTIFICATION-TYPE autoscaling:TEST_NOTIFICATION
作成したトピックに対してすべて通知設定
c:ASbin>as-put-notification-configuration test-as-group --notification-types
autoscaling:EC2_INSTANCE_LAUNCH,autoscaling:EC2_INSTANCE_LAUNCH_ERROR,autoscaling:EC2_INSTANCE_TERMINATE,autoscaling:EC2_INS
TANCE_TERMINATE_ERROR,autoscaling:TEST_NOTIFICATION --topic-arn "arn:aws:sns:ap-northeast-1:302441370058:vpc-as"
OK-Put Notification Configuration
SNS設定
Notificationの内容見ても
わかるようにAutoscalingが行う
動作はLaunchかTerminate
16
株式会社サイバーエージェント
それ以外にも時間指定してインスタンスを増減させるスケジューリング機能もある。
今回の動作対象としてないので例だけ書いておく。
※ちなみにうまく動きました。
指定した時刻に4台にするスケジュール(test-ScheduleScaleOut1)を作る
as-put-scheduled-update-group-action test-ScheduleScaleOut1 --auto-scaling-group test-as-group --time 2013-06-13T08:20:00Z --min-size
4 --max-size 4
c:ASbin>as-put-scheduled-update-group-action test-ScheduleScaleOut1 --auto-scaling-group test-as-group --time 2013-06-13T07:00:00Z
--min-size 3 --max-size 4
OK-Put Scheduled Update Group Action
c:ASbin>as-describe-scheduled-actions
UPDATE-GROUP-ACTION test-as-group test-ScheduleScaleOut1 2013-06-13T07:00:00Z 3 4
補足
17
株式会社サイバーエージェント
本日の内容
・シナリオ1:負荷を掛けてスケールアウト
・シナリオ2:負荷が減らしてスケールイン
・今回の設定
・シナリオ3:運用TIPS
18
株式会社サイバーエージェント
・初めの状態はインスタンスがminimum台数の2台。
・インスタンスにCPU負荷を掛けCPU使用率を100%にする。インスタンスが1つ追加される。
Cloudwatchインターバルが60秒なので120秒程度待つ。
・さらに3分間(cooldown)CPU使用率を100%にする。続けてインスタンスが1つ追加される。
※インスタンスがLaunch,Terminateされる度に通知メールが来ること
シナリオ1:負荷を掛けてスケールアウト
19
株式会社サイバーエージェント
無限ループさせるスクリプト(cpubusy.pl)でCPU100%にする。
2台分のインスタンスのCPU使用率を100%にすることで、Auto Scaling Group全体のCPU使用率が100%
になる。
サーバに負荷を掛ける
20
株式会社サイバーエージェント
以下コマンドでグループ全体のCPU使用率を確認し、しばらく待つ。
c:CWbin>mon-get-stats --metric-name "CPUUtilization" --statistics "Average" --namespace
"AWS/EC2" --dimensions "AutoScalingGroupName=test-as-group"
2013-06-17 07:49:00 0.0 Percent
2013-06-17 07:50:00 1.665 Percent
2013-06-17 07:51:00 0.835 Percent
2013-06-17 07:52:00 68.85333333333334 Percent
2013-06-17 07:53:00 100.0 Percent
サーバに負荷を掛ける
100%になってきた
21
株式会社サイバーエージェント
差出人:test-as <no-reply@sns.amazonaws.com>
件名:Auto Scaling: launch for group "test-as-group“
本文:Service: AWS Auto Scaling
Time: 2013-06-17T08:28:35.345Z
RequestId: 3d53a48c-2a99-4619-a0b0-fbf359469fe6
Event: autoscaling:EC2_INSTANCE_LAUNCH
AccountId: 302441370058
AutoScalingGroupName: test-as-group
AutoScalingGroupARN: arn:aws:autoscaling:ap-northeast-
1:302441370058:autoScalingGroup:f66c7227-8422-41e8-96cc-
9e067b5da0ea:autoScalingGroupName/test-as-group
Description: Launching a new EC2 instance: i-a4640xxx
:
SNSの通知が来る
メール来た
EventでLaunchした旨がわかる
InstanceIDもDescriptionに書かれてる
22
株式会社サイバーエージェント
1分経つとインスタンスのLaunchが開始されたことが確認できる。
以下コマンドでグループ内のインスタンス状態確認。1台”i-b2177xxx”のインスタンスがLaunchされだし
ている。しばらくして、ELBからEC2のステータスが”InService”になればOK。
c:ASbin>as-describe-auto-scaling-groups
AUTO-SCALING-GROUP test-as-group test-lc ap-northeast-1c,ap-northeast-1a test-lb01 2 8
3 Default
INSTANCE i-9a0a6xxx ap-northeast-1a InService Healthy test-lc
INSTANCE i-b20f6xxx ap-northeast-1c InService Healthy test-lc
INSTANCE i-b2177xxx ap-northeast-1c Pending Healthy test-lc
TAG test-as-group auto-scaling-group Name AutoScale01 true
サーバに負荷を掛ける
23
株式会社サイバーエージェント
※今回の上限値の8台までリニアにスケールすることを確認できた。
増えたインスタンスにCPU負荷を掛けることを繰り返すことで常にグループ全体のCPU使用率が高い状
態を保った。結果8台までインスタンスがLaunchされ、高負荷状況でもそれ以上はLaunchされなかった。
サーバに負荷を掛ける
24
株式会社サイバーエージェント
本日の内容
・シナリオ1:負荷を掛けてスケールアウト
・シナリオ2:負荷が減らしてスケールイン
・今回の設定
・シナリオ3:運用TIPS
25
株式会社サイバーエージェント
シナリオ1の続き、2台のインスタンスに掛けたCPU負荷を停止する。しばらく経つと1台のterminateが
始まる。
c:ASbin>as-describe-auto-scaling-groups
AUTO-SCALING-GROUP test-as-group test-lc ap-northeast-1c,ap-northeast-1a ue-lb01 2 8
4 Default
INSTANCE i-9a0a6xxx ap-northeast-1a Terminating Healthy test-lc
INSTANCE i-10167xxx ap-northeast-1a InService Healthy test-lc
INSTANCE i-b2177xxx ap-northeast-1c InService Healthy test-lc
INSTANCE i-4a197xxx ap-northeast-1c InService Healthy test-lc
TAG test-as-group auto-scaling-group Name AutoScale01 true
シナリオ2:負荷が減らしてスケールイン
Terminate始まった
26
株式会社サイバーエージェント
差出人:test-as <no-reply@sns.amazonaws.com>
件名:Auto Scaling: termination for group "test-as-group“
本文:Service: AWS Auto Scaling
Time: 2013-06-17T08:36:51.279Z
RequestId: a33730d6-869c-416f-a3ba-469b513d2022
Event: autoscaling:EC2_INSTANCE_TERMINATE
AccountId: 302441370058
AutoScalingGroupName: test-as-group
AutoScalingGroupARN: arn:aws:autoscaling:ap-northeast-
1:302441370058:autoScalingGroup:f66c7227-8422-41e8-96cc-
9e067b5da0ea:autoScalingGroupName/test-as-group
Description: Terminating EC2 instance: i-4a197xxx
:
SNSの通知が来る
メール来た
EventでTerminateした旨がわかる
InstanceIDもDescriptionに書かれてる
27
株式会社サイバーエージェント
さらに3分経つと2台目のインスタンスのterminateも始まり、最小インスタンス台数の2台となる。
c:ASbin>as-describe-auto-scaling-groups
AUTO-SCALING-GROUP test-as-group test-lc ap-northeast-1c,ap-northeast-1a test-
lb01 2 8 2 Default
INSTANCE i-10167xxx ap-northeast-1a InService Healthy test-lc
INSTANCE i-4a197xxx ap-northeast-1c InService Healthy test-lc
TAG test-as-group auto-scaling-group Name AutoScale01 true
シナリオ2:負荷が減らしてスケールイン
28
株式会社サイバーエージェント
Auto Scalingで行うアクションは、Launch、Terminateのみ
インスタンスを作る(Launch)、消す(Terminate)のみ
Notificationできる種類にもある通り、この2種類しかアクションはない。
インスタンスをStopとかできない。問答無用で消す。
シナリオ1,2から
29
株式会社サイバーエージェント
今回はバタつかなかったが、別の環境で実装した際にバタつきがおきました。
バタつくとは、インスタンスのTerminateとLaunchを繰り返す状態。
原因はAuto ScalingのGracePeriodとELBのIntervalとHealthCheck設定でした。
ELBのヘルスチェックデフォルト値は、Interval 30s、HealthyThreshold 10となっており、これだと30s*10回
=300s後にインスタンスステータスが”InService”となる設定になります。
Auto ScalingのGracePeriodがこれより短い値だと、インスタンスLaunch後GracePeriodの時間が経過して
からAuto Scaling側のヘルスチェックを行いますが、ELB側でHealthyThresholdの回数分チェックがまだ
行われてない為ステータスがInServiceとなっていません。その為Auto Scaling側のヘルスチェックも失敗
するので(Auto Scalingが行うヘルスチェックはELBのステータスを見る為) 、Auto Scalingがインスタンス
をterminateし、その後LaunchとTerminateを繰り返します。
なので必ず ASのGracePeriod>ELBのHealthyThreshold*Interval としてください。
バタついた!?
30
株式会社サイバーエージェント
ややこしいですが、複数サービスと連携している為、各サービスで時間についてのパラメータを持ってい
ます。
①Auto Scaling
-GracePeriod:Launch後ヘルスチェック開始するまでの時間
-Cooldown:Launch後次のアクション実行までの待機時間
②ELB
-Interval:ELBのインスタンスへの監視間隔
-HealthyThreshold:連続指定回数OKだとインスタンスステータスを”InService”とする閾値
③Cloudwatch
-Period:CloudWatchの監視間隔
※CloudWatchでのCPU閾値モニタリング間隔は60秒(ScaleOut(In)Alarm設定より)
バタついた!?
31
株式会社サイバーエージェント
Launch
インスタンス起動
GracePeriod
ヘルスチェック開始
1分
Cooldown
次のアクション開始
3分
ELBのHealthyThreshold*Interval
Interval0.5分(30秒)*Threshold10=300秒
Auto Scaling
ELB
②ELBがここで
インスタンスを正常と認識
①ELBがここではまだ
正常と認識してない
③なのでヘルスチェック
NGでターミネートする
④次のアクションで
Launchし、これを繰り返す
ELBのインターバル設定が長いと
32
株式会社サイバーエージェント
Launch
インスタンス起動
GracePeriod
ヘルスチェック開始
1分
Cool-down
次のアクション開始
3分
ELBのHealthyThreshold*Interval
Interval0.2分(12秒)*Threshold4=48秒
Auto Scaling
ELB
ELBのインターバル設定を短くした
②Auto Scalingのヘルスチェックで
“ELBでのインスタンスの正常性”を確認し
OKなので正常と見なす
①ELBがここで
インスタンスを正常と認識
・・・だと思います
ドキュメントがないので検証結果を
基にした推測となります。
33
株式会社サイバーエージェント
GracePeriod確認方法
as-describe-auto-scaling-groups --show-long
AUTO-SCALING-GROUP,test-as-group,test-lc01,“ap-northeast-1c,ap-northeast-1a”,2013-06-
18T10:23:18.312Z,ue-lb01,ELB,4,8,4,180,60,“subnet-・・・
赤字の左がCooldown、右がGracePeriod
バタついた!?
34
株式会社サイバーエージェント
本日の内容
・シナリオ1:負荷を掛けてスケールアウト
・シナリオ2:負荷が減らしてスケールイン
・今回の設定
・シナリオ3:運用TIPS
35
株式会社サイバーエージェント
Auto Scaling実装後の運用での”あるある”シナリオ
シナリオ3:運用TIPS①~⑧
36
株式会社サイバーエージェント
まず、確実にあるインスタンスへのデプロイや設定変更作業する時
常にAMIをベースでイメージ化しておく必要がある(AMIからLauch後にchefでデプロイとかNG)
・インスタンスへの直接変更はしない。
・AMIを更新する
・AMIのIDを指定しているLaunchConfigの更新
・LaunchConfigを指定しているAutoScalingGroupの更新
・ローリングオートスケーリング実施
※勝手にローリングオートスケーリングと言ってしまいましたが、AMI更新作業後に1台Terminateすると
新しいAMIで勝手にLauchされます。それを繰り返す事です。
運用①:サーバ(インスタンス)の更新
37
株式会社サイバーエージェント
Auto Scalingなので、AMIを更新しないとダメ
インスタンスを修正しても、AMIを更新できてないと元のイメージでLaunchされて元の状態のインスタン
スが出来てしまう。デグレっちゃう。
インスタンスへの直接変更はしない。
38
株式会社サイバーエージェント
・グループ外のインスタンスを1つ、AMIの雛形用に作成しておく
・手動でインスタンスを作ればAutoScalingGroup外のインスタンスとなる
・このインスタンスはLBに入れようが入れなくても構わない。LBに入れてもAutoScalingGroupに入る訳
ではない。
・インスタンスに変更を加えたい場合、このインスタンスに対して更新を行い、このインスタンスからAMI
を作成する
※雛形インスタンスはグループ内でも構わないが、グループ外としておくことで、グループ内インスタン
スをのこしたまま動作確認にも使える。確認後にAMI作成し、グループ内インスタンスも更新していくと
いいかと
AMIを更新する
39
株式会社サイバーエージェント
更新と言ったが、新しいLaunchConfigを作成する
as-create-launch-config test-lc02 --image-id ami-xxxxxxxx --instance-type t1.micro --key
handson_key --group ue_s_group01
AMIのIDを指定しているLaunchConfigの更新
新しいLaunchconfig名で新しいAMIのIDを指定して、
新しいLaunchConfigを作る。
それ以外は変えず
40
株式会社サイバーエージェント
as-update-auto-scaling-group test-as-group –-launch-configuration test-lc02
LaunchConfigを指定しているAutoScalingGroup
の更新
これで、AutoScalingGroupの
AMIが新しいものになった
41
株式会社サイバーエージェント
既存のインスタンスを手動でTerminateする
Terminateが完了すると、Auto Scalingは現状のインスタンス台数を保持しようとする為、
新しいインスタンスをLaunchする。
この時新しいAutoScalingGroupで定義したLauchConfigにあるAMI(新しいAMI)を使ってインスタンスが
Launchされる
1台のTerminate、Launchが完了したら、2台目3台目とローリングで実施する
ローリングでインスタンス置き換え実施
42
株式会社サイバーエージェント
現在負荷が来るのが分かっていてスケジューリングするのでは遅く、悠長に設定したポリシー通り増やし
てのでは遅い状況で、すぐに指定台数増やしたい時(多分こういうシチュエーション)
以下コマンドでインスタンス台数を5台に増やせる。
as-set-desired-capacity test-as-group --desired-capacity 5
ただし指定台数は、AutoScalingGroupでの下限上限の範囲内で指定可能
※desired-capacityとmin-sizeが似ているが、前者の方が使いどころが限定的というか、あまりない気が
する
as-set-desired-capacity test-as-group --desired-capacity 5
as-update-auto-scaling-group test-as-group –min-size 5
運用②:一気にインスタンスを指定台数にする
43
株式会社サイバーエージェント
以下の赤字部分がdesired-capacityの値
as-describe-auto-scaling-groups
AUTO-SCALING-GROUP test-as-group test-lc ap-northeast-1c,ap-northeast-1a test-lb01 2 8 5
Default
INSTANCE i-94264xxx ap-northeast-1a InService Healthy test-lc
INSTANCE i-02294xxx ap-northeast-1c InService Healthy test-lc
INSTANCE i-02294xxx ap-northeast-1c InService Healthy test-lc
INSTANCE i-02294xxx ap-northeast-1c InService Healthy test-lc
INSTANCE i-02294xxx ap-northeast-1c InService Healthy test-lc
TAG test-as-group auto-scaling-group Name AutoScale01 true
スケールイン、スケールアウトポリシーはそのまま継続して有効で、上記のように5台にして負荷が閾値以下なら
ポリシーに乗っ取りTerminateされていく、逆に閾値を超えていればポリシーに乗っ取りLaunchされていく
運用②:一気にインスタンスを指定台数にする
44
株式会社サイバーエージェント
オートスケールのアクションを一旦無効にしたい時
以下コマンドでtest-scalin-alarmを無効(enableで有効)、閾値超えてもLaunchしない
mon-disable-alarm-actions test-scalein-alarm
確認は以下コマンドで、有効時は↓の赤字がtrue
mon-describe-alarms --show-long
test-scalein-alarm,(nil),ALARM,Threshold Crossed: 1 datapoint (38.21) was less t
han the threshold (40.0).,"{"version":"1.0","queryDate":"2013-06-
06T09:19:10.158+0000","startDate":"2013-06-
16T09:14:00.000+0000","statistic":"Average","period":300,"recentDatapoints":[38.21],"threshold":40.0}",fals
e,(nil),arn:aws:sns:ap-northeast-
1:302441370058:test,(nil),AWS/EC2,CPUUtilization,{AutoScalingGroupName=test-as-
group},300,Average,(nil),1,LessThanThreshold,40.0test-scaleout-alarm,(nil),OK,Threshold Crossed: 1
datapoint (56.391818181818174) was not greater than the threshold
(65.0).,"{"version":"1.0","queryDate":"2013-06-16T09:18:19.823+0000","startDate":"2013-06-
16T09:13:00.000+0000","statistic":Average,"period":300,"recentDatapoints":[56.391818181818174],"thresho
ld":65.0},
運用③:アラーム(トリガ)の一時的に停止
45
株式会社サイバーエージェント
・ASG内の台数をポリシーに沿って増やし(減らし)たい時、テストでポリシーの確認したい時とか
-増やす(ポリシー台数に沿って)
as-execute-policy test-scaleout-policy --auto-scaling-group test-as-group
-減らす
as-execute-policy test-scalein-policy --auto-scaling-group test-as-group
・指定インスタンスを消したい時、インスタンスID指定してAutoScalingGroup内インスタンスを消せる
(min以下は怒られる)
as-terminate-instance-in-auto-scaling-group i-54c7a656 --decrement-desired-capacity
Are you sure you want to terminate this instance? [Ny]y
INSTANCE ad9c84c2-265b-4f9d-8b36-3e33dc16955d InProgress At 2013-06-17T04:29:
27Z instance i-54c7a656 was taken out of service in response to a user request,shrinking the capacity from 3
to 2.
:
運用④:手動で増やす減らす
46
株式会社サイバーエージェント
・行動ログ閲覧したい時、以下はuserrequestによりdesiredcapacityが0->2になったことが分かる。他にも有用
な情報は取れそう。
※Auto Scalingのログってこれくらい
as-describe-scaling-activities
c:ASbin>as-describe-scaling-activities --auto-scaling-group test-as-group --show-long
ACTIVITY,195c3391-93bb-4f54-99f1-cf2b7c97949e,2013-06-17T02:53:00Z,test-as-group,Successful,(nil),"At
2013-06-17T02:52:22Z a user request created an AutoScaling
Group changing the desired capacity from 0 to 2. At 2013-06-17T02:52:27Z an instance was started in
response to a difference between desired and actual capacity, increasing the capacity from 0 to
2.",100,Launching a new EC2 instance: i-30f39232,(nil),2013-06-17T02:52:27.149Z
ACTIVITY,a3de4c39-b073-4593-88e4-c3d0a2444caa,2013-06-17T02:53:01Z,test-as-
group,Successful,(nil),"At 2013-06-17T02:52:22Z a user request created an AutoScaling
Group changing the desired capacity from 0 to 2. At 2013-06-17T02:52:27Z an instance was started in
response to a difference between desired and actual capacity, increasing the capacity from 0 to
2.",100,Launching a new EC2 instance: i-36f39234,(nil),2013-06-17T02:52:27.149Z
運用⑤:Auto Scalingのアクティビティログ
47
株式会社サイバーエージェント
・AutoScalingの機能を一旦止めたい時 as-suspend-processes test-as-group コマンド成功するとOKとでる。確認は↓
as-describe-auto-scaling-groups ※現状インスタンスには影響なし
AUTO-SCALING-GROUP test-as-group test-lc ap-northeast-1c,ap-northeast-1a ue-lb01 2 8 2 Default
INSTANCE i-645c3a66 ap-northeast-1c InService Healthy test-lc
INSTANCE i-d65d3bd4 ap-northeast-1a InService Healthy test-lc
SUSPENDED-PROCESS HealthCheck User suspended at 2013-06-16T05:00:03Z test-as-group
SUSPENDED-PROCESS AddToLoadBalancer User suspended at 2013-06-16T05:00:03Z test-as-group
SUSPENDED-PROCESS Launch User suspended at 2013-06-16T05:00:03Z test-as-group
SUSPENDED-PROCESS RemoveFromLoadBalancerLowPriority User suspended at 2013-06-16T05:00:03Z test-as-group
SUSPENDED-PROCESS AZRebalance User suspended at 2013-06-16T05:00:03Z test-as-group
SUSPENDED-PROCESS ScheduledActions User suspended at 2013-06-16T05:00:03Z test-as-group
SUSPENDED-PROCESS Terminate User suspended at 2013-06-16T05:00:03Z test-as-group
SUSPENDED-PROCESS ReplaceUnhealthy User suspended at 2013-06-16T05:00:03Z test-as-group
SUSPENDED-PROCESS AlarmNotification User suspended at 2013-06-16T05:00:03Z test-as-group
・有効化 as-resume-processes test-as-group コマンド成功するとOKとでる。確認は↓
c:ASbin>as-describe-auto-scaling-groups
AUTO-SCALING-GROUP test-as-group test-lc ap-northeast-1c,ap-northeast-1a ue-lb01 2 8 2 Default
INSTANCE i-645c3a66 ap-northeast-1c InService Healthy test-lc
INSTANCE i-d65d3bd4 ap-northeast-1a InService Healthy test-lc
※suspend中に1台減らしてresumeしたら、1台のunhealthyを認識後1台増加した。
運用⑥:Auto Scalingの無効化
AutoScalingGroupを消しちゃうと、
配下のインスタンスは
全部Terminateされちゃう!
48
株式会社サイバーエージェント
・なんらかの理由で、インスタンスは残してAuto Scalingの設定を消したい時
AutoScalingGroupを削除すると、グループ内のインスタンスは全てTerminateされる
サービスインのままシームレスにやりたい場合、
事前にグループ内と同じ台数のインスタンスを手動Launchする(グループ外インスタンスとなる)
グループ外インスタンスのサービスインされたことを確認した後に、AutoScalingGroupを削除する
グループ内インスタンスもTerminateされる
サービスインさせているグループ外インスタンスがいる為サービス影響はない。
運用⑦:Auto Scaling削除
49
株式会社サイバーエージェント
落ちても立ち上がるサーバですね。
AutoScalingGroupに設定する最小台数(min-size)があります。Auto Scalingはこの台数を下回った場
合は、その台数を維持するよう新しいInstanceをLaunchします。
つまり、極端な話それほど負荷が来ないし1台のサーバでいいようなシステムでも
Auto Scalingを使うことで、サーバ1台でステータスがNGとなったら新しいInstanceを
自動的にLaunchする可用性を高めたサービス運用が可能です。
本来だと可用性を高めるためにELBの下に最低2台のインスタンスを入れますが、
それが不要となり、AWSのInstanceコスト削減にもなります。
※AWS全体の費用でインスタンスにかかる費用が支配的な為、この効果は大きい
※2台並べる構成よりダウンタイムは大きくなります。
運用⑧:Auto Healing
50
株式会社サイバーエージェント
Auto Scalingを理解し制御できるようになってからの導入・運用がよいと思います。
必要十分な試験を行ってはいないですが、制御できるようであれば問題なく動きそうです。
今後、ManagementConsoleが出ると思われます。Auto Scalingのツールも日々進化しているので、現状
での導入後は定期的なキャッチアップが必要です。
APIツールは常に最新にしよう!
まとめ
51
株式会社サイバーエージェント
API環境設定:サーバワークスさんのサイト参照
http://blog.serverworks.co.jp/tech/2011/01/17/amazonautoscaling%E6%A9%9F%E8%83%BD%E3%81%AB
%E3%81%A4%E3%81%84%E3%81%A6/
SNS設定:suz-labさんのサイト参照
http://blog.suz-lab.com/2012/09/auto-scalingec2sns.html
Auto Scaling薄い教科書:サーバワークスさんのサイト参照
http://www.slideshare.net/serverworks/auto-scaling-
17149997?ref=http://blog.serverworks.co.jp/tech/2013/03/13/auto_scaling_introductions/
Thank you
参考URL
52
株式会社サイバーエージェント
ご清聴ありがとうございました!

Aws st 20130617-auto_scaling