AWSスポットインスタンスの真髄

Copyright gedow.net All Rights Reserved.
財布の紐を限界まで締める！
AWSスポットインスタンスの真髄
外道父@GedowFather
2015/06/17
#2 市ヶ谷Geek★Night

Copyright gedow.net All Rights Reserved. 2
自己紹介
■私は
外道父@GedowFather
■所属
ドリコム
■職種
インフラエンジニア
■ブログ
外道父の匠

ま
だ
オ
ン
デ
マ
ン
ド
で
お
布
施
し
て
る
の
？
そ
ら
ウ
ハ
ウ
ハ
で
売
上
高
を
公
開
し
ち
ゃ
い
ま
す
わ

目次
1. 基本と目的
2. 深イイ話
3. アーキテクチャ
4. その他の工夫

基本と目的

スポットインスタンスを三行で
1. 費用が超安い！
2. 起動が少し遅い！
3. 強制削除されるリスク！

安い理由は入札式
 余っているリソースを使ってもらうため
 需要と供給により価格が変動する
 入札価格が変動価格を上回れば起動を継続
でき、下回れば強制削除される
入札価格
変動価格
起動できない
起動できる
強制削除
起動できる
$0.1
$0.2
$0.01
$0.05
$1.0

費用の比較
オンデマンド 100%
リザーブドインスタンス 55～75%
スポットインスタンス最小 14%
最大 1000%
 リザーブドは事業規模の変化度合いに合わ
ないし、１年経てばc3=>c4のような上位
互換が期待できるのでメインにはしない
 スポットのワクワク感

価格変動の度合い
 予測は不可能
 xlarge以下は比較的落ち着いている
 それ以上は無慈悲な急騰が常
c3.4xlarge の平和な24時間
$0.15 ～ $0.25
c3.4xlarge のよくある一週間
最大 $5.0

高スペックの価格変動
 c3.8xlarge は1ヶ月間に数十回も高騰
 オンデマンドの 2～5倍
 おまえらは誰と闘っているんだ状態
このオンデマンドは $1.68

起動時間が少し遅い
 オンデマンドはポチッてから
約３～４分
で起動が完了する
 スポットはまず入札処理が入り、入札が
成功してから起動に入るため
約７～８分
を必要とする

強制削除
 入札価格 ≧ 変動価格＝セーフ
 入札価格＜変動価格＝アウト
一度でもアウトの条件を満たすと、
１～２分で強制的にTerminateされる
1分経過
スポット
入札価格
AWS神

基礎知識から導き出される結論
リスクを排除して
スポットだけで
運用したら激安じゃない

深イイ話

リソースは全く同じ
 オンデマンドのインスタンスも、スポッ
トインスタンスも、元となるサーバーの
リソースは全く同じ
 スポットだからCPUやストレージの品質
が劣っているということは一切ない
オンデマンドオンデマンドスポット
ホストサーバー

価格ルール

変動／入札価格の最大値
 変動価格はオンデマンド価格の10倍
まで跳ね上がる
 入札価格も10倍までとなる
オンデマンドが $0.294 なので
最大で $2.94 まで跳ね上がる

2015年4月中旬までの価格ルール
 最大入札価格はオンデマンドの4倍まで
 それ以上は申請して上限を引き上げる形式
 価格の継続的な異常高騰を和らげるために
改定された
企業（A）企業（B）
スポットの存在意義にそぐわない利用状況にメスが入った
変更が入った瞬間、
オンデマ10倍以上の
LaunchConfiguration
では起動できなくなる
というトラブルが発生
(外道式青天井界王拳20倍施策より)

強制Terminateを避けるテクニック
最大変動価格
＝最大入札価格
＝オンデマの10倍
すなわち
オンデマンドの
10倍で入札したら
落とされない！！
基本的にTerminate

安全な停止

入札価格超過以外の落とし穴
 需要と供給の関係で成り立っているので、
需要が急増した場合は入札や変動価格の高
低に関わらず強制Terminateが走る可能性
がある
 変動価格MAXでよく起こる
 発動時に削除されるかは運

強制Terminateをインスタンス自身が知る
ローカルのメタデータで、神様による無慈悲
なTerminate発動予定時間を取得できる
http://169.254.169.254/latest/meta-data/spot/termination-time
 普段は 404 Not Found を返す
 価格超過やリソース不足によるTerminate確定か
ら数秒後に200 OKと停止時刻を返すようになる
 5秒間隔でのチェックを推奨されている
 検知したら、新規リクエストの受け付けを停止す
るなど、必要な処理を済ませる
AWS

通常のインスタンス破棄前に任意の処理を行う
 AutoScaleにおける起動完了前や削除実行
前に、任意秒を待機し、任意の処理を行う
ための LifecycleHook という機能がある
 削除前に待機することで、安心安全に落と
