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

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

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

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

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

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. 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 グループ！

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グループ)＋(オンデマンド１✕６グループ) が平時の台数となる

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 高騰  グループ単位で価格を監視し、高騰と判断したらインスタンスを破棄してグループの稼働を停止する  残る３グループの負荷は上がるが平常運転の範囲内  価格が落ち着いたら、またスケールアウトを開始する

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

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 価格高騰により１グループ死亡しても残るグループの負荷は 4/3倍になるだけ

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

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

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

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

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. 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%削減

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

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. 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. 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とインスタンスタイプで台数に偏りが出ると、リスクも偏ることになる

56. 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を分けなくても、実はそもそもこうなっているはず  リソースを多目に消費することは台数節約でもある

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

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

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

外道父

Transcript

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

外道 父

Transcript

外道父