Upgrade to Pro — share decks privately, control downloads, hide ads and more …

がんばらないスポットインスタンス運用 / Spot-instance-Matsuri

がんばらないスポットインスタンス運用 / Spot-instance-Matsuri

秋のスポットインスタンス祭り ~ そろそろクラウドネイティブなコスト最適化はじめてみませんか? 発表資料です
https://awsj-compute.connpass.com/event/192302/

FUJIWARA Shunichiro

November 11, 2020
Tweet

More Decks by FUJIWARA Shunichiro

Other Decks in Technology

Transcript

  1. Agenda カヤックでのスポットインスタンス活⽤の変遷 2014 〜 ⾃前⼊札期 2017 〜 Spot Fleet 期

    2019 〜 Auto Scaling Group - Mixed Instance Type 期 頑張らずにスポットインスタンスを使うために
  2. カヤックでのスポットインスタンス活⽤の変遷 - ⾃前⼊札期 2014年10⽉ Lobi Rec SDK リリース モバイルゲームのプレイ動画共有サービス 当初は動画変換に

    Amazon Elastic Transcoder を利⽤ モンスターストライクへ導⼊されてコストが問題に → EC2スポットインスタンスで変換処理
  3. 2014年当時のスポットインスタンス aws ec2 request-spot-instances ... ⼊札価格 台数 LaunchSpec インスタンスタイプ、Subnetなど を指定して

    スポットインスタンスの起動をリクエスト ⼊札価格が現在の価格より⾼ければ起動してくる リクエスト時の⼊札価格より現在の価格が⾼くなると落とされる スポット価格はオンデマンド価格より⾼くなることもある !! インスタンスを Stop できない。Terminate のみ
  4. いい感じに動画変換サーバをオートスケールしたい 当時はスポットインスタンスをオートスケールする仕組みがなかったため ⾃前 daemon を動かして spot-request / terminate をコントロール .

    動画変換queueのjobの溜まり具合を⾒る 当時はZabbixのメトリクス . 毎分jobの数を⾒て溜まっていたら台数を1.4倍にするようにspot request 5分程度何もしない cooldown time = 起動して処理が進むのを待つ . jobが減少傾向ならそれ以上起動しない . 全台の平均CPU使⽤率を⾒て、25%以上idleがあれば台数を減らしていく jobが溜まっていなくてもCPUに余裕がない 均衡している なら減らさない
  5. 苦労した点 ⾃分ですべてやっているので、細やかな気配りが必要 インスタンスタイプ AZを固定⾼騰して起動できない → 価格をAPIを叩いて収集、安いものを優先起動 落とす時は1時間の端数を使い切りそうなものから → 当時は課⾦単位が1時間だった 今は1分

    AMIをビルドするたびに追従が必要 → AMI⼀覧を取得して最新かつavailableのを使う だいぶ頑張った https://speakerdeck.com/haruyosh/amazon-ec2-auto- scaling-niyorusupotutoinsutansuhuo-yong-jiang-zuo? slide=20
  6. カヤックでのスポットインスタンス活⽤の変遷 - Spot Fleet期 2015年 Spot Fleet リリース Fleet 全体のCPU数/台数を指定して、要件を満たすようスポットインスタンスを起動

    → インスタンスが落ちると別インスタンスが⾃動的に起動してくる リリース当初は指定したキャパシティを保つのみ 2016年9⽉オートスケーリング対応でLobiのユースケースに適⽤可能になった → 2017年に導⼊ アプリケーションサーバコストの⼤幅削減に成功
  7. アプリケーションサーバも Spot Fleet に オンデマンドのAutoScalingGroup ASG とSpotFleetを併⽤してコスト削減を試みた ASGとFleetはお互い無関係 = オートスケーリングの閾値設定がそれぞれ必要

    オンデマンドはCPU 60%でスケールアウト SpotFleetはCPU 40%でスケールアウト 価格が安いSpotのほうを反応しやすくしておくとコスト効率がよい . CPU負荷が上がるとSpotが先に起動する . Spotが⾼騰して落とされる/起動できないとさらにCPU負荷が上がってくる . オンデマンドの閾値に達してオンデマンドが起動する 安価なスポットが起動できない場合には⾼価なオンデマンドでカバー
  8. ASG / SpotFleet 併⽤の問題点 管理が⾯倒 例えば AMI 差し替え時… ASG :

    設定変更で可能 SpotFleet : キャパシティ以外の変更は作り直し なのでこのような頑張りが必要に . 新しいAMIのFleetを作成 / 古いFleetをCancel インスタンスは⽌めない . 新しいFleetのインスタンスがELBに⼊る . ELBから古いFleetのインスタンスを外す . 古いFleetのインスタンスを削除 Fleetのキャンセル時にインスタンスを削除する設定も可能だが 120秒前の退役予告が⾶んでこないので処理中のリクエストが死ぬ
  9. 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
  10. 最低台数を多めにして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の台数は残る
  11. 異世代インスタンスを混ぜて⼤丈夫? 世代が変わる C3 → C4 C4 → C5 と確実に処理は速くなるが… 実アプリケーションの処理速度はCPUだけでは決まらない

    CPUの速度 AZをまたぐ通信やAWS外へのリクエスト どちらも外部からみた1リクエストの処理速度 レイテンシ に影響する C5 で AZ またぎの通信が多い RDSが別AZ C4 で AZ またぎの通信が少ない RDSが同AZ 実測してみるとレイテンシは⼤差なかったりする
  12. トラブル対応Tips: スポットインスタンスが全体的に枯渇したら ごくまれにある 実際にあった例: 3AZに分散していた c5.4xlarge がすべてほぼ同時に terminate → c4

    を混ぜていたので致命傷にはならなかった 対応: c5d c5n m5 等を追加して影響を軽減 性能差には あまり こだわらず、多くのインスタンスタイプで分散を⼤きくする
  13. トラブル対応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のクロスゾーン負荷分散は有効にしておくこと