[AWSマイスターシリーズ]Amazon CloudWatch & Auto Scaling

© 2012 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified or distributed in whole or in part without the express consent of Amazon.com, Inc.
AWSマイスターシリーズ
CloudWatch & Auto Scaling
2013.6.26
アマゾンデータサービスジャパン株式会社
ソリューションアーキテクト
今井雄太

2
1. CloudWatch
2. Auto Scaling
アジェンダ

3
CloudWatch

Copyright © 2012 Amazon Web Services
AWSの各種リソースをモニタリングするためのWebサービス
Amazon CloudWatchとは？
CloudWatch
状況を
レポート

5
Amazon CloudWatchの特徴
 サービスごとに定義されたメトリクス（=監視項目）
 メトリクスをベースにアラームを設定可能
EC2 ELB RDS

6
Amazon CloudWatchのアラーム設定
WebサーバインスタンスのCPU利用率に対するアラームを作成
• “Create Alarm”をクリック

7
アラームが発動する条件を設定

8
アラームが発動した際のアクションを指定
• Send Notification  Create New Email Topic

9
アラーム時に取れるアクション
通知を送る
• Simple Notification Service (SNS)を使った通知を送る
• 例： Emailの送信、HTTPのAPIを呼ぶ、などが可能
Auto Scaling Policyをトリガーする
インスタンスをStop/Terminateする -- New!
• 例：
• 利用率の低いインスタンスをStopしてコスト削減
• ステータスチェックが失敗したインスタンスをTerminate

10
請求通知機能(ビリングアラート)
AWSクラウドの利用料金を監視・通知できるように
US EastでしかAlarmが作
れないが、全リージョンの
合計金額で監視可能

11
請求通知機能(ビリングアラート)
$400の利用料金を超えるとこんな通知メールがきます
©2011 Amazon Web Services May not be reused or redistributed without permission

12
カスタムメトリクス
独自のメトリクスを保存し、モニタリング、グラフ化できる
“mon-put-data”コマンドラインツール
“PutMetricData”もしくは、API コール
“mon-list-metrics”でデータを参照
サイズは最大8KB - HTTP GET
40KB for - HTTP POST
$ mon-put-data –metric-name RequestLatency
--namespace "GetStarted“
--timestamp 2010-10-29T20:30:00Z
--value 87
--unit Milliseconds
GetStartedという架空の
アプリケーションの指定し
た時刻のRequest
Latencyを登録する例

13
カスタムメトリクス値の登録例
前頁と同様の例（引数に省略形）
単一のデータポイントではなく統計値を登録する例
$ mon-put-data -m RequestLatency -n "GetStarted" -t 2010-10-29T20:30:00Z
-v 87 -u Milliseconds
$ mon-put-data -m RequestLatency -n "GetStarted" -t 2010-10-29T21:30:00Z
-s "Sum=577,Minimum=65,Maximum=189,SampleCount=5" -u Milliseconds
注：タイムスタンプを省略すれば現時点のデータとして登録される

14
カスタムメトリクスの統計値取得
mon-get-statsで統計値を取得可能
もちろんマネージメントコンソールでも
$ mon-get-stats -n GetStarted -m RequestLatency -s “Average” …

15
インスタンス監視用サンプルスクリプト
OSでしか取れない情報をカスタムメトリクスとして
CloudWatchに登録
• メモリ利用率、ディスク利用率、などなど
• Cronなどで実行可
• 5分おきにメモリ利用率とディスク利用率を登録するcronの設定例
LinuxとWindows向けに提供
• Linux: http://aws.amazon.com/code/8720044071969977
• Windows: http://aws.amazon.com/code/7932034889155460
*/5 * * * * ~/aws-scripts-mon/mon-put-instance-data.pl --mem-util --disk-space-
util --disk-path=/ --from-cron