すための処理を入れることができる
ココで止まってもらい
ココで必要な処理を行い
自身でシステムに通知するか、
任意秒が過ぎたら、
次のプロセス(削除処理)へ移る

制限値

入札数の制限
 アカウントごとの設定に、EC2インスタン
ス数の上限数が 20 といった制限値がある
 入札数にも制限があり、デフォルトで 20
となっている
 各種設定と同様、申請で引き上げ可能
 入札数のカウントはインスタンスを削除し
たらすぐ減るわけではないので、短時間で
起動と削除を繰り返すと入札できなくなる

アーキテクチャ

メインをスポットにする覚悟を決める
 入札価格をオンデマンドの10倍にす
ることで強制Terminateを避ける
 スポットの仕様変更や機能追加に追随
し続ける『
コ
ス
ト
を
抑
え
る
』
『
安
全
に
運
用
し
続
け
る
』
「
イ
ン
フ
ラ
エ
ン
ジ
ニ
ア
」の

制限値を上げる申請をする
デフォルト値申請値(例)
EC2インスタンス数 20 400
入札数 20 400
AutoScalingGroup数 20 100
 AutoScalingGroupは構築時に気づけるが、イ
ンスタンス関連は運用に入ってから引っかかる可
能性があるので注意する
 申請は１営業日もあれば通るので焦らなくてOK
 多すぎず少なすぎず、気持ち多目に

AutoScalingGroup

AutoScalingGroupを作成する
Availability Zone [1a]
Spot
c3
1～100台
Spot
c4
1～100台
Ondemand
c3
1台
Ondemand
c4
1台
監視用
Ondemand
c3
1台
Availability Zone [1c]
Spot
c3
1～100台
Spot
c4
1～100台
Ondemand
c3
1台
Ondemand
c4
1台
監視用
Ondemand
c4
1台

AutoScalingGroupを細かく分ける理由
Spot
c3
1～100台
Spot
c4
1～100台
Ondemand
c3
1台
Ondemand
c4
1台
監視用
Ondemand
c3
1台
Spot
c3
1～100台
Spot
c4
1～100台
Ondemand
c3
1台
Ondemand
c4
1台
監視用
Ondemand
c4
1台
 変動価格がインスタンスタイプ／AZ単位のため
 複数のインスタンスタイプを併用し、高騰による
強制Terminateのリスクを減らすため
 監視用グラフを永存したり、アプリログのサンプ
リングを送信するため
10 グループ！

オンデマンドも併用する理由
スポットが不調な時に予備のスケールアウト
となる
急激なスケールアウトが必要になった時、ス
ポットより素早く起動できる
監視用インスタンスはホスト名やIPアドレス
を固定で据え置きたい

スポットメインのスケール条件
スポットオンデマンド監視用
min 1 1 1
max 100 100 1
CPU条件増減率 CPU条件増減率
increase(1) 40% 20%↑ 70% 20%↑
なしincrease(2) 80% 80%↑ 90% 80%↑
decrease 20% 20%↓ 40% 20%↓
 平時はスポットだけが増設され、有事はオンデマンドも増設
 落ち着けばオンデマンドから削減される
 (スポット1～100✕4グループ)＋(オンデマンド１✕６グ
ループ) が平時の台数となる

高騰したスポットは破棄する
type AZ min max desired
スポット c3 1a 1 100 25
1c 1 100 28
c4 1a 1 100 22
1c 1 100 25
オンデマ c3 1a 1 100 1
1c 1 100 1
c4 1a 1 100 1
1c 1 100 1
監視用 c3 1a 1 1 1
c4 1c 1 1 1
min max desired
1 100 25
0 0 0
1 100 22
1 100 25
1 100 1
1 100 1
1 100 1
1 100 1
1 1 1
1 1 1
高騰
 グループ単位で価格を監視し、高騰と判断したらインスタン
スを破棄してグループの稼働を停止する
 残る３グループの負荷は上がるが平常運転の範囲内
 価格が落ち着いたら、またスケールアウトを開始する

高騰と平常の判断条件
 直近1時間平均を比較値とする
 １時間に数十ある履歴の、価
格と割当時間から計算する
 わずか数分の突発高騰でのイ
ンスタンス破棄を防ぐため
16時に比較する値は
$3.0 ではなく
$0.5 程度になる
１時間平均の変動価格＝比較値
高騰 if 比較値 ≧ オンデマンド価格✕1.2
平常 if 比較値＜オンデマンド価格✕0.8
※条件を離すことで自動処理の連続発動を回避

高騰リスクの低減
 c3だけだと1a&1cが同時に高騰する可能性が高く、最悪
リソースがゼロになるため、c4を併用することで最悪でも
リソース半減に抑えられる
 さらに m3/m4/r3 を併用という選択もありうる
