ABEJA Arts Blog

株式会社ABEJAのメンバーが最先端の “Mechanical Arts” と、それを実際に社会に適用する中で必要な “Liberal Arts” について発信します

スポットインスタンスを効率的に管理するSpotinstを使おう

みなさん、AWSのスポットインスタンスは使っていますか? スポットインスタンスを使えばオンデマンドインスタンスの約70-80%引きでEC2を利用でき、大きなコスト削減が出来ます。 しかし、スポットインスタンスは価格変動が起きるとインスタンスが停止したりするリスクがありますよね? その辺りのリスクをヘッジしてくれるのがSpotinstというサービスになります。

Spotinstは価格変動によるリスクヘッジだけじゃないメリットがたくさんあるので紹介したいと思います。 Spotinstは何個かサービスがあるのですが、その中のElastigroupという機能を主に説明していきます。

結論

先に結論書いておきます。 かなり安いから使わない理由は無いです。Pricingの項目を参照ください。

Elastigroupとは

spotinst.com

トレンド分析

Elastigroupは独自の予測アルゴリズムを使用して、AWSなどのクラウドプロバイダーによって「中断されようとしている」スポットインスタンスを特定して排除してくれます。 排除前に、Elastigroupはアプリケーションを自動的に最も安価な「利用可能な」スポットインスタンスまたはオンデマンドインスタンスに移行させ、ダウンタイムは発生させなくしてくれます。 実際に自動的にオンデマンドに切り替わることが何度かありました。 価格変動リスクを事前に察知し、利用可能なスポットもしくはオンデマンドに切り替わってくれるのはすごくありがたい機能です。

ECS Integration

僕がよく使っている機能がECS Integrationです。 ECSでホスト側のAutoScaleをする場合は、基本はホストのリソース(予約量)の余りを見てスケールさせるCPUReservationもしくはMemoryReservationになります。 例えば予約量が70%や80%を超えるとAutoScaleを発動させたりしますが、インスタンスタイプやコンテナサイズがバラバラの場合は ホストのリソースが空いているにも関わらず、コンテナサイズが合わないためデプロイ出来ない といった事象がよく発生します。AutoScaleの閾値を50%や60%に下げれば一時的に解決しますがリソース効率がすごく悪く感じるのと、根本的に予約量云々じゃなくて リソースに空きがなかったらスケール して欲しいものです。

そこでSpotinstのECS Integrationです。 これは複数の機能があります。

AutoScaler

AutoScalerはECSでコンテナデプロイした時にリソース不足で発生するイベント(Insufficient Memory、Insufficient CPUなど)を検知し、ホスト側を自動的にスケールしてくれる機能です。まさに リソース不足を検知してスケール してくれる機能です。 また、ホストが増えすぎて余剰リソースがあると コンテナを空いているところに寄せてから 自動的に縮退してくれます。すごくコスト効率が良い機能です。 ECSの場合は縮退等の機能はないため自分で作る必要がありましたが、Elastigroupは自動で行ってくれます。

f:id:xwkns157:20180225174241p:plain

Automatic Autoscaler for ECS - Spotinst API

Headroom

Headroomは 1024cpu/2048MBを5個分確保しておいて というような設定を行うことで、期待したリソース分を定常的に確保することが出来ます。 EC2 AutoScalingの場合はホストのCPU/MEMの何%消費したらスケールという設定になるので、インスタンスタイプがバラバラだとコンテナを綺麗にハマるようにするにはすごく計算が面倒になります。インスタンスタイプの種類が増えたら計算し直したりとか結構面倒です。 Headroomの方が コンテナを扱う上で 適切なリソース確保を行ってくれます。

f:id:xwkns157:20180225174715p:plain

Automatic Autoscaler for ECS - Spotinst API

Tetris Scaling

こちらは僕はまだ使ったことがなく、問い合わせたレベルの情報です。 ECSのスケジューリング(コンテナの配置)はECSに任せているとECSが配置してくれますが、リソース効率は良くないように思います。 Tetris Scalingは ECSの空きリソース状況を見て適切にコンテナをスケジューリング してくれるそうです。名前の通り テトリス的に配置 してくれる良い機能です。 この機能を使う場合はSpotinstAPI経由でコンテナをデプロイする必要あります。

https://help.spotinst.com/hc/article_attachments/115007594765/ECS-Blog-4.png

インスタンスの安全なDrain

ECSのホストを縮退する時には、縮退対象のホスト上のコンテナが動いているので、コンテナを違うホストに移動してからホストを削除しないとコンテナ上のアプリケーションのダウンタイムが発生します。 ECSにDrain機能がありますが、StopやTerminate前には自らDrainする必要があります。 Spotinst経由で縮退等を行うと、 自動的にDrainの上で縮退する 仕様になります。地味に楽です。 ホストを総入れ替えするときなど様々な面で縮退する時があるので、ECSの運用には必要不可欠な機能です。

f:id:xwkns157:20180225175118p:plain

Blue Green Deployment

