＃別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なノードを置く
など配慮は要りそうです。