この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
こんにちは植木和樹です。既存システムのAWS移行の仕事などをやっていると、移行時にAutoScaling構成にすべきかどうか？という検討をする機会があります。AutoScalingにしておくと高負荷や障害にも強いシステムが構成できるのですが、システム移行となると色々と既存構成を変更しなければならないことが多いです。
そこで今回はこれまで関わった案件でAutoScaling化する上で検討しなければならなかった点を、頭の中の整理を兼ねてまとめてみました。
AutoScalingとはなにか？
「Auto Scaling （仮想サーバーAmazon EC2 の処理能力の自動拡張・縮小機能）| アマゾン ウェブ サービス（AWS 日本語）」では3つのユースケースが紹介されています。
- Amazon EC2 群を自動的に縮小・拡張
- 規模を固定して Amazon EC2 群を管理
- Elastic Load Balancing での Auto Scaling
つまりAutoScalingを用いる理由は「負荷分散」と「可用性向上」の2つ、といえます。
AutoScalingはCloudWatchと連携して、EC2のCPU負荷やELBのリクエスト数の増減に応じてインスタンス数を増減します。時間帯や曜日、季節によって負荷が大きく変化するサイトでは自動拡張・縮小機能が有効です。
AutoScalingはDesiredCapacityというパラメーターで指定した台数にEC2を維持しようとする機能があります。障害でEC2のインスタンスが不安定（UnHealthy）になった場合はAutoScalingはそのインスタンスを「あきらめ」、新しいインスタンスを自動的に起動してEC2群に組み込みます。こうすることで常に固定台数のインスタンスを維持することができ、サービス障害を回避することができます。
AutoScalingでのEC2構成上注意すること
いいこと尽くめのAutoScalingですが、起動されるEC2側では構成上注意しなければならない点があります。これを一言でいうと「EC2は使い捨てられるようにする」です。言い方を変えると「EC2に状態を持たせない」「ステートレス化」ということです。
EC2はいつでも捨てられるようにする
不安定になったEC2はいつでも捨てられる（Terminateできる）よう内部にデータは保持しないことが重要となります。データを保持していると不安定になった際にインスタンスがTerminateされて、なくなってしまいます。ここでいうデータには次のものが考えられます。
- アプリケーションで生成された永続的に保管すべきデータ
- アップロードされた画像ファイルなど
- HTTPなどのセッションデータ
- ApacheやTomcatなどのログファイル
- /var/log/messages などOSのログファイル
不安定（UnHealthy）になったEC2はAutoScalingによって自動的にTerminateされます。注意してもらいたいのはAutoScaling下のEC2はインスタンスのSTOPができなくなる、ということです。そのため構築途中の環境ではAutoScalingを使わないのが良いでしょう。（AutoScalingのsuspend/resumeを使うことで状態チェックを無効にすることもできます。Suspend and Resume Auto Scaling Process - Auto Scaling）
EC2は起動したらすぐに使える状態にする
前述したようにAutoScalingは負荷やEC2の状態に応じて自動的にインスタンスを起動します。この時起動が終わったインスタンスは、ジョブ（HTTPリクエストなど）を処理可能な状態になっていなければいけません。
この「ジョブが処理可能な状態」というのはアプリケーションの作りに大きく依存する部分があります。そのためインフラ担当者だけでなく、アプリケーション開発者にも「使い捨て」の考え方を理解してもらう必要があります。
- 素のAmazon Linuxから始めて、アプリケーションとして処理可能な状態になるまでにどのような設定過程が必要か
- AutoScalingで起動するEC2は、その過程のどの時点の状態にしておくか（ある状態をAMI化する、など）
- EC2起動後に最新の状態にするために、どのような仕組みにしておくか（起動後にS3から最新ファイルをダウンロードして自動展開する、など）
「稼働中にEC2のプログラムをバージョンアップしたけど、AutoScalingで起動されたEC2に反映されてなかったためデグレージョンしてしまった」というトラブルがないように気をつけましょう。
まとめ
2013年12月に、いよいよAutoScalingがマネージメントコンソールに対応しました。
Amazon Web Services ブログ: 【AWS発表】AWS Management Console が Auto Scaling をサポート
これまではコマンドラインツールやCloudFormationからしか操作できなかったので導入までの敷居が高かったかもしれませんが、GUIで操作できるようになったことでより手軽に設定ができるようになっています。
たとえサーバー1台でもAutoScalingを使うことで「1日のある時間帯だけ起動するサーバー」や「障害が発生すると自動復旧するサーバー」といった構成も組むことができます。まずはEC2をステートレスにできないか検討したうえでAutoScalingの導入を進めていってはいかがでしょうか？
下記は私が考えたAutoScaling応用例です。あわせて参考にしていただければと思います。
3
