2015年12月16日に放送したEC2 Spot Instance & Auto Scalingの回の資料です。今後の予定は以下をご覧ください。 http://aws.amazon.com/jp/about-aws/events/#webinar

1. &
Amazon EC2
スポットインスタンス
Auto Scaling
Amazon Web Service Japan K.K.
Solutions Architect
Akihiro Tsukada

2. AWSでの担当
スタートアップのお客様
モバイル系ソリューション
AWS Mobile Hub
Amazon Cognito
サーバレスアーキテクチャ
低コストアーキテクチャ
エンジニア的な属性
Ruby, iOS
OOP, SOLID, KISS
好き
ジャッキーチェン
妻と娘
塚田 朗弘 @akitsukada
2

3. はじめに

4. Q
スポットインスタンス と
Auto Scaling は
“新サービス”？
4
「新サービス紹介月間」 ？

5. A
歴史は古いが、
今なお新機能のリリースが多く、
改めてご紹介したいサービス
5

6. スポットインスタンスに関するアップデート@2015
(参考情報)
2015.03.25
リザーブドインスタンス
&スポットインスタンス
Black Belt Webinar
〜〜
2009.12 2015.12
2015.05
スポットフリートAPI
リリース
2015.01
ターミネート通知機能
リリース
2015.08
スポット
入札アドバイザー
リリース
2015.08
スポットフリート拡張
リソース指向入札機能
リリース
2015.10
管理コンソールと
CloudFormationが
スポットフリートに対応し、
実行中フリートのサイズ変更機能
リリース
2015.10
スポットブロック
リリース
6

7. アジェンダ
Amazon EC2
EC2 スポットインスタンス
Auto Scaling
Tips
Q & A
7

8. Amazon EC2