Spot
c3
100%
Spot
c4
100%
1a
Spot
c3
100%
Spot
c4
100%
1c
Spot
c3
133%
Spot
c4
1a
Spot
c3
133%
Spot
c4
133%
1c
価格高騰により
１グループ死亡しても
残るグループの負荷は
4/3倍になるだけ

通常停止対策

LifecycleHookで安全にシャットダウン
ココで3600秒止まってもらい
インスタンス自身がLifecycleHookに
入ったと認識したら必要な処理を行い
Complete通知を送って終了する。
完了までの時間はサービスの性質次第
 スケールインや高騰時のグループインスタンス破棄において、
安全かつ必要な処理を済ませる
 ELBから外す、ユーザー切断を待つ、タグを付ける、監視
サーバーから自ホストのデータを削除する
 処理が完了したらAWSに通知を送ってTerminate

LifecycleHookの通知と問題点
 LifecycleHookの通知はインスタンスが直接受けるのではな
く、SNS/SQSを通して受け取る
 メッセージ内にCompleteを送るためのトークンがある
 SNSだと余剰サーバーが必要になるので却下
 SQSだとインスタンス自身で取りにいけるが、キューは任
意のメッセージを受け取ることができない
SNS 管理
サーバー
削除対象
サーバー
SNSの場合
PUSH?
PULL?
SQS
削除対象
サーバー
SQSの場合
こんなことで複雑な仕組みにしたくない
キューから自身宛のメッセージを取得しづらい
何度も取得処理をして時間がかかる可能性がある

LifecycleHookの通知を取得する仕組み
 10秒毎に全インスタンスでキューをチェック
 あれば必ず1通は取得できるので、インスタンスIDとトーク
ンを抜き出し、該当のインスタンスにタグを登録
 さらにインスタンス自身のタグをチェックし、該当タグがあ
れば削除前処理を行い、Complete通知をして完了する
SQS 削除対象
サーバー
(B)
サーバー
(C)
サーバー
(A)
Send Message
Get & Delete Message
Create Tags
 LifecycleTransition
 LifecycleActionToken

Linuxのinitシステム管理では挙動が不確か
 正常なシャットダウン処理の場合、initスクリプト
に sleep を仕込むことでTerminateを遅らせるこ
とができそうだが無理
 Terminateによるshutdown実行後は、sleepで耐
えていても数分後にインスタンスを強制削除される
 LifecycleHookが確実な手段だし、便利なのでオス
スメ
 だがトークンの受け取りが厳しい。メタデータに埋
め込んでくれ

強制停止対策

強制Terminateに備える
http://169.254.169.254/latest/meta-data/spot/termination-time
 入札価格超過によるTerminateはないが、需要/供
給のリソース不足で落とされるので仕込む
 Bashデーモン
 5秒間隔で監視し、検知したらLifecycleHookと
同じ削除前処理を実行する

唯一の弱点
 １回１回の処理時間が短いHTTPは問題ない
 １つの処理に数分数十分以上の持続接続が必要な場
合は、クライアントやジョブの処理終了に間に合わ
ず落とされてしまう
 WebSocket / MQTT や集計処理など
 切断時にクライアント再接続やジョブ再実行する仕組み
 Terminateを検知した時点でそれを促す仕組み
Terminate検知 Terminate実行１～２分間
HTTP
長時間の持続接続サービス
この間に処理を安全に終えられるか
が分かれ目となる
過ぎるとユーザーに
不利益が生じるため
工夫が必要になる
クライアントが強制切断される

費用効果

オンデマンドのみと併用の比較
 オンデマンドのコストを 100 とする
 好調スポットのコストを 15 とする
 最小台数と大規模台数でそれぞれ、同台
数におけるオンデマンドのみのコストと、
スポット構成のコストを比較する

最小台数の場合
Spot
c3
1台
Spot
c4
1台
Ondemand
c3
1台
Ondemand
c4
1台
監視用
Ondemand
c3
1台
Spot
c3
1台
Spot
c4
1台
Ondemand
c3
1台
Ondemand
c4
1台
監視用
Ondemand
c4
1台
Spotコスト = 1台✕4グループ✕15 = 60
Ondemandコスト = 1台✕6グループ✕100 = 600
Spot + Ondemand = 660
Ondemandのみ = 1000＞34%削減

大規模台数の場合
Spot
c3
30台
Spot
c4
30台
Ondemand
c3
1台
Ondemand
c4
1台
監視用
Ondemand
c3
1台
Spot
c3
30台
Spot
c4
30台
Ondemand
c3
1台
Ondemand
c4
1台
監視用
Ondemand
c4
1台
Spotコスト = 30台✕4グループ✕15 = 1800
Ondemandコスト = 1台✕6グループ✕100 = 600
Spot + Ondemand = 2400
Ondemandのみ = 12600＞81%削減

