SideCI TechBlog

SideCIを作っているアクトキャットのエンジニアによる技術ブログです。


SpotFleetを使ったらEC2のコストが1/4になった話

こんにちは。最近SideCIのインフラまわりを見ている@wata727です。最近注目しているサービスはArukasです。個人的に未来を感じているサービスなので、今後の機能追加にワクワクしています。 今回は最近のSideCIにおけるSpotFleetの活用事例についてお話したいと思います。

SpotFleetってなに

SpotFleetとは、AWSの低価格なサーバリソース群、スポットインスタンスを保持するための仕組みです。スポットインスタンスは、AWSで使用されていないリソースを対象に、需要と供給にあわせて、価格が変動するインスタンスです。そのため、通常のインスタンスよりもお安く購入することができます。 ただ、普通に使うだけでお安く購入できる、、なんて甘い話は無くて、価格は常に変動するため、希望する購入価格を超える場合には起動しているインスタンスが削除されてしまいます。

そのため、従来は途中で中断しても問題ないようなバッチ処理などで広く利用され、安定して複数台起動し続けるためには、複雑なスクリプトを自前で持つ必要がありました。しかし、SpotFleetはスポットインスタンスが価格を超えた場合には自動で入札し直してスポットインスタンスを起動するため、簡単に安定してスポットインスタンスの台数を維持することが可能になりました。

特に最近はAutoScalingに対応するなど、ガンガン進化しているので、これをきっかけにSideCIでもバックエンドのサーバでSpotFleetを採用する運びとなりました。

スポットインスタンスの価格変動とスポットインスタンスプール

先程もちょっと触れましたが、スポットインスタンスは余剰リソースの需要と供給から、価格が決定されます。これはAWS上のすべてのサーバに対してではなく、Availability Zoneごと、インスタンスタイプごとにグループ分けされています。これはスポットインスタンスプールと呼ばれています。 例えば、m3.largeとm4.largeで、それぞれap-northeast-1a, 1bに対しては、全部で4種類の組み合わせ(スポットインスタンスプール)が存在するので、それぞれの価格も異なります。

同じプールからすべてのインスタンスを購入してしまうと、そのプールが他のプールに比べて価格が安ければ、最安値で購入できますが、高いときには総合的に高いですし、最悪の場合、上限価格を超えて、すべてのサーバが削除されてしまうことがあります。 ここまでは今までのスポットインスタンスと同じですが、SpotFleetはプールを分散することができ、長期的にインスタンスを運用できることがポイントです。

安定してSpotFleetを運用するためにやっていること

SpotFleetを2つに分ける

2つに分けたSpotFleetのイメージ

SpotFleetには配置戦略と呼ばれるオプションがあります。常に最安のインスタンスを起動するlowestと、可能な限りプールを分散して安いインスタンスを起動するdiversifiedの2種類です。(2016年10月11日現在)

lowest戦略は最安で購入できる分、先程例に上げたように、価格上昇時にまとめてインスタンスが削除されてしまう危険が伴います。一方、diversified戦略はプールが分散されるので、価格変動によるインスタンス全停止のリスクは下がります。その分、せっかく安いインスタンスがあっても、別の高い価格のインスタンスを買わなくてはいけないことがあります。ジレンマです。

この解決策として「最低限稼働してほしい」インスタンスはdiversified戦略のSpotFleetで起動し、それ以外はlowest戦略のSpotFleet、というように2つのSpotFleetに分割します。もちろん、diversifed戦略は台数が2台以上でないと意味がありませんので、それは最低限確保するようにしてください。

SpotFleet間の上限価格に差をつける

SpotFleetを2つに分けるだけでも、全インスタンス停止のリスクは避けられますが、更にlowestとdiversifedで上限価格の差をつけることをおすすめします。 SpotFleetは上限価格を超えた時点で、別のプールからインスタンスを起動するので、仮に2つのSpotFleetが多くのインスタンスを同じプールから起動していても、インスタンスが削除されるタイミングをずらすことができます。つまり、同時に全インスタンスが停止するリスクを下げることができます。 もちろん、こんな感じで一気に価格が高騰することも珍しくないので、その場合にはあまり効果は見込めませんが…

価格推移のイメージ

lowest戦略のSpotFleetをAutoScalingで最適化する

あとは、せっかくAutoScalingに対応しているので、lowest戦略のSpotFleetはピークにあわせて増減するようにしておきます。diversifiedのインスタンスは減らさないようにしましょう。もしもdiversifiedのインスタンスをAutoScalingしたい場合には、それはdiversified戦略のSpotFleetで起動している台数が多すぎるので、lowest戦略のSpotFleetに移したほうが良さそうです。

まとめ

SpotFleetを採用した結果、EC2の費用が実に約1/4程度まで減りました。スポットインスタンスを使うためには、サーバをAMIから起動してすぐにサービスインできるようにしたり、突然削除されても影響が無いようにアプリケーションを設計する必要があったりして、なかなかに難易度が高いですが、費用効果は絶大です。

実際、このスペックがこれだけ必要なんだ!というほど厳密な状況というのはまず無くて、多くの場合は少し余裕を持って稼働させっぱなしになっていると思います。リソースは有限なので、みんなで余ったリソースを分け合える、サーバに依存しないような未来がやってくるといいですね。現場からは以上です。