16
監視をEC2起動時に自動設定する(Linux) 1/2
前頁で紹介したサンプルスクリプト
http://aws.amazon.com/code/8720044071969977
例えば mon-put-instance-data.pl --mem-util と起動す
るとメモリ利用率をCloudWatchにカスタムメトリクスと
してputしてくれる。
Namespace: Sysmte/Linux,
MetricName: MemoryUtilization,
Dimension: InstanceId

17
監視をEC2起動時に自動設定する(Linux) 2/2
IAM Roleで認証できるので、CloudWatchのput権限を
持ったRole付けて下記のようなUser Data渡して起動すれ
ば自動的にメモリとディスク利用率をCloudWatchで監視
できる。
#!/bin/sh
cd /home/ec2-user
wget http://ec2-downloads.s3.amazonaws.com/cloudwatch-
samples/CloudWatchMonitoringScripts-v1.1.0.zip
unzip CloudWatchMonitoringScripts-v1.1.0.zip
rm CloudWatchMonitoringScripts-v1.1.0.zip
chown ec2-user:ec2-user aws-scripts-mon
echo "*/5 * * * * ec2-user /home/ec2-user/aws-scripts-mon/mon-put-instance-data.pl --
mem-util --disk-space-util --disk-path=/ --from-cron" >> /etc/crontab

18
CloudWatchの料金
もちろん初期費用無しの従量課金
標準の監視は無料
• EC2インスタンスの標準監視（5分間隔）含
 ELB、RDSは1分間隔が無料
課金対象及び料金（2013年6月現在 Tokyoリージョン）
• カスタムメトリクス 1つにつき
• $0.525/月
• アラーム1つにつき
• $0.10/月
• APIリクエスト1000回につき
• $0.0105（Get, List, Putごとに）
• EC2インスタンスの詳細監視（1分間隔）
• $3.675 （インスタンスごとに）
最新の料金詳細は、こちら：
http://aws.amazon.com/jp/cloudwatch/

19
CloudWatchの制約
メトリクスの保存は2週間まで
EC2インスタンスのOS内の情報取得にはカスタムメト
リクス登録が必要
データポイントは最短で1分間隔

20
必要に応じて他の監視ツールによる補完
ソフトウェア
• Pros: 導入しやすく低コスト
• Cons: 但し運用は自分で
• 例：
• Nagios
• Cacti
• Zabbix
• Munin
監視のサービス
• Pros: 導入しやすく運用コストも不要
• Cons: お任せする分、費用はかかる場合も
• 例：
• New Relic
• satelliz

CloudWatchのTIPS

APIコールは少しばらつきをもたせる
• カスタムメトリクスの登録や、別のシステムからの状態の取得
などにおいて、同時APIコール数が多くなってくるとスロットリ
ングが発生する。
• APIコール時に数秒のジッタを挟むなどして対応する。
CloudWatchのTips

23
Auto Scaling

Auto Scalingとは？定義した設定に従って自動でAmazon EC2の台数を増減させるメカニ
ズム
 需要が増加した時はシームレスに増やしてパフォーマンスを維持
 需要が減少した時には自動的に減らしてコスト削減
Auto Scalingとは
Auto scaling GroupCloudWatch
Alarm
Auto Scaling
Elastic
Load Balancing

Auto ScalingはELB以外の
環境でも利用できる
Elastic
Load Balancing
Simple Queue Service

Netflixの実例
リクエスト数の推移
インスタンス数の推移
CPU利用率
Netflix techblogより：
http://techblog.netflix.com/2012/01/aut
o-scaling-in-amazon-cloud.html

サーバの増減に必要な情報
Amazon EC2インスタンスの起動に必要な情報
• AMIは？
• セキュリティグループは？
• キーペアは？
何台インスタンスを起動すべきか
• どのELB配下に？
• どのAZに？
• 最低何台？最大何台？
どういうルールで増やすか（減らすか）
• 例1： 2台増やす（2台減らす）
• 例2： 50%増やす（50%減らす）
Launch Configuration
Autoscaling Group
Autoscaling Policy

