秋のスポットインスタンス祭り ～ そろそろクラウドネイティブなコスト最適化はじめてみませんか？ 発表資料です https://awsj-compute.connpass.com/event/192302/
がんばらないスポットインスタンス運⽤2020.11.11 秋のスポットインスタンス祭り⾯⽩法⼈カヤック 藤原俊⼀郎 @fujiwara
View Slide
@fujiwaragithub.com/kayac/ecspressoAmazon ECS デプロイツールgithub.com/fujiwara/lambrollAWS Lambda デプロイツール
Game & Community
Agendaカヤックでのスポットインスタンス活⽤の変遷2014 〜 ⾃前⼊札期2017 〜 Spot Fleet 期2019 〜 Auto Scaling Group - Mixed Instance Type 期頑張らずにスポットインスタンスを使うために
カヤックでのスポットインスタンス活⽤の変遷 - ⾃前⼊札期2014年10⽉ Lobi Rec SDK リリース モバイルゲームのプレイ動画共有サービス当初は動画変換に Amazon Elastic Transcoder を利⽤モンスターストライクへ導⼊されてコストが問題に→ EC2スポットインスタンスで変換処理
2014年当時のスポットインスタンスaws ec2 request-spot-instances ...⼊札価格 台数 LaunchSpec インスタンスタイプ、Subnetなど を指定してスポットインスタンスの起動をリクエスト⼊札価格が現在の価格より⾼ければ起動してくるリクエスト時の⼊札価格より現在の価格が⾼くなると落とされるスポット価格はオンデマンド価格より⾼くなることもある !!インスタンスを Stop できない。Terminate のみ
いい感じに動画変換サーバをオートスケールしたい動画の投稿量は⼤きな波があった イベント開始直後など→ EC2 コスト削減のためにオートスケールしたい
いい感じに動画変換サーバをオートスケールしたい当時はスポットインスタンスをオートスケールする仕組みがなかったため⾃前 daemon を動かして spot-request / terminate をコントロール. 動画変換queueのjobの溜まり具合を⾒る 当時はZabbixのメトリクス. 毎分jobの数を⾒て溜まっていたら台数を1.4倍にするようにspot request5分程度何もしない cooldown time = 起動して処理が進むのを待つ. jobが減少傾向ならそれ以上起動しない. 全台の平均CPU使⽤率を⾒て、25%以上idleがあれば台数を減らしていくjobが溜まっていなくてもCPUに余裕がない 均衡している なら減らさない
いい感じに動画変換サーバをオートスケールしたい. 動画変換queueのjobの溜まり具合を⾒る. 毎分jobの数を⾒て溜まっていたら台数を1.4倍. jobが減少傾向ならそれ以上起動しない. 全台の平均CPU使⽤率を⾒て、25%以上idleがあれば台数を減らしていく
苦労した点⾃分ですべてやっているので、細やかな気配りが必要インスタンスタイプ AZを固定⾼騰して起動できない→ 価格をAPIを叩いて収集、安いものを優先起動落とす時は1時間の端数を使い切りそうなものから→ 当時は課⾦単位が1時間だった 今は1分AMIをビルドするたびに追従が必要→ AMI⼀覧を取得して最新かつavailableのを使うだいぶ頑張ったhttps://speakerdeck.com/haruyosh/amazon-ec2-auto-scaling-niyorusupotutoinsutansuhuo-yong-jiang-zuo?slide=20
カヤックでのスポットインスタンス活⽤の変遷 - Spot Fleet期2015年 Spot Fleet リリースFleet 全体のCPU数/台数を指定して、要件を満たすようスポットインスタンスを起動→ インスタンスが落ちると別インスタンスが⾃動的に起動してくるリリース当初は指定したキャパシティを保つのみ2016年9⽉オートスケーリング対応でLobiのユースケースに適⽤可能になった→ 2017年に導⼊アプリケーションサーバコストの⼤幅削減に成功
アプリケーションサーバも Spot Fleet にオンデマンドのAutoScalingGroup ASG とSpotFleetを併⽤してコスト削減を試みたASGとFleetはお互い無関係 = オートスケーリングの閾値設定がそれぞれ必要オンデマンドはCPU 60%でスケールアウトSpotFleetはCPU 40%でスケールアウト価格が安いSpotのほうを反応しやすくしておくとコスト効率がよい. CPU負荷が上がるとSpotが先に起動する. Spotが⾼騰して落とされる/起動できないとさらにCPU負荷が上がってくる. オンデマンドの閾値に達してオンデマンドが起動する安価なスポットが起動できない場合には⾼価なオンデマンドでカバー
ASG / SpotFleet 併⽤の問題点管理が⾯倒例えば AMI 差し替え時…ASG : 設定変更で可能SpotFleet : キャパシティ以外の変更は作り直しなのでこのような頑張りが必要に. 新しいAMIのFleetを作成 / 古いFleetをCancel インスタンスは⽌めない. 新しいFleetのインスタンスがELBに⼊る. ELBから古いFleetのインスタンスを外す. 古いFleetのインスタンスを削除Fleetのキャンセル時にインスタンスを削除する設定も可能だが120秒前の退役予告が⾶んでこないので処理中のリクエストが死ぬ
カヤックでのスポットインスタンス活⽤の変遷ASG Mixed Instance Type期2018年11⽉ ASG オンデマンド・スポットインスタンス混在対応リリースオートスケーリンググループに複数インスタンスタイプ、オンデマンド、スポットインスタンスを組み合わせて配置できるように！→ SpotFleetをやめられる2019年 Lobi で導⼊管理の容易さとコストの最適化を簡単に両⽴できて最⾼頑張らなくてよくなった！
安全にスポットインスタンスを使うために頑張らなくてよいとはいえやはりオンデマンドとは違うのでいくつか考慮が必要
いつ落とされてもいいように備えるインスタンスメタデータAPIで停⽌の120秒前に知ることが可能ASGのライフサイクルフックでLambdaを呼ぶこともできるhttp://169.254.169.254/latest/meta-data/spot/instance-action{"action": "terminate", "time": "2020-09-18T08:22:00Z"}予告が来たら速やかに停⽌準備を例ELB から⾃分⾃⾝を外すログをインスタンスの外に出す⻑時間の連続稼働が必要で、失敗できないワークロードには向かない
ASG Mixed Instance Type 戦略スポットインスタンスは様々な理由で落とされることがあるASG全体のキャパシティが不⾜しないために多様なインスタンスタイプ、AZを組み合わせる例: c5 c5d c5n c4 m5 m5d...を 3AZに配置配分戦略は capacity-optimized にするリアルタイムの容量データを調べ、可⽤性の最も⾼いプールを予測することで、そのプールからスポットインスタンスを⾃動的に起動しますhttps://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/asg-purchase-options.html
最低台数を多めにして3AZで例: 最低で 4xlarge * 3 で捌ける負荷だとしたら、2xlarge * 6 にする台数が少ないと分散が⼗分ではないため、複数台同時に落ちる危険が⾼くなる例3台中2台が同時に落ちると突然処理能⼒が1/3に4台が AZ a:b:c= 2:1:1の場合、AZ-a のインスタンスが落ちると 1/2 に3AZ構成で最低台数は3の倍数にしておくのがお勧めASGは極⼒AZのバランスを揃えようとするため安定性が増す1AZがすべて落ちても2/3の台数は残る
異世代インスタンスを混ぜて⼤丈夫？世代が変わる C3 → C4 C4 → C5 と確実に処理は速くなるが…実アプリケーションの処理速度はCPUだけでは決まらないCPUの速度AZをまたぐ通信やAWS外へのリクエストどちらも外部からみた1リクエストの処理速度 レイテンシ に影響するC5 で AZ またぎの通信が多い RDSが別AZC4 で AZ またぎの通信が少ない RDSが同AZ実測してみるとレイテンシは⼤差なかったりする
異世代インスタンスを混ぜた場合の処理能⼒平準化ALBの最⼩未処理リクエストルーティングアルゴリズム LOR を利⽤すると処理中のリクエストが⼀番少ないインスタンスに優先的にリクエストを回す遅い＝単位時間あたりの処理中のリクエスト数が多い通信のレイテンシが同じであれば…CPUが遅いインスタンスにはリクエストが減るCPUが速いインスタンスにはリクエストが増える→ 負荷が平準化されるただし、CPUは速いが通信のレイテンシが⼤きいインスタンスもリクエストが減るこれが⼀番CPU的には暇
異世代インスタンスを混ぜても⼤丈夫！我々のユースケースの場合、CPU使⽤率にして最⼤15ポイント程度の差CPU使⽤率が 40%〜55% に分散
異世代インスタンスを混ぜても⼤丈夫！平均ではなく最⼤のインスタンスのCPU負荷を⾒る⼀番負荷の⾼いインスタンスに余裕があるうちにスケールできる閾値を決める多少ゆるめの設定で台数が多くなっても、全台オンデマンドよりは格段に安い安全側に倒しましょう
トラブル対応Tips: スポットインスタンスが全体的に枯渇したらごくまれにある実際にあった例: 3AZに分散していた c5.4xlarge がすべてほぼ同時に terminate→ c4 を混ぜていたので致命傷にはならなかった対応: c5d c5n m5 等を追加して影響を軽減性能差には あまり こだわらず、多くのインスタンスタイプで分散を⼤きくする
トラブル対応Tips: 特定のAZでのみ起動しづらくなったら特定AZで枯渇することがあるASGはAZ間のインスタンス台数 バランス を保つことをたいへん重視するので…. AZ-a のインスタンスが terminate. 不⾜分を補うために AZ-b c で起動する. AZ-a で起動可能になったので起動してくる. AZバランスを取るため AZ-b AZ-c のインスタンスが terminate. しかし AZ-a では枯渇気味なのですぐに terminate 2に戻るというループが始まり、ひたすら起動と停⽌を繰り返すことがある対応: ASGのsubnetから⼀時的に枯渇しているAZのsubnetを削除してやり過ごすELBのクロスゾーン負荷分散は有効にしておくこと
新機能！ 2020.11.05Capacity Rebalancinghttps://aws.amazon.com/jp/blogs/compute/proactively-manage-spot-instance-lifecycle-using-the-new-capacity-rebalancing-feature-for-ec2-auto-scaling/ASG内のSpotインスタンスが中断 停⽌ 予告を受けた場合に落ちる前に別のインスタンスを起動してくれる機能停⽌時の⼀時的な容量減をカバーできる
まとめスポットインスタンスの運⽤は、5年前は⼤変だった 昔話ここ数年で格段に楽に。頑張らなくてよくなった！ASG Mixed Instance Type で幅広いインスタンスタイプ/AZを混ぜるのがおすすめオートスケーリングの閾値設定は攻めすぎない
fujiwara3
oekazuma
yoshinagaiwnl
hirosatogamo
oracle4engineer
chiroruxx
blue_goheimochi
lmi
yutaro527
robots
uzulla
t88
foursue
nonsquared
philhawksworth
holman
denniskardys
bkeepers
lara
notwaldorf
sugarenia
dotmariusz
mclloyd
thoeni
reverentgeek