大規模なオンラインサービスを支えるためのオートスケールと、サービスをすばやく進化させていくための迅速なデプロイ。クックパッドはこの2つをクラウド技術の組み合わせによって両立させています。同社のインフラ責任者である成田氏がその仕組みやルールを、Amazonクラウドのユーザーコミュニティ主催のイベントJAWS DAYS 2014で解説しました。本記事では、その講演内容をダイジェストで紹介します。
ただ、僕らは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は使わないでオートスケールを実装する方が良さそうだと判断しました。