Auto Scalingの
各コンポーネントと動作
LaunchConfiguration
• AMI ID
• Security Group
• Key pair
• …
Auto scaling
Group
• Min: X
• Max: Y
• ELB: elb-xxx
Autoscaling
Policy
1台増やす
Autoscaling
Policy
1台減らす
has-a
1. アラーム発動
2. アラームに対応
するAuto Scaling
Policy駆動
3. Auto Scalingが
LaunchConfiguration
に従ってインスタンスを
グループに追加

Launch Configuration詳細
インスタンスの起動設定を記述必須
• AMI
• インスタンスタイプ
• Security group(s)
任意
• Keypair名
• IAM Profile
• kernel id
• RAMDISK ID
• Spot Price
• Block Device Mappings
• user-data
• ebs-optimized
• Detailed Monitoring
Auto scaling Group
Launch Configuration
Add!
Auto Scaling
どのAMIからどんな設定
で起動するかを決める
インスタンス起動時の設定

Auto Scaling Group
Auto scaling Group
Add!
Auto Scaling
起動しているインスタン
スグループの設定
必須
• Launch Configuration
• インスタンス最大数
• インスタンス最小数
• Availability Zones
任意
• Tag
• VPC
• Termination Policy
• Health Check Type
• Desired Capacity
• Health Check Grace Period
• Load Balancer
起動するインスタンス数などの設定
min max
Desired
capacity

Auto Scaling Policy
Auto scaling Group
Add!
Auto Scaling
インスタンス追加/削除
時の挙動の設定
Auto Scaling Group辺り25個まで
Adjustする台数
最小Adjust台数
Adjust Type
• ChangeInCapacity: X台増減
• ExactCapacity: X台に指定
• PercentChangeInCapacity: 現キャパシティに対してX%増減
スケール時の動作設定

Auto Scalingの設定手順(1/3)
Auto ScalingのCLIツールを取得しておく
• http://aws.amazon.com/developertools/2535
• AWSの新CLIでも実施可能ですが、現状(2013/6)まだド
キュメントが揃っていないのでこちらのツールでご案内しま
す。
まずはLaunch Configを作る
$ as-create-launch-config LAUNCH_CONFIG_NAME
--image-id hogehoge #AMIのID
--instance-type c1.mediuma #インスタンスタイプ
--group fugafuga #セキュリティグループ名
--key foo #keypair名

次はAuto Scaling Group作る
• これが完了した時点でAuto Scaling Groupの設定に基いて
インスタンス群が立ち上がってくる
Auto Scaling Policy作る
$ as-create-auto-scaling-group AUTO_SCALING_GROUP_NAME
--launch-configuration LAUNCH_CONFIG_NAME # launch config名
--min-size 4 # 最小台数
--max-size 8 # 最大台数
$ as-put-scaling-policy POLICY_NAME
--type ChangeInCapacity #Scaling Type
--auto-scaling-group AUTO_SCALING_GROUP_NAME #ASG名
--adjustment 3 #スケールアクションごとのアジャスト値

最後にCloudWatchのアラームを
Auto Scaling Policyに設定する

Auto Scalingの設定手順
次はAuto Scaling Group作る
• これが完了した時点でAuto Scaling Groupの設定に基いて
インスタンス群が立ち上がってくる
Auto Scaling Policy作る
$ as-create-auto-scaling-group AUTO_SCALING_GROUP_NAME
--launch-configuration LAUNCH_CONFIG_NAME # launch config名
--min-size 4 # 最小台数
--max-size 8 # 最大台数
$ as-put-scaling-policy POLICY_NAME
--type ChangeInCapacity #Scaling Type
--auto-scaling-group AUTO_SCALING_GROUP_NAME #ASG名
--adjustment 3 #スケールアクションごとのアジャスト値

Scaleしなくても Auto Scaling
Auto Healingとして利用
• Min N, Max Nとして設定すればN台のHealthyなインスタンス
をキープ
Auto Scaling Groupをまとめて監視
min
max
Desired
capacity

