Contenu connexe Similaire à AWS Black Belt Techシリーズ Amazon CloudWatch & Auto Scaling (20) Plus de Amazon Web Services Japan (20) AWS Black Belt Techシリーズ Amazon CloudWatch & Auto Scaling1. Amazon CloudWatch & Auto Scaling
AWS Black Belt Tech Webinar 2014 (旧マイスターシリーズ)
アマゾンデータサービスジャパン株式会社
⼭山本教仁
5. 5
CloudWatchができること
• 各AWSサービスのメトリックス監視
– メトリックス = 監視項⽬目(例例:CPU使⽤用率率率)
– メトリックスはあらかじめ定義され、構成済み
• サービス開始時から監視開始
• EC2ではハイパーバイザーから監視できる項⽬目
– メトリックスを追加定義も可能
• カスタムメトリックス
– メトリックス値を時系列列にグラフ表⽰示
• 各メトリックスに対してアラームを作成可能
– しきい値を設定(例例:CPU使⽤用率率率60%以上)
– メトリックス値がしきい値を越えたら起こすアクションを定義(例例:メールで通知)
• EC2上のログ監視 ・・・Amazon CloudWatch Logs
– メトリックスとアラームも作成可能
– 詳細は近⽇日BlackBeltでご紹介
6. 6
CloudWatchができること:メトリックス監視
• CloudWatch監視対象サービス
– EC2
– EBS
– ELB
– Auto Scaling
– RDS
– DynamoDB
– ElastiCache
– EMR
– OpsWorks
– Redshift
– Route 53
– CloudFront
– SNS
– SQS
– SWF
– Storage Gateway
– Billing
• メトリックス例例
EC2のメトリックスELBのメトリックス
CPUCreditBalance
CPUCreditUsage
CPUUtilization
DiskReadBytes
DiskReadOps
DiskWriteBytes
DiskWriteOps
NetworkOut
NetworkIn
StatusCheckFailed_̲Instance
StatusCheckFailed
StatusCheckFailed_̲System
VolumeIdleTime
VolumeQueueLength
VolumeReadOps
VolumeReadBytes
VolumeTotalReadTime
VolumeWriteBytes
VolumeWriteOps
VolumeTotalWriteTime
Latency
BackendConnectionErrors
HealthyHostCount
UnHealthyHostCount
RequestCount
HTTPCode_̲ELB_̲5XX
HTTPCode_̲Backend_̲4XX
CPUUtilization
FreeableMemory
SwapUsage
FreeStorageSpace
DiskQueueDepth
ReadIOPS
ReadThroughput
ReadLatency
NetworkReceiveThroughput
NetworkTransmitThroughput
WriteIOPS
WriteThroughput
WriteLatency
DatabaseConnections
BinLogDiskUsage
EBSのメトリックス
RDSのメトリックス
9. 9
CloudWatchができること:アラーム
• アラーム設定
– メトリックス(e.g. CPU使⽤用率率率)としきい値(e.g. 60%以上)で構成
– 3つのアラーム状態を管理理
• OK–
メトリックスの値が、定義されたしきい値を下回っている
• ALARM
– メトリックスの値が、定義されたしきい値を上回っている
• INSUFFICIENT_̲DATA
– アラームが開始直後であるか、メトリックスが利利⽤用できないか、データが不不⾜足していていア
ラームの状態を判定できない
– 各アラーム状態に対してアクションを定義可能
• 通知(Notification)
– Amazon Simple Notification Service(SNS)を使って通知
– メール送信やHTTP(S)送信、Amazon Simple Queue Service(SQS)への送信が可能
• Auto Scalingアクション
– Auto Scaling GroupのScaling Policyを指定し、インスタンスのスケールアウト/インが可能
• EC2アクション
– EC2インスタンスの停⽌止およびTerminateが可能
12. 12
カスタムメトリックス
• 独⾃自のメトリックスを保存し、モニタリング、グラフ化できる
– AWS CLIの”put-‐‑‒metric-‐‑‒data”、API Toolsの”mon-‐‑‒put-‐‑‒data”、もしくは”PutMetricData”
APIでデータを登録
– “list-‐‑‒metrics”でメトリックス定義を参照
– “get-‐‑‒metric-‐‑‒statistics”でデータを参照
– サイズ制限として、HTTP GETは8KB、HTTP POSTは40KB、1つのPutMetricDataリクエ
ストに20データまで
$ aws cloudwatch put-‐‑‒metric-‐‑‒data –metric-‐‑‒name RequestLatency
-‐‑‒-‐‑‒namespace GetStarted“
-‐‑‒-‐‑‒timestamp 2014-‐‑‒10-‐‑‒28T12:30:00Z
-‐‑‒-‐‑‒value 87
-‐‑‒-‐‑‒unit Milliseconds
$ aws cloudwatch put-‐‑‒metric-‐‑‒data -‐‑‒-‐‑‒metric-‐‑‒name RequestLatency¥
-‐‑‒-‐‑‒namespace GetStarted“¥
-‐‑‒-‐‑‒timestamp 2014-‐‑‒10-‐‑‒28T12:30:00Z
-‐‑‒-‐‑‒statistic-‐‑‒value Sum=60,Minimum=15,Maximum=105,SampleCount=5
GetStartedという
架空のアプリケーションの
指定した時刻のRequest
Latencyを登録する例例
単⼀一値の登録と
統計セットの登録例例
13. 13
カスタムメトリックス
• データの参照
– “get-‐‑‒metric-‐‑‒statistics”でデータを参照
$ aws cloudwatch get-‐‑‒metric-‐‑‒statistics -‐‑‒-‐‑‒metric-‐‑‒name RequestLatency”¥
-‐‑‒-‐‑‒namespace GetStarted”¥
-‐‑‒-‐‑‒statistics Average”¥
-‐‑‒-‐‑‒start-‐‑‒time 2014-‐‑‒10-‐‑‒28T12:30:00Z¥
-‐‑‒-‐‑‒end-‐‑‒time 2014-‐‑‒10-‐‑‒28T12:30:00Z
-‐‑‒-‐‑‒period 300
– マネージメントコンソール
14. 14
サンプルスクリプトの提供
• OSでしか取れない情報をカスタムメトリックスとしてCloudWatch
に登録するサンプルスクリプトを提供
– メモリ利利⽤用率率率、ディスク利利⽤用率率率、など
– Cronなどで実⾏行行可
– 5分おきにメモリ利利⽤用率率率とディスク利利⽤用率率率を登録するcronの設定例例
*/5 * * * * ~∼/aws-‐‑‒scripts-‐‑‒mon/mon-‐‑‒put-‐‑‒instance-‐‑‒data.pl
-‐‑‒-‐‑‒mem-‐‑‒util -‐‑‒-‐‑‒disk-‐‑‒space-‐‑‒util -‐‑‒-‐‑‒disk-‐‑‒path=/ -‐‑‒-‐‑‒from-‐‑‒cron
• LinuxとWindows向けに提供
– Linux
• http://aws.amazon.com/code/8720044071969977
– Windows
• http://aws.amazon.com/code/7932034889155460
15. 15
サンプルスクリプト設定例例
• サンプルスクリプトをEC2のUserDataに定義
– CloudWatchのput権限を与えたIAM Roleを付与
– User Dataに下のように定義
– EC2起動時から⾃自動的にメモリとディスク利利⽤用率率率を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
16. 16
CloudWatchの特徴と注意点
• 標準監視は設定不不要で無料料
• 監視項⽬目の追加も可能
– 標準メトリックスで取得できない監視項⽬目は追加が必要
• アラーム設定により通知可能
• メトリックスデータの保管は2週間まで
– 2週間以上保存する場合は、get-‐‑‒metric-‐‑‒statisticsでデータを取得し別の場所に保管し
ておく
– CloudWatch Logsのログの保管は無期限含めた⻑⾧長期保管可能
• データ保管粒粒度度は最短で1分間隔
– 1分間でのAverage、Maximum、Minimum、サンプル数が記録されていく
• APIコールにスロットリングあり
– カスタムメトリックスの頻繁な登録や頻度度の⾼高いデータ取得には注意
17. 17
監視システムでのCloudWatch活⽤用例例
• 既存の監視システムを使いたい場合、CloudWatchとの連携が必要
• CloudWatchだけでは監視要求が満たされないと判断される場合も、
カスタムメトリックス、CloudWatch Logs、もしくはサードパーティツール
と組み合わせての監視が必要
組み合わせ例例
監視要求項⽬目
本番環境検証環境
EC2RDSEC2RDS
ホスト(Ping)サードパーティツールCloudWatch※CloudWatch※CloudWatch※
CPUサードパーティツールCloudWatchCloudWatchCloudWatch
メモリサードパーティツールCloudWatchCloudWatchCloudWatch
ディスクI/OサードパーティツールCloudWatchCloudWatchCloudWatch
ディスク使⽤用量量サードパーティツールCloudWatchCloudWatchCloudWatch
ネットワークサードパーティツールCloudWatchCloudWatchCloudWatch
プロセスサードパーティツールCloudWatchなしCloudWatch
ポート/サービスCloudWatch ELBCloudWatchなしCloudWatch
ログサードパーティツールスクリプトなしなし
※アラーム状態情報(OKかINSUFFICIENTか)で代替
19. 19
CloudWatchの料料⾦金金
• 初期費⽤用無しの従量量課⾦金金
• 標準の監視は無料料
– EC2インスタンスの標準監視(5分間隔)
– EBS、ELB、RDSは1分間隔が無料料
• アラームやカスタムメトリックスは⼀一定数まで無料料
– 10メトリックス、10 アラーム、および100万APIリクエスト
– 1 か⽉月あたり5GBのデータの取り込みおよび5GBのアーカイブされたストレー
ジ
• 課⾦金金対象及び料料⾦金金(2014年年10⽉月現在 Tokyoリージョン)
– EC2詳細モニタリング1インスタンスにつき$3.50/⽉月
– カスタムメトリックス1つにつき$0.50/⽉月
– アラーム1つにつき$0.10/⽉月
– APIリクエスト1000回につき$0.01(Get, List, Putごとに)
最新の料料⾦金金情報は、http://aws.amazon.com/jp/cloudwatch/pricing/
21. 21
Auto Scalingとは
• トリガーを受けてEC2インスタンス数を⾃自動的に増減させる仕組み
– パフォーマンス維持やキャパシティ増強、コスト削減のために利利⽤用可能
CloudWatchAuto scaling Group
Alarm
Auto Scaling
Elastic
Load Balancing
①リソース監視
②しきい値を越えたら
アラーム
④結果として新規にサーバが
デプロイされる
③アラームのアクションに
登録されたASアクションが起動
22. 22
Auto Scalingの典型的な利利⽤用ケース
• 負荷分散ELB配下のWebサーバ
• SQSからジョブを取ってバッチ実⾏行行するワーカ
Elastic Load BalancingSimple Queue Service
WebサーバのAuto Scaling Group
CPU使⽤用率率率やELBのRequest数などを
トリガーにする
ワーカ(バッチ)のAuto Scaling Group
SQSのキューに溜溜まっているメッセージ数などを
トリガーにする
23. 23
Netflixでの活⽤用例例
リクエスト数の増減に応じた
インスタンス数の増減
リクエスト数の推移
インスタンス数の推移
CPU利利⽤用率率率
Netflix techblogより:
http://techblog.netflix.com/2012/01/
auto-‐‑‒scaling-‐‑‒in-‐‑‒amazon-‐‑‒cloud.html
24. 24
Auto Scalingの基本的な動き
Auto Scaling Groupの中で最低台数(Min値)維持
CloudWatchのアラームをトリガーとして受ける
Auto Scaling Policyに応じて、
対象のEC2インスタンス群に対し何台増やすか決める
指定されたAMIからEC2インスタンスを起動する
25. 25
Auto Scalingの基本的な動き
Auto Scaling Groupの中で最低台数(Min値)維持
CloudWatch
への設定
CloudWatchのアラームをトリガーとして受ける
AutoScaling
AutoScaling Policyの設定
Groupの設定
Auto Scaling Policyに応じて、
対象のEC2インスタンス群に対し何台増やすか決める
指定されたAMIからEC2インスタンスを起動する
Launch Configuration
の設定
AutoScaling
Groupの設定
26. 26
Auto Scaling Group
• 設定項⽬目
– Auto Scaling Group名
– Launch Configuration
– Maximum(インスタンス最⼤大数)
– Minimum(インスタンス最⼩小数)
– Desired Capacity
– VPC
– Availability Zones
– Health Check Type
– Health Check Grace Period
– Load Balancer
– Termination Policy
– Tag
Auto scaling Group
Add!
Desired
capacity
Auto Scaling
起動している
インスタンスグループの設定
min max
27. Auto Scaling Groupの設定
EC2管理理コンソールから設定
27
Launch Configuration
の指定
その後、Policyや
通知⽅方法、タグの指定
所属するVPCやSubnet、ELBを指定
28. 28
Launch Configuration
• 設定項⽬目
– Launch Configuration名
– AMI
– インスタンスタイプ
– kernel id
– RAMDISK ID
– Block Device Mappings
– Security group(s)
– Keypair名
– IAM Profile
– Spot Price
– user-‐‑‒data
– ebs-‐‑‒optimized
– Detailed Monitoring
Auto scaling Group
Add!
Auto Scaling
どのAMIからどんな設定で
起動するかを決める
30. 30
Auto Scaling Policy
• 設定項⽬目
– Auto Scaling Group名
– Policy名
– Scaling adjustment(増減させる台
数)
• スケールイン時はマイナス記号をつ
ける
– Adjustment type
• ChangeInCapacity: X台増減
• ExactCapacity: X台に指定
• PercentChangeInCapacity: 現キャ
パシティに対してX%増減
– Cooldown period(Auto Scaling
Policyを実⾏行行する間隔)
Auto scaling Group
Add!
Auto Scaling
インスタンス追加/削除
時の挙動の設定
32. 32
CloudWatchアラーム
• CloudWatchのアラーム設定で、Auto Scaling Actionを定義し、トリガーを送るAuto
Scaling GroupとAuto Scaling Policyを選択
• もしくは、Auto Scaling GroupのScaling Policy設定画⾯面からトリガーとしてのアラーム
を設定
33. 33
その他の使い⽅方
• Auto Healingとして利利⽤用
– Min N, Max Nとして設定すれ
ばN台のHealthyなインスタン
スをキープ
• Auto Scaling Groupをま
とめて監視
• スケジュールベースでイ
ンスタンス増減
34. 34
スケジュールベースの設定イメージ
• 時刻を指定してのスケジューリング
$ aws autoscaling put-scheduled-update-group-action
--scheduled-action-name ScaleUp
--auto-scaling-group AUTO_SCALING_GROUP
--start-time 2014-10-29T10:00:00Z
--desired-capacity 3
• cronのように繰り返しのスケジューリング
$ aws autoscaling put-scheduled-update-group-action
--auto-scaling-group AUTO_SCALING_GROUP
--recurrence “30 0 1 1,6,12 0”
--desired-capacity 3
• 複数のスケジュールを設定可能
35. 35
Auto Scalingによるインスタンス増減のタイミング
• Auto Scaling GroupのHealthyインスタンス数検知
– StatusがHealthyなインスタンス数がMin値以下になるとインスタンス追加起動
• CloudWatchアラームのAuto Scaling Actionトリガー
– AutoScaling Policyにしたがってインスタンス数を増減
• Auto Scaling Groupのスケジュール
– スケジュールにしたがってインスタンス数を増減
• ⼿手動コマンド
– コマンドでMax/Min/Desired Capacity値修正しインスタンス増減
– コマンドでAuto Scaling Policy実⾏行行
– コマンドでインスタンスの追加(Attach)/削除(Detach)
– コマンドでAutoScaling Groupに所属するインスタンスのStatusをUnhealthyに変更更しイ
ンスタンス増減
36. 36
ライフサイクル・アクションフック
• ライフサイクル・フック
・・・New!
– EC2インスタンスが起動後Auto Scaling Groupに追加されるまで、StatusがPendingとなる
– EC2インスタンスがAuto Scaling Groupから除外されTerminateされるまで、Statusが
TerminatingとなりTerminate処理理が⼀一時停⽌止する
– ライフサイクル・フックを設定しておくと、PendingまたはTerminatingの状態になったときに、
通知対象にメッセージを送り、標準で60分間待機に⼊入る
– 待機時間は最⼤大48時間
– 通知対象としては、SNSトピックもしくはSQSキュー
• ライフサイクル・アクション
– ライフサイクル・フックを拾拾って各種インスタンス初期化処理理が可能
• ソフトウェアのインストールや設定、EBSボリュームの作成/初期化/アタッチ、メッセージキューイン
グへの接続、等
• 最後にスナップショットの取得、ログの退避、問題判別作業、等
– 処理理が終了了したらAuto Scalingライフサイクルへ完了了を通知する
– 処理理が60分以内に終わらない場合は、Heartbeatを送って時間延⻑⾧長可能
37. 37
インスタンス増のときの注意点
• インスタンス起動時にアプリケーションが⾃自動的に動作
するよう設計する
– アプリケーションをインストール済みで⾃自動起動設定をしたAMIを作成
– アプリケーション構成スクリプト等をLaunch Configurationのuser data
に記載してインスタンス起動時に⾃自動実⾏行行&構成
– Auto Scaling Lifecycle Hookを使って外からEC2構成
起動時
すべてインストールHook:Pending
&構成済みのAMI
⾃自動スクリプト実⾏行行
Hookを拾拾って
スクリプト実⾏行行
構成ファイル
取得構成ファイル
取得
38. 38
インスタンス減のときの注意点
• インスタンスがTerminateされた場合を考慮した設計にする
– Auto Scaling配下のインスタンスは、随時Terminateされる可能性がある
– Termination Policyのカスタマイズは可能だが、障害等も鑑み、いつ落落ちてTerminateされ
てもよいような設計とする
• ステートレスなアーキテクチャー
– スティッキーセッションは使わない、セッション情報は外側の永続的ストレージに保管
(Dynamo DBやElastiCache等)
– ログは定期的にS3に送る(サーバ終了了時に残りのログをS3にバックアップ)
Hook:Terminating
Terminate時に残りのログ等を
外部ストレージに対⽐比させる
セッション情報含めたデータは外
部DB/ストレージに保管してある
ためTerminateされても問題なし
Hookを拾拾って
スクリプト実⾏行行
39. 39
EC2インスタンスのライフサイクルを理理解する
• Auto ScalingはEC2インスタンスをLaunchし、Terminateする
(Start/Stopではない)
• 既存インスタンスのAuto Scaling GroupへのAttach、およびAuto
Scaling Group内インスタンスのDetachが可能
– 利利⽤用例例)
• 既存インスタンスや⼿手動で構成したインスタンスをAuto Scaling Groupに追加可能
• あらかじめ起動構成済みのインスタンスをすぐにAuto Scalingへ追加可能(Launchを待つ必
要がない)
• Auto Scaling Group内インスタンスをDetachして別⽬目的で流流⽤用可能
• Auto Scaling Group内EC2インスタンスをStandbyにして⼀一時的
にGroupから外すことが可能
– 利利⽤用例例)
• インスタンスの問題判別、メンテナンス
• ライフサイクル・フック機能で、LaunchしてAuto Scaling Group
に参加する前およびTerminate前にユーザ処理理を⼊入れることが可能
40. 40
Auto Scalingのライフサイクル(⾃自動)
Auto Scalingを設定したときの動き
DesiredCapacity数
でインスタンス起動
トリガーと
Auto Scaling Policy
でインスタンス増
トリガーと
Auto Scaling Policy
でインスタンス減
Hook:LaunchingHook:Terminating
SNSSQSSNSSQS
スケジュールで
インスタンス起動停⽌止
41. 41
Auto Scalingのライフサイクル(⼿手動)
Attachで
既存インスタンスを
Auto Scaling Group
に追加
Standbyで
インスタンスを⼀一時的に
Auto Scaling Group
適⽤用外に
Detachで
Group内インスタンスを
Auto Scaling Group
から外す
Terminate Instanceで
Auto Scaling Group
内インスタンスを
Terminate
Hook:Terminating
Set Healthで
インスタンス
ステータスを
⼿手動でセット
StandbyUnhealthy
SNSSQS
Auto Scaling Groupに対する⼿手動での操作例例
42. 42
Termination Policy
Auto Scaling Group内インスタンスをどの順番でTerminateするかのポリシー
があり、カスタマイズも可能です。
• 標準では以下の⼿手順
– (Terminationを⾏行行うAZの中で)最
も古いLaunch Configurationを使う
インスタンスを選択
– 同条件のインスタンスが複数いたら
次の課⾦金金が始まるタイミングが最も
近いインスタンスを選択
– さらに同条件のインスタンスが複数
いたらランダムに選択して
Terminate
• カスタムポリシー
– 下記のポリシーを1つまたは複数指定可
• OldestInstance / NewestInstance
– インスタンスの起動時刻を参照して、最
も古い / 新しいインスタンスを優先的
にTerminate
• OldestLaunchConfiguration
– 最も古いLaunch Configurationを使う
インスタンスを優先的にTerminate
• ClosestToNextInstanceHour
– 次の課⾦金金が始まる時刻が最も近いインス
タンスを優先的にTerminate
• Default
– 標準動作
– 複数指定した場合は指定順で適⽤用
– 全ポリシーを適⽤用しても複数インスタ
ンスが候補になったらランダムに選択
43. 43
Auto Scaling Policyの使い⽅方
• Policyのトリガーが重要
– 何をトリガーにインスタンス数を増減させるか
– EC2のCPU使⽤用率率率か、ELBのLatencyやRequest数か、HTTP接続数か等
• スケールアウト時に増やすインスタンス数
– Policyは、default cooldownで指定された秒数(デフォルトでは300秒)待ってから次のPolicyが実⾏行行されるため、
インスタンス数を増やすのに時間がかかる
– Policyで何インスタンスずつ増やすかの指定が重要
– ⼿手動コマンドでPolicy実⾏行行する場合は、-‐‑‒-‐‑‒no-‐‑‒honor-‐‑‒cooldownオプションでこの待ち時間を無視できる
• スケールインのタイミング
– スケールインでインスタンスをTerminateする際、ステートフルなアプリケーションの場合はセッションが切切れる可
能性がある
– スケールインはゆっくり⾏行行うか、アクセスの少ない時間帯に⼿手動もしくはスケジュールで実⾏行行
• 予測できる負荷はスケジュールベースで対応
– バッチ処理理
– アクセス傾向から⾒見見た定時アクセス負荷増
– たとえば、保険として、予測できない負荷への対応のために負荷ベースのスケーリングをしかける
• Policyの整合性を確認する
– スケジュールベースと負荷ベースでインスタンス台数の整合性は取れるようにしておく(Auto Scalingはトリガーを
元に順番に実⾏行行していくだけ)
– 負荷がかかってインスタンス数が増えた状態で、スケジュールベースが実⾏行行されるといったんインスタンス数が減り、
負荷に応じて再度度増やす、というような想定しないインスタンス数の増減が起こる可能性がある
44. 44
急激な負荷増のときへの対応
• Auto Scalingは時間がかかる
– CloudWatchでアラームとなるのに数分
– EC2起動⾃自体に数分
– アプリケーションやコンテンツのデプロイに数分以上
– Cooldown時間アクションを待ちながら、指定されたインスタンス数ずつのEC2増減をイテレーション
で実⾏行行していくため、⼤大量量インスタンス起動時はさらに時間がかかる
• キャンペーン時など、急激な負荷増加が⾒見見込まれる場合、事前にAuto Scaling
配下のインスタンスを増やしておく
– Auto Scaling API/CLI(execute-‐‑‒policy、attach-‐‑‒instances、set-‐‑‒desired-‐‑‒capacity)等であらかじめ
台数を増やしておく
– ELBのPre-‐‑‒Warming(暖機運転)もあらかじめ申請しておく
• AutoScalingですぐに台数を増やしたいとき
– set-‐‑‒desired-‐‑‒capacityやexecute-‐‑‒policyを-‐‑‒-‐‑‒no-‐‑‒honor-‐‑‒cooldownオプションで実⾏行行
– ⼀一度度に複数台の増減をすることも可
45. 45
Auto Scaling運⽤用上の注意点まとめ
• Auto Scalingをうまく使えば、可⽤用性があがり、コスト最適化され、運⽤用
負荷が軽減する
• 対象アプリケーションをステートレスに設計する
– Auto Scaling Group内のインスタンスは、つねにTerminateされうることを想定する
– ステートレスにできない場合は、ライフサイクル・フック機能等をうまく使う
• Auto Scalingのライフサイクルを理理解する
• Auto Scaling Policyのトリガーを何にするかがポイント
– アプリケーションとしてどのメトリックスを⾒見見ればスケールアウトによって解決できる負荷増なの
かを理理解する
– トリガーとする各メトリックス性質を理理解する
• 例例:t2インスタンスはCPUがバーストするのでCPU使⽤用率率率で負荷増を捉えにくい
• スケールアウト時、Pre-‐‑‒Warming(暖機運転)含めどう対応するか、何台
ずつ何秒間隔で増やすか検討する
• スケールインのタイミングと実施⽅方法を検討する
• 事前の負荷テストによる動作確認、⼩小規模システムからの適⽤用等、Auto
Scalingの性質を理理解しながら適⽤用する
• Auto Scalingをうまく使ってクラウド最適なシステムを実現
46. 46
参考資料料
• Amazon CloudWatch Developer Guide
– http://docs.aws.amazon.com/ja_̲jp/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html
• Amazon CloudWatch FAQ
– https://aws.amazon.com/jp/ec2/faqs/#amazon-‐‑‒cloudwatch
• Amazon CloudWatch価格
– http://aws.amazon.com/jp/cloudwatch/pricing/
• Auto Scaling⼊入⾨門ガイド
– http://docs.aws.amazon.com/ja_̲jp/AutoScaling/latest/GettingStartedGuide/Welcome.html
• Auto Scaling Developer Guide
– http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/WhatIsAutoScaling.html
• Auto Scaling FAQ
– https://aws.amazon.com/jp/ec2/faqs/#auto-‐‑‒scaling
• Auto Scaling価格
– http://aws.amazon.com/jp/autoscaling/pricing/