参考・注意
この記事は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の設定
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でアラームを設定
先ほど作成した、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接続)する。
負荷をかける
# 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台目のインスタンスが起動します。
負荷を解除する
# 負荷を解除するコマンド
# 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も削除