【AWS Cloud Watch】CloudWatchアラームによるCPU使用率監視とAutoScalingとの連携

##目標
CloudWatchアラームにEC2の標準メトリクス（CPUUtilzation）を監視させ、それが一定値を超えた場合にアラームを起動することで、AutoScaling内のインスタンス数を増加させるシステムを構築する。

##前提
・AutoScalingの基本的な概念や作成手順がある程度わかること。
（本記事ではAutoScalingの作成手順は要所のみとさせて頂いております）

##CloudWatchとは
各AWSサービス（EC2、ELB、RDS、S3、EBS）のリソース情報（例としてはCPU使用率、ディスクIO、ネットワークIO等など。これをCloudWatchでは**メトリクス**と呼びます。）収集を行い、
それをCloudWatchダッシュボード等で可視化させるサービスです。
**CloudWatchアラーム**を利用することで、メトリクス情報を監視し、監視条件として指定した**しきい値**を超過した場合、
アラームを発砲し**SNSによるメッセージ送信、AutoScalingアクション実行等の処理連携をすることが可能**となります。

##構成図
![cloudwatch (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/eb1767f9-c6de-1c30-0e1c-d843d98e1fd7.png)

##作業の流れ
| 項番 | タイトル |
|:----:|:-------------|
| 1 | [AutoScaling設定](#1autoscaling設定) |
| 2 | [CloudWatchアラームの設定](#2cloudwatchアラームの設定)|
| 3 | [システム動作確認](#3システム動作確認)|

##手順
###1.AutoScaling設定
要所のみの手順記載とさせて頂きます。

**①起動設定の作成**
**どのような構成（利用するAMIやインスタンスタイプ等）のEC2インスタンスをAutoScalingで利用するか**という設定を行うのが`起動設定`です（※）。
基本的に設定内容は自由ですが、安価かつCPU使用率を意図的に上げやすくするため低スペックの`t2.micro`を利用しています。
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/a464219c-76fc-2d85-0b2e-68337a8c601d.png)

※起動設定作成時の流れに関しては以下を参考
[AWS Auto ScalingとELBの組み合わせ（オートヒーリング構築）(1. 起動設定（Launch Configuration）作成)](https://qiita.com/aWdfcfG2jLr73pe/items/f388341d8e42392792f5#1-%E8%B5%B7%E5%8B%95%E8%A8%AD%E5%AE%9Alaunch-configuration%E4%BD%9C%E6%88%90)

**②AutoScalingグループの作成**
**どこ（どのVPCやAZに）にどんな規模（EC2インスタンスの台数等）のAutoScalingを構築するか**という設定が`AutoScalingグループ`となります。
AutoScalingグループに紐づかせる起動設定は前手順①で作成した設定
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/d18e89c6-c673-0d73-99be-8206cdda20ca.png)

本記事ではロードバランシングなしのAutoScalingとします。
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/8b505bd9-51ce-b746-d516-a2d4e111ad63.png)

AutoScalingグループ内に起動するEC2インスタンスの数は1-2台とし、通常時は1台稼働としました。
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/3aeeef7a-5308-166b-c449-30fcd80748ac.png)

`スケーリングポリシー`（どのようなタイミングでグループ内のEC2インスタンス数を増加or減少させるか）はグループ作成後設定を行います。グループ作成前段階では`なし`とします。
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/fc76e70e-c7fa-ed75-7494-9bf9d50ba199.png)

一通り作成を終えたら設定確認画面となりますので、問題なければ`Auto Scalingグループを作成`
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/02384d8e-cb91-e395-8a9a-86e16fd5ac6e.png)

作成されたAutoScalingグループを選択し詳細画面遷移後、起動設定及びAutoScalingグループの設定が正しければ、
`インスタンス管理`画面で以下のようにEC2インスタンスが1台自動作成される想定です（※）。

※もし作成されない場合、以下画面内の`アクティビティ`からAutoScalingのログを確認可能です（筆者は起動設定で適当に選んだAMIが対象のAZでサポートされてなく起動不可となってしまった事例あります。。）。

![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/f9a883b8-6d0f-1af0-945f-4f1550fce345.png)

次に設定を保留したスケーリングポリシーの設定を行います。
作成されたAutoScalingグループを選択し詳細画面を表示後、`自動スケーリング`⇒`ポリシーを追加`をクリック
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/b6506570-d3b4-50eb-0cc9-680e6427faee.png)

ポリシータイプを`シンプルなスケーリング`とし、スケーリング時のアクションは`1キャパシティユニットを追加`とします。

![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/0714e893-5d32-aa0a-7056-f52240ef87db.png)

###2.CloudWatchアラームの設定
**①CloundWatchアラーム作成開始**
[CloudWatchコンソール](https://ap-northeast-1.console.aws.amazon.com/cloudwatch/)の左リスト内から`アラーム`をクリック
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/c49a196e-885a-b218-b3d7-33d86768d6d6.png)

