Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

77,834 views

Published on

Gedow style how to use aws spot instance.

Published in: Technology

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

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

×