オンデマンドでAuto Scaling
Auto Scaling Groupのdesired capacityを利用するとある程
度手動でEC2の台数をコントロールできる
Desired Capacityとは、「いま起動しておいてほしい台数」
Auto Scaling Groupの最小台数と最大台数の間で設定可能。
上記のコマンドだと、一旦5台起動している状態になるが、
その後はポリシーに沿ってスケールアウト/インする。
$ as-set-desired-capacity AUTOSCALING_GROUP_NAME --desired-capacity 5
min max
Desired
capacity

スケジュールに従ってAuto Scaling
Auto Scalingはスケジュールベースでも設定可能
$ as-put-scheduled-update-group-action ScaleUp
--auto-scaling-group AUTO_SCALING_GROUP
--start-time "2013-05-12T08:00:00Z"
--desired-capacity 3
$ as-put-scheduled-update-group-action scaleup-schedule-year
--auto-scaling-group AUTO_SCALING_GROUP
--recurrence “30 0 1 1,6,12 0”
--desired-capacity 3
Auto Scaling Groupに単発スケジュールを追加
Auto Scaling Groupに再帰的スケジュールを追加
Auto Scaling Groupには複数のスケジュールを追加できる
下記のコマンドで現在の設定を確認できる
$ as-describe-scheduled-actions --auto-scaling-group AUTO_SCALING_GROUP
--headers
詳細
http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/schedule_time.html

負荷ベースと
スケジュールベースの使い分け
予測できる負荷はスケジュールベースで対応
• バッチ処理
• 予定されたメディア露出
予測不可な負荷については負荷ベースのスケーリングで
保険をかける
• 必要に応じてスケジュールベースのスケールをしかけた上で、
突発的な負荷に対する対策として負荷ベースの設定をしておく

Auto Scalingの高度な操作
Auto Scaling Group内のインスタンスのHealthyステー
タスを外部から制御
• 例：他の監視ツールやインスタンス自身のヘルスチェック結果
をAuto Scalingに反映させる場合など
一時的にAuto Scalingの動きを止める
• 例：不具合インスタンスの調査を行う時など
$ as-set-instance-health i-123abc45d –-status Unhealthy
$ as-suspend-processes MyAutoScalingGroup

ELBのヘルスチェックと連携
ELBが行ったヘルスチェックの結果に基づいてAuto
Scalingを駆動
• 例：アプリケーションレベルのヘルスチェック結果を反映した
インスタンスの健全性維持
Grace Periodとは？
• Auto ScalingがELBのヘルスチェックの結果を無視する期間
• 起動直後でELBから見たStatusがOutOfServiceの場合など
• 上記の例ではインスタンス起動後300秒間はAuto Scalingは
Unhealthyと見なさない
$ as-update-auto-scaling-group my-test-asg-lbs –-health-check-type ELB
–-grace-period 300

Terminateするインスタンスの選択
標準では以下の手順
1. （Terminationを行うAZの中で）最も古いLaunch
Configurationを使うインスタンスを選択
2. 同条件のインスタンスが複数いたら次の課金が始ま
るタイミングが最も近いインスタンスを選択
3. さらに同条件のインスタンスが複数いたらランダム
に選択してTerminate
カスタムポリシーも選択可（次ページ）

カスタムTermination Policy
下記のポリシーを1つまたは複数指定可
• OldestInstance / NewestInstance — インスタンスの起動時刻を
参照して、最も古い / 新しいインスタンスを優先的にTerminate
• OldestLaunchConfiguration — 最も古いLaunch Configuration
を使うインスタンスを優先的にTerminate
• ClosestToNextInstanceHour — 次の課金が始まる時刻が最も近
いインスタンスを優先的にTerminate
• Default --- 標準動作
複数指定した場合は指定順で適用
全ポリシーを適用しても複数インスタンスが候補になったらラ
ンダムに選択