1時間平均の価格変動グラフ（1ヶ月間）
Ondemand価格
Ondemand価格
c3.xlarge
c4.xlarge
ほぼオンデマンドの
20～25%をキープ
一時荒れるも避難し、
大半を最低価格の
14%でキープ

インスタンスタイプの選択
 希望は 2xlarge あたりだった
 最初に採用したのは c3/c4.xlarge
 c4がご乱心＆ m3が安定したので
c3/m3.xlarge に避難
 m2 は安定しているがHVM非対応
 新しい m4 は多分、数カ月後に荒波
 CC2/CR1 もわりとブルーオーシャン
 高スペック＋Dockerという手も……

オンデマンドいる？
 いざ運用してみると、思いの外スポットのス
ケールアウトだけで稼働できてしまう
 オンデマンドがいらない気になるけど、そこ
までスポットは信用するべきものでもない
 最終防衛ライン
 1セットにつき６つのオンデマンドが確定な
ので、リザーブドインスタンスを適用すると
さらに削減できる

その他の工夫

AutoScalingGroup管理の簡略化
 LaunchConfigurationが多い
 production / staging
 spot / ondemand
 c3 / c4
 AutoScalingGroupが多い
 同上
 1a / 1c
 監視用
 CloudWatchが多い
 Increase (peace / pinch)
 Decrease
 監視用は除く
＞合計8件
＞合計20件
＞合計48件
自動化した
作成・削除・更新など全て

独自TimeBasedスケールアウト
12時 23時
 サービスの性質上、12時と23時がピークタイムであり、
12～23時の間はイベントやメンテナンスによる急激な
増減がある。特にメンテ明けの台数は危険
 11:30 にMinSizeを、その時点のInService✕N倍の台
数に強制増設する（1.5～3倍）
 23:30 にMinSizeを元に戻す
 日中の台数節約放棄の代わりに運用し易さと安定を得る
強制Increase
自然な増減に
切り替え
最低台数を
キープ

AZ間のレイテンシ差に対応する（１）
AZ [1a]
EC2
AZ [1c]
EC2
RDS
速い少し遅い
 RDSやElastiCacheが同じAZにあるとレイ
テンシが低い
 違うAZからだと遅くはないが、同AZより
はレイテンシが高い
AZ [1a]
Spot
c3
10台
Spot
c4
9台
AZ [1c]
Spot
c3
3台
Spot
c4
2台
 レイテンシが低いほど多くCPU
処理をできるためスケールアウ
トされやすい
 CPU性能が低いほどスケールア
ウトされやすい
 AZとインスタンスタイプで台
数に偏りが出ると、リスクも偏
ることになる

AZ間のレイテンシ差に対応する（２）
AZ [1a]
Spot
c3
6台
Spot
c4
6台
AZ [1c]
Spot
c3
3台
Spot
c4
2台
Max 6 Max 6 Max 100 Max 100
グループごとの台数を監視
最低台数より＋４台以上の
グループはMax値を抑える
Max = Desired
差が狭まったらMaxを戻す
この仕掛による挙動とリスク
抑えつけたグループの分、スケールアウトの全体増加率が
減少するため、１グループあたりの増加率で調整する
Increase条件がCPU 40%だとすると、抑えつけたグルー
プはCPU60%前後にまで上がる
 AZを分けなくても、実はそもそもこうなっているはず
 リソースを多目に消費することは台数節約でもある

スクリプトで AWS CLI を使わない
 AWS CLIは重い（CPUをメチャ喰う）
 手動や数時間に１回の実行ならば問題ない
 数十秒単位だとCPU利用率のグラフが常に10%前
後など無駄すぎる消費
 重いのは認証処理
 シェルのコマンドベースだと毎回この処理が入る
 軽量プログラミング言語＋SDKで書けば、認証
を確保したままループ処理をできるため軽い
 最初はBashで書いたがRubyに書きなおした
 手動実行管理スクリプト
 自動実行ジョブスクリプト
 監視アラート／グラフ用値出力スクリプト

AWS Japan と同じ社屋に入る
アルコタワー
アネックス
Amazon Japan
アルコタワー
19F
AWS Japan
17F
ドリコム
他の階も
Amazonが
徐々に侵食中
 相談や新着情報を伝えに天上界から降りてきてくれ、終
わると天上界にお帰りになられる
 天上界にお伺いし、USチームと電話会議したり、来日し
ているとディープな情報交換できる（完璧な通訳付き）

俺
の
コ
ス
ト
が
高
騰
し
ち
ま
う
か
ら
な
！
で
も
……
で
も
で
も
ス
ポ
ッ
ト
は
怖
い
し
や
め
た
ほ
う
が
い
い
と
思
う
よ
！
fin

AWSスポットインスタンスの真髄

More Related Content

What's hot

Viewers also liked

Similar to AWSスポットインスタンスの真髄

AWSスポットインスタンスの真髄