更に`アラームの作成`をクリック
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/9cd76f50-bccb-4235-e918-0a0cbe948947.png)


**②CloundWatchアラームの詳細設定**
**メトリクスと条件の指定**
`メトリクスの選択`をクリック
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/3178cbf9-73bc-892b-00f0-a0ae0b4c8a1e.png)

EC2用のメトリクスを監視します。
`すべてのメトリクス`内にある`EC2`をクリック
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/b34f994e-2e0b-4628-70f9-0b41662be63a.png)

本記事ではAutoScalingグループ内に存在する全インスタンスのメトリクスを監視したいため、
`Auto Scalingグループ別`をクリック
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/a9b42642-4df3-2e5b-adcf-6c81f7c0cc0c.png)

作成したAutoScalingグループのメトリクス`CPUUtilization`（CPU使用率）をチェックし、CloudWatchアラームの監視対象として設定します。
チェックしたら`メトリクスの選択`をクリック
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/50403c07-f764-c48d-0d82-a3f7917dc121.png)

次にCloudWatchアラームを起動する際のトリガー条件を設定していきます。
今回は`1分間の平均値`をトリガーの基準とします。
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/3e9f62bd-84b0-c19e-43fa-dc5611f8e1ae.png)

CPU使用率が`80%よりも大きい場合`というトリガー条件とします。
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/e845ab5c-be08-7ed5-3b83-35ac3b1d8db4.png)


**アクションの設定**
CloudWatchアラームが起動した際にSNSによるメッセージ通知も可能ですが、今回は設定なしとします。
`削除`をクリック
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/4e54876c-e34d-7892-4dc8-23623c1e0a79.png)

CloudWatchアラーム起動時のAutoScalingアクションを設定します。
`Auto Scalingアクションの追加`をクリック
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/30c7c34e-7f14-2516-6fcf-abfbb02942d0.png)

CloudWatchが`アラーム状態`のとき、`前手順で作成したAutoScalingグループの1インスタンス追加アクションを実行する`という設定をします。
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/b220b8b5-ff08-168d-9306-40183c3b5143.png)

**名前と説明を追加**
任意のCloudWatchアラーム名を入力します。
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/f21445b1-ccb5-8daa-bc85-e9253e2187a3.png)


**プレビューと作成**
内容に問題なければ`アラームの作成`をクリック
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/103a3764-e2b4-1f6e-6584-eeef12ea39c9.png)

**③アラームの簡単な動作確認**
作成したCLoudWatchアラームの挙動を軽く確認します。
作成したCloudWatchアラーム詳細画面の`履歴`から対象アラームの動作履歴が確認可能です。
`データ不足`（アラームの状態を確定するためのデータが不十分であることを示す）と`OK`（アラームの監視条件として指定したしきい値をクリア（※）していることを示す）を行き来していれば問題ございません。

※今回で言えばAutoScalingグループ内の全EC2インスタンスのCPU使用率が80%以下

![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/233c7b1d-3b0e-0532-939f-12639b1a382a.png)

###3.システム動作確認
**①CPU使用率上昇用スクリプト実行**
作成したAutoScalingグループ内に存在するEC2インスタンスにOSログイン後、以下のスクリプトを作成します。

```bash:loop.sh

#!/bin/bash

while true
do
  # 存在しないコマンドを繰り返し実行
  invalidcommand
done
```

スクリプト実行（実行後Command not foundが繰り返し出力されます。停止するにはctrl+Cを実行します）

```bash

source loop.sh
```

別ターミナルを開き`vmstat 5`を確認すると、ユーザプロセス(us)とカーネル(sy)のCPU使用率を合わせた値が100%となっていることが分かります。

```

[ec2-user@ip-172-31-33-157 ~]$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 492464   2088 432648    0    0    36    42  227  567  2  3 95  0  0
 1  0      0 493180   2088 432648    0    0     0     4 5631 13709 34 66  0  0  0
 1  0      0 491980   2088 432648    0    0     0    25 5572 13708 36 64  0  0  0
 1  0      0 493056   2088 432648    0    0     0     0 5234 13960 36 64  0  0  0
 1  0      0 492808   2088 432648    0    0     0     0 5709 13962 37 63  0  0  0
 2  0      0 492808   2088 432648    0    0     0     0 5726 13955 35 65  0  0  0
```

**②CloudWatchアラームの確認**
CloudWatchアラームを確認すると状態が`アラーム`（アラームの監視条件として指定したしきい値を超過していること）となり、履歴からそれに伴いAutoScalingアクションが実行されたことが分かります。
![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/93323387-0a61-2fb1-ab31-7cfedcc66f1e.png)

**③AutoScalingグループ確認**
一応AutoScalingグループも確認すると、AutoScalingアクションの実行によってグループ内のインスタンス数が1台から2台になっていることが確認できれば、システムの動作はOKです。

![tempsnip.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647616/794b50ca-42e6-b803-8500-d28ffffb62be.png)