AutoScaling & SpotInstance Handson

©2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Auto Scaling と Spot Instance
のハンズオン(前編)
アマゾンウェブサービスジャパン株式会社

本日の資料
Asset1
https://bit.ly/2DwiAei
2

3
注意事項
【上限緩和について】
1人最大以下のリソースを使います。同じAWSアカウントで複数人ハンズオンする場合は掛け
る人数分緩和申請が必要です。
VPC*1、IGW*1
EC2：負荷ノード (t2.micro*1), AutoScalingノード(m3.medium*4、t2.micro*4)、
予備ノード(m1.medium*4、t2.small*4)、イメージ取得用ノード(t2.micro*1)、ALB*1
【想定費用】
AutoScalingで利用する一番高いm1.medium(ondemand $0.122/h)が4台,2時間で$0.976、
負荷を掛けるt2.micro(ondemand $0.0152/h)が3台,2時間で$0.0912で合計$1.0672
(SpotInstanceを使うのでもっと安くなります。その他ALBや転送料金もありますが最大この
くらいの料金とみてください)
【準備事項】
AWSを利用可能なネットワークに接続されたPC(Windows, Mac OS, Linux等）
事前に用意していただいたAWSアカウント
SSHクライアント（Windows環境ではTera Termを推奨）
ブラウザ（FirefoxもしくはChromeを推奨）

ハンズオン概要

• Auto Scalingを使い、ALB配下にいるEC2を負荷に応じて自動でスケールアウ
ト/スケールインを行う
• Auto ScalingグループでEC2フリート機能 (設定オプションとしては”購入オプ
ションとインスタンスを組み合わせる”)を使い、Spot Instance とオンデマンドイ
ンスタンスを組み合わせてスケーリングさせる。
※Spot Instance を組み合わせることでコスト効率を上げる。さらにこの機能は
リザーブドインスタンスも組み合わせることが出来るのでさらなるコスト効率向
上が期待できる
• OSSのApacheBenchによる負荷テストを行う
5

全体構成図
6
Spot Instance
Instance
Spot Instance
Spot Instance
Load-Server
Auto Scaling group
ALB
VPC
AZ1
AZ2
Web-EC2

アジェンダ
① はじめの準備
CloudFormationを使い、VPC、 SecurityGroup、負荷を発生するEC2(Load-Server)1台を自動作成
② ロードバランサの作成
ターゲットグループとALBを作成
③ Auto Scalingの設定(Spot Instanceも活用)
インスタンス起動時の設定のLaunchテンプレートを作成。どういった場所でEC2を起動し、スポットを何割使
うかなどを設定したAuto Scalingグループを作成
④ 負荷テスト
OSSのApach Benchで負荷を発生させて、スケーリングの動作を確認
⑤ オプション
スポット料金確認、手動でスポットインスタンス起動、スケジュールアクション、カスタムメトリクス、予測スケー
リング
7

①はじめの準備
CloudFormationを使い、VPC, SecurityGroup(22,80ポートオープン)、EC2などを
作成します。※東京リージョンで実施
9
Load-Server
VPC
CloudFormation

全体構成図
10
Spot Instance
Instance
Spot Instance
Spot Instance
Load-Server
Auto Scaling group
ALB
VPC
AZ1
AZ2
Web-EC2
赤丸の箇所を作成します

AWSマネージメントコンソールから”EC2”をクリック、”キーペア”をクリック、[キーペア作成]を
クリック、”キーペア名”を入力し[作成]をクリック、操作しているパソコンに秘密鍵
(handson.pem)がダウンロードされます
(1)キーペアの作成
11

AWSマネージメントコンソールから”CloudFormation”を選択し、 [スタックの作成]をクリック
(2)EC2を１台CloudFormationで構築
12

“テンプレートの選択“->”テンプレートをS3にアップロード”->[ファイルを選択]をクリックし、
ダウンロードしたテンプレート(handson-autoscaling.yaml)を指定し[次へ]をクリック
13
利用Asset1 (1の”handson-autoscaling.yaml”)

“スタックの名前”に”handson-autoscaling”(任意)、“キーペア”は先程作成したキーペアを
指定して[次へ]をクリック。その後も[次へ]をクリックし最後に[作成]をクリック。
数分ほど待つとVPC, SecurityGroup、EC2一台などが出来上がる
14

数分で完了する。”出力”タブに以下の情報が出力されていることを確認する
15

(3)SSHログイン方法
必要なもの
• インスタンス作成時に指定したキーペアの秘密鍵ファイル (handson.pem)
• インスタンスに割当たるパブリックIP
SSHログイン方法
（具体的な操作方法は次ページより説明しています）
• 接続先ホスト：インスタンスに割当たるパブリックIP
• ログインユーザ名： ec2-user
• 接続方法：公開鍵暗号方式（秘密鍵ファイルを指定）
この後SSHログインと出てきたら以下の手順で進めてください
16

Windowsからログインする場合
• TeraTerm (ttssh.exe) を起動 http://sourceforge.jp/projects/ttssh2/
• 1.接続するインスタンスのパブリックDNS名を入力
• 2.SSH2を指定
• 3.「OK」をクリック
• 4.この画面が出たら「続行」をクリック
→
1
2
3 4
17

• ユーザ名: ec2-user
• 「RSA/DSA/ECDSA/ED25519鍵を使う」を選択
• 秘密鍵ファイル（handson.pem）を選択して接続
→→
1
2 3
5
6
7
4. すべてのファイル(*.*)を選択する
(選択しないと鍵が表示されない)
補足）この認証画面で時間が掛かりすぎた場合、タイムアウトに
より「OK」をクリックしても繋がらない場合があります。その場合
は再度Teratermを起動してやり直してください。
18

Mac/Linuxからログインする場合
• ターミナルからコマンドラインでログイン (事前に秘密鍵
（pemファイル）のパーミッションを600にしないと接続出来
ません)
$ chmod 600 ~/Downloads/handson.pem
$ ssh -i ~/Downloads/handson.pem ec2-user@割当てたパブリックIPアドレス
(3)SSHログイン方法(Macの場合)
19

 インスタンスは完全に起動完了しているか？
 起動時に指定した内容どおりに起動しているか？
 接続先のIPアドレスあるいはホスト名は正しいか？
 指定したSecurity Groupは 22(SSH) を有効にしているか？
 指定したKey Pairと対応する鍵ファイルを指定しているか？
 秘密鍵ファイルのパーミッションは600になっているか？(Mac/Linuxから)
(3)SSHログインがうまくいかない時
20

② ロードバランサーの作成

全体構成図
22
Spot Instance
Instance
Spot Instance
Spot Instance
Load-Server
Auto Scaling group
ALB
VPC
AZ1
AZ2
Web-EC2

EC2の画面から、左側メニューの”ターゲットグループ”をクリックし、
[ターゲットグループの作成]をクリックする
(1)ターゲットグループの作成
23

以下値を入力し、[作成]をクリックする。
(1)ターゲットグループの作成
24
・ターゲットグループ名：
”handson-as-target”
・VPC：handson-as-vpc

EC2の画面から、左側メニューの”ロードバランサー”をクリックし、
[ロードバランサーの作成]をクリックし、次の画面で
Application Load Balancerの[作成]をクリックする
(2)ロードバランサーの作成
25

以下の値を入力し[次の手順]
をクリックし、
次の画面も[次の手順]をクリックする
・名前：handson-as-lb
・アベイラビリティゾーンの箇所
-VPC：handson-as-vpc
-AZ：2つともチェックを入れる
26

27
“既存のセキュリティグループ”にチェックを入れ、”handson-as-sg”にチェックを入れ、
[次の手順]をクリックする

以下の値を入力し[次の手順]をクリックし、
次のページはそのままターゲットを登録せず
に[次の手順]、
最後のページで[作成]をクリック
・ターゲットグループ：
既存のターゲットグループ
・名前：”handson-as-target
28

③ Auto Scalingの設定

Auto Scaling の3つの構成要素
Launch
Template
(Launch
Configuration)
Scaling PlanAuto Scaling
Group
① ② ③

全体構成図
32
Spot Instance
Instance
Spot Instance
Spot Instance
Load-Server
Auto Scaling group
ALB
VPC
AZ1
AZ2
Web-EC2

起動するインスタンスの設定は”Launch Configuration”か”Launch Template”で行う、
今回は複数のインスタンスタイプとSpot Instanceを組み合わせることが出来る
“Launch Template”で行う
(補足)Launch ConfigurationとLaunch Template
33
• 昔はAutoScalingを使う場合、必ず
LaunchConfigurationを使っていた
• Launch ConfigurationからLaunch
Templateに複製する機能あり
Launch Configuration Launch Template
• Launch Templateのバージョン
管理機能あり
• AutoScaling グループで“購入
オプションとインスタンスを組み
合わせる”のオプションが使える
①

起動するインスタンスの設定は”Launch Configuration”か”Launch Template”で行う、
今回は複数のインスタンスタイプとSpot Instanceを組み合わせることが出来る
“Launch Template”で行う
34
• 昔はAutoScalingを使う場合必ず
LaunchConfigurationを使っていた
• Launch Templateに複製する機能
あり
Launch Configuration Launch Template
• Launch Templateのバージョン
管理機能あり
• AutoScalingGroupで“購入オプ
ションとインスタンスを組み合わ
せる”のオプションが使える
Launch Configurationで出来ることは全てLaunch Templateで出来る。さらにSpot Instance
などが利用でき多機能なため、現在はLaunch Templateをお勧めします。
①(補足)Launch ConfigurationとLaunch Template

EC2の画面から、左側メニューの”Launch Template”をクリックし、
[起動テンプレートの作成]をクリックする
(1)Launch Templateの作成
35
①

以下の値を入力(次のスライド続く)
・起動テンプレート名：handson-as-template
・AMI ID： ami-0010c84e565efc06a
・キーペア名：handson
・セキュリティグループ：handson-as-sg
36
①

“高度な詳細”箇所をクリックし、
以下の値を入力し、画面右下の[起動テンプレートの作成]をクリックする
・モニタリング：有効化
37
①

EC2の画面から、左側メニューの”Auto Scalingグループ”をクリックし、
[Auto Scalingグループの作成]をクリックする
(2)Auto Scaling グループの作成
38
②

“起動テンプレート”にチェックを入れ、”handson-as-template”にチェックを入れ
[次のステップ]をクリックする
39
②

40
・グループ名：handson-as-grp
・購入オプションとインスタンスを組み合わせる：チェックを入れる
・インスタンスタイプ：m3.medium、t2.micro を追加
(上記インスタンスタイプが表示されない場合 m1.medium、t2.small を選択)
・インスタンスの分散で、次のデフォルト設定を使用しすぐに開始します：チェックを外す
②

41
“購入オプションとインスタンスを組み合わせる”オプションは、オンデマンド+
リザーブド, スポットの購入オプションの比率、様々なインスタンスタイプを組
み合わせてキャパシティーをプロビジョニングする(EC2 フリートのAPIを使っ
ている)をAuto Scalingから使う機能です。Auto Scaling はこの設定に基づ
いて、希望のキャパシティーを満たす最低価格のSpot Instanceの組み合わ
せをプロビジョニングします

42
②
複数インスタンスタイプを選択する場合、レイテンシが大
事なワークロードではCPU性能(CPU数)やインスタンス
世代が同じインスタンスタイプを選んでください。レイテン
シがそれほど大事でなければ、より安く購入できる古い
インスタンスタイプや様々なインスタンスタイプを選択す
ることも有効です
リストの順番は優先順で、リスト最上部のインスタンスが
下位インスタンスよりも優先で使用されます。

43
以下の値を入力し[次の手順]をクリッ
クする
・ベースを超えるオンデマンド割合：
25%
・ネットワーク：”10.9.0.0/16”のVPC
・サブネット：”10.9.0.0/24”
と”10.9.1.0/24”のサブネット
・ロードバランシング：チェック
・ターゲットグループ：”handson-as-
target”
・ヘルスチェックタイプ：”ELB”
・モニタリング：”CloudWatch詳細モ
ニタリングを有効化”にチェック
②

現在３種類、リリースされた順にSimpleScalingPolicy、ScalingPolicyWithStep、
TargetTrackingPolicyがある。今回は運用負担が少ないTargetTrackingPolicyを使います
※より高度なスケーリング戦略として、TargetTrackingPolicyとScalingPolicyWithStepを組み合わせることも可能です。
例:スケールアウトにはTargetTrackingPolicyを使い、スケールインにはScalingPolicyWithStepを使う等が考えられます。
(補足)Scaling Policyの種類
44
• 指定されたターゲット値に近い値に
メトリクスを維持するためにスケール
アウト/スケールインします。また、負
荷パターンの変動によるメトリクスの
変動に合わせて調整し、ASGの容
量の急速な変動を最小化します。
スケールインは緩やかに行われます
Target Tracking Policy
Simple Scaling Policy
• 明示的なしきい値を設定し、そ
れを超えたら何台(何%)のEC2
を増やす(または減らす)を定義
します。TargetTrackingPolicyと
比較すると細かいカスタマイズ
ができ、その分設定と運用の手
間はあります。
Scaling Policy with Step
③

現在３種類、リリースされた順にSimpleScalingPolicy、ScalingPolicyWithStep、
TargetTrackingPolicyがある。今回は運用負担が少ないTargetTrackingPolicyを使います
※より高度なスケーリング戦略として、TargetTrackingPolicyとScalingPolicyWithStepを組み合わせることも可能です。
例:スケールアウトにはTargetTrackingPolicyを使い、スケールインにはScalingPolicyWithStepを使う等が考えられます。
(補足)Scaling Policyの種類
45
• 指定されたターゲット値に近い値に
メトリクスを維持するためにスケール
アウトスケールインします。また、負
荷パターンの変動によるメトリクスの
変動に合わせて調整し、ASGの容
量の急速な変動を最小化するので、
スケールインには時間をかけます。
Target Tracking Policy
Simple Scaling Policy
• 明示的なしきい値を設定し、そ
れを超えたら何台(何%)のEC2
を増やす(または減らす)を定義
します。TargetTrackingPolicyと
比較すると細かいカスタマイズ
ができます。その分設定と運用
の手間はあります。
Scaling Policy with Step
ステップが 1 つであっても、簡易スケーリングではなくステップスケーリングポリシーを使用す
ることをお勧めします。スケーリングアクティビティ中やヘルスチェック交換中、アラームは継
続的に評価されグループはロックされません。Auto Scaling グループ内のインスタンス数に
比例して増減するメトリクス (使用率メトリクス) に基づいてスケールする場合は、代わりに
ターゲット追跡スケーリングポリシーを使用することをお勧めします
https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/as-scale-based-on-
demand.html
https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/as-scaling-simple-
step.html
③

46
“スケーリングポリシーを使用して、こ
のグループのキャパシティを調整す
る”にチェックを入れ、以下の値を入
力し[次の手順]をクリックし次のペー
ジは何もせず[次の手順]をクリックす
る
・”スケーリングポリシーを使用してこ
る”にチェックを入れる
・最大インスタンス数：4
・スケールグループサイズの
-名前：handson-as-policy
-メトリクスタイプ:CPUの平均使用率
-ターゲット値：20%
-インスタンスは：120
ここではTargetTrackingPolicyを設定している
②

る
47
他のスケーリングポリシーに変更したい場合はここをクリックする
②今回はTargetTrackingPolicyを使う
メトリクスを、EC2のCPU使用率、EC2のネットワーク転送量、ALBのリクエスト
数、またはカスタムメトリクス(後半の⑤オプションで説明)から選択し、値を指定
するとその値を維持するようにスケールアウト/スケールインを行う。(例えば
CPU使用率を60%と指定すればピークタイムに60%をキープするために20台
のEC2が起動し、アイドルタイムは60%をキープするためにEC2を減らし4台の
EC2が起動する状態にするなど)

48
ウォームアップ期間
②
る

©2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.49
 クールダウン期間
Simple Scaling policyのみで有効。
拡大や縮小が適用される前に、追加のインスタンスを起動または終了しないようにします。
Auto Scaling グループがSimple Scaling Policyを使用して動的にスケールした後、クール
ダウン期間が完了するのを待ってから規模の拡大や縮小を再開します
(補足)クールダウン、ウォームアップの補足説明
https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/Cooldown.html
 ウォームアップ期間
Simple Scaling policy以外で有効。
スケールアウトでインスタンス起動時のウォームアップ期間、この間ウォームアップ中のイン
スタンスは ASGの集合メトリクスの対象になりません。したがって、複数のアラーム超過が
発生してもステップ調整値の範囲は変わらず、1 つのスケーリングアクティビティという結果
になります。これにより、必要以上の数のインスタンスが追加されることがなくなります
https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/as-scaling-simple-step.html#as-step-scaling-warmup

50
オートスケールで作成されるEC2インスタンスにタグを付ける設定
キーに”Name”、値に”Autoscaling_EC2”でタグを作成し、[確認]をクリック、
最後のページで[Auto Scaling グループの作成]をクリックする
②

51
しばらくすると最小台数の1台の起動を確認できる
②

(3)CloudWatch Alarmの確認
52
マネコンから”CloudWatch”の”アラーム”をクリックし、”すべてのAutoScalingアラームを非表
示”のチェックを外す。TargetTrackingPolicyの作成時に、指定した閾値に応じて自動的に
CloudWatch Alarmが2つ作成されています。それぞれスケールアウト/スケールイン用で、
スケールアウトは素早く(3分)、スケールインはゆっくり(15分)進むように構成されます。
※このアラームはメトリクスの変動に合わせてAuto Scalingによって調整(再作成)されます

④ 負荷テスト

全体構成図
54
Spot Instance
Instance
Spot Instance
Spot Instance
Load-Server
Auto Scaling group
ALB
VPC
AZ1
AZ2
Web-EC2

$ ssh -i ~/Desktop/handson.pem ec2-user@<handson-as-loadserverのDNS名>
(1)Load-Server から ApacheBench を実行
負荷を掛けるサーバーにsshログインする
※<handson-as-loadserverのDNS名>はCloudFormationの“出力”タブを確認し、
キーが”LoadServer”で値に”DNS名”が表示されている
abコマンドで負荷を発生
※<ALBのエンドポイント>はEC2の画面でロードバランサから確認する
$ ab -n 2400000 -c 16 http://<ALBのエンドポイント>/test.php
(注意)負荷のかかり方や実行時間は状況によりまちまちです
コマンドリファレンス利用してください。 Asset1 (4の”comd_reference.txt””)
-c 同時接続数
-n リクエスト数

CloudWatchの画面から、左側メニューの”メトリクス”をクリックし、
”EC2”->” Auto Scaling グループ別”を順にクリックする
56
(2)オートスケール確認

“handson-as-grp”の”CPUUtilization”にチェックを入れ、
”グラフ化したメトリクス”のタブをクリックし、期間を”1分”にする
57

EC2の左側メニューから“Auto Scalingグループ”をクリックし、”アクティビティの履歴”
タブをクリックし、しばらくすると、インスタンスの増加がはじまる
58

“インスタンス”タブで起動台数4台を確認する
59

EC2の左側メニューの”スポットリクエスト”をクリックし、
4台のうち75%の3台が Spot Instance で起動していることを確認する
※台数は誤差がある可能性あり
60

EC2の画面から左側メニューで”インスタンス”をクリックし、対象インスタンスにチェックをし
“説明”タブで”ライフサイクル”の箇所が”spot”であれば Spot Instance であることも確認できる
61

”ライフサイクル”の列を追加しSpot(spot instance)かnormal(on-demand)を確認する
こともできる
62

ウォームアップ期間が終わり、集合メトリクスのCPU使用率も少し下がる
※以下のグラフの状態になればabコマンドはctrl+cでキャンセルしても構いません
63

Auto Scalingグループの”モニタリング”タブで状況確認もする
64

ApacheBenchのリザルト
毎秒2826リクエスト、1リクエストに5.662ms、90％以上は9msという結果がわかります
65

負荷が終わり、CPU使用率が下がりCPU使用率がほとんどなくなる
66

しばらくすると、Auto Scalingによるスケールインが発動し、インスタンスが段階的に
削除されていきます。※TargetTrackingPolicyのスケールインの発動にはは15分程
度かかり時間を要します。後半の”⑤オプション”のスライドを読み進めていてください。
67

スケールインの確認が不要であれば、手動でEC2を削除してください。
Auto Scalingグループ”handson-as-grp”にチェックを入れ、アクションから編集をクリックし
希望するキャパシティを1にし保存します。
68

⑤ オプション

(1)Spot Instance の料金確認
マネコンのスポットリクエストから、[Savings Summary]をクリックし現在スポットリクエスト
履歴が残っているものを対象としたSpot Instanceによる節約概要を確認できます。
以下だとDetailにあるインスタンスタイプがon-demandだと$0.91のところSpot Instanceで
$0.13で85%節約できたことがわかります。

マネコンのスポットリクエストから今回のリクエストIDにチェックを入れ、[価格設定履歴]
をクリック。価格の遷移が確認できる。以下だと20190106時点でm3.mediumは価格
が90% off で3ヶ月間ほとんど変動していない事がわかる

マネコンのサービスから”Cost Explore”をクリックし、“Explore”->”Cost & Usage”
をクリックする

①画面右の”FILTERS”の”Service”の”EC2-Instances”
にチェックを入れ[Apply filters]をクリック
②グラフ右上の”More”->“Purchase option”をクリック

画面のようにOn-demand, Spot, Reservedの割合が指定した期間で表示される

EC2の画面の左側メニューから”Launch Template”をクリックし、” handson-as-template”
にチェックを入れ、[アクション]->[テンプレートからインスタンスを起動する]をクリックする
(2)手動でのスポットリクエスト

以下を入力(次のスライドに続く)
・ソーステンプレートのバージョン
1(Default)
・インスタンスタイプ
t2.micro
・サブネット
handson-as-subnet1a

高度な詳細をクリックし、購入オプションの”スポットインスタンスのリクエスト”にチェック
を入れ、[テンプレートからインスタンスを起動する]をクリックする

(参考情報)
“スポットパラメータのカスタマイズ”をクリックし、スポットインスタンスの中断時の動作を
休止/停止/終了に変えることができます
(補足)手動でのスポットリクエスト

スポットリクエストは作成されインスタンスが起動したことを確認する

確認が終わったら、対象のスポットリクエストにチェックを入れ、[アクション]->
[スポットリクエストのキャンセル]をクリックし、確認のポップアップで[確認]をクリックする
インスタンスが削除されたことを確認する

$ aws ec2 run-instances --launch-template LaunchTemplateName=handson-as-
template,Version=1 --subnet-id <subnetid> --instance-type t2.micro --instance-
market-options MarketType=spot
{
"Instances": [
{
"Monitoring": {
"State": "pending"
},
"PublicDnsName": "",
"StateReason": {
"Message": "pending",
81
同様の手順をCLIで実行し、マネコンからスポットリクエストやインスタンス起動確認を行う
コマンドリファレンス利用してください。Asset1 (5-2の”comd_reference.txt”)
※”subnetid”はCloudFormationの”出力”タブで確認する

$ aws ec2 describe-spot-instance-requests --spot-instance-request-ids
<spotrequestid>
{
"SpotInstanceRequests": [
{
"Status": {
"Message": "Your spot request is fulfilled.",
"Code": "fulfilled",
82
以下のコマンドでスポットリクエストの状態を確認する。
※”spotrequestid”はスポットリクエスト作成時の出力かマネコンから確認する

以下のコマンドで、マネコンからスポットリクエストのキャンセルを行う。
(インスタンスは削除されない)
$ aws ec2 cancel-spot-instance-requests --spot-instance-request-ids
<spotrequestid>
{
"CancelledSpotInstanceRequests": [
{
"State": "cancelled",
"SpotInstanceRequestId": ”sir-xxxxxxxx"
}
]
}
※”spotrequestid”はスポットリクエスト作成実行時の出力かマネコンから確認する

$ aws ec2 describe-spot-instance-requests --spot-instance-request-ids
<spotrequestid> |grep InstanceId
"InstanceId": "i-xxxxxxxxxxxxxxxxx",
84
以下のコマンドでスポットリクエストで起動されたインスタンスIDを確認する。
※”spotrequestid”はスポットリクエスト作成時の出力かマネコンから確認する
確認したインスタンスIDのEC2インスタンスを削除する
$ aws ec2 terminate-instances --instance-ids <instanceid>
{
"TerminatingInstances": [
{
"InstanceId": "i-xxxxxxxxxxxxxxxxx",
"CurrentState": {

今回は触れないが、スポットフリートという形でスポットリクエストを作ると、複数種類の
インスタンスタイプを一度に起動することもできる

(3)スケジュールアクション
対象のASGにチェックを入れ、下の”スケジュールされたアクション”タブをクリックし、
[予定アクションの作成]をクリック

以下の値を入れ、予定アクションを作成する。
この例だと、06:05(JSTで15:05)に４台の台数になるようにインスタンスが起動される
・名前：
test1
・希望するキャパシティ：
4
・開始時刻
任意

指定時刻に予定したアクションが行われることを確認。
15:05に合計4台になるように、既存の1台があるので残り3台の起動が始まった。
(注意)スケジュールアクションは最大2分遅れる場合がある

https://qiita.com/pioho07/items/5c0ad11f1e326a0654c1
(4)ターゲット追跡スケーリングポリシーで
定義済メトリクス以外を追加
 ターゲット追跡スケーリングポリシーについて
https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/as-scaling-target-tracking.html
 predefinedmetrics(定義済メトリクス)
https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/APIReference/API_PredefinedMetricSpecification.html
AutoScalingのGUIではターゲット追跡スケーリングポリシーを作成する時、カスタム
メトリクスの選択をまだサポートしていないがCLIで実現できる。
※Autoscalingとして負荷に応じて比例して増加するメトリクスを選ぶ事が大事
 put-scaling-policy
https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html
 Custom Metrics
https://docs.aws.amazon.com/ja_jp/autoscaling/plans/userguide/gs-customized-metric-specification.html

(5)AutoScalingの予測スケーリング
Auto Scaling 予測スケーリングを使用することにより、切迫したトラフィックの変動が生
じる前に Auto Scaling グループが自動的にスケーリングします。また Auto Scaling
を使用して、単一のスケーリングプランで複数のリソースのスケーリング設定を管理でき
ます
①マネコンでAuto Scalingをクリック ②[今すぐ始める]をクリック

“Amazon EC2 Auto Scalingグループの選択”にチェックを入れ、”AutoScalingグループ”
のプルダウンで”handson-as-grp”を選択し、[次へ]をクリックする

スケーリングプランの名前に”handson-as-plan”、スケーリング戦略に”カスタム”にチェック
(次のスライドへ続く)

“予測スケーリング”にチェック、スケーリングメトリクスに”CPUの平均使用率”、平均使用率(
パーセント)に”handson-as-grp”、ターゲット値に”20”、外部のスケーリングポリシーの置き換
えにチェックを入れ、[次へ]をクリック。※設定済のスケーリングポリシーは削除されます
次のページも[次へ]をクリック、次のページで[スケーリングプランの作成]をクリック

①名前の”handson-as-plan”をクリック
②autoScalingGroup/handson-as-planをクリック

Auto Scaling グループで実測された過去一週間の実際の負荷実績と、これを元に
機械学習を行い予想された2日間の負荷予測が確認できます。

前半で終わりの方は、あとかたずけ
1. スケーリングプラン(handson-as-plan)削除 ※オプション-5を行った人のみ
2. Auto Scaling グループ (handson-as-grp)削除
3. Launch Template(handson-as-template)削除
4. ALB(handson-as-lb)削除
5. TargetGroup(handson-as-target)削除
6. CloudFormationスタック(handson-autoscaling)削除
7. キーペア削除(必要であれば消さない)
8. (再確認)”Autoscaling_EC2“、”handson-as-loadserver”という名前の
EC2が削除されていることを確認
96

補足
今回は問題になる負荷トラフィックではないですが、AWS環境における負荷テスト実施時
の重要な考慮点として、Amazon EC2 Testing Policyをご参照ください。
https://aws.amazon.com/ec2/testing/
97
スポットリクエスト制限はデフォルトで、アカウントのリージョンごとに 20 個のスポットイン
スタンスです。スポットインスタンスの制限は動的です｡新規のアカウントの場合、制限が
20 個未満で開始することがありますが、時間とともに増加します
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-spot-limits.html

補足
現在のスポットインスタンス価格確認
https://aws.amazon.com/jp/ec2/spot/pricing/
スポットインスタンスアドバイザースポットインスタンスの中断頻度やオンデマンドとの
コスト比率の確認できる
https://aws.amazon.com/jp/ec2/spot/instance-advisor/
負荷試験(セキュリティ監査)申請フォーム高い負荷試験を行う場合の申請フォーム
https://aws.amazon.com/jp/security/penetration-testing/
98

補足
99
スポット管理を楽にするパートナー様のサービス、Spotinst
https://tech-blog.abeja.asia/entry/lets-use-spotinst

Auto Scaling ハンズオン_後編
(ログ管理、AMI更新とデプロイ、監視、など)
後編へ
Thank you!

Auto Scaling と Spot Instance
のハンズオン(後編)
アマゾンウェブサービスジャパン株式会社

本日の資料
Asset2
https://bit.ly/2AV3i0Y
102

• 常にEC2インスタンスが削除されるAuto Scalingにおいて、取得保存しておき
たいEC2インスタンスの各種ログをS3に送る
• 更新したAMIをAuto Scalingグループにデプロイする
• ファイルをAuto Scalingグループにデプロイする
• Auto Scalingに対する監視/モニタリングのメトリクスを確認する
104

全体構成図
105
S3
CodeDeploy
CloudWatch
Spot Instance
Instance
Spot Instance
Spot Instance
Auto Scaling group
ALB
VPC
AZ1
AZ2
Web-EC2
デプロイ

アジェンダ
S3バケット、IAMロール作成
② ログ管理
Fluentdを入れて必要なログをストリーミングでS3に安全に保存
③ AMI作成とデプロイ
ゴールデンAMIを更新しAuto Scalingグループにデプロイ
CodeDeployを使ってAuto Scalingグループにphpファイルをデプロイ
④ 監視/モニタリング
Auto Scalingで取得できるメトリクスを確認する
⑤ オプション
EC2のデタッチ/スタンバイ、EC2中断のエミュレートなど
106

 S3 バケット作成
 IAMロール作成 (EC2アタッチ用)
 IAMロール作成 (CodeDeployアタッチ用)
108

(1)S3バケット作成
EC2のログを出力、デプロイアセットを保存するためのバケットを作る
AWSマネージメントコンソールから”S3”を選択し、画面の[バケットを作成する]
109

バケット名に以下を入力し
左下の[作成] をクリック
“20190130-handson-as-ueharaxx”
ueharaのところはご自身の名字
xxにはご自身の誕生日の日にち
※S3バケット名はグローバルで一意である必要
があるので、バケット作成ができればバケット名
は任意でも構いません
110

”apachelog”, ”html” のフォルダを2つ作る
111

112
利用Asset2(1の”ec2deploy.zip”)
・htmlフォルダに”ec2deploy.zip”をアップロードする

(2)IAMロール作成 (EC2アタッチ用)
demo-minilakeでロール作成
EC2からAmazonESfullアクセスを付与
作成したロールをEC2にアタッチ
EC2がS3にログを書き込むためのIAM ロール作成
AWSマネージメントコンソールから”IAM”を選択し、”ロール”をクリック[ロールの作成]
113

”AWSサービス”をクリックし、[EC2]をクリック、[次のステップ: アクセス権限]をクリック
114

“AmazonS3FullAceess”にチェックを入れ、[次のステップ]をクリックし、次のページも
[次のステップ]をクリックし、最後に“ロール名”に”handson-as-ec2”と入力し、
[ロールの作成]をクリック
115

(3)IAMロール作成 (CodeDeployアタッチ用)
demo-minilakeでロール作成
EC2からAmazonESfullアクセスを付与
作成したロールをEC2にアタッチ
CodeDeployを実行するためのIAM ロール作成
AWSマネージメントコンソールから”IAM”を選択し、”ロール”をクリック[ロールの作成]
116

”AWSサービス”をクリックし、サービスで[CodeDeploy]をクリック、ユースケースで
[CodeDeploy]をクリック、[次のステップ]をクリック
117

[次のステップ]をクリックし、次のページも[次のステップ]をクリックし、
最後に“ロール名”に”handson-as-codedeploy”と入力し、[ロールの作成]をクリック
118

②ログ管理

 AMIからインスタンス作成
 EC2の設定 (Fluentd)
 ゴールデンAMIの作成
120

EC2の画面から、”インスタンス”->[インスタンスの作成]をクリック
121
(1)AMIからインスタンス作成

“コミュニティ AMI”をクリックし、以下のAMI IDで検索し[選択]をクリック
AMI ID:ami-0010c84e565efc06a
122

• インスタンスタイプ：t2.micro
=>[次の手順]
• VPC:handson-as-vpc
• 自動割り当てパブリックIP：有効
• IAMロール:handson-as-ec2
=>[次の手順]=>[次の手順]
• Name:handson-as-hinagata
=>[次の手順]
• セキュリティグループ：handson-as-sg
=>[確認と作成]=>[起動]
• キーペア：handson
=>[インスタンスの作成]
123
以下を入力しAMIの更新用となるEC2を作成する

(2)EC2の設定 (Fluentd)
ログ収集ツールFluentdのインストール
124

Fluentdとは
 Treasure Dataが開発したOSS
 Ruby製ツール
 軽量
 ログの収集、変換、転送
 特に日本で人気
 Pluggableなので拡張可能で様々なデータストアにリアルタイムログ転送
 バッファリング、再送処理などの機能
※ https://td-agent-package-browser.herokuapp.com/3/redhat/6/x86_64
125

SSHログインし以下の設定を行う
利用Asset2(2の”cmd.txt” コマンドリファレンス)
• rootになる
# sudo su -
• td-agentをインストール
# rpm -ivh
http://packages.treasuredata.com.s3.amazonaws.com/3/amazon/2/2/x86_64/
td-agent-3.3.0-0.amazon2.x86_64.rpm
• /usr/lib/systemd/system/td-agent.serviceの8行目修正
User=td-agentからUser=rootに編集
126

• td-agent.confの修正
Asset2(2の”td-agent.conf”) の中身を<your s3 bucket>のところを実際の
バケット名に置換し、/etc/td-agent/td-agent.confにコピペする
• Fluentdの自動起動設定(実際の起動は後ほど行います)
# systemctl enable td-agent.service
# systemctl restart td-agent.service
• FluentdによろapacheアクセスログのS3へのストリーミング確認
ブラウザでhttp://<handson-as-hinagata>/test.phpに数回アクセス
５分ほど待ちS3にログが出力されることを確認
s3://20190130-handson-as-ueharaxx/apachelog/p-10-9-0-55.ap-northeast-
1.compute.internal.20190123-1045.gz
127

(3)ゴールデンAMI作成
128
EC2の画面から、”インスタンス”をクリックし、”handson-as-hinagata”にチェックを入れ、
[アクション]->”イメージ”->”イメージの作成”をクリック

(3)ゴールデンAMI作成
129
イメージ名を”handson-as-ueharaxx”とし、[イメージの作成]をクリックする
この後の画面でAMI IDが表示されるのでメモ帳などに控えておく
ueharaのところはご自身の名字
xxにはご自身の誕生日の日にち

③AMI更新とデプロイ

 Auto Scaling グループの修正(初期状態)
 起動テンプレートの修正
 Auto Scaling グループの修正でAMIをデプロイ
 CodeDeploy でファイルをデプロイ
131

• オンデマンドの割合：50%
• 希望するキャパシティ：2
• 最小：2
• 最大：４
Auto Scaling グループを以下に修正し、現在の台数を変更する
(1)Auto Scaling グループの修正(初期状態)
もともとオンデマンド1台なら、このタイミングでスポット1台増える
ブラウザで継続的にALBに対してアクセスできることを確認する
※オンデマンドの割合50%の理由は後ほど補足

EC2の画面から、”テンプレートの起動”をクリックし、[起動テンプレートの作成]をクリック
(2)起動テンプレートの修正
133

• “新規テンプレートのバージョンの作成“：チェック
• テンプレート名：”handson-as-template”
• AMI ID：さきほど作成したAMIでメモ帳に控えたID
• キーペア名：handson
• 起動テンプレートのセキュリティグループ：handson-as-sg
▼高度な詳細
• IAMインスタンスプロフィール：handson-as-ec2
• モニタリング：有効化
• ユーザーデータ：利用Asset2(3の”userdata.txt”)を貼り付ける
(CodeDeploy Agentインストール処理)
(2)起動テンプレートの修正
134
#!/bin/bash
# install CodeDeploy agent
yum install ruby -y
yum install aws-cli -y
cd /home/ec2-user
wget https://aws-codedeploy-ap-northeast-1.s3.amazonaws.com/latest/install
chmod +x ./install
以下を入力し画面右下の[起動テンプレートの作成]をクリックする

135

今回テストなので、デプロイが早く行われるようALBのヘルスチェック間隔などの設定を
変更する。本番利用時は適切な値を調整ください。
EC2の画面からターゲットグループ、handson-as-targetのヘルスチェック以下のように
編集し[保存]する
• 正常しきい値：2
• 非正常しきい値：2
• タイムアウト：2
• 間隔：5
(3)Auto Scaling グループの修正でAMIデプロイ

ターゲットグループhandson-as-targetの属性の編集から以下を編集し [保存]する
• 登録解除の遅延：0

138
EC2の画面から、”Auto Scaling グループ”をクリックし、”handson-as-grp”にチェクを入れ
、[操作] ->”編集”をクリック

• “新規テンプレートのバージョン“：最新
• 最小：4
• 最大：４
• 終了ポリシー：OldestLaunchTemplate(Defaultは削除する)
以下を入力し画面右下の[保存]をクリックする
新しいテンプレートで２台作成される
(新しいAMIを使った起動テンプレートで作成される)
https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/as-instance-termination.html
※終了ポリシー”OldestLaunchTemplate”により古いLaunchテンプレートのインスタンスが優先的に終了される

• 最小：2
• 最大：４
現在の台数が4台になったら、再度Auto Scaling グループを修正する
古い２台が削除される
(古い起動テンプレートのEC2が優先的に削除される)
※オンデマンドの割合が例えば25%でインスタンスが1台だと、その
割合分のオンデマンドインスタンス1台を残そうとするので、古い起動テンプレートであって
も削除の対象とならない。そのため前のスライドでオンデマンドの割合を50%とした

• 最小：4
• 最大：４
現在の台数が2台になったら、再度Auto Scaling グループを修正する
すべて新しいLaunchテンプレートのインスタンスにする
しばらくしたらS3にapacheアクセスログが出力されていることを確認する

142

AWS CodeDeploy とは
特徴 (http://aws.amazon.com/jp/codedeploy/)
• Amazon.comと同様の仕組みで、管理され
たデプロイを実現
• エージェントをインストールするだけで
EC2でもオンプレミスでも管理可能
• グループ内に、一度にデプロイしたり1台ず
つデプロイしたりと設定可能
価格体系 (http://aws.amazon.com/jp/codedeploy/pricing/)
• EC2インスタンスへのデプロイは無料
• S3を利用した場合そのリソース分が課金対象
• オンプレミスインスタンスへは1台に1回デ
プロイすると$0.02
アプリケーションデプロイの一元管理サービス

CodeDeployの画面から、左側メニューの”アプリケーション”->[アプリケーションの作成]
をクリック
(4)CodeDeploy でファイルデプロイ

以下を入力し[アプリケーションの作成]をクリック
アプリケーション名：handson-as-app
コンピューティングプラットフォーム：EC２/オンプレ

[デプロイグループの作成]をクリックし、以下を入力し、最後に画面右下の
[デプロイグループの作成]をクリック
• デプロイグループ名：handson-as-depgrp
• サービスロール：handson-as-codedeploy
• Amazon EC2 Auto Scaling グループ：チェック
• Auto Scaling グループ：handson-as-grp
• デプロイ設定：CodeDeployDefault.OneAtATime (1台づつデプロイ)
• ロードバランサを選択：handson-as-target
デプロイタイプは
インプレイスかBlue/Green

選択できるデプロイタイプはインプレースとBlue/Greenの２種類。今回はインプレース
https://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/welcome.html
• インプレースデプロイ
インプレースデプロイ中は、ロードバランサーにより、デプロイ先のインスタンスに対する
インターネットトラフィックのルーティングがブロックされ、そのインスタンスへのデプロイが
完了した時点でインスタンスに対するトラフィックのルーティングが再開されます
• Blue/Greenデプロイ
既存の Auto Scaling グループをコピーして CodeDeploy で自動的にプロビジョニングす
ることができます。また、新しいインスタンスにトラフィックを再ルーティングするタイミング、
トラフィックをルーティングするレート、および完了時に古いインスタンスを終了するかどう
かも選択できます

[デプロイの作成]をクリックし、以下を入力し、最後に画面右下の
[デプロイの作成]をクリック
• デプロイグループ： handson-as-depgrp
• リビジョンの場所： s3://handson-as-ueharaxx/html/ec2deploy.zip

１台づつインプレイスでデプロイが行われていく
CodeDeploy上で確認する
ブラウザで継続的にALBに
対してアクセスできることを
確認する

ブラウザから継続的にアクセスし、画面が新しいphpファイルに切り替わっていくことを確認する
新
旧

CodeDeployで使ったリビジョンec2deploy.zipファイルの中身
※s3://handson-as-ueharaxx/html/ec2deploy.zip
appspec.yml
scripts/delete_php.sh
test.php
デプロイを管理するために AWS
CodeDeploy によって使用されるYAML
式または JSON 形式ファイル
既存test.phpファイルを削除するスクリプ
ト
ブラウザで表示しているtest.phpファイル
デプロイ対象ファイル

appspec.ymlの中身
https://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/reference-appspec-file.html
version: 0.0
os: linux
files:
- source: test.php
destination: /var/www/html/
hooks:
BeforeInstall:
- location: scripts/delete_php.sh
timeout: 300
runas: root
デプロイ対象ファイルtest.phpを指定
test.phpのデプロイ先を指定
デプロイ前に実行するスクリプト
デプロイ後にapache restartなど、他にも
様々な定義ができます

Auto Scalingのライフサイクルフックとして、インスタンス起動時のCodeDeploy実行が登録
される

Codeシリーズのサービスを使うことでよりCI/CDを自動化できます
(補足)Codeシリーズを使ってデプロイパイプライン
CodeCommit
S3
CodeBuild CodeBuild CodeDeploy CloudWatch
CodePipeline

④監視/モニタリング

 Auto Scalingのグループメトリク有効化
 CloudWatch メトリクスの確認
156

(1)Auto Scalingのグループメトリク有効化
157
EC2の画面から、Auto Scalingグループで”handson-as-grp”にチェックを入れ”モニタリ
ング”タブをクリックし、”グループメトリックスコレクションを有効化にする”をクリックする

(2)CloudWatch メトリクスの確認
158
Auto Scalingを利用時に確認するメトリクスをいくつかみていく
①Auto Scaling グループメトリクス

159
CloudWatchの画面を開き、左側メニューの”メトリクス”をクリックし、”Auto Scaling”->
“グループメリクス”をクリック

160
以下はGroupInServiceInstancesでAuto Scalingグループ内のサービスインしている台数

161
Auto Scaling グループメトリクス一覧
https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/as-instance-monitoring.html

162
定期的に監視するとよさそうなもの
• ”GroupServiceInstances”
現在のサービスインしているインスタンス数で、これがグループの最大数に
迫ってきたらアラームを上げて最大数を上げるなどする
• “GroupPendingInstances”,” GroupTerminatingInstances”
保留中と終了中のインスタンス数で、これが長時間高い状態は保留中の処
理や終了が正常に行われていない可能性がある

163
②EC2/Auto Scaling グループ別のメトリクス

164
CloudWatchの画面を開き、左側メニューの”メトリクス”をクリックし、
”EC2”->“Auto Scaling グループ別”をクリック

165
以下はAuto Scaling グループ “handson-as-grp”のCPU使用率

CPU 使用率 — CPUUtilization
ディスク読み取り — DiskReadBytes
ディスク読み取り操作 — DiskReadOps
ディスク書き込み — DiskWriteBytes
ディスク書き込み操作 — DiskWriteOps
ネットワーク入力 — NetworkIn
ネットワーク出力 — NetworkOut
ステータスチェックに失敗 (すべて) — StatusCheckFailed
ステータスチェックに失敗 (インスタンス) — StatusCheckFailed_Instance
ステータスチェックに失敗 (システム) — StatusCheckFailed_System
166
https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/as-instance-monitoring.html#as-view-group-metrics
EC2/Auto Scaling グループ別のメトリクスの一覧

CPU 使用率 — CPUUtilization
ディスク読み取り — DiskReadBytes
ディスク読み取り操作 — DiskReadOps
ディスク書き込み — DiskWriteBytes
ディスク書き込み操作 — DiskWriteOps
ネットワーク入力 — NetworkIn
ネットワーク出力 — NetworkOut
ステータスチェックに失敗 (すべて) — StatusCheckFailed
ステータスチェックに失敗 (インスタンス) — StatusCheckFailed_Instance
ステータスチェックに失敗 (システム) — StatusCheckFailed_System
167
https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/as-instance-monitoring.html#as-view-group-metrics
スケーリングポリシーのメトリクスとして指定したものは定期的な確認をすべき
今回であればCPUUtilization

168
③ApplicationELB/AppELB 別のメトリクス

169
CloudWatchの画面を開き、左側メニューの”メトリクス”をクリックし、
”ApplicationELB”->“AppELB別、TG別メトリクス”をクリック

170
スケーリングポリシーのメトリクスタイプを、”ターゲット別の Application Load Balancer リ
クエストの数”とした場合は”RequestCountPerTarget”を定期的に確認

⑤オプション

(1)EC2のデタッチ/スタンバイ/スケールイン保護
172
Auto Scalingグループ内のEC2インスタンスに行える操作
Auto ScalingグループからEC2インスタンスを一時的に切り離して、トラブルシュート
や調査を行うことができます。
• デタッチ/アタッチ
Auto Scalingグループから削除し通常のEC2インスタンスとして扱えます。再度
アタッチすることも、別のAuto Scalingグループにアタッチすることもできます
• スタンバイ/実行中
一時的にAuto Scalingグループのサービスの対象外にします。Auto Scalingグル
ープ内には残ります
• スケールイン保護/解除
スケールイン時の削除対象から外します。

スタンバイを試す
Auto Scaling グループの画面から、”handson-as-grp”にチェック->”インスタンス”タブ
をクリック->任意のインスタンス1つにチェック-> [操作]->”スタンバイに設定”をクリック

“負荷を分散するため、新しいインスタンスをAuto Scaling グループに追加します”
にチェックを入れ、[スタンバイに設定]をクリック

1台がスタンバイとなり、1台が補充され、合計で５台になる
※デタッチ/スタンバイ/スケールイン保護など出来ますが、Auto Scalingで使うEC2インス
タンスは、基本はステートレスでディスポーザブルな使い方を前提に設計してください

(2)中断のエミュレート
176
スポット料金がお客様のリクエストの上限料金を超えた場合、または容量が使用できなく
なった場合、EC2 はスポットインスタンスを終了、停止、または休止状態にします。 EC2
では、スポットインスタンスの中断通知が表示されます。それにより、インスタンスの停止
前に2 分の警告期間が与えられます
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/spot-interruptions.html
この警告は、CloudWatch イベントとして、およびスポットインスタンス上のインスタンスメタ
データの項目として使用可能です。
CloudWatchイベントでメッセージを確認してみます

177
SNSの画面を開き、左側メニューから”トピック”クリックし、 [新しいトピックの作成]をクリック
トピック名に”handson-sns”を入力し、[トピックの作成]をクリック

178
作成したトピックのARN名をクリック
[サブスクリプションの作成]->プロトコルに”Email”を選択メールアドレス入力->[サブスクリプ
ションの作成]。”Subscription Confirm”のメールが届くので”confirm subscription”をクリック

179
EC2の画面を開き、左側メニューの”スポットリクエスト”をクリックし、
[スポットインスタンスのリクエスト]をクリック

180
以下を入力し、画面右下の[作成]をクリック
• 起動テンプレート：handson-as-template
• ネットワーク：handson-as-vpc
• アベイラビリティゾーン： “ap-northeast-1a” と “ap-northeast-1c”にチェック
• ターゲット容量を維持する：チェック
• 合計ターゲット容量：”2” インスタンスにする

181
CloudWatchの画面を開き、左側メニューの”ルールをクリックし、[ルールの作成]をクリック

以下を入力/選択し、画面右下の[設定の詳細]をクリック。
その後ルール名をhandson-ruleと入力し[ルールの作成]をクリック
サービス名：EC2
イベントタイプ:EC2 Spot Instance Interuption Warning
ターゲット：SNSトピック
トピック：handson-sns

EC2の画面で、左側メニューから”スポットリクエスト”をクリックし、[アクション]->
”ターゲット容量の変更”をクリック。新しいターゲットキャパシティを1にし、[送信]をクリック

スポットインスタンスの中断通知イベントを検知し、SNSでで通知が行われる。
スポットインスタンスの中断イベントをもとにLambdaを実行してELBから安全に取り外す
などの利用も可能

補足
ZOZO Technologies様のAuto ScalingとCodeDeployとOpsWorksを使った事例
https://techblog.zozo.com/entry/codedeploy-autoscaling
Under the Hood:AWS CodeDeploy and Auto Scaling Integration(ちょっと古い)
https://aws.amazon.com/jp/blogs/devops/under-the-hood-aws-codedeploy-and-auto-scaling-integration/
DataDog での Auto Scaling の監視
https://qiita.com/pypypyo14/items/81beab7e26a33172eb1d
Zabbix での Auto Scaling の監視
https://aws.typepad.com/aws_partner_sa/2016/09/opsjaws-try-ops-with-zabbix-4.html
外道父様のAuto Scaling全般のTIPS
http://blog.father.gedow.net/2019/02/05/aws-auto-scaling-2019/
185

あとかたずけ
【オプション-2 を実施した人のみ】
1. スポットリクエストのキャンセル
2. CloudWatchイベント削除
3. SNSトピック削除
【本編実施】
1. Auto Scalingグループの”希望キャパシティ”、”最小”、”最大”を全て0にする
2. CodeDeployのアプリケーションを削除(handson-as-app)
3. EC2インスタンスの削除(handson-as-hinagara)
4. AMIの削除(handson-as-ueharaxx)
5. S3バケットの削除(20190130-handson-as-ueharaxx)
6. IAMロールの削除(handson-as-ec2、 handson-as-codedeploy)
186

Thank you!

AutoScaling & SpotInstance Handson

More Related Content

What's hot

Similar to AutoScaling & SpotInstance Handson

More from Makoto Uehara

Recently uploaded

AutoScaling & SpotInstance Handson

Editor's Notes