2014/10/15

AWSでスポットインスタンスが死んで生き返るとどうなるの? っていう話

昨日、会社で仕事してたら家のサーバが繋がらなくなって仕事どころじゃなくて上の空だったれもんです。帰っていろいろ調べてみたら家の近所の900軒だけ停電したっていうレアイベントに巻き込まれてたというオチでした。

で、昨日の今日というわけではないんですが今日はこのサイトが落ちまして、このサイトにちょっとしたプライベートな自分用スクリプトを仕込んであったぼくはあわわわわみたいな感じになったわけです。で、原因はというと、このサイトはAWSにおいてあってSpot Instanceで動いているので、Spot Instanceの値段が一時的に上がって落ちていた! 以上! という感じでした。

Persistent Requestをオンにすると値段が下がったらまた起動してくれるのでこれオンにしておけばいいかーみたいな感じにしてあったんですが、実際に落ちたのははじめてなので具体的にどういう事象が起きるかというのは初めて知ったというところなので、せっかくなのでまとめておこうかなという記事です。

まずどんな感じでインスタンスを構成してたかというのをメモがてら書いておくと、こんな感じです。

• Spot InstanceのAmazon Linuxを/(root)が8GBのEBS(gp2)で起動する
• それとは別に20GBのEBS(gp2)をアタッチして/dataにマウントする
• rootはDelete On Terminationオン、dataはDelete On Terminationオフにする
• EIPをつけて、DNS(beatsync.netのAレコード)からはEIPに向ける
• rootには基本的になんもデータを置かない。nginxとコンパイルしたperlを置いただけ
• dataにnginxのログとwebappおよび記事データを置く(全部ファイルで、DB使ってません★ミ)
• 記事の更新はgitで適当に、自動的に

さぁ! こんな感じなんですがSpot Insntanceが死んで再び上がってくるとどうなっていたかというと!

• 起動したときのAMIからもう一度立ち上がったのでデータは全部巻き戻った
• 新しく8GBと20GBのEBSが確保されて新しいSpot Instanceにアタッチされた
• 古いSpot InstanceのrootのEBSはスパッと消えた(Delete On Terminationオン)
• 古いSpot InstanceのdataのEBSはavailableな状態で残った(Delete On Terminationオフ)
• EIPは自動で付かず、手でつけ直す必要があった

なるほどね! なるほどね! という感じでした。

となると、新しく起動してきたときにcrontabの@rebootにスクリプトを仕込んで、gitのrepoに取りにいって最新のデータをデプロイしてEIPを自分のインスタンスに付け替えるようにすれば大丈夫っていう感じなのかなー。あと、nginxのログが万が一必要になったら古いEBSから引っ張り出すようにすればOKですかね。そもそもnginxのログを保全する必要があるならS3に毎日送っちゃうのが無難ですけど。

そんなわけで、自分のサイトはAWSのSpot Instanceでいいんじゃねみたいな酔狂なことを考えてる人がいたら参考にしてみてはいかがでしょうか。まぁ正直落ちないにこしたことないのでもっと安い国産クラウドサーバーにするとか(たとえばちょうどIDCフロンティアが月500円からみたいなニュースリリースだしてましたね)、もしくはVPSにするとか、そういう感じで安定性を求めた方が楽だとはおもいます。