##今回の記事について
この記事はAWS初学者を導く体系的な動画学習サービス
「AWS CloudTech」の課題カリキュラムで作成しました。
https://aws-cloud-tech.com
##前回の続き
前回の記事の続きになります。
前回作成した環境に構築していきますので、まずはこちらをご覧ください。
##今回やること
・起動テンプレートの作成
・ELBの配下にAutoScalingGroupを紐付ける
・CloudWatchでAutoScalingのCPU使用率を監視するアラームの作成
（CPU使用率７０％以上、CPU使用率３０％以下）
・作成したアラームとAutoScalingのスケーリングポリシーを紐づける
・検証（意図的にEC2のCPUに負荷をかけてAutoScalingによりEC2が増減するか確認）
##環境
macOS Big Sur バージョン１１.２.２
##構成図
##起動テンプレートの作成（AutoScalingで起動するEC２インスタンスの設定）
＊起動設定でも出来ますが、Amazonは起動テンプレートの利用を推奨しているようです。
EC2コンソールを開き、左ペインからテンプレートの起動を選択
↓
起動テンプレートを作成
起動テンプレート名： LaunchTemplate1 （任意の名前）
テンプレートバージョンの説明：1.0.0 （任意）
AutoScalingのガイダンス: このテンプレートをAutoScalingで使用するのでチェックを入れる
AMI：以前のハンズオンで作成しているEC2を設定
インスタンスタイプ：検証用であれば無料枠でOK
キーペア：すでに作成してあるものを使用
セキュリティグループ：後で設定するのでここでは空白でOK
リソースタグ：リソースタイプをインスタンスに設定すると、AutoScalingによって立ち上がったインスタンスにタグ付けできる
ネットワークインターフェイスの設定
セキュリティグループ：既存のEC2に紐付けているものと同じSGを選択
パブリックIPの自動割り当て：有効化
他デフォルトで起動テンプレートの作成
＊ちなみに既存のEC2を選択してアクション→イメージとテンプレート→インスタンスからテンプレートを作成から簡単に作れます。
##ELBの配下にAutoScalingGroupを紐付ける
前回までのハンズオンで作成したEC2２台を停止しておく。RDSは起動してる状態。
####AutoScalingGroupの作成
####ステップ１ 起動テンプレートまたは起動設定を選択する
Auto-Scaling グループ名：Test-AutoScaling1 （任意）
起動テンプレート：先ほど作成した起動テンプレートを設定
####ステップ２ 設定の構成
インスタンスの購入オプション：起動テンプレートに準拠する
VPC、サブネット選択
（今回の場合、パブリックサブネット２つ選択）
####ステップ３ 詳細オプションを設定
ロードバランシング：前回までのハンズオンで作成したELBのターゲットグループを設定
ヘルスチェック：ヘルスチェックのタイプをELBにチェックを入れる
その他の設定（モニタリング）：後で変更できるのでひとまず飛ばして次へ進む
####ステップ４ グループサイズとスケーリングポリシーを設定する
希望する容量：2 (任意)
最小キャパシティ：2 (任意)
最大キャパシティ：4 (任意)
スケーリングポリシー：後から設定するのでひとまず飛ばして次へ
####ステップ５ 通知を追加
AutoScaling内のEC２が起動、終了するたびに、SNSなどで通知が欲しければ設定する
####ステップ６ タグを追加
任意で設定
####ステップ７ 確認
確認して問題なければ作成
＊作成後、現在EC2を２台とも停止してるので、AutoScalingで設定した希望する容量２台を維持するために、起動テンプレートで設定した２台のEC2インスタンスが新しく起動される。
##CloudWatchでAutoScalingのCPU使用率を監視するアラームの作成
作成するアラーム
・CPU使用率が７０％以上になった場合に起動するアラーム
・CPU使用率が３０％以下になった場合に起動するアラーム
早速、CloudWatchコンソール画面で、アラームの作成を選択
####ステップ１ メトリクスと条件の指定
メトリクスの選択⇨EC2⇨AutoScalingグループ別⇨先ほど作成したAutoScalingのCPU Utilization⇨メトリクスの選択
統計：平均値
期間：５分（デフォルト）
しきい値の種類：静的
アラーム定義：７０ より大きい
その他の設定：欠落したデータを不正（しきい値を超えている）として処理
＊CPU使用率が極端に高まると、EC２がCloudWatchにメトリクスを送れないと予想されるから
####ステップ２ アクションの設定
SNSトピックで作成したメールアドレス宛に通知が届く設定
（SNSトピックを作成してなければ作成する）
####ステップ３ 名前と説明を追加
アラーム名：CPU_high（任意）
####ステップ４ プレビューと作成
確認して問題なければ作成
＊省略
もう一つのアラーム（CPU使用率３０％以下）も同じように作成しましょう。
（設定）
アラーム定義：３０ より小さい
その他の設定：欠落データを見つかりませんとして処理
アラーム名：CPU＿low（任意）
＊設定後のステータス
CPU＿high OK
CPU＿low アラーム状態
となっていることを確認する
##作成したアラームとAutoScalingのスケーリングポリシーを紐づける
作成したAutoScalingのタブ⇨自動AutoScaling⇨スケーリングポリシー⇨ポリシーを追加
ポリシータイプ：シンプルなスケーリング
スケーリングポリシー名：CPU＿add（CPU_remove）
CloudWatchアラーム：CPU＿high(CPU_low)
アクションを実行：追加(削除) １ キャパシティユニット
スケーリングアクティビティを許可するまでの秒数：３０（任意）
highとlowのスケーリングポリシーをそれぞれ作成する
これでアラームに応じてAutoScalingによるEC2インスタンスが増減する仕組みができた。
##検証（意図的にEC2のCPUに負荷をかけてAutoScalingによりEC2が増減するか確認）
・どちらか片方のEC2インスタンスへssh接続する
・EC2インスタンスに負荷をかける
負荷をかけるコマンド：yes >> /dev/null &
＊４つほど実行する
・Linuxサーバーの負荷を確認する
Linuxサーバーの負荷を確認するコマンド：topでCPU使用率を確認できる
（抜けるにはctrl+c）
＊もう一つのインスタンスでも同じように負荷をかける
しばらくしてAutoScalingのグラフを確認するとCPU使用率が高まってるのが確認できる
また、設定したCloudWatchアラームのCPU＿highもアラームになってるのがわかる
さらに、EC2インスタンスが新しく立ち上がっているのが確認できるはず
（AutoScalingグループのアクティビティログでも確認できる）
＊負荷がかかってる以上、設定した最大インスタンス数までインスタンスが立ち上がる
####負荷を戻す
再びインスタンスに戻り、先ほど負荷をかけたyesコマンドをkillする
kill プロセスIDで負荷を解除できる
＊kill {3974..3977}とすれば複数のIDをまとめて解除できる
最後にtopコマンドでCPU使用率が０％になっていることを確認
＊もう一つのインスタンスでも同じように解除する
しばらくするとCPU使用率が３０％を下回り、インスタンスが削除される動きになるが、ELBのConnection drainingの設定（デフォルトで３００秒後）により、その時間経過後に削除される。
＊ELBのConnection drainingとは
ELBから何らかの理由（障害など）でEC2が切り離されると、設定した時間経過後にEC2が削除される。
急に削除するとサーバーを使用しているユーザーに迷惑がかかるためこの機能がある。
（AWS SAAやSOAの資格試験にも出ます）（１〜３６００秒の間で設定可能）
最終的に希望の容量（EC2インスタンス２台）に戻ってれば今回のハンズオンは終了。
お疲れ様でした。