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

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

(注意)このハンズオンでは料金が12~13円/時間発生します。

##内容
ELBの配下にAutoScalingグループを紐付けて、EC2インスタンスを希望2、最小2、最大4の範囲でスケーリングさせる。
AutoScaling全体のCPU使用率を監視するアラームを2つ作成。1つめをCPU使用率70%以上,2つめをCPU使用率を30%以下のアラームです。
アラームとAutoScalingポリシーを紐付けます。

**目的**
一時的にEC2に負荷をかけてEC2インスタンスが自動的に増減される動きを確認します。

##AutoScalingの設定

https://qiita.com/tr76aquarius/items/6b76baaab54e152ce6ed#%E6%A6%82%E8%A6%81

EC2<AutoScaling<AutoScalingグループを選択、
グループを作成

**ステップ１**
名前を入力(=Test-AutoScaling1)
起動テンプレート(=以前の講座で作成した物を選択)を設定
バージョンをLatestを選択(最新のもの)
次へ

**ステップ２**
EC2インスタンスを起動する際の購入オプション(通常のオンデマンド)で設定

ネットワーク
EC2インスタンスをどのVPCサブネットで起動するか(2つ選択)

**ステップ３**
詳細オプション
ロードバランシングの有効化を選択
Application Load Balancerのターゲットグループを選択(TG1)

ヘルスチェック
EC2のステータスチェック、インスタンスを立ち上げた際2/2のチェックが合格したかというチェックのみ
ELBにチェックを入れる(ELBのHTTP80番ポートのヘルスチェックを追加)

その他の設定
モニタリング
後から変更できるので一旦空白で可

**ステップ4**
グループサイズ
希望容量2
最小キャパシティ2
最大キャパシティ4に設定

スケーリングポリシー
CloudWatchアラームと後から紐づけるので一旦なしに設定

インスタンスのスケールイン保護
CPU使用率が低下した際EC2が削除される一般の動きを、削除しないように設定できるチェックボックス(=有効にしない)
次へ

**ステップ５**
通知の設定もできる

**ステップ６**
AutoScalingにタグを追加できる
今回はなし

**ステップ７**
確認と作成

作成完了するとEC2インスタンスを確認した際既に今回作成したEC2インスタンスが2つ起動されています。

###AutoScaling 動作テスト
　AutoScalingグループを作成した際に起動したEC2インスタンスを試しに終了してみて稼働しているインスタンスを1つに減らしてみます。
　すると、AutoScalingグループのアクティビティ<アクティビティ履歴にELBのヘルスチェックに失敗した履歴が表示されます。
　その後、設定した希望する容量と実際のキャパシティに差があるとAutoScalingが検知し、EC2インスタンスが起動したと表示されます。

結果
→ インスタンスの一覧を見ると新しくEC2インスタンスが立ち上がっていることを確認できます。

##CloudWatchでアラームを設定

https://qiita.com/tr76aquarius/items/86d98cd9839af63f89a7　

　先ほど作成した、AutoScalingグループに紐づいている２台のEC2インスタンスの使用状況(平均のCPU使用率)によって ↓ 
・CPU使用率が70%以上ならEC2インスタンスを1台追加
・CPU使用率が30%以下ならEC2インスタンスを1台削除
このアラームをCloudWatchで設定

CloudWatch<アラーム<アラームの作成

**ステップ1**
メトリクスと条件の指定
メトリクスの選択ではどのグラフを選択するかという意味で
AutoScaling機能はEC2<AutoScalingグループ別を選択
AutoScalingグループ名(Test-AutoScaling1)のメトリクス名(CPUUtilization)をチェックし、メトリクスの選択をクリック

統計→ 平均値
期間→ 5分

※条件※
しきい値の種類→ 静的
CPUUtilization(CPU使用率)が次の時では
70 より大きい
時発動するといった設定ができます。

その他の設定で欠落データの処理
CPU使用率が極端に高まると、EC2インスタンスがメトリクスをCloudWatchに送れない事態が予想されるので
欠落データを不正(しきい値を越えている)として処理を選択して

