この記事は、AWS Advent Calendar 2015 の17日目の記事です。
昨年の Advent Calendarでは、「スポットインスタンスを安定して利用するための取り組み」という記事を書かせて頂き、スポットインスタンスの安定運用に取り組んでいたことを書かせて頂きました。
あれから１年、AWSスポットインスタンスに関するサービスも増え、
さらにサービスを組み合わせることで安定してサービス運用できそうになってきているので、
その取り組みについて書きたいと思います。
（スポットインスタンスの基本などは昨年の記事やネットで検索して頂ければと...）
振り返り
これまでは、下記のような環境でスポットインスタンスとAutoScaleを組み合わせて安定運用を実現していました。
システム構成
- AutoScaleの機能を利用してキャパシティの確保を行う
- AutoScalingGroupのmin-sizeの指定
- インスタンスタイプと入札価格を指定した複数のLaunchConfigを用意
- 例) ConfigA (c3.8xlarge, $2.0)
- 例) ConfigB (c3.4xlarge, $1,0)
- 例) ConfigC (r3.4xlarge, $1.5)
- 1つのELBに複数のAutoScalingGroupをぶら下げる
- AutoScalingGroupのload-balancer-namesを同じELBに設定
- 例) GropuA => ConfigA を10台
- 例) GropuB => ConfigB を6台
- AutoScalingGroupのload-balancer-namesを同じELBに設定
- 1つのAutoScalingGroupでは、複数のLaunchConfigを切り替えながら設定
- LaunchConfigを切り替えればスポットの再入札を行う機能を利用
- 例) GropuA のConfigAという設定から ConfigCに切り替えて10台を起動させる
- LaunchConfigを切り替えればスポットの再入札を行う機能を利用
- 価格不足でサーバが落ちた場合、CloudWatchに金額を問い合わせて最安値のスポットインスタンスを探して再入札
- Zabbixでサーバの監視とスポットインスタンスの価格を監視
- サーバが落ちるまたは、Zabbix-agentの停止をトリガーに価格情報の確認（ここは理想）
- JenkinsでオートスケールのLaunchConfigを切り替え
- 無事にスポットインスタンスでサーバ起動
- Zabbixでサーバの監視とスポットインスタンスの価格を監視
- オートスケールで起動するサーバは、遅くても3~5分以内にチューニングしておく
図にすると下記のような感じになりますが、見ていただいて分かる通り非常に複雑でめんどくさく、
特定の人しか触れないシステムが完成してしまいます。
※ この切替をZABBIXやJenkinsを用いて実施
課題
オートスケールと組み合わせることでスポットインスタンスを便利に利用することが出来るのですが、課題は山積みです。
- 1つのELBに複数AutoScalingGroupがぶら下がり、サーバの管理が大変
- 1つのAutoScalingGroupには、1種類のインスタンスタイプと入札額でしかスポットリクエストを行えない
- 対象のELBに今何台ぶら下がっていて、どのAutoScalingGroupのサーバを増減させて良いか分からない
- Zabbixでスポットインスタンスの価格情報を監視している
- 一度スポットインスタンスで稼働させると価格上昇で落ちるまでは入れ替えられない
- 今より安いインスタンスに置き換えるのを自前で実装すると複雑すぎて危険
- 複数のAutoScalingGroupを利用していると余計にわけわからなくなりそう
- 結局1時間未満で価格上昇で落ちるのではなく任意で落とした場合は費用がかかるのでコストがかかる可能性がある
などなど、結局は「複雑すぎるシステム」となってしまいインフラ費用はかなり抑えられるかもしれませんが、
運用コストがかなり膨らんでしまい、結局誰も使えなくなるシステムが出来上がってしまう危険性をかなり秘めていました。
そんな課題を今年発表されたサービスでAWSは改善してくれそうです！！
スポットインスタンス関連サービス
スポットフリートAPI
使いたいインスタンスタイプや入札価格を指定すると、自動で最安値のインスタンスを選択して起動してくれるめっちゃ便利な機能です。
これまでオートスケールや価格監視システムと組み合わせて無理やり組み込んでいた機能を1つのAPIで実現してくれている機能になります。
このAPIを利用することで、たとえば
- 基本設定
| 項目 | 設定値 |
|---|---|
| サーバ台数 | 20台 |
| 入札価格 | $1.0 |
| インスタンスタイプ | c3.8xlarge, c3.4xlarge, r3.4xlarge |
とすることで、３つのインスタンスタイプの中から最安値のインスタンスを選択して入札する処理を自動で行ってくれます。
入札価格を管理しつつかつ起動台数設定に満たしていない場合には再度入札をかけてくれるという...
これでAutoScalingGroup複雑すぎる問題は解消できそうです！
EC2スポットブロック
スポットブロックとは、スポットインスタンスを1~6時間継続して利用できるようになった新機能です。
これまでは需要と供給によって価格が変動し、入札価格と現在のサーバ価格で起動し続けられるかどうかが決まっていたので
不安定な状況での利用でしたが、最大で6時間もスポットインスタンスを使い続けることを担保してくれるとか嬉しいですね。
このスポットブロックは、スポットフリートAPIのオプションとして設定することが可能なため合わせて利用することが出来ます！
スポットフリートAPIとスポットブロックを組み合わせたシステム構成
スポットブロックを利用すると通常のスポットインスタンスに比べて若干割高にはなりますが、確保できる時間は担保されます。
ゲーム業界だとイベント開始直前やフィーバー発生時など瞬間的に負荷が高くなることが予測される場合にスポットブロックを利用すれば良さそうですね！
あとは、これらを制御するJenkinsなりLambdaなりで単純な構成にすれば、
以前よりシンプルで安定したスポットインスタンスの運用が行えそうです。
まだまだ検証段階ではありますが、楽しみな構成の１つかなと思います。
とは言えスポットだけの運用はまだまだリスクはある
昨年の記事でも書きましたがお客様にサービスを届けている環境で利用する際には、
やはりスポットインスタンスだけでの運用はリスクがありすぎると思います。
社内のバッチ処理や分析関連であれば問題無いかもですが、お客様に使って頂いているサービスであれば
我々は品質の高いサービスを提供する義務がありその点は最優先で考えなければいけない点となると思います。
そのため、本番運用を行うにはやはりオンデマンドやリザーブドインスタンスとの併用が基本の考え方だと感じています。
まとめ
スポットインスタンスは、一時的な利用が基本思想ではありますが、
工夫することで本番環境でも十分利用できると考えています。
とはいえ、複雑なシステムになってしまい運用が疎かになってしまうのは本末転倒なので、
チームで議論したうえで足並みを揃えて取り組んでいくことが重要だなぁと思います。
余談
2013年頃からスポットインスタンスを利用していますが、
2014年後半にかけて利用者や情報発信する方々が多くなってきたという印象があるのですが、
最近は情報発信も落ち着いてきているのかなという印象です。
スポットインスタンスは利用者が増えることで需要が高まり価格が高騰する可能性はありますが、
良い事例悪い事例を共有することで、さらによいシステムへ成長するきっかけを得られるため
是非スポットインスタンス事例なども発信して頂けたら勉強になるなと思いました。
参考
スポットインスタンスとオートスケール
-
AWS Black Belt Tech シリーズ 2015 - Amazon EC2 スポットインスタンス & Auto Scaling
- やってきたことやりたいことがまとまっている非常に良い資料だと思いました！
スポットフリートAPI
- AWSブログ
- スポットインスタンスを上手く利用するために
- その他ブログ