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

AWSスポットインスタンスの真髄
Copyright gedow.net All Rights Reserved. 財布の紐を限界まで締める！ AWSスポットインスタンスの真髄外道父@GedowFather 2015/06/17 #2 市ヶ谷Geek★Night
Copyright gedow.net All Rights Reserved. 2 自己紹介 ■私は外道父@GedowFather ■所属ドリコム ■職種インフラエンジニア ■ブログ外道父の匠
Copyright gedow.net All Rights Reserved. 3 まだオンデマンドでお布施してるの？そらウハウハで売上高を公開しちゃいますわ
Copyright gedow.net All Rights Reserved. 4 目次 1. 基本と目的 2. 深イイ話 3. アーキテクチャ 4. その他の工夫
Copyright gedow.net All Rights Reserved. 基本と目的
Copyright gedow.net All Rights Reserved. 6 スポットインスタンスを三行で 1. 費用が超安い！ 2. 起動が少し遅い！ 3. 強制削除されるリスク！
Copyright gedow.net All Rights Reserved. 7 安い理由は入札式  余っているリソースを使ってもらうため  需要と供給により価格が変動する  入札価格が変動価格を上回れば起動を継続でき、下回れば強制削除される入札価格変動価格起動できない起動できる強制削除起動できる $0.1 $0.2 $0.01 $0.05 $1.0
Copyright gedow.net All Rights Reserved. 8 費用の比較オンデマンド 100% リザーブドインスタンス 55～75% スポットインスタンス最小 14% 最大 1000%  リザーブドは事業規模の変化度合いに合わないし、１年経てばc3=>c4のような上位互換が期待できるのでメインにはしない  スポットのワクワク感
Copyright gedow.net All Rights Reserved. 9 価格変動の度合い  予測は不可能  xlarge以下は比較的落ち着いている  それ以上は無慈悲な急騰が常 c3.4xlarge の平和な24時間 $0.15 ～ $0.25 c3.4xlarge のよくある一週間最大 $5.0
Copyright gedow.net All Rights Reserved. 10 高スペックの価格変動  c3.8xlarge は1ヶ月間に数十回も高騰  オンデマンドの 2～5倍  おまえらは誰と闘っているんだ状態このオンデマンドは $1.68
Copyright gedow.net All Rights Reserved. 11 起動時間が少し遅い  オンデマンドはポチッてから約３～４分で起動が完了する  スポットはまず入札処理が入り、入札が成功してから起動に入るため約７～８分を必要とする
Copyright gedow.net All Rights Reserved. 12 強制削除  入札価格 ≧ 変動価格＝セーフ  入札価格＜変動価格＝アウト一度でもアウトの条件を満たすと、１～２分で強制的にTerminateされる 1分経過スポット入札価格 AWS神
Copyright gedow.net All Rights Reserved. 13 基礎知識から導き出される結論リスクを排除してスポットだけで運用したら激安じゃない
Copyright gedow.net All Rights Reserved. 深イイ話
Copyright gedow.net All Rights Reserved. 15 リソースは全く同じ  オンデマンドのインスタンスも、スポットインスタンスも、元となるサーバーのリソースは全く同じ  スポットだからCPUやストレージの品質が劣っているということは一切ないオンデマンドオンデマンドスポットホストサーバー
Copyright gedow.net All Rights Reserved. 価格ルール
Copyright gedow.net All Rights Reserved. 17 変動／入札価格の最大値  変動価格はオンデマンド価格の10倍まで跳ね上がる  入札価格も10倍までとなるオンデマンドが $0.294 なので最大で $2.94 まで跳ね上がる
Copyright gedow.net All Rights Reserved. 18 2015年4月中旬までの価格ルール  最大入札価格はオンデマンドの4倍まで  それ以上は申請して上限を引き上げる形式  価格の継続的な異常高騰を和らげるために改定された企業（A）企業（B）スポットの存在意義にそぐわない利用状況にメスが入った変更が入った瞬間、オンデマ10倍以上の LaunchConfiguration では起動できなくなるというトラブルが発生 (外道式青天井界王拳20倍施策より)
Copyright gedow.net All Rights Reserved. 19 強制Terminateを避けるテクニック最大変動価格＝最大入札価格＝オンデマの10倍すなわちオンデマンドの 10倍で入札したら落とされない！！基本的にTerminate
Copyright gedow.net All Rights Reserved. 安全な停止
Copyright gedow.net All Rights Reserved. 21 入札価格超過以外の落とし穴  需要と供給の関係で成り立っているので、需要が急増した場合は入札や変動価格の高低に関わらず強制Terminateが走る可能性がある  変動価格MAXでよく起こる  発動時に削除されるかは運
Copyright gedow.net All Rights Reserved. 22 強制Terminateをインスタンス自身が知るローカルのメタデータで、神様による無慈悲なTerminate発動予定時間を取得できる http://169.254.169.254/latest/meta-data/spot/termination-time  普段は 404 Not Found を返す  価格超過やリソース不足によるTerminate確定から数秒後に200 OKと停止時刻を返すようになる  5秒間隔でのチェックを推奨されている  検知したら、新規リクエストの受け付けを停止するなど、必要な処理を済ませる AWS
Copyright gedow.net All Rights Reserved. 23 通常のインスタンス破棄前に任意の処理を行う  AutoScaleにおける起動完了前や削除実行前に、任意秒を待機し、任意の処理を行うための LifecycleHook という機能がある  削除前に待機することで、安心安全に落とすための処理を入れることができるココで止まってもらいココで必要な処理を行い自身でシステムに通知するか、任意秒が過ぎたら、次のプロセス(削除処理)へ移る
Copyright gedow.net All Rights Reserved. 制限値
Copyright gedow.net All Rights Reserved. 25 入札数の制限  アカウントごとの設定に、EC2インスタンス数の上限数が 20 といった制限値がある  入札数にも制限があり、デフォルトで 20 となっている  各種設定と同様、申請で引き上げ可能  入札数のカウントはインスタンスを削除したらすぐ減るわけではないので、短時間で起動と削除を繰り返すと入札できなくなる
Copyright gedow.net All Rights Reserved. アーキテクチャ
Copyright gedow.net All Rights Reserved. 27 メインをスポットにする覚悟を決める  入札価格をオンデマンドの10倍にすることで強制Terminateを避ける  スポットの仕様変更や機能追加に追随し続ける『コストを抑える』『安全に運用し続ける』「インフラエンジニア」の
Copyright gedow.net All Rights Reserved. 28 制限値を上げる申請をするデフォルト値申請値(例) EC2インスタンス数 20 400 入札数 20 400 AutoScalingGroup数 20 100  AutoScalingGroupは構築時に気づけるが、インスタンス関連は運用に入ってから引っかかる可能性があるので注意する  申請は１営業日もあれば通るので焦らなくてOK  多すぎず少なすぎず、気持ち多目に
Copyright gedow.net All Rights Reserved. AutoScalingGroup
Copyright gedow.net All Rights Reserved. 30 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台
Copyright gedow.net All Rights Reserved. 31 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台  変動価格がインスタンスタイプ／AZ単位のため  複数のインスタンスタイプを併用し、高騰による強制Terminateのリスクを減らすため  監視用グラフを永存したり、アプリログのサンプリングを送信するため 10 グループ！
Copyright gedow.net All Rights Reserved. 32 オンデマンドも併用する理由 スポットが不調な時に予備のスケールアウトとなる 急激なスケールアウトが必要になった時、スポットより素早く起動できる 監視用インスタンスはホスト名やIPアドレスを固定で据え置きたい
Copyright gedow.net All Rights Reserved. 33 スポットメインのスケール条件スポットオンデマンド監視用 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グループ)＋(オンデマンド１✕６グループ) が平時の台数となる
Copyright gedow.net All Rights Reserved. 34 高騰したスポットは破棄する 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 高騰  グループ単位で価格を監視し、高騰と判断したらインスタンスを破棄してグループの稼働を停止する  残る３グループの負荷は上がるが平常運転の範囲内  価格が落ち着いたら、またスケールアウトを開始する
Copyright gedow.net All Rights Reserved. 35 高騰と平常の判断条件  直近1時間平均を比較値とする  １時間に数十ある履歴の、価格と割当時間から計算する  わずか数分の突発高騰でのインスタンス破棄を防ぐため 16時に比較する値は $3.0 ではなく $0.5 程度になる１時間平均の変動価格＝比較値高騰 if 比較値 ≧ オンデマンド価格✕1.2 平常 if 比較値＜オンデマンド価格✕0.8 ※条件を離すことで自動処理の連続発動を回避
Copyright gedow.net All Rights Reserved. 36 高騰リスクの低減  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倍になるだけ
Copyright gedow.net All Rights Reserved. 通常停止対策
Copyright gedow.net All Rights Reserved. 38 LifecycleHookで安全にシャットダウンココで3600秒止まってもらいインスタンス自身がLifecycleHookに入ったと認識したら必要な処理を行い Complete通知を送って終了する。完了までの時間はサービスの性質次第  スケールインや高騰時のグループインスタンス破棄において、安全かつ必要な処理を済ませる  ELBから外す、ユーザー切断を待つ、タグを付ける、監視サーバーから自ホストのデータを削除する  処理が完了したらAWSに通知を送ってTerminate
Copyright gedow.net All Rights Reserved. 39 LifecycleHookの通知と問題点  LifecycleHookの通知はインスタンスが直接受けるのではなく、SNS/SQSを通して受け取る  メッセージ内にCompleteを送るためのトークンがある  SNSだと余剰サーバーが必要になるので却下  SQSだとインスタンス自身で取りにいけるが、キューは任意のメッセージを受け取ることができない SNS 管理サーバー削除対象サーバー SNSの場合 PUSH? PULL? SQS 削除対象サーバー SQSの場合こんなことで複雑な仕組みにしたくないキューから自身宛のメッセージを取得しづらい何度も取得処理をして時間がかかる可能性がある
Copyright gedow.net All Rights Reserved. 40 LifecycleHookの通知を取得する仕組み  10秒毎に全インスタンスでキューをチェック  あれば必ず1通は取得できるので、インスタンスIDとトークンを抜き出し、該当のインスタンスにタグを登録  さらにインスタンス自身のタグをチェックし、該当タグがあれば削除前処理を行い、Complete通知をして完了する SQS 削除対象サーバー (B) サーバー (C) サーバー (A) Send Message Get & Delete Message Create Tags  LifecycleTransition  LifecycleActionToken
Copyright gedow.net All Rights Reserved. 41 Linuxのinitシステム管理では挙動が不確か  正常なシャットダウン処理の場合、initスクリプトに sleep を仕込むことでTerminateを遅らせることができそうだが無理  Terminateによるshutdown実行後は、sleepで耐えていても数分後にインスタンスを強制削除される  LifecycleHookが確実な手段だし、便利なのでオススメ  だがトークンの受け取りが厳しい。メタデータに埋め込んでくれ
Copyright gedow.net All Rights Reserved. 強制停止対策
Copyright gedow.net All Rights Reserved. 43 強制Terminateに備える http://169.254.169.254/latest/meta-data/spot/termination-time  入札価格超過によるTerminateはないが、需要/供給のリソース不足で落とされるので仕込む  Bashデーモン  5秒間隔で監視し、検知したらLifecycleHookと同じ削除前処理を実行する
Copyright gedow.net All Rights Reserved. 44 唯一の弱点  １回１回の処理時間が短いHTTPは問題ない  １つの処理に数分数十分以上の持続接続が必要な場合は、クライアントやジョブの処理終了に間に合わず落とされてしまう  WebSocket / MQTT や集計処理など  切断時にクライアント再接続やジョブ再実行する仕組み  Terminateを検知した時点でそれを促す仕組み Terminate検知 Terminate実行１～２分間 HTTP 長時間の持続接続サービスこの間に処理を安全に終えられるかが分かれ目となる過ぎるとユーザーに不利益が生じるため工夫が必要になるクライアントが強制切断される
Copyright gedow.net All Rights Reserved. 費用効果
Copyright gedow.net All Rights Reserved. 46 オンデマンドのみと併用の比較  オンデマンドのコストを 100 とする  好調スポットのコストを 15 とする  最小台数と大規模台数でそれぞれ、同台数におけるオンデマンドのみのコストと、スポット構成のコストを比較する
Copyright gedow.net All Rights Reserved. 47 最小台数の場合 Availability Zone [1a] Spot c3 1台 Spot c4 1台 Ondemand c3 1台 Ondemand c4 1台監視用 Ondemand c3 1台 Availability Zone [1c] 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%削減
Copyright gedow.net All Rights Reserved. 48 大規模台数の場合 Availability Zone [1a] Spot c3 30台 Spot c4 30台 Ondemand c3 1台 Ondemand c4 1台監視用 Ondemand c3 1台 Availability Zone [1c] 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%削減
Copyright gedow.net All Rights Reserved. 49 1時間平均の価格変動グラフ（1ヶ月間） Ondemand価格 Ondemand価格 c3.xlarge c4.xlarge ほぼオンデマンドの 20～25%をキープ一時荒れるも避難し、大半を最低価格の 14%でキープ
Copyright gedow.net All Rights Reserved. 50 インスタンスタイプの選択  希望は 2xlarge あたりだった  最初に採用したのは c3/c4.xlarge  c4がご乱心＆ m3が安定したので c3/m3.xlarge に避難  m2 は安定しているがHVM非対応  新しい m4 は多分、数カ月後に荒波  CC2/CR1 もわりとブルーオーシャン  高スペック＋Dockerという手も……
Copyright gedow.net All Rights Reserved. 51 オンデマンドいる？  いざ運用してみると、思いの外スポットのスケールアウトだけで稼働できてしまう  オンデマンドがいらない気になるけど、そこまでスポットは信用するべきものでもない  最終防衛ライン  1セットにつき６つのオンデマンドが確定なので、リザーブドインスタンスを適用するとさらに削減できる
Copyright gedow.net All Rights Reserved. その他の工夫
Copyright gedow.net All Rights Reserved. 53 AutoScalingGroup管理の簡略化  LaunchConfigurationが多い  production / staging  spot / ondemand  c3 / c4  AutoScalingGroupが多い  同上  1a / 1c  監視用  CloudWatchが多い  Increase (peace / pinch)  Decrease  監視用は除く＞合計8件＞合計20件＞合計48件自動化した作成・削除・更新など全て
Copyright gedow.net All Rights Reserved. 54 独自TimeBasedスケールアウト 12時 23時  サービスの性質上、12時と23時がピークタイムであり、 12～23時の間はイベントやメンテナンスによる急激な増減がある。特にメンテ明けの台数は危険  11:30 にMinSizeを、その時点のInService✕N倍の台数に強制増設する（1.5～3倍）  23:30 にMinSizeを元に戻す  日中の台数節約放棄の代わりに運用し易さと安定を得る強制Increase 自然な増減に切り替え最低台数をキープ
Copyright gedow.net All Rights Reserved. 55 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とインスタンスタイプで台数に偏りが出ると、リスクも偏ることになる
Copyright gedow.net All Rights Reserved. 56 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を分けなくても、実はそもそもこうなっているはず  リソースを多目に消費することは台数節約でもある
Copyright gedow.net All Rights Reserved. 57 スクリプトで AWS CLI を使わない  AWS CLIは重い（CPUをメチャ喰う）  手動や数時間に１回の実行ならば問題ない  数十秒単位だとCPU利用率のグラフが常に10%前後など無駄すぎる消費  重いのは認証処理  シェルのコマンドベースだと毎回この処理が入る  軽量プログラミング言語＋SDKで書けば、認証を確保したままループ処理をできるため軽い  最初はBashで書いたがRubyに書きなおした  手動実行管理スクリプト  自動実行ジョブスクリプト  監視アラート／グラフ用値出力スクリプト
Copyright gedow.net All Rights Reserved. 58 AWS Japan と同じ社屋に入るアルコタワーアネックス Amazon Japan アルコタワー 19F AWS Japan 17F ドリコム他の階も Amazonが徐々に侵食中  相談や新着情報を伝えに天上界から降りてきてくれ、終わると天上界にお帰りになられる  天上界にお伺いし、USチームと電話会議したり、来日しているとディープな情報交換できる（完璧な通訳付き）
Copyright gedow.net All Rights Reserved. 59 俺のコストが高騰しちまうからな！でも …… でもでもスポットは怖いしやめたほうがいいと思うよ！ fin

Check these out next

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

Recommended

More Related Content

Slideshows for you(20)

Viewers also liked(20)

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

Recently uploaded(20)

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