次へをクリック

**ステップ2**
アクションの設定
通知
アラームが発生した際の通知先にSNSを指定する

次へをクリック

**ステップ3**
名前と説明を追加
アラーム名(=CPU_High)

次へをクリック

**ステップ4**
プレビューと作成

アラームの作成をクリックすると作成される

同じようにCPU使用率が30%よりも低い条件、欠落データを見つかりませんとして処理を選択、アラーム名(CPU_Low)として作成

しばらくするとCPU_HighがOK、CPU_Lowがアラーム状態と表示されることを確認してください。

##スケーリングポリシーにCloudWatchのアラームを紐付ける
EC2<AutoScalingグループ<名前がTest-AutoScaling1を選択<自動スケーリングを選択
現在スケーリングポリシーは指定されていませんと表示があると思うのでポリシーを追加をクリックし作成します

ポリシータイプ=シンプルなスケーリング
スケーリングポリシー名=CPU_add
CloudWatchアラーム=CPU_High
アクションを実行=追加、1,キャパシティユニット(EC2インスタンスのこと)
発動後に何秒間待機できるか指定できる(=30秒)
作成をクリック

今度はCPU_Lowの条件でポリシー(名前をCPU_remove)を作成

##テスト
EC2インスタンス<接続<インスタンスに接続<EC2 Instance Connectを使用しブラウザでログイン(SSH接続)する。
###負荷をかける

```console
# Linuxサーバーの負荷を確認するコマンド
top
# 今回確認箇所が上部の%Cpu(s):

# topコマンドから抜けるには
ctrl + c

# 負荷をかけるコマンド
# (ひたすらyesを出力し続けるコマンドで/dev/nullにリダイレクト(=>>)する(&=バックグラウンドで))
yes >> /dev/null &

# 4回ほど負荷をかけるコマンドを実行した後topコマンドで確認するとCPU使用率が高まります。
# 同じようにもう一つのEC2インスタンスに接続し、この負荷をかけるコマンドを数回実行します。
```

アラーム確認
CloudWatch<メトリクスでメトリクスのグラフを確認
EC2<AutoScalingグループ<グループ名=Test-AutoScaling1,メトリクス名=CPUUtilizationを確認
CPU使用率が高く表示され、CloudWatch<アラームでもCPU_Highがアラーム状態になったのを確認したら,AutoScalingが発動しEC2インスタンスが新しく起動しているのが確認できます。

AutoScalingグループのアクティビティ履歴にログが出ています。
希望する容量が2→ 3に書き変わっているのが確認できます。
更に時間が経つと3→ 4になり、4台目のインスタンスが起動します。

###負荷を解除する
```console
# 負荷を解除するコマンド
# topコマンドで動いているプロセスのIDを確認し,killコマンドで停止できる
kill PID

# 連番時は{}が使用でき、まとめて削除できる
kill {〇〇..××}

# もう一つのEC2のyesコマンドも停止させるのを忘れずに
```

5分経過するとCPU使用率が落ち着いてきます。
CloudWatch<アラーム<CPU_HighのアラートがOKに変更されます。

更に待つとCPU使用率が低くなるのでCPU_Lowがアラーム状態になります。
低くなるとEC2インスタンスがすぐ削除されるわけではなく、AutoScalingグループの希望する容量が4→3、3→2に変更されているが、まだインスタンスは削除されていません。これは、ロードバランサー<ターゲットグループ<グループの詳細の属性に登録解除の遅延が300秒とあります。ターゲットを確認するとステータスがdrainingとなっています。ELBの配下のインスタンスをいきなり引き剥がすと、そこにアクセスしていたエンドユーザーに影響が出るので猶予期間がある状態のことをdrainingといいます。

##テスト終了(後始末)
このまま稼働しているEC2を削除しても、AutoScalingによって自動的にEC2インスタンスが作られるので、先にAutoScalingを削除しておきます。削除後にEC2インスタンスを削除しましょう。
CloudWatchアラームもアクションから手動削除
スナップショットを撮った上でRDSも削除