●概要
起動設定または起動テンプレートを作成してからAuto Scalingを設置する。
Auto Scalingの設定からロードバランサーのターゲットグループに設定する。
●起動設定
なにをどのように起動させるか設定可能。
☆既存の起動設定は変更不可。
EC２からAMIを作成してAMIを登録する。
インスタンスタイプを選択可能
EBSも選択可能
スポットインスタンス選択可能
ユーザーデータも設定可能
セキュリティグループも設定可能
●起動テンプレート
起動テンプレートは起動設定の後継みたいな位置づけ
そのため、起動設定ではなく起動テンプレートを使うことがAWS推奨
●垂直スケーリングと水平スケーリング
・垂直スケーリング
スケールアップ:メモリやCPUの追加・ 増強
スケールダウン:メモリやCPUの削減・ 低性能化
・水平スケーリング
スケールアウト:処理する機器/サーバー台数を増加する
スケールイン:処理する機器/サーバー台数を低減する
☆スケールインは保護できる。
●スケーリングポリシー
⭐︎CloudWatchとの連携も可能
○動的なスケーリング
・簡易スケーリング
CPUが７０％いったらスケーリングするなど１つのメトリクスに対して１つの境界線を設ける設定をする。
・ステップスケーリング
簡易スケーリングの上位互換
メトリクスに対して複数の境界線を指定できる。
スケーリング動作後、数値が境界線に達した場合クールダウンと関係なく反応する。
５０％のCPU使用率の場合、６０％の場合と段階で処理が実行される。
CPU５０％の時は１台、CPU７０％の時は２台と作成してくれる。
50%で１台インスタンスが実行されている場合は70%の時、差分の１台が実行される。
・ターゲット追跡スケーリング
１つのメトリクスに関して目標値を設定する。
☆全体のCPU使用率を５０％を目標に設定するとそれに合わせてスケーリングすると設定ができる。
ステップアップスケーリングを違ってAWS側が管理してくれる。
○静的スケーリング
・手動スケーリング
希望する容量に合わせてスケーリングできる。
・スケジュールされたスケーリング
スケーリングする日付を指定してスケーリングする。
負荷が高まる時間がわかっているなら設定してプラスで動的スケーリングを入れる。
●ヘルスチェックと猶予期間
○ヘルスチェック
Auto sualingグループ管理対象下のインスタンスの動作をチェックして
異常が見られた場合に新しいインスタンスへ置き換える。
○Auto sualingのヘルスチェックは２種類
・EC2のヘルスチェック
インスタンスステータスがRun以外の状態を異常と判断
・ELBのヘルスチェック
ELBタイプでは、インスタンスのステータスチェックと
ELBのヘルスチェックからインスタンスの状態を判断します。
○猶予期間
すぐにそのインスタンスが利用可能な状態になる訳ではありません。
その間にヘルスチェックでエラーが出続けると困るので、
一定期間ヘルスチェックをしないという猶予期間があります。
●ウォームアップとクールダウン
◯クールダウン(別名:スケーリングクールダウン）
☆新しいインスタンスができるまでの待ち時間
☆Auto sualingが発動した直後に追加でインスタンスが増減されるのを防ぐため。
☆猶予期間がヘルスチェックであり、クールダウンはインスタンスの増減であるため。
デフォルト300秒
◯例外
スケジュールされたアクションやターゲット追跡またはステップスケーリングポリシーが開始された場合はクールダウン期間中でも発動する。
例：
CPUが80%を超えたため新しいインスタンスが追加される。
しかしクールダウンがない場合、インスタンス追加後2分は処理が開始できないため
CPUが80%を超えた状態が2分以上続く。
80%を超えているためインスタンスがさらに追加される。
ここでクールダウンを3分とすると、スケール後3分はスケールしない時間となる。
●暖気運転(プレウォーミング)
リクエストが瞬間的に増えたときの回避策としてあらかじめ急激なアクセス増が予想される場合に ELBの暖気申請を行い事前にELBをスケールしておきます。
申請項目にリクエスト数 （リクエスト/秒）やスループット (bit/秒)が存在。
●ライフサイクルフック
Auto Scalingグループによるインスタンスの起動時または削除時にインスタンスを一時停止してカスタムアクションを実行する機能で
例）
起動時にデータを取得してきたり、削除時にログやデータの退避の処理を追加するといった用途で使えます。
待機時間はデフォルトで1時間、最大で48時間まで設定できます。
Lambdaとの連携が可能
●終了ポリシー(ターミネーションポリシー)
スケールインの際に、インスタンスを削除するのか決める。
○設定
・デフォルト
AZ:1番多いインスタンスが配置されているazのインスタンスを削除する。
古いインスタンスが複数ある場合は次の課金発生が短いインスタンスを削除する。
課金発生が短いインスタンスが複数ある場合はランダム
・カスタム
AZ: 1番多いインスタンスが配置されているazのインスタンスを削除する。
全AZで同数のインスタンスが配置されている場合はランダムで削除する。
インスタンス:選択したAZのカスタムポリシー
・選択肢
OldestInstance もっとも古いインスタンス
NewestInstance もっとも新しいインスタンス
OldestLaunch Configuration もっとも古い起動設定にしているインスタンス
ClosestTo NextInstanceHour 次の課金が始まるタイミングがもっとも近いインスタンス
●auto scalingの挙動
・基本的な挙動
インスタンスが最も少ないAZで起動する
インスタンス起動が失敗した場合、起動が成功するまで別AZで起動する。
・再分散の実施
AZ間で不均等が起こると実施する。
不均等の原因のインスタンスを停止してリソース不足のAZへインスタンスを新規で起動する。
古いインスタンスを停止する前に新しいインスタンスを起動することでパフォーマンスの低下を防ぐ。
auto scalingの最大容量が近づくと分散処理が遅くなったり完全停止したりする。
これを回避するために一時的に最大容量を増やす(最大容量の10%または＋1)
●クロスゾーン負荷分散
例えばアベイラビリティーゾーンが2つあり、
各アベイラビリティーゾーンにターゲットノード（EC2インスタンス）の起動数に偏りがあっても
・インスタンスの起動失敗
24時間起動失敗でAmazon側が停止する
・インスタンスこと障害状態だと数分間リカバリーされるかチェックする。
リカバリーされない場合、新しいインスタンスを起動して障害状態のインスタンスを終了する。
・トラブルシューティングのステップ
auto scalingを停止してから調査を行うのが一般的。
☆サブネットの自動割り当てIPをオンにしないとIPが割り当てられない。