AutoScalingのインスタンスをどう扱うのか（デプロイ編）

AWS Advent Calendar 2013 の 5日目のエントリーです。ついでに独りでAdvent Calendarに挑戦中です。

　みんな大好きAutoScalingの話です。AWSのAutoScalingは負荷に応じてサーバ（EC2）を自動的に縮小・拡張することが出来る夢のようなサービスです。AutoScalingを上手く活用出来れば、急なアクセス増でサーバが耐え切れずSorryページを出すという残念な結果を防げます。実際に使っていて、ピークに合わせて自動的にサーバが増えて徐々にサーバが減っていく様子をグラフで見ると、AWS使ってて良かったなぁとしみじみと実感できます。
　しかし、JAWSUGなどでAWSを使い始めた人にAutoScalingを使っていると聞いても、使いたいのだけどまだ導入出来ていないという返事が多いです。何故でしょうか？幾つかパターンがありましたので、整理してみます。

AutoScalingを使わない理由

AutoScalingが必要な程、負荷が高くならない
ボトルネックの箇所の問題から、AutoScalingを利用しても問題が解決しない
AutoScalingより素晴らしい仕組みを作っているから
アプリケーションの構成管理の問題

　まず1番のAutoScalingが必要な程、負荷が高くならないというパターンですが、実はこれが一番多いようです。確かにそういうシステムも多いですね。その場合は仕方がないので、１台構成のAutoScalingで起き上がりこぼし的に自動復旧出来ますよとステマで終わることにしています。2番目のボトルネックパターンですが、よくある話としてDBサーバがボトルネックになっているのでAutoScalingでフロントエンドサーバが増えても困るというケースです。問題点が見えているのであれば、直しましょう。3番目のAutoScalingより素晴らしい仕組みパターンですが、AWSを使い込んでいる人によく見られるケースです。ManualScalingパターンやSWF-Scalingパターンなど先人たちの知恵に感謝して、パクれるものはパクってしまいましょう。最後の4番目のアプリケーションの構成管理の問題のパターン。実はこのケース、結構多いのではないかと思っています。今回は、このアプリケーションの構成管理問題を考えてみます。

AutoScalingにおけるアプリケーションの構成管理の問題

　ではAutoScalingにおけるアプリケーションの構成管理の問題とは何でしょうか？一言でいうと、AutoScalingで立ち上がったインスタンスに最新のアプリ（※）が入っているかという点です。AutoScalingは、AMIをベースに起動します。AMI内のアプリと最新のアプリの不一致だと問題ということですね。要は、最新のソースであることをどう保証するかです。ここがAutoScaling利用の最初の肝の部分であり壁でもあります。
※今回のケースの表現では、アプリの中にミドルウェアやソースなど包括的に含んでいるものとします。

AutoScalingにおける２つのデプロイパターン

　では、一般的にはAutoScalingを利用する際には、どうするのでしょうか？極論すると２つのパターンしかありません。アプリリリースの度にAMIを作成し直す方法と、インスタンス起動後に最新のアプリを落としてくる方法です。

　まずAMI再作成パターンですが、メリットとしては起動時に他のシステムに依存しないので障害発生ポイントが少なく確実性が高いという点とデプロイ待ち時間がないので早いという利点があります。これに対してデメリットとしては、AMIを常に最新の状態にする必要があるので運用の手間が掛かるという点があります。この点から、一般的にはAutoScalingのアンチパターンとされる向きもあります。これに対しては、詳細後述します。
　次にインスタンス起動後に最新のアプリを落としてくるパターンで、BootStrapなどと呼ばれています。起動時に最新の状態にする方法としては、cloud-initやcloud-boothookを使う方法があります。ChatWorkさんのこの記事で詳しく解説されているので一度ご覧くださればと思います。このパターンのメリットとしては、AMIの作成頻度が低いので、運用負荷が小さいことです。デメリットとしては、インスタンス立ち上げ後にアプリのデプロイをするので時間が掛かるという点です。単純にソースのデプロイだけであればそれほど時間はかかりませんが、Chefで構成もアップデートとまでなると時間が掛かるケースが出てきます。AutoScalingが発動する場合は、基本的にはリソースが逼迫している場合です。少しでもサーバがオンラインの状態にしたいので、この点が問題になるケースがあります。また、デプロイなどで他のリソースを参照する為に、その部分の障害でデプロイ出来ないというケースに対しての対応策を練り込んでおく必要があります。（この辺りを考慮したManualScalingというパターンもあります。）

AMIの作成をシステムに落としこむ

　上記のような説明をすると、じゃぁどっちが良いのという話が出てきます。どちらを選ぶかはケースバイケースなので一概には言えません。判断基準としては、システムの性質であったり開発運用しているチームの水準など色々な要素があります。またEC2のAutoScalingに拘らずとも、ElasticBeansTalkであったりdockerのような構築方法が出てきたりと状況は刻々と変わってきています。あまり理想を求めすぎると壁が果てしなく高くなるので、まずは出来る範囲から取り組むのが良いでしょう。
　私としてのお勧めは、AMIの作成をシステムとして落としこむことからだと思います。最近の潮流ですと、サーバの設定周りはChefのようなProvisioningツールで自動化するといった方法や、アプリのデプロイについてCapistranoやFablic，ant,mavenなどのツールを使うのが定番になっています。デプロイの自動化までの敷居は下がっているので、まずはそこに取り組みましょう。その後に後工程としてAMIの作成とAutoScaling対象の入れ替えスクリプトを付け加えれば、リリースまでの一連の流れをシステムに落とし込めることになります。デプロイ自動化まで出来る人であれば、問題なく出来るでしょう。
　デプロイの自動化なんて、まだまだ手をつけられないよという方も安心してください。その場合はリリース頻度は低いと想いますので、その都度手動でAMIを作っても問題はないはずです。

まとめ

　AutoScalingを使い出すと、最終的にはセッションやログを外出しにしてサーバをステートレスにしましょうとなります。ただ、いきなりそこまでやるとなると敷居が高すぎて一歩が踏み出せません。だから、まずはアプリのバージョンの保証の部分から取り組みましょう。後の部分は、運用始めてから順次考えいけばよいです。AutoScalingをもっと突き詰めていくと、安易にAutoScalingに頼るなとか、EC2部分を最小限にしてAWSの他のサービスで代替出来ないか考えよとか色々あります。しかし一足飛びには行きませんので、まずはAutoScalingを目指しましょう。AutoScalingが使えるということは、AWSを使いこなすという意味で重要なポイントだと思います。一段上を目指して、是非チャレンジしてみてください。enjoy!!

この他にもセッションやログの持ち方とかまとめたいことが沢山あるので、また機会を改めて書こうかと思います。