[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

© 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. 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

http://aws.amazon.com/code/8720044071969977




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/

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 Group CloudWatch

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

http://techblog.netflix.com/2012/01/auto-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名

http://aws.amazon.com/developertools/2535

http://aws.amazon.com/developertools/2535



次は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

http://aws.clouddesignpattern.org/

http://aws.clouddesignpattern.org/


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

http://www.slideshare.net/AmazonWebServicesJapan/20130506-23096544






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/

http://aws.amazon.com/jp/training/

[awsマイスターシリーズ]amazon cloudwatch & auto scaling

Technology