【ハンズオン3】スケーラビリティのあるブログサービスを構築する

##今回の記事について
この記事はAWS初学者を導く体系的な動画学習サービス
「AWS CloudTech」の課題カリキュラムで作成しました。
https://aws-cloud-tech.com

##前回の続き
前回の記事の続きになります。
前回作成した環境に構築していきますので、まずはこちらをご覧ください。

https://qiita.com/wanidrums/items/9f08a6c6e62328f34cfa

##今回やること
・起動テンプレートの作成
・ELBの配下にAutoScalingGroupを紐付ける
・CloudWatchでAutoScalingのCPU使用率を監視するアラームの作成
（CPU使用率７０％以上、CPU使用率３０％以下）
・作成したアラームとAutoScalingのスケーリングポリシーを紐づける
・検証（意図的にEC2のCPUに負荷をかけてAutoScalingによりEC2が増減するか確認）


##環境

macOS Big Sur バージョン１１.２.２

##構成図

![hands-on3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1650745/5dde4b28-bc63-3154-d35a-fd91f1e83a83.png)

##起動テンプレートの作成（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インスタンス２台）に戻ってれば今回のハンズオンは終了。

お疲れ様でした。