クックパッドのAWS活用術　1日10回デプロイする大規模サイトの裏側 （後編）

オートスケールはAmazon Auto Scalingを使わないと判断

　今日の本題であるオートスケールの話をしたいと思います。

　オートスケールとは一般に、トラフィックが増えたらサーバを増やしましょうね、という作業を自動化するものですね。


　なぜオートスケールをするのかというと、最大のトラフィックに合わせてインスタンスを立てっぱなしにすると、この点線のサーバも含めて9時間で45インスタンス分の課金になりますが、トラフィックに応じてオートスケールさせれば22インスタンス分で済むから、という考え方です。

　オートスケールを容易にするためにAmazon Auto Scalingがあります。これはCloudWatchのトリガーでインスタンスを立てたり落としたりするものです。


　ただ、僕らはAmazon Auto Scalingを使わずにオートスケールをやっています。理由の1つ目は、CloudWatchが1分ごとにしかリクエストカウントの値がとれないので、オートスケールの反応が1分遅れるためです。

　それからもう1つは勝手にGraceful Terminate問題と呼んでいるのですが、いまAmazon Auto Scalingがサーバをトラフィックに応じて10台から8台に減らしたとすると、これにELBが微妙に追随していなくて、落としたはずの2台にもトラフィックを振ってエラーになるんです。

　がんばればこれを安全な挙動にできるのですが、僕が触った感じではずいぶんプログラミングが必要です。

　そしてこれが最大の問題なのですが、最初に説明したとおり、僕らは1日に10回デプロイしていて、これがAmazon Auto Scalingとは相性が悪いんです。

　例えば、いまアプリのバージョン1（v1）がサーバに入っています。図の上にあるのはAmazon Machine Image（AMI）です。ここで開発者がv2をデプロイしている最中にAmazon Auto Scalingが動き出すと、まだAMIはv1のままなので、デプロイされたv2とAmazon Auto Scalingで展開されたv1が混在してしまうという問題があります。


　このためデプロイ作業とAmazon Auto Scalingの排他制御をしなくてはいけないのですが、Amazon Auto Scalingではインスタンスの増減をしようとするときにそれをフックして中断させるのは至難の業で、すごく難しい。

　そこでAmazon Auto Scalingは使わないでオートスケールを実装する方が良さそうだと判断しました。

オートスケールとデプロイを鍵で排他制御