• Save
Aws st 20130617-auto_scaling
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Aws st 20130617-auto_scaling

  • 3,536 views
Uploaded on

JAWS新宿鮫 ...

JAWS新宿鮫
勉強会資料、AutoScaling 実装・運用編

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,536
On Slideshare
3,536
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
19

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. AWS Auto Scalingの薄い運説 2013/06/19 JAWS 新宿鮫 株式会社サイバーエージェント CAMP事業部 システムグループ 上原 誠
  • 2. 2 株式会社サイバーエージェント 自己紹介 ・ ~2012年2月 某SIerでインフラ周りに従事 ・ 2012年3月 サイバーエージェント入社 - Amebaスマフォプラットフォームの構築 - 統合ログ解析基盤やオンラインデータベースの インフラミドルウェア部分を担当 - Hadoop、HBase、Flume ・ 上原 誠 (@pioho07) 【名前】 【経歴】 Facebook申請歓迎 makoto.uehara.39
  • 3. 3 株式会社サイバーエージェント
  • 4. 4 株式会社サイバーエージェント
  • 5. 5 株式会社サイバーエージェント株式会社サイバーエージェント スマートフォンサービス
  • 6. 6 株式会社サイバーエージェント Auto Scalingとは Auto Scaling により、お客様が定義する条件に応じて、Amazon EC2 の能力を、 自動的に縮小・拡張することができます。Auto Scaling では、お客様が使用中の Amazon EC2 インスタンスの数を、需要が急上昇した時はシームレスに増やして パフォーマンスを維持し、需要が弱まる時に自動的に減らすことにより、コスト を最小化する ことができます ※AWSウェブページより抜粋 ようは、事前に定義したメトリックの閾値や インターバル等に基づいて、 自動的にインスタンスがスケールする
  • 7. 7 株式会社サイバーエージェント 本日の内容 AutoScalingの基本的な2つのシナリオで動 かすのと、いくつかの運用TIPSを紹介 ※AutoScalingと連携するサービス
  • 8. 8 株式会社サイバーエージェント 本日の内容 ・シナリオ1:負荷を掛けてスケールアウト ・シナリオ2:負荷が減らしてスケールイン ・今回の設定 ・シナリオ3:運用TIPS
  • 9. 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を実施し、クライアント端末からAutoScaleとCloudWatchのAPIを叩けるよう にしておく
  • 10. 10 株式会社サイバーエージェント 前提条件② AutoScaling概念説明 AutoScalingの概念はやや複雑。本スライドではシナリオに沿った動作部分に着目 している為、概要は以下サーバワークスさんの”AutoScalingの薄い説明書”が非 常にわかり易いので、事前に読んでおく。 http://www.slideshare.net/serverworks/auto-scaling- 17149997?ref=http://blog.serverworks.co.jp/tech/2013/03/13/auto_scaling_in troductions/
  • 11. 11 株式会社サイバーエージェント 本日の内容 ・シナリオ1:負荷を掛けてスケールアウト ・シナリオ2:負荷が減らしてスケールイン ・今回の設定 ・シナリオ3:運用TIPS
  • 12. 12 株式会社サイバーエージェント AutoScalingGroup内のインスタンス台数を下限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の旨をメール通知する 今回のAutoScaling設定内容説明 ・grace-period インスタンスが起動してヘルスチェックを 始めるまでの待ち時間 アプリの起動時間などを考慮した猶予時間 ・cooldown 次のアクションまでのインターバル ・period CloudWatchのkなしインターバル
  • 13. 13 株式会社サイバーエージェント ①LaunchConfig 起動するEC2の設計書(AMI、インスタンスタイプ、SSHキー、セキュリティグループ) ②AutoScalingGroup AutoScaling全体設計(LaunchConfig、最大台数、最小台数、AZ、ELB、VPC、ヘルスチェック) ③ScaleOutPolicy スケールアウト設計書(増加させる台数、スケール後の待機時間) ④ScaleOutAlarm 監視閾値とアクション設計(CloudWatchの監視間隔、監視対象、監視メトリクス、閾値、アク ション実行までの評価回数、アクション内容(アクションはScaleInPolicy)) ⑤ScaleInPolicy スケールアウトの設計書(減少させる台数、スケール後の待機時間) ⑥ScaleInAlarm 監視閾値とアクションの設計(CloudWatchの監視間隔、監視対象、監視メトリクス、閾値、ア クション実行までの評価回数、アクション内容(アクションはScaleInPolicy)) AutoScalingに必要なモノ(コンフィグ)
  • 14. 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. 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:¥AS¥bin>as-put-notification-configuration test-as-group --notification-types autoscaling:EC2_INSTANCE_LAUNCH,autoscaling:EC2_INSTANCE_LAUNCH_ERROR,autoscaling:EC2_INSTANCE_TERMINATE,autoscaling:EC2_IN STANCE_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. 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:¥AS¥bin>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:¥AS¥bin>as-describe-scheduled-actions UPDATE-GROUP-ACTION test-as-group test-ScheduleScaleOut1 2013-06-13T07:00:00Z 3 4 補足
  • 17. 17 株式会社サイバーエージェント 本日の内容 ・シナリオ1:負荷を掛けてスケールアウト ・シナリオ2:負荷が減らしてスケールイン ・今回の設定 ・シナリオ3:運用TIPS
  • 18. 18 株式会社サイバーエージェント ・初めの状態はインスタンスがminimum台数の2台。 ・インスタンスにCPU負荷を掛けCPU使用率を100%にする。インスタンスが1つ追加される。 Cloudwatchインターバルが60秒なので120秒程度待つ。 ・さらに3分間(cooldown)CPU使用率を100%にする。続けてインスタンスが1つ追加される。 ※インスタンスがLaunch,Terminateされる度に通知メールが来ること シナリオ1:負荷を掛けてスケールアウト
  • 19. 19 株式会社サイバーエージェント 無限ループさせるスクリプト(cpubusy.pl)でCPU100%にする。 2台分のインスタンスのCPU使用率を100%にすることで、AutoScalingGroup全体のCPU使用率が 100%になる。 サーバに負荷を掛ける
  • 20. 20 株式会社サイバーエージェント 以下コマンドでグループ全体のCPU使用率を確認し、しばらく待つ。 c:¥CW¥bin>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. 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. 22 株式会社サイバーエージェント 1分経つとインスタンスのLaunchが開始されたことが確認できる。 以下コマンドでグループ内のインスタンス状態確認。1台”i-b2177xxx”のインスタンスが Launchされだしている。しばらくして、ELBからEC2のステータスが”InService”になればOK。 c:¥AS¥bin>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. 23 株式会社サイバーエージェント ※今回の上限値の8台までリニアにスケールすることを確認できた。 増えたインスタンスにCPU負荷を掛けることを繰り返すことで常にグループ全体のCPU使用率が 高い状態を保った。結果8台までインスタンスがLaunchされ、高負荷状況でもそれ以上は Launchされなかった。 サーバに負荷を掛ける
  • 24. 24 株式会社サイバーエージェント 本日の内容 ・シナリオ1:負荷を掛けてスケールアウト ・シナリオ2:負荷が減らしてスケールイン ・今回の設定 ・シナリオ3:運用TIPS
  • 25. 25 株式会社サイバーエージェント シナリオ1の続き、2台のインスタンスに掛けたCPU負荷を停止する。しばらく経つと1台の terminateが始まる。 c:¥AS¥bin>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. 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. 27 株式会社サイバーエージェント さらに3分経つと2台目のインスタンスのterminateも始まり、最小インスタンス台数の2台とな る。 c:¥AS¥bin>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. 28 株式会社サイバーエージェント AutoScalingで行うアクションは、Launch、Terminateのみ インスタンスを作る(Launch)、消す(Terminate)のみ Notificationできる種類にもある通り、この2種類しかアクションはない。 インスタンスをStopとかできない。問答無用で消す。 シナリオ1,2から
  • 29. 29 株式会社サイバーエージェント 今回はバタつかなかったが、別の環境で実装した際にバタつきがおきました。 バタつくとは、インスタンスのTerminateとLaunchを繰り返す状態。 原因はAutoScalingのGracePeriodとELBのIntervalとHealthCheck設定でした。 ELBのヘルスチェックデフォルト値は、Interval 30s、HealthyThreshold 10となっており、これだ と30s*10回=300s後にインスタンスステータスが”InService”となる設定になります。 AutoScalingのGracePeriodがこれより短い値だと、インスタンスLaunch後GracePeriodの時間が経 過してからAutoScaling側のヘルスチェックを行いますが、ELB側でHealthyThresholdの回数分 チェックがまだ行われてない為ステータスがInServiceとなっていません。その為AutoScaling側の ヘルスチェックも失敗するので(AutoScalingが行うヘルスチェックはELBのステータスを見る為) 、 AutoScalingがインスタンスをterminateし、その後LaunchとTerminateを繰り返します。 なので必ず ASのGracePeriod>ELBのHealthyThreshold*Interval としてください。 バタついた!?
  • 30. 30 株式会社サイバーエージェント ややこしいですが、複数サービスと連携している為、各サービスで時間についてのパラメータを 持っています。 ①AutoScaling -GracePeriod:Launch後ヘルスチェック開始するまでの時間 -Cooldown:Launch後次のアクション実行までの待機時間 ②ELB -Interval:ELBのインスタンスへの監視間隔 -HealthyThreshold:連続指定回数OKだとインスタンスステータスを”InService”とする閾値 ③Cloudwatch -Period:CloudWatchの監視間隔 ※CloudWatchでのCPU閾値モニタリング間隔は60秒(ScaleOut(In)Alarm設定より) バタついた!?
  • 31. 31 株式会社サイバーエージェント Launch インスタンス起動 GracePeriod ヘルスチェック開始 1分 Cooldown 次のアクション開始 3分 ELBのHealthyThreshold*Interval Interval0.5分(30秒)*Threshold10=300秒 AutoScaling ELB ②ELBがここで インスタンスを正常と認識 ①ELBがここではまだ 正常と認識してない ③なのでヘルスチェック NGでターミネートする ④次のアクションで Launchし、これを繰り返す ELBのインターバル設定が長いと
  • 32. 32 株式会社サイバーエージェント Launch インスタンス起動 GracePeriod ヘルスチェック開始 1分 Cool-down 次のアクション開始 3分 ELBのHealthyThreshold*Interval Interval0.2分(12秒)*Threshold4=48秒 AutoScaling ELB ELBのインターバル設定を短くした ②AutoScalingのヘルスチェックで “ELBでのインスタンスの正常性”を確認し OKなので正常と見なす ①ELBがここで インスタンスを正常と認識 ・・・だと思います ドキュメントがないので検証結果を 基にした推測となります。
  • 33. 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. 34 株式会社サイバーエージェント 本日の内容 ・シナリオ1:負荷を掛けてスケールアウト ・シナリオ2:負荷が減らしてスケールイン ・今回の設定 ・シナリオ3:運用TIPS
  • 35. 35 株式会社サイバーエージェント AutoScaling実装後の運用での”あるある”シナリオ シナリオ3:運用TIPS①~⑧
  • 36. 36 株式会社サイバーエージェント まず、確実にあるインスタンスへのデプロイや設定変更作業する時 常にAMIをベースでイメージ化しておく必要がある(AMIからLauch後にchefでデプロイとかNG) ・インスタンスへの直接変更はしない。 ・AMIを更新する ・AMIのIDを指定しているLaunchConfigの更新 ・LaunchConfigを指定しているAutoScalingGroupの更新 ・ローリングオートスケーリング実施 ※勝手にローリングオートスケーリングと言ってしまいましたが、AMI更新作業後に1台 Terminateすると新しいAMIで勝手にLauchされます。それを繰り返す事です。 運用①:サーバ(インスタンス)の更新
  • 37. 37 株式会社サイバーエージェント AutoScalingなので、AMIを更新しないとダメ インスタンスを修正しても、AMIを更新できてないと元のイメージでLaunchされて元の状態のイ ンスタンスが出来てしまう。デグレっちゃう。 インスタンスへの直接変更はしない。
  • 38. 38 株式会社サイバーエージェント ・グループ外のインスタンスを1つ、AMIの雛形用に作成しておく ・手動でインスタンスを作ればAutoScalingGroup外のインスタンスとなる ・このインスタンスはLBに入れようが入れなくても構わない。LBに入れてもAutoScalingGroup に入る訳ではない。 ・インスタンスに変更を加えたい場合、このインスタンスに対して更新を行い、このインスタ ンスからAMIを作成する ※雛形インスタンスはグループ内でも構わないが、グループ外としておくことで、グループ内 インスタンスをのこしたまま動作確認にも使える。確認後にAMI作成し、グループ内インスタン スも更新していくといいかと AMIを更新する
  • 39. 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. 40 株式会社サイバーエージェント as-update-auto-scaling-group test-as-group –-launch-configuration test-lc02 LaunchConfigを指定している AutoScalingGroupの更新 これで、AutoScalingGroupの AMIが新しいものになった
  • 41. 41 株式会社サイバーエージェント 既存のインスタンスを手動でTerminateする Terminateが完了すると、AutoScalingは現状のインスタンス台数を保持しようとする為、 新しいインスタンスをLaunchする。 この時新しいAutoScalingGroupで定義したLauchConfigにあるAMI(新しいAMI)を使ってインスタ ンスがLaunchされる 1台のTerminate、Launchが完了したら、2台目3台目とローリングで実施する ローリングでインスタンス置き換え実施
  • 42. 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. 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. 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}",false,(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.39181818181817 4],"threshold":65.0}, 運用③:アラーム(トリガ)の一時的に停止
  • 45. 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. 46 株式会社サイバーエージェント ・行動ログ閲覧したい時、以下はuserrequestによりdesiredcapacityが0->2になったことが分かる。他 にも有用な情報は取れそう。 ※AutoScalingのログってこれくらい as-describe-scaling-activities c:¥AS¥bin>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 運用⑤:AutoScalingのアクティビティログ
  • 47. 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:¥AS¥bin>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台増加した。 運用⑥:AutoScalingの無効化 AutoScalingGroupを消しちゃうと、 配下のインスタンスは 全部Terminateされちゃう!
  • 48. 48 株式会社サイバーエージェント ・なんらかの理由で、インスタンスは残してAutoScalingの設定を消したい時 AutoScalingGroupを削除すると、グループ内のインスタンスは全てTerminateされる サービスインのままシームレスにやりたい場合、 事前にグループ内と同じ台数のインスタンスを手動Launchする(グループ外インスタンスとなる) グループ外インスタンスのサービスインされたことを確認した後に、AutoScalingGroupを削除する グループ内インスタンスもTerminateされる サービスインさせているグループ外インスタンスがいる為サービス影響はない。 運用⑦:AutoScaling削除
  • 49. 49 株式会社サイバーエージェント はい、正確に言うと、落ちないではなく落ちても立ち上がるサーバですね。 AutoScalingGroupに設定する最小台数(min-size)があります。AutoScalingはこの台数を下 回った場合は、その台数を維持するよう新しいInstanceをLaunchします。 つまり、極端な話それほど負荷が来ないし1台のサーバでいいようなシステムでも AutoScalingを使うことで、サーバ1台でステータスがNGとなったら新しいInstanceを 自動的にLaunchする可用性を高めたサービス運用が可能です。 本来だと可用性を高めるためにELBの下に最低2台のインスタンスを入れますが、 それが不要となり、AWSのInstanceコスト削減にもなります。 ※AWS全体の費用でインスタンスにかかる費用が支配的な為、この効果は大きい ※2台並べる構成よりダウンタイムは大きくなります。 運用⑧:AutoScalingを使って 落ちないサーバ
  • 50. 50 株式会社サイバーエージェント AutoScalingを理解し制御できるようになってからの導入・運用がよいと思います。 必要十分な試験を行ってはいないですが、制御できるようであれば問題なく動きそうです。 今後、ManagementConsoleが出ると思われます。AutoScalingのツールも日々進化しているので、 現状での導入後は定期的なキャッチアップが必要です。 APIツールは常に最新にしよう! まとめ
  • 51. 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 AutoScaling薄い教科書:サーバワークスさんのサイト参照 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. 52 株式会社サイバーエージェント ご清聴ありがとうございました!