＃別blogから引っ越した2014/2/17の記事です。

話題の（？）Immutable Infrastructure にインフラ1年生がEC2 Spot Instance で挑んでみました。

いざTryしてみて社内に共有する資料を作ったのですが、せっかくなので公開しました。

当社提供中のソーシャルゲーム「タワーオブドラゴン」はAWSで稼働しています。

ソーシャルゲームはその特性上、こんなケースが頻繁に発生します。

サービスを停止させること無くアプリケーションを更新する
突然のトラフィック増大に対応するためサーバを急きょ追加しスケールアウトする
大規模なアップデートを施すため一律更新済のサーバを展開する
EC2も常にオンデマンドで使っているとコストが嵩んでしまいます。

トラフィックが落ち着いている時は Reverse Proxy / Application Server の台数を絞ってコストを削減していますが、Load Balancer 配下の Reverse Proxy が余りにも少ない状態だと、ELBからの切り離し・切り戻しで残されたActive系に瞬間的な高負荷がかかるのか、HTTP500が返ってしまうことがあるようでした。

このため、deployする時だけELB配下のノードを増やすという間抜けな運用をしており、1deploy $1.2 みたいな貧乏性にはむず痒い状態になっていました。

このままではdeploy回数を減らすという、ある意味で正しい((オンラインのままでdeployすると、どうしても少数のエラーが起きてしまっているため))けど、守りに入った間違った状態に向かってしまう。

何かいい方法はないか考え、そういえば Spot Instance という手があると思いつきました。

これまで Spot Instance は存在や概要は知っていれど、入札だ強制停止だなんだと取っ付きにくく、使ったことがありませんでした。

実際にやってみたらあっさり簡単でコストも圧縮できました。

ただし、いつ急激に価格が跳ね上がるかは予測できないため、

安全圏な入札価格に設定する
ELB配下に1台はオンデマンドなり非Spotなノードを置く
など配慮は要りそうです。