ECS Integrationの次に活用しているサービスがBlue Green Deploymentです。 これはElastigroupで管理しているインスタンスを変更(インスタンスタイプやAMIやuserdataなど色々)する際にEC2をデプロイし直す必要があるのですが、その際に 必ずBlue Green Deploymentが強制 されます。 しかも「何%ずつ入れ替える割合指定」や「ヘルスチェックを見てから縮退する」といった機能も付いているので安全に入れ替えることも出来ます。 Spotinstに触れる前はB/G機構を自前で作ろうとしていましたが、これを見た瞬間に「そもそもEC2自体の管理はしていきたくないし、こんなところでリソース割くのアレだし、 作るのはやめて、使おう 」と思いました。 みなさん、作るのは辞めましょう。 Meltdownとか来てもSpotinstで安全にデプロイ出来ます。

備考: 実はオンデマンドインスタンスもElastiGroupで管理出来るのでオンデマンドインスタンスでもB/G機能は利用出来ます

http://blog.spotinst.com/app/uploads/2016/03/G-FLOW-04.png

Implementing Blue/Green deployments with Elastigroup on AWS - Spotinst

ちょっとした機能

スポットインスタンスとオンデマンドインスタンスのバランス制御出来ます。

こんな感じでスライダーで比率を変えられます

f:id:xwkns157:20180225172939p:plain

SPOT MARKET SCORINGも表示

アベイラビリティゾーンとインスタンスタイプごとに参考の割引率を表示してくれます

f:id:xwkns157:20180225173100p:plain

もちろんインスタンスタイプを色々選べます

以下は一部です。

f:id:xwkns157:20180225173137p:plain

ステートフルサーバもスポットインスタンスで管理できる??

この機能はまだ 怖くて 使ってないのですが、かなり強力な機能です。 Elastgroupは基本はステートレスなサーバが対象ですが、ステートフルなサーバでもスポットインスタンスが使えるそうです(一部の機能が使えないものあるかも)。 re:Inventに行った時にブースが出てたので質問したのですが、想定通り仕様は以下の通りでした。

  • 対象インスタンスのSnapshotを常に取り続ける
  • 価格変動が発生するとインスタンスを停止させる(ここで一旦停止)
  • インスタンス停止後にもう一度Snapshotを取る(最終のSnapshotからの差分取得のためSnapshotの時間は短い)
  • オンデマンドで起動(ここで再開)

概ね数分の停止で復旧出来るらしいので、通常のオンデマンド程度の対応時間になるのではないでしょうか。 ちなみにEBSやPrivateIPなども維持できるオプションもあるので、ステートフルなサーバでもコスト削減のチャンスはあるかもです。 公開事例ではredisなどで使われているそうです。

http://blog.spotinst.com/app/uploads/2017/07/mceclip0.png

Stateful Applications with Spot Instances - Spotinst

サポート

結構プロアクティブに答えてくれます。ライブチャットでも早いレスポンスで好感です。 ドキュメントに詳しく書かれていない部分もあるので「これであってる?」とか聞いても即日回答だったり、 先日も「AWSからSpotInstanceの上限エラー出てるけど、AWSサポートに緩和申請した?他に何かフォローすることある?」とか来てました。

ちなみに英語必須です。

Pricing

※Webサイトに公開されてないですが、問い合わせたら言ってもいいとのことだったので掲載してます

あまり見ない面白い価格設定なのですが、 オンデマンドの価格からスポットインスタンスによって割り引かれた価格の20% が利用料になります。 ベースで何かかかるわけではなく、通常使うより安くなるのは確実です。

計算式: ( オンデマンド利用料 - スポットインスタンス利用料 ) * 20% = Spotinst利用料

参考例: ( $100 - $20 ) * 20% = $16

スポットインスタンス利用料: $20 Spotinst利用料: $16 合計: $36

つまり合計としてはスポットインスタンスをそのまま利用するより20%分高くなりますが、上記参考例に上げるとオンデマンドより64%安くなることになります。

AutoScalerやHeadroomとかを考えると、実は20%取られてもSpotinstの方が安かったということもあるし、 AutoScalerやHeadroomを自分で開発・実装するくらいなら遥かに安価です。

その他細々した機能

Spot Analyzer

AWSのアカウントと連携しているとオンデマンドから切り替えるとこれだけ安くなるよ!ってのをサジェストしてくれる

Integrationと既存リソースのインポート

以下のようなツールなどとIntegration出来るのと、それらの既存リソースをSpotinst化するためにインポート機能もあります。

f:id:xwkns157:20180225173242p:plain

最後に

スポットインスタンス使わないならFargateがオススメです。 ホストの管理しなくていいし、上のようなこともしなくていい。Fargate使いたい。

でも、コスト効率上げるならスポットインスタンス使う必要があり、Spotinst使えば便利な機能が目白押し。

でも、Fargate使いたい。要はFargateでスポットインスタンスが出ればいいんやで。待ってますAWSさん。

宣伝

ABEJAでは、SREエンジニアを募集しています!! www.wantedly.com

ABEJAが発信する最新テクノロジーに興味がある方は、是非ともブログの読者に!

ABEJAという会社に興味が湧いてきた方はWantedlyで会社、事業、人の情報を発信しているので、是非ともフォローを!! www.wantedly.com

ABEJAの中の人と話ししたい!オフィス見学してみたいも随時受け付けておりますので、気軽にポチッとどうぞ↓↓