44
Autoscalingに
スポットインスタンス
Autoscalingのローンチコンフィグを作成時に”—spot-
price”オプションを設定
> as-create-launch-config spotlc-5cents --image-id ami-XXXXXX
--instance-type m1.small --spot-price "0.05"
インスタンスがTerminateされても
Desired Capacityを満たすよう継続的
に入札が行われる
スポット価格が入札額を上回っている場
合はDesired Capacityを満たせない
Scale Outパターン
http://aws.clouddesignpattern.org
スポットインスタンスに関するマイスターWebinarのリンク：
http://www.slideshare.net/AmazonWebServicesJapan/aws-16524731

ElasticBeanstalkのWeb UI
45
Autoscalingの閾値を設定
変更  CPUUtilization
変更  Percent
Click
変更  70
変更  30

ASGARD by Netflix
https://github.com/Netflix/asgard/wiki/Quick-Start-Guide

コードのデプロイメント

48
Auto Scaling使うとEC2の
起動タイミングは
任意に制御できない

49
うまく利用するにはアプリ
デプロイの自動化をしてお
く必要がある

50
Auto Scalingでデプロイ
コードコード
新規サーバーを
デプロイ
Auto ScalingではAMIからサーバーをデプロイするところまで面倒見てくれる
AMI
AMIにコードを埋め込ん
でおけばOK？
ひとまずOK。ただし、コード
を修正するたびにAMIを新しく
する必要があるので、頻繁な
デプロイを行う際は更に対策
が必要。

51
コード修正のたびにAMIを新しくするのは手間がかかる。
PHPやRuby, node.jsなどのLLを利用しているのであれば・・
コードコード
新規サーバーを
デプロイ
AMI デプロイ時にSCMから最
新のコードを取ってくる
ようにしよう

52
Launch Configurationに以下のようなuser dataを渡し
ておけば起動時にgitから最新のコードを取得してきてく
れる。
上記は前提として、コードが”/var/www/html”にあっ
て、gitで管理されている場合の話。
より柔軟なデプロイについては下記を参照
http://www.slideshare.net/AmazonWebServicesJapan/20130506-
23096544
#!/bin/sh
cd /var/www/html
sudo -u httpd-user git pull
service httpd restart

Auto ScalingのTIPS

トリガーにするメトリクスはアプリ次第。
• 一般的にはCPUが多い。
• WebSocketなどの環境ではメモリや接続数も重要。
しきい値もアプリ次第だが、最初は厳し目に設定してお
いて、様子を見ながらゆるくしていくのがベター。
AZのキャパシティは均等に
• 利用するAZの倍数で増やし、減らす、等

Auto Scalingの発動はSNSでキャッチできる
• as-put-notification-configuration コマンドを利用することに
より、既存のSNSトピックに対してオートスケーリングイベン
トが発生したときに通知を出すように設定ができる
Auto Scalingは時間がかかる
• 基本的には、オートスケーリングは1台ずつのEC2増減をイテ
レーションで実行していく。
• 3台増やす際には、1台増やして、cool down periodを待って、2
台目増やして・・・という具合
• as-set-desired-capacityを--no-honor-cooldownオプション
付けて発行すると、一度に複数台の増減をすることも可能。

増やす時は速く
• サービスのレスポンスを落とさずに
減らす時はゆっくり
それって本当にAuto Scaling必要か？ともう一度確認し
てみる
• Auto Scalingは銀の弾丸ではないので、どんなユースケースに
もマッチするわけではない。
• デプロイや監視、しきい値設定など、それなりに手間を掛けて
育てる必要がある。
• 最初は、緩めのしきい値でアラームからメールを飛ばして対応、
から始めるのもアリ。

57
ご参加ありがとう
ございました。
トレーニングコース（有料）もあります！
AWS実践入門１
トレーニング
AWS実践入門２
トレーニング
Architecting
on AWS
トレーニング
AWS 認定ソリュー
ションアーキテクト-
アソシエイトレベル
認定試験
http://aws.amazon.com/jp/training/

[AWSマイスターシリーズ]Amazon CloudWatch & Auto Scaling

More Related Content

[AWSマイスターシリーズ]Amazon CloudWatch & Auto Scaling