9. Amazon Elastic Compute Cloud (EC2)
• 特徴 (http://aws.amazon.com/jp/ec2/)
– 必要な時に必要なだけ1時間単位の従量課金で
利用できる仮想サーバリソース
– 世界11箇所のリージョンで利用可能
– 様々なスペック・OSを選択可能
• 価格体系 (http://aws.amazon.com/jp/ec2/pricing/)
– インスタンス利用料($0.02/hour 〜)
– データ転送量(OUT $0.14/GB )
仮想クラウドサーバ
9

10. Amazon EC2 購入オプション
オンデマンドインスタンス
スタンダードな時間課金型インスタンス
リザーブドインスタンス
1年間または3年間の予約をすることで最大75%の割引
スポットインスタンス
使われていないEC2インスタンスに入札して格安利用
最大90%以上の大幅割引
Dedicated Hosts
お客様専用の物理サーバーを確保
10

11. Auto Scaling
• 特徴 (http://aws.amazon.com/jp/autoscaling/)
– Amazon EC2インスタンス群を自動的に
スケール
– 耐障害性の向上（インスタンスの異常を
検知して、新しいインスタンスを起動）
– EC2インスタンスの起動料金の最適化
• 価格体系 (http://aws.amazon.com/jp/autoscaling/pricing/)
– Auto Scaling自体の利用は無料
– Auto Scalingによって起動されるEC2インス
タンスの起動料金
• Spotインスタンスとしても起動可能
EC2インスタンスを負荷またはスケジュールに応じて自動増減
Desired
Capacity
必要に応じて
追加される
Capacity
起動設定
• インスタンスタイプ
• AMI
• Spot入札価格 など
11

12. Auto Scaling @
Request
Instances
12

13. 大幅なコストカット
サーバーリソース節約
急な負荷増加に対応
巨大な計算能力の確保
…etc
13

14. EC2 スポットインスタンス

15. Amazon EC2 スポットインスタンス
余っているEC2インスタンスを低価格で有効活用していただく仕組み
最大90%以上の割引価格でEC2インスタンスを使用可能
スポット入札アドバイザー、Spot Fleet、Spot Blockなどの
強力な周辺ツール/機能
分散処理、Workerが典型的なユースケース
…だったが、新しい動きも出てきている
Amazon EMR、Auto Scalingとの併用が容易
$1 $
15

16. この資料において単に「スポットインスタンス」という場合、
特に断りがなければ従来のスポットインスタンスを指します。
スポットブロック機能およびそのインスタンスを指す場合は明示的に
「スポットブロック」「スポットブロックのインスタンス」と呼びます。
注
16

17. スポットインスタンス関連概念の整理
スポットプール
スポット価格
入札価格
落札
インスタンスの中断
17

18. ap-northeast-1a
(Tokyo Region)
m4.large
…
m4.xlarge
スポット関連概念の整理
c4.large
ap-northeast-1c
m4.large
…
m4.xlarge c4.large
18

19. ap-northeast-1a
(Tokyo Region)
m4.large
…
m4.xlarge
スポット関連概念の整理
c4.large
ap-northeast-1c
m4.large
…
m4.xlarge c4.large
使用中
使用中
使用中
使用中
使用中 使用中
19

20. ap-northeast-1a
(Tokyo Region)
m4.large
…
m4.xlarge
スポット関連概念の整理 - スポットプール
c4.large
ap-northeast-1c
m4.large
…
m4.xlarge c4.large
使用中
使用中
使用中
使用中
使用中 使用中
Availability Zone（以下AZ）、OS、
インスタンスタイプごとの使われていない
EC2インスタンスたち
20

21. ap-northeast-1a
(Tokyo Region)
m4.large
…
m4.xlarge
スポット関連概念の整理 - スポット価格
c4.large
ap-northeast-1c
m4.large
…
m4.xlarge c4.large
使用中
使用中
使用中
使用中
使用中 使用中
$0.0384 $0.0346$0.0346
$0.0530
$0.0209
スポットプール毎に需要と共有のバランスで変動する、
その時点でのスポットインスタンス課金額
同じインスタンスタイプでもAZで異なる価格
$3.66
21

22. ap-northeast-1a
(Tokyo Region)
m4.large
…
m4.xlarge
スポット関連概念の整理 - 入札価格
c4.large
ap-northeast-1c
m4.large
…
m4.xlarge c4.large
使用中
使用中
使用中
通常
使用中
通常
使用中
通常
使用中
$0.0384 $0.0346$0.0346
$0.0530
$0.0209
「最大でここまでなら支払ってもよい」という価格
実際に課金されるのはスポット価格
管理コンソールまたはRequestSpotInstances APIから
リクエスト可能
$3.66
「東京リージョンの
1aにあるc4.largeを
最大$0.05で使いたい！」
22

23. ap-northeast-1a
(Tokyo Region)
m4.large
…
m4.xlarge
スポット関連概念の整理 - 落札
c4.large
ap-northeast-1c
m4.large
…
m4.xlarge c4.large
使用中
使用中
使用中
通常
使用中
通常
使用中
通常
使用中
$0.0384 $0.0346$0.0346
$0.0530
$0.0209
入札価格がスポット価格を上回り、スポットプールに空きがあった場合※、
希望したスポットインスタンスを使いはじめることができる
※詳しくは「スポットインスタンスのしくみ」を参照のこと
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/how-spot-instances-work.html
$3.66「東京リージョンの
1aにあるc4.largeは
現在$0.0346なので、
$0.05入札で起動できた！」
23

24. ap-northeast-1a
(Tokyo Region)
m4.large
…
m4.xlarge
スポット関連概念の整理 - インスタンスの中断
c4.large
ap-northeast-1c
m4.large
…
m4.xlarge c4.large
使用中
使用中
使用中
通常
使用中
通常
使用中
通常
使用中
$0.0384 $0.0346
$0.051
$0.0530
$0.0209
スポット価格が変動し入札価格を上回ったとき、スポットインスタンス
はターミネートされる。インスタンスから以下のURLをGETすると、
2分前から通知を取得できる。5秒ごとのポーリングを推奨。
http://169.254.169.254/latest/meta-data/spot/termination-time
$3.66「スポット価格が変動して
入札価格$0.05を上回って
しまった。ターミネート前
に終了処理をしよう」
24

25. スポットリクエストと課金チャート

26. 単価
時間
スポット価格
入札額
課金額
①ワンタイム
リクエスト投入
(type=one-time)
$0.01
$0.24
$0.30
1h 1h
③1時間
単位の課金
④
入札額＜スポット価格
になったので
インスタンス終了
ワンタイムスポットリクエスト(デフォルト)と課金
②
入札額>スポット価格
になったので
インスタンス起動
<1h
⑤強制終了時の1時間
未満の利用分は非課金
⑥ワンタイムリクエストは
自動キャンセルされるので
インスタンスは起動しない 26

27. 単価
時間
スポット価格
入札額
課金額
①永続
リクエスト投入
(type=persistent)
$0.01
$0.24
$0.30
1h 1h
③1時間
単位の課金
④
入札額＜スポット価格
になったので
インスタンス終了
永続スポットリクエスト(オプション)と課金
②
入札額>スポット価格
になったので
インスタンス起動
<1h
⑤強制終了時の1時間
未満の利用分は非課金
⑥永続スポットリクエストは
キャンセルするまで有効
なので再度インスタンス起動 27

28. 入札戦略（旧）
スポットフリート（後述）の登場以前は、以下の様な
意図と要領で入札価格を決定するノウハウがあった
1. コスト最小型
ターゲットスポットプールの最低価格で入札
2. 価格履歴順応型
直近のスポット価格等をプログラムで監視して入札額を調整
（≒手動スポットフリート！）
3. オンデマンドキャップ型
オンデマンド料金付近で入札し、オンデマンドより高い課金はさせない
4. 割り込みリスク最小型
オンデマンドよりも高く入札し、ターミネートのリスクを軽減する
現在はスポットフリートを使うことで基本的にこれらを
カバーできるため、スポットフリートの活用がオススメ！
28

29. 価格高騰しにくいスポットプールを選ぶには
スポット入札アドバイザー（2015.08〜）
リージョン、OS、入札価格
(25%, 50%, 100%)を選ぶ
と、各スポットプールの過
去データ（先週、先月）と
照合して、価格高騰の可能
性を表示してくれる。
vCPUやメモリ、EMRサポー
ト有無でフィルタリングも
可能。
https://aws.amazon.com/jp/ec2/spot/bid-advisor/
29

30. スポットインスタンス ここまでのまとめ
EC2購入オプションの一つで、各スポット関連サービスの
基本となる考え方
管理コンソールおよびRequestSpotInstances APIで利用
機能連携されているAutoScaling、EMRからも利用可能
スポット価格が入札価格を上回るとターミネートされる
通知をチェックし、終了処理を仕込んでおく必要がある
対策としていくつかのアプローチがあり、それぞれ考慮
しておくべきことがある（次ページ参照）
スポット入札アドバイザーで価格変動しにくいスポットプー
ルを見つけることができる
30

31. スポットインスタンス利用時の考慮点

32. スポットインスタンス 利用時に考慮しておくべきこと
1. ターミネート時の後処理
2. 突然のターミネートが許容されるワークロードか？
Webのフロントサーバなどユーザインパクトに直結する箇所や、
遅延が許されないタスクでの使用はNG…だった
今なら、そういうときはスポットフリートを検討すべし
3. いかにターミネートの頻度、リスクを軽減するか
複数のスポットプールに分散し、スポット価格高騰時のリスクを
軽減するスポットフリートを利用する
スポット価格の変動に関わらず、一度落札できさえすれば
指定時間内は落ちないスポットブロックを利用する
4. とはいえ、それでも必要なインスタンスが確保できなかったら？
32

33. スポットフリート

34. スポットフリート（2015.05〜）
EC2スポットインスタンスを効率よく利用するための
ユーザー支援＆スポット管理機能
管理コンソールおよびRequestSpotFleet APIから利用
複数のスポットプールにそれぞれ異なる価格を入札した
り、各プールのスポット価格が変動した際の処理を自動
化したりできる
必要な台数またはリソースをフリート全体で確保する
インスタンスの配置戦略として、最も低価格なスポット
プールを優先して使う、極力多くのスポットプールに分
散して利用するといった戦略が選択できる 34

35. つまりスポットフリートとは
1. 複数のスポットプールを効率的に使う
• より安価なスポットプールを選択
• より安全に複数のスポットプールを選択
2. 大量のコンピューティングリソースを
スポットインスタンスで維持しやすくする
というスポットユーザ支援機能
35

36. 《事例紹介》
Webアプリケーション with スポットフリート

37. Elastic Load
Balancing
Stateless
Web Servers
(Spot)
Stateless
Web Servers
(Spot)
Session
State Data
Spot fleet
Availability Zone A
Availability Zone B
Stateless
Web Servers
(Spot)
Stateless
Web Servers
(Spot)
ステートレスなWebサーバ群
37

38. スポットフリートによるDiversification
複数のスポットプールを選択
似た性能/指向を持つ
インスタンスタイプを選択
c3.large, m3.large,
m4.large, r3.large,
c4.large
38

39. 30日間以上で約50台の
スポットインスタンスが
リクエストされた
- 45台を下回ることは
なかった
- 50台必要な箇所で
45台に落ちること
を許容したことで、
85%のコストカットに
0
0.02
0.04
0.06
0.08
0.1
0.12
30
35
40
45
50
55
Instances Average Price Per Instance
- 50台を45台にして
試算しても、やはり
83%のコストカットに
スポットフリート＠Webアプリ の結果
39

40. Whodunit?
40

41. スポットブロック

42. スポットブロック（2015.10〜）
スポットインスタンスのオプションではあるが、指定した
時間中（1〜6時間）はターミネートされないという機能
スポットインスタンスをAPIでリクエストする際、
blockDurationMinutesパラメータを指定すると
スポットブロックとしてのリクエストになる
管理コンソールは未対応（2015年12月16日現在）
スポット価格とは別系統で変動するスポットブロック専用の
価格（以下、ブロック価格）は存在する
課金額としては落札時のブロック価格が維持される
指定時間内でも、使用を中止すればその時点までの
課金しか発生しない
42

43. ~ 21% 1時間以内
~ 35% 2時間以内
~ 40% 3時間以内
およそ50%のインスタンスが
6時間以内にターミネートされている
6時間は妥当か？
43

44. EC2 各購入オプション料金比較例
2015年12月16日現在/東京リージョン/Linuxインスタンス。()内はOn-Demandからの節約比率
On
Demand
Reserved Instances for 1 year Spot
Instance
s
Spot Block
All
Upfront
Partial
Upfront
No
Upfront 1h 6h
c4.large $0.14
$0.0935
(33%)
$0.095
(32%)
$0.106
(24%)
$0.0265
(81%)
$0.077
(45%)
$0.098
(30%)
m4.large $0.183
$0.0961
(47%)
$0.098
(46%)
$0.115
(37%)
$0.0206
(88%)
$0.101
(44%)
$0.128
(30%)
r3.large $0.21
$0.1339
(36%)
$0.1367
(35%)
$0.157
(25%)
$0.0202
(90%)
$0.116
(44%)
$0.147
(30%)
44

45. オフピーク時間の定義は2015年12月16日現在の情報
Spot Block
1h 6h
c4.large
$0.070
(50%)
$0.091
(35%)
m4.large
$0.093
(49%)
$0.118
(35%)
r3.large
$0.107
(49%)
$0.136
(35%)
45
リージョン オフピーク時間 (UTC)
米国東部 (バージニア北部) 土曜日 0:00〜月曜日 0:00
米国西部 (北カリフォルニア) 土曜日 12:00〜月曜日 12:00
米国西部 (オレゴン) 土曜日 12:00〜月曜日 12:00
欧州 (アイルランド) 土曜日 9:00〜月曜日 9:00
欧州 (フランクフルト) 土曜日 10:00〜月曜日 10:00
アジアパシフィック (シンガポール) 土曜日 8:00〜月曜日 8:00
アジアパシフィック (東京) 土曜日 9:00〜月曜日 9:00
アジアパシフィック (シドニー) 土曜日 10:00〜月曜日 10:00
南米 (サンパウロ) 金曜日 19:00〜日曜日 19:00
オフピーク時間はさらに5%引き（スポットブロックのみ）
https://aws.amazon.com/jp/ec2/spot/pricing/

46. スポットブロックと課金（時間経過パターン）
単価
時間
ブロック価格
入札額
課金額
$0.24
$0.30
6h
①リクエスト
投入
--block-duration-minutes 360
②落札後は
課金額固定
③指定した時間が経過した
46

47. スポットブロックと課金（手動終了パターン）
単価
時間
ブロック価格
入札額
課金額
$0.24
$0.30
③手動でリクエストを
終了した
6h
①リクエスト
投入
--block-duration-minutes 360
②落札後は
課金額固定
47

48. つまりスポットブロックとは
1. 最初に落札さえできれば、ブロック価格が高騰
しても課金額維持＆指定時間内は終了されない
2. 1〜6時間の短期間を前払いなしで割安利用でき
るリザーブドインスタンスに近いもの
• 途中で終了すれば課金も停止(期間縛りなし)
• 価格はオンデマンドより安くスポットより高い
というスポットインスタンスの拡張機能
48

49. Q
それでも必要なインスタンスを
確保できなかったら？
そもそも落札できなかったら？
49

50. A
（解答例）
オンデマンドインスタンスの
予備系を用意しておく
50

51. 前提
1. スポットは落ちるもの。
2. スポットが落ちた時、ある程度の遅延を許容できる
設計になっていること。
構成
スポットなサーバ群とオンデマンドなサーバ群を用意
オンデマンドなサーバ群は最低台数のみ立てておく
二つのサーバ群に同じ処理をさせる
(例:同じジョブを捌くWorkerなど)
スポットサーバ群が突然全てターミネートしても、オンデマンド
サーバ群がスケールアウトするよう Auto Scaling Group※
(以下ASG)を設定しておく。あるいは、スポットの終了処理中に
オンデマンドサーバ台数を変更するなど。 51
※Auto Scalingについては後ほど詳しく解説
オンデマンド予備軍の作り方(ASGで実現する場合)

52. オンデマンド予備軍の作り方(ASGで実現する場合)
Super Hard Task
Spot ASG On-Demand ASG
When CPU > 60% Then Add
2
When CPU < 20% Then Rem
2
When CPU > 75% Then Add
2
When CPU < 35% Then Rem
2
1. ASGの準備
同じタスクを与えつつ、
Scaling PolicyのThresholdに
差をつけ、
Spot ASGは
On-Demand ASGより
スケールアウトしやすく
スケールインしにくい
設定にしておく
52

53. オンデマンド予備軍の作り方(ASGで実現する場合)
Super Hard Task
Spot ASG On-Demand ASG
When CPU > 60% Then Add
2
When CPU < 20% Then Rem
2
When CPU > 75% Then Add
2
When CPU < 35% Then Rem
2
2. 普段はSpot ASGで捌く
普段はSpot ASGだけインスタ
ンスが増減し、On-Demand
ASGは常に1台だけになってい
ることを確認する
53

54. オンデマンド予備軍の作り方(ASGで実現する場合)
Super Hard Task
Spot ASG On-Demand ASG
When CPU > 60% Then Add
2
When CPU < 20% Then Rem
2
When CPU > 75% Then Add
2
When CPU < 35% Then Rem
2
3. スポット価格高騰！
Spot ASGのインスタンスが
終了し、On-Demand ASGの
1台のみが残る
54

55. オンデマンド予備軍の作り方(ASGで実現する場合)
Super Hard Task
Spot ASG On-Demand ASG
When CPU > 60% Then Add
2
When CPU < 20% Then Rem
2
When CPU > 75% Then Add
2
When CPU < 35% Then Rem
2
4. On-Demandがスケール
On-Demand ASGが
Auto Scalingによって
スケールアウトし、
Spot ASGの代わりに頑張る
55

56. Auto Scaling

57. Auto Scaling
オンとオフ 予測可能なピーク
無駄なサーバーは落としておきたい
負荷に応じて必要最小限の台数を立てておきたい
余剰キャパシティ
立ちっぱなしのEC2
57

58. 予測可能なピークオンとオフ
Auto Scaling
需要に応じて自動的にサーバが増減しコストカット
スケーリングのポリシーやインスタンスは柔軟に設定可能
UnhealthyなインスタンスやAZを自動で排除して高可用性
サービスが成長してきたら最大台数を増やして対応
すっきり！
58

59. Auto Scaling @
Request
Instances
59

60. 代表的なユースケース 1/2 – ELB配下のWebサーバ
EC2 EC2Auto
Scaling
AZ-1 AZ-2
スケーリングトリガーの例
ELBのRequest数
Auto Scaling Group内EC2の
CPU使用率など
EC2は複数AZに分散して高可用性
ELB
60

61. 代表的なユースケース 2/2 – SQSのジョブを処理するWorker
EC2 EC2Auto
Scaling
AZ-1 AZ-2
スケーリングトリガーの例
SQSのキューに溜まった
メッセージ（ジョブ）数
Auto Scaling Group内EC2の
CPU使用率など
EC2は複数AZに分散して高可用性
大量のスポットインスタンスを
併用しやすいパターン
コストカットチャンス！
SQS
61

62. 1. CloudWatchアラームによるスケーリング
負荷や各種イベントに応じて増減させる
CPU使用率、ELB Laytency、SQSのメッセージ数 etc…
2. Scheduled Actionによるスケーリング（管理コンソール未対応）
特定日時指定実行
「2015/12/31 22:45 JST にインスタンスを30台にする」
繰り返し実行
cronライクな定義方法
「毎週水曜日17:50にスポットインスタンスを100台にして
19:10に10台に戻す」など
3. 手動スケーリング
管理コンソール/CLIから手動で操作可能
スケーリングの種類
62

63. 1. Auto Scaling Group (以下ASG)
Auto Scalingの全体的な情報管理単位
ASG名、最小/最大台数、ヘルスチェック方法、AZ/VPC、ターミネート
ポリシー、ELB、Instance Tags、Launch Configurationなど
2. Launch Configuration
ASG内でEC2インスタンスを起動する際に必要な情報
通常のEC2インスタンスを起動する際の入力情報とほぼ同じ
Launch Configuration名、AMI、インスタンスタイプ、
Security Group(s)、Key Pair、IAM role、user-data、
Storage、CloudWatch Detailed Monitoring、Spot priceなど
3. Auto Scaling Policy
ASG内でいつどのようにスケールイン/アウトを実行するか
ASG一つにつき複数のポリシーを設定できる
Policy名、トリガーとするAlarm、Action内容
Auto Scalingの設定
63

64. Auto Scaling図解
Auto Scaling Group
AZ-1:VPC1:Subnet1Scaling Policy 2 (simple policy)
Min:2, Max:6
AZ, VPC/Subnet, ELB, Tags
AZ-2:VPC2:Subnet2
Scaling Policy 1 (with steps)
Alarm: HighCPUUtilization
Actions(Steps):
60 < value → add 2 Instances
80 < value → add 10% of group
30 > value → remove 2 Instances
warm up: 300 seconds
Alarm: HighLaytency
Action(only one):
300 < value → add 2 Instances
cool down: 300 seconds
Launch Configuration
Launch Configuration
Launch Configuration
AMI, Instance Type,
IAM Role, Security Group,
Key Pair, user-data,
Storage, Spot Price
Associate
64

65. Auto Scaling図解
Auto Scaling Group
Launch Configuration
Launch Configuration
Launch Configuration
AZ-1:VPC1:Subnet1Scaling Policy 2 (simple policy)
Min:2, Max:6
AZ, VPC/Subnet, ELB, Tags
AZ-2:VPC2:Subnet2
Scaling Policy 1 (with steps)
Alarm: HighCPUUtilization
Actions(Steps):
60 < value → add 2 Instances
80 < value → add 10% of group
30 > value → remove 2 Instances
warm up: 300 seconds
Alarm: HighLaytency
Action(only one):
300 < value → add 2 Instances
cool down: 300 seconds
AMI, Instance Type,
IAM Role, Security Group,
Key Pair, user-data,
Storage, Spot Price
Associate
Alarm!!
CloudWatch
①CloudWatchから、CPU使用率60%超のAlarm!
65

66. Auto Scaling図解
Auto Scaling Group
Launch Configuration
Launch Configuration
Launch Configuration
AZ-1:VPC1:Subnet1Scaling Policy 2 (simple policy)
Min:2, Max:6
AZ, VPC/Subnet, ELB, Tags
AZ-2:VPC2:Subnet2
Scaling Policy 1 (with steps)
Alarm: HighCPUUtilization
Actions(Steps):
60 < value → add 2 Instances
80 < value → add 10% of group
30 > value → remove 2 Instances
warm up: 300 seconds
Alarm: HighLaytency
Action(only one):
300 < value → add 2 Instances
cool down: 300 seconds
AMI, Instance Type,
IAM Role, Security Group,
Key Pair, user-data,
Storage, Spot Price
Associate
②Min-Max:2-6で現在4台なのであと2台増やせる
66

67. Auto Scaling図解
Auto Scaling Group
Launch Configuration
Launch Configuration
Launch Configuration
AZ-1:VPC1:Subnet1Scaling Policy 2 (simple policy)
Min:2, Max:6
AZ, VPC/Subnet, ELB, Tags
AZ-2:VPC2:Subnet2
Scaling Policy 1 (with steps)
Alarm: HighCPUUtilization
Actions(Steps):
60 < value → add 2 Instances
80 < value → add 10% of group
30 > value → remove 2 Instances
warm up: 300 seconds
Alarm: HighLaytency
Action(only one):
300 < value → add 2 Instances
cool down: 300 seconds
AMI, Instance Type,
IAM Role, Security Group,
Key Pair, user-data,
Storage, Spot Price
Associate
③Launch Configurationに従いインスタンス起動
67

68. Auto Scaling図解
Auto Scaling Group
Launch Configuration
Launch Configuration
Launch Configuration
AZ-1:VPC1:Subnet1Scaling Policy 2 (simple policy)
Min:2, Max:6
AZ, VPC/Subnet, ELB, Tags
AZ-2:VPC2:Subnet2
Scaling Policy 1 (with steps)
Alarm: HighCPUUtilization
Actions(Steps):
60 < value → add 2 Instances
80 < value → add 10% of group
30 > value → remove 2 Instances
warm up: 300 seconds
Alarm: HighLaytency
Action(only one):
300 < value → add 2 Instances
cool down: 300 seconds
AMI, Instance Type,
IAM Role, Security Group,
Key Pair, user-data,
Storage, Spot Price
Associate
④インスタンスの初期化、Health Checkを実行
68

69. Auto Scaling図解
Auto Scaling Group
Launch Configuration
Launch Configuration
Launch Configuration
AZ-1:VPC1:Subnet1Scaling Policy 2 (simple policy)
Min:2, Max:6
AZ, VPC/Subnet, ELB, Tags
AZ-2:VPC2:Subnet2
Scaling Policy 1 (with steps)
Alarm: HighCPUUtilization
Actions(Steps):
60 < value → add 2 Instances
80 < value → add 10% of group
30 > value → remove 2 Instances
warm up: 300 seconds
Alarm: HighLaytency
Action(only one):
300 < value → add 2 Instances
cool down: 300 seconds
AMI, Instance Type,
IAM Role, Security Group,
Key Pair, user-data,
Storage, Spot Price
Associate
⑤Health Checkに問題なければELB配下に追加
69

70. Auto Scaling図解
Auto Scaling Group
Launch Configuration
Launch Configuration
Launch Configuration
AZ-1:VPC1:Subnet1Scaling Policy 2 (simple policy)
Min:2, Max:6
AZ, VPC/Subnet, ELB, Tags
AZ-2:VPC2:Subnet2
Scaling Policy 1 (with steps)
Alarm: HighCPUUtilization
Actions(Steps):
60 < value → add 2 Instances
80 < value → add 10% of group
30 > value → remove 2 Instances
warm up: 300 seconds
Alarm: HighLaytency
Action(only one):
300 < value → add 2 Instances
cool down: 300 seconds
AMI, Instance Type,
IAM Role, Security Group,
Key Pair, user-data,
Storage, Spot Price
Associate
⑥Warm up期間はASGのメトリクスに含まれない
70

71. Auto Scaling図解
Auto Scaling Group
Launch Configuration
Launch Configuration
Launch Configuration
AZ-1:VPC1:Subnet1Scaling Policy 2 (simple policy)
Min:2, Max:6
AZ, VPC/Subnet, ELB, Tags
AZ-2:VPC2:Subnet2
Scaling Policy 1 (with steps)
Alarm: HighCPUUtilization
Actions(Steps):
60 < value → add 2 Instances
80 < value → add 10% of group
30 > value → remove 2 Instances
warm up: 300 seconds
Alarm: HighLaytency
Action(only one):
300 < value → add 2 Instances
cool down: 300 seconds
AMI, Instance Type,
IAM Role, Security Group,
Key Pair, user-data,
Storage, Spot Price
Associate
⑦Auto ScalingのAction完了！
71

72. スケールイン/アウト時の考慮点

73. 1. 設定済みのAMI
（ゴールデンイメージ）を用いる
スケールアウト時の初期化処理（組み合わせて使うのが現実的）
すべてインストール
＆構成済みのAMI
2. user-dataで
初期化スクリプトを実行する
3. Life Cycle Hooksを利用して初期化する
#!/bin/bash
cd /home/ec2-user;
aws s3 cp s3://aws-install-sh/install
chmod +x ./install;
./install auto;
pending
SQS
SNS
73

74. 1. ターミネートに備える
スケールインのActionが走ったらいずれかのインスタンスは
ターミネートする
2. サーバーをステートレスにしておく
セッション情報はDynamoDBやElastiCache等に外出しする
ログファイルはS3にアップロードするなどの実装をする
WebSocketのようなコネクション維持系プロトコルを使う
場合は工夫が必要
スケールイン時の後処理
74

75. Auto Scaling
ライフサイクルとターミネート

76. 1. Auto ScalingによるEC2起動/終了処理を待機させ、
SNS/SQSに通知させる
Pending(待機)→Running→Terminating(待機)→Terminated
デフォルト60分の待機時間にカスタムアクション（初期化/終了処
理）を行う
2. ライフサイクルアクション
以下の操作時は、SNS/SQSへの通知に含まれていた
LifecycleActionTokenをパラメータとして指定する
1. 待機時間の延長
recordLifecycleActionHeartbeatコマンドを1度叩くと
60分ずつ延長でき、最大48時間まで待機させられる
2. カスタムアクションの完了
completeLifecycleActionコマンドを叩く
Auto Scaling Life Cycle Hooks
76

77. ターミネーションポリシー
スケールイン時、どのインスタンスから削除するか※
① OldestLaunchConfiguration
最も古いLaunch Configurationにより起動している
インスタンス
② OldestInstance/NewestInstance
最も古い/新しい起動時刻のインスタンス
③ ClosestToNextInstanceHour
次の課金が始まるタイミングが最も近いインスタンス
④ Default
①③の順に適用し、複数インスタンスが残ればランダム
複数ポリシー指定時は指定順に適用
全ポリシー適用後も複数インスタンスが存在する場合はランダム
※ただしインスタンス保護（次ページ）されているインスタンスは除く 77

78. インスタンス保護 （2015.12.07〜）
スケールイン時、任意のインスタンスを削除されないよう保護できる
長時間かかるタスクを実行中のインスタンス、Hadoopクラスタのマス
ターノードなど
78

79. Tips
1. Auto Scaling を Auto Healingとして使う
2. Auto Scaling Policyの調整方法
3. スパイクアクセスに立ち向かう
4. スポットプールとAuto Scalingの設定は常に見なおそう
5. スポットフリートAPIのJSONパラメータを生成
6. 各種上限に注意
7. Serverless Architectureのコスト効率

80. Auto ScalingをAuto Healingとして使う
Tips[1/7]

81. Auto Healing
サーバに障害が発生したとき自動的にネットワークから切
り離し、健全なサーバをサービスインさせる
方法
Auto Scaling Group の Min を任意の数に設定する
Min-Max=1-1 にすれば
「常に1台起動。増えも減りもしない」
Min-Max=2-N にすれば
「常に2台起動。片方に障害があっても1台は耐える」
…など
Auto ScalingをAuto Healingとして使う
81

82. Auto Scaling Policyの調整方法
Tips[2/7]

83. Auto Scaling Policyのパラメータチューニング
前提として、
そのまま使える公式な算出法などはない
83

84. 以下の考え方を元にやってみて細かく調整
1. Max Instances = ピーク時の必要インスタンス数
2. Min Instances = Max * (アイドルタイムReq数 / ピーク時Req数) + α
3. Threshold
High = ピーク時の平均CPU使用率
Low = 最初低めに設定して少しずつ上げてみる
（10%→5%ずつ上げて50%、など）
4. Cool down, Warm up period等
アプリやサーバ、初期化処理等の性質によるため一般化は難しい
インスタンスが起動と終了を短時間で繰り返してしまわないよう注意
無用な課金が発生してしまうかも
これらは経験則であり、絶対的な解ではありません
Auto Scaling Policyのパラメータチューニング
※CPU使用率を使うとして
84

85. Tips
スパイクアクセスに立ち向かう
[3/7]

86. より突発的な
スパイクアクセス
に立ち向かうには
例: テレビ放送等
86

87. AutoScalingや
ELBは
突発的なピーク向き
ではない
87

88. ELB
Auto
Scaling
こういうのが
得意

89. スパイクアクセスの対応方法
1. ELB…Pre-Warming
ビジネスサポートにご加入いただくと申請可能です
2. Webサーバ…増設（スケールアウト）
3. DBサーバ…増強（スケールアップ）
89

90. RDSAZ1 AZ2RDS
スパイクアクセスの対応方法
90

91. RDSAZ1 AZ2RDS
スパイクアクセスの対応方法
ELB
Pre-Warming
91

92. RDSAZ1 AZ2RDS
スパイクアクセスの対応方法
ELB
Pre-Warming
… … EC2
スケールアウト
92

93. RDSAZ1 AZ2 RDS
スパイクアクセスの対応方法
… …
ELB
Pre-Warming
EC2
スケールアウト
RDS
スケールアップ
93

94. RDSAZ1 AZ2RDS
スパイクアクセスの対応方法
94
終わったら、
戻せる。
クラウドの
いいところ。

95. スパイクアクセスの予測ができない場合
1. ランディングページをS3でホスティングする
2. CloudFrontから配信する
…etc
95

96. Tips
スポットプールとAuto Scalingの設定は
常に見なおそう
[4/7]

97. スポットプール
スポットプールに対する需要は徐々に変わっていく
Auto Scaling
サービスのユーザー数、機能、アーキテクチャ等々、
様々な要因によって、徐々に適切なポリシーやMax台
数は変わっていく
スポットプールとAuto Scalingの設定は常に見なおそう
97

98. Tips
スポットフリートAPIのJSONパラメータを
管理コンソールで生成
[5/7]

99. request-spot-fleet APIのパラメータ
aws ec2 request-spot-fleet --spot-fleet-request-config { "IamFleetRole":
"arn:aws:iam::781603563322:role/fleet-role", "TargetCapacity": "100",
"SpotPrice": "0.03", "ValidFrom": "2015-09-15T00:56:19Z", "ValidUntil": "2016-
09-14T07:00:00Z", "TerminateInstancesWithExpiration": true,
"LaunchSpecifications": [ { "ImageId": "ami-0d4cfd66", "InstanceType":
"c3.large", "WeightedCapacity": 2, "SubnetId": "subnet-d0dc51fb" }, {
"ImageId": "ami-0d4cfd66", "InstanceType": "c3.large", "WeightedCapacity": 2,
"SubnetId": "subnet-64531413" }, { "ImageId": "ami-0d4cfd66", "InstanceType":
"c3.large", "WeightedCapacity": 2, "SubnetId": "subnet-0b1b8052" }, {
"ImageId": "ami-0d4cfd66", "InstanceType": "c3.xlarge", "WeightedCapacity": 4,
"SubnetId": "subnet-d0dc51fb" }, { "ImageId": "ami-0d4cfd66", "InstanceType":
"c3.xlarge", "WeightedCapacity": 4, "SubnetId": "subnet-64531413" }, {
"ImageId": "ami-0d4cfd66", "InstanceType": "c3.xlarge", "WeightedCapacity": 4,
"SubnetId": "subnet-0b1b8052" }, { "ImageId": "ami-0d4cfd66", "InstanceType":
"c3.4xlarge", "WeightedCapacity": 16, "SubnetId": "subnet-d0dc51fb" }, {
"ImageId": "ami-0d4cfd66", "InstanceType": "c3.4xlarge", "WeightedCapacity":
16, "SubnetId": "subnet-64531413" }, { "ImageId": "ami-0d4cfd66",
"InstanceType": "c3.4xlarge", "WeightedCapacity": 16, "SubnetId": "subnet-
0b1b8052" }, { "ImageId": "ami-0d4cfd66", "InstanceType": "c3.8xlarge",
"WeightedCapacity": 32, "SubnetId": "subnet-d0dc51fb" }, { "ImageId": "ami-
0d4cfd66", "InstanceType": "c3.8xlarge", "WeightedCapacity": 32, "SubnetId":
"subnet-64531413" }, { "ImageId": "ami-0d4cfd66", "InstanceType":
"c3.8xlarge", "WeightedCapacity": 32, "SubnetId": "subnet-0b1b8052" }, {
"ImageId": "ami-0d4cfd66", "InstanceType": "c3.2xlarge", "WeightedCapacity":
8, "SubnetId": "subnet-d0dc51fb" }, { "ImageId": "ami-0d4cfd66",
"InstanceType": "c3.2xlarge", "WeightedCapacity": 8, "SubnetId": "subnet-
64531413" }, { "ImageId": "ami-0d4cfd66", "InstanceType": "c3.2xlarge",
"WeightedCapacity": 8, "SubnetId": "subnet-0b1b8052" } ] }
99

100. スポットフリートtips - 新コンソールでJSONを生成
① ②
③
1. スポットインスタンス管理画面を開く
2. 画面右上部分の青い吹き出しをクリック
3. Try it out. をクリック
100

101. スポットフリートtips - 新コンソールでJSONを生成
画面を進めて
JSON configを
クリックすると選択した値がJSONで出力され、API利用時の雛形ができる 101

102. Tips
各種上限の確認と緩和申請方法
[6/7]

103. 各種上限の確認と緩和申請方法 – EC2関連
管理コンソール > EC2 > Limits
※今日お話した関連のものはだいたいここにある 103

104. 各種上限の確認と緩和申請方法 – 利用状況確認
管理コンソール > Trusted Advisor > Performance > Service Limits
①
②
③
104

105. 各種上限の確認と緩和申請方法 – 利用状況確認
上限値の80%以上使用中のサービスを示してくれたりする
105

106. Tips
Serverless Architecture
のコスト効率
[7/7]

107. S3
アプリはS3から配信
されるHTML/JS、
またはネイティブ実装
ELB/EC2を使わず
API Gatewayと
Lambdaで応答
運用/構築/開発から
の解放
ランニングコスト
効率が高く、多くの
場合 コスト減 に
Lambda
Other
Services
API Gateway Cognito
CloudFront
サーバレスアーキテクチャ例
107

108. Q&A
次回Webinarのお申し込み
http://aws.amazon.com/jp/event_schedule/
108

109. Webinar資料の配置場所
• AWS クラウドサービス活用資料集
– http://aws.amazon.com/jp/aws-jp-introduction/
109

110. 公式Twitter/Facebook
AWSの最新情報をお届けします
@awscloud_jp
検索
最新技術情報、イベント情報、お役立ち情報、お得なキャンペーン情報などを
日々更新しています！
もしくは
http://on.fb.me/1vR8yWm
110