サーバーの拡張（スケール）方法
サーバー負荷状況に応じて拡張・運用する際に使用するのが、AWSのAuto Scalingという機能です。Auto Scalingにより、サイトの運用担当者が定義する条件に応じて、サーバー（EC2）を自動的に拡張あるいは縮小することができます。
Auto Scalingは、AWSマネジメントコンソールから設定できます。コンソールから[EC2]を選択し、ナビゲーションペインから[Launch Configurations]を選択してください。コマンドラインインターフェイスを使用する場合は、AWSコマンドラインインターフェイス（CLI）かAWS Tools for Windows PowerShellを選択しましょう。
詳細はこちらでご確認ください。
Auto Scalingでサーバーを拡張・運用するための方法は、主に以下の3つです。
手動スケーリング
もっとも基本的なのが手動スケーリングです。Auto Scalingグループの最大値、最小値、希望するサーバー容量の変更を指定します。手動スケーリングでは、Auto Scalingが、更新された容量を維持するために、インスタンスを作成、終了するプロセスを管理します。すぐに対応が必要な状況では、こちらが選択されることが多いです。
参考：手動スケーリング
http://docs.aws.amazon.com/ja_jp/AutoScaling/latest/DeveloperGuide/as-manual-scaling.html
スケジュールに基づくスケーリング
例えばLIGブログ上のキーワード（人名など）がテレビで取り上げられることが事前にわかっている場合、テレビの放送時間に合わせてグループのインスタンスの数をいつ増やし、いつ減らすかは、事前にある程度正確に予測可能です。
スケジュールに基づくスケーリングでは、日付と時刻に基づいて、自動的にスケーリングアクションが実行されます。
参考：スケジュールに基づくスケーリング
http://docs.aws.amazon.com/ja_jp/AutoScaling/latest/DeveloperGuide/schedule_time.html
要求（ポリシー）に基づくスケーリング
要求（ポリシー）に基づくスケーリングは、Auto Scalingプロセスを制御するパラメータを定義しておこなう、ちょっと高度な方法です。「平均CPU使用率が15分間にわたり90％を超えるとEC2インスタンス群の拡大を要求する」のように定義をすることにより、手動やスケジュールで間に合わない部分に対応できます。
特定の状況について、手動やスケジュールで対応することはもちろんできますが、ネックになるのはこれらの条件がいつ変化するかわからない場合です。このとき、あらかじめ予想できるリスクについて、Auto Scalingが応答するようにセットアップしておけるのが利点です。
具体的には、モニタリングするイベントごとに、スケールアウト（インスタンスの起動）とスケールイン（インスタンスの終了）を設定します。「ネットワーク帯域幅が一定のレベルに達するとスケールアウトする」ように設定したければ、まず増加したトラフィックに対処するためにAuto Scalingが特定の数のインスタンスを起動するように指定するポリシーを作成し、ネットワーク帯域幅レベルが元に戻ったときに特定の数だけスケールインするためのポリシーも作成しておきます。こうすれば、自動でネットワーク帯域幅の増減に対応できるのです。
参考：要求に基づくスケーリング
http://docs.aws.amazon.com/ja_jp/AutoScaling/latest/DeveloperGuide/as-scale-based-on-demand.html
LIGブログではこのように組み合わせています
LIGブログでは、基本的に「要求（ポリシー）に基づくスケーリング」をおこなっています。具体的には、CPUの利用率が30％を超えた状態が5分以上続いたら、新しいインスタンスの起動を要求するような設定です。逆に、インスタンスの終了は余裕をもっておこなうようになっています。
ですから、よほどのことがない限りインスタンスの増減を手動でおこなうことはありませんが、記事がバズッたり、TVで取り上げられるなどした際は、モニタリングをして手動で適切なインスタンス数に変更することもあります。
AWSの拡張・運用するときに注意したいこと
ここまで、Webサーバー構築で負荷に応じて自由自在に拡張・運用する方法をご紹介してきました。しかし、よく誤解されるのが「AWSはアウトソーシングサービスではない」ということです。Auto Scalingしかり、可用性を高める基盤設計は個別に実施しなければいけません。
アイレットの後藤さんからは大切なのは”障害は起きるもの”という前提をたてた上で「障害が起きたとき、いかに早く復旧させるか」「いかにスムーズに予備サーバーに移行するか」を検討することが重要です、と教えていただきました。障害の状況次第では、原因を調査・特定して復旧させるよりも、予備サーバーをすぐに起動させて、障害が発生したサーバーと入れ替えて復旧を優先する、といったクラウドサービスらしい障害対応を行うこともあるそうです。
例えば、LIGブログの場合は、トラブルが発生したときに、復旧にあたるエンジニアと、原因を調査するエンジニアをわけるように運用しています。このことによって、復旧は早くなり、予備サーバーへの移行もスムーズになるでしょう。しかし、ひとつネックになっているのは、夜間の対応が難しいということです。LIGは夜勤制ではないので、トラブルが発生した場合は、誰かが非常対応に当たるということになります。
このような場合については、多くのエンジニアさんも苦労されていると思いますが、やはりサイトを運用する企業は、専門のサービスを利用するのがいいのではないでしょうか。
AWSを有効活用する「cloudpack」
どれだけ対策しても、なかなか万全にはいかず、エンジニアの負担が大きいサーバー対策。そこでご紹介したいのが、「cloudpack」です！
cloudpackはAWSの導入設計、環境構築、運用・保守までをトータルでサポートするマネージドホスティングサービス。
上で紹介したようなAWSのサービスに関して、構築から24時間サポート・サービス監視までさまざまなサポートをおこなっています。
LIGブログでも突発的なトラフィック増加に耐えるように設定していますが、さすがに24時間100％守りつづけるのはなかなか難しいもの。今回ご紹介した方法でスケーリングをおこないつつ、補えない部分はこうしたサービスを活用してみるのも良いかもしれませんね。
