既存のシステムに対してこれからAmazon EC2 AutoScaling（以降はAutoScalingと記載）を導入するシステム運用者向けに導入判断のポイントについて書きたいと思います。
オートスケール（AutoScaling）の導入判断ポイント
この記事を読むとオートスケール導入すべきかどうかの判断ポイントが分かります。
オートスケール導入のメリットは何となく想像できると思うのですが、
-
突発的なアクセスや（キャンペーンなど）予測されるアクセス時の対応
-
手動スケール運用の工数削減
-
コスト（AWS利用料）削減
大体この３つだと思います。
デメリットはオートスケール導入や運用にかかる工数（大変さ）です。
クラウドなら簡単に導入できると思われているのか
「うちのシステムをオートスケール化しといて。すぐできるでしょ？」
と頼まれたのですが、躓きポイントがありました。
一般的にはメリデメを比較して導入するかどうかを判断すると思います。
本記事ではAutoScaling導入工数や導入後に発生する工数について記載しています。
※AutoScalngの機能については書きません。（基本的には思った通りに動いてくれましたので、、）
AutoScaling導入工数や導入後に発生する工数
アプリケーションリリース
リリース自動化がされているかどうかで運用工数が変わります。
自動化されていない場合はリリース毎に以下の運用が発生します。
- リリース完了後に最新のAMIを取得
- オートスケールに利用するAMIを最新に更新
ログ収集
ログ収集の仕組みにサーバ固有の設定（ホスト名など）がある場合はUser Dataで比較的簡単に設定ファイルの更新が可能ですが、ログ収集先にサーバ固有の設定がある場合は大変かもしれません。
設定ファイルにサーバ固有の設定がないか、あった場合はその設定を排除できないか確認しておきましょう。
監視
自動で監視設定追加する機能があるのが理想ですが、
そういった機能が無い監視製品ではオートスケールされたサーバの監視設定は以下のように行います。
- スケールアウト時はUser Dataで監視設定を追加
- スケールイン時はAutoScalingのライフサイクルフック機能を利用して、監視設定削除を実施
ジョブ
監視と同様でスケールアウト、スケールイン時に設定を追加する処理を検討する必要があります。
オートスケール対象サーバ
ELBのヘルスチェックだけでサービスインしてよいか判断できるかどうかで導入工数が大きく変わります。
ヘルスチェックだけではサービスインしてよいか判断できない場合は、User Dataで
サービスの正常性をチェックする必要があります。
又、サーバ固有の設定がある場合は、User Dataでの設定が必要になります。
まとめ
AWS Well-Architectedの設計の原則に沿っていれば上記の面倒な設定や運用は発生しません。
監視やジョブは自動で設定が行われ、オートスケール対象サーバに固有設定が無く、リリースの自動化が実現されていることがクラウド設計の原則です。
設計の原則に沿っていないシステム（月間100万PV以上の大手ECサイト）に
オートスケールを導入した経験を纏めさせていただきました。
オートスケール導入工数の見積に活かして頂けたら幸いです。