・需要に応じて自動的にサーバーが増減し、コストカット
Auto Scaling Group
・設定した最小値～最大値に起動インスタンスを収める
・起動台数をAZ間でバランシング
・AZ障害時は他のAZでインスタンス起動
Launch Configuration
・AMIやインスタンスタイプ、IAMなどを設定して起動する
Scaling Plan
・どのようにインスタンスを起動するか
①Auto Scaling Planの維持
最小台数を維持する。
Auto Healing：インスタンスに障害発生時に自動的にサービスから切り離し、健全なインスタンスをサービスイン
②手動管理
インスタンスを手動で変更
③スケジュールベース
CLI/SDKで定義
スケーリング開始は最大2分遅れる場合があるので注意
④動的スケーリング
監視：CloudWatchに応じたインスタンスの増減
上記の複数のプランを組み合わせることも可能
ヘルスチェック
①EC2ヘルスチェック：インスタンスのステータスがrunning以外を以上と判断
②ELBヘルスチェック
・ヘルスチェックの猶予期間がある。インスタンス起動からヘルスチェック開始までの時間。アプリケーションデプロイを考慮
・異常と判断されたインスタンスは自動的に終了
クールダウン
スケーリングアクション実行後指定した時間は次にスケーリングアクションを実行しない仕組み
→インスタンス初期化中の無駄なスケーリングを回避するため
※シンプルスケーリングポリシーにのみ対応
ターミネーションポリシー
①OldestInstance/NewestInstance：起動時刻
②OldestLaunchConfiguration：最も古いLaunch Configuration
③ClosestToNextInstanceHour：課金のタイミングが近い
④Default：②③の順に適用。複数インスタンスが残ればランダム
インスタンス保護
任意のインスタンスを削除されないよう保護できる
・インスタンスのデタッチ、アタッチ、スタンバイ
ライフサイクルフック
Auto Scalingの起動/終了時に一定時間（デフォルトは1時間、最大48時間）待機させ、カスタムアクションを実行できる
・スケールアウト時の初期化処理
①設定済みのAMIを用いる
②user-dataで初期化スクリプトを実行（Bootstrap処理）
③ライフサイクルフックで初期化
・サーバーをステートレスにする
ステートレス：サーバーにセッション情報などがない。スケールアウトに向いている
ステートフル：サーバーにセッション情報あり。常にサーバー間で同期が必要なので、スケールアウトに向いていない
・突発的なスパイクには向いていない
→インスタンス作成～アプリ起動の時間がかかるため。
対応策としては、
①CloudFrontなど大きなキャパシティを持ったAWSサービスに処理をオフロードする
②スパイクを裁くのを諦め、スロットリング機能（処理性能の上限）を設ける
③一定以上の負荷を超えたら静的ページに切り替える
・ユースケース
①ELB配下のWebサーバーをAuto Scaling
→EC2は複数AZに分散し、高可用性
ELBのリクエスト数、EC2の平均CPU使用率などがトリガー
②SQSのジョブを処理するWorkerをAuto Scaling
キューのメッセージ数などがトリガー
③Blue/Green
Blue/Green
デプロイ時に、既存のインスタンスとは違うインスタンスを作成し、一気に/徐々に作成したインスタンスを使用するようにする。
移行方法は下記
・DNSのWeighted round robinを使用して、徐々にトラフィックを移行
→DNSのTTLを考慮する必要あり。
・ELBを利用して、移行する
→Elastic Container Service(ECS。Dockerコンテナを格納する場所)を利用して、新しいインスタンスを作成することも可能
In place
デプロイ時に既存のインスタンスを操作することで対応する
参考URL：http://aws.typepad.com/sajp/2015/12/what-is-blue-green-deployment.html
Elastic MapReduce(EMR)
<Hadoop(分散処理をしてくれるソフトウェア)を動かせる環境を提供してくれるサービス
参考URL：http://mgi.hatenablog.com/entry/2014/05/04/085148
参考URL：https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2017-auto-scaling