- 会員限定
- 2014/03/31 掲載
クックパッドのAWS活用術 1日10回デプロイする大規模サイトの裏側 (後編)
ITジャーナリスト/Publickeyブロガー。大学でUNIXを学び、株式会社アスキーに入社。データベースのテクニカルサポート、月刊アスキーNT編集部 副編集長などを経て1998年退社、フリーランスライターに。2000年、株式会社アットマーク・アイティ設立に参画、オンラインメディア部門の役員として2007年にIPOを実現、2008年に退社。再びフリーランスとして独立し、2009年にブログメディアPublickeyを開始。現在に至る。
オートスケールはAmazon Auto Scalingを使わないと判断
今日の本題であるオートスケールの話をしたいと思います。オートスケールとは一般に、トラフィックが増えたらサーバを増やしましょうね、という作業を自動化するものですね。
なぜオートスケールをするのかというと、最大のトラフィックに合わせてインスタンスを立てっぱなしにすると、この点線のサーバも含めて9時間で45インスタンス分の課金になりますが、トラフィックに応じてオートスケールさせれば22インスタンス分で済むから、という考え方です。
オートスケールを容易にするためにAmazon Auto Scalingがあります。これはCloudWatchのトリガーでインスタンスを立てたり落としたりするものです。
それからもう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は使わないでオートスケールを実装する方が良さそうだと判断しました。
オートスケールとデプロイを鍵で排他制御
今すぐビジネス+IT会員にご登録ください。
すべて無料!ビジネスやITに役立つメリット満載!
-
ここでしか見られない
1万本超のオリジナル記事が無料で閲覧可能
-
多角的にニュース理解
各界の専門家がコメンテーターとして活躍中!
-
スグ役立つ会員特典
資料、デモ動画などを無料で閲覧可能!セミナーにご招待
-
レコメンド機能
あなたに合わせた記事表示!メールマガジンで新着通知
関連タグ
PR
PR
PR