【AWS_27】ハンズオンの検証_Amazon EC2 Auto Scaling

AWSのハンズオンに、EC2、RDS、ELB、Wordpressを構築した環境を流用して「Amazon EC2 Auto Scaling」を体験できるとありましたので検証してみたいと思います。
AWSのハンズオン(EC2、RDS、ELB、Wordpressの構築)は、以下の記事にまとめています。
Auto Scaling を使用することで、ワークロードに応じて EC2 インスタンス の数を自動的に スケールアウト(サーバ台数を増やす)・スケールイン(サーバ台数を減らす)させる方法を体験できるそうです。以下の記事を参考にしました。
EC2 Auto Scalingハンズオン
https://catalog.us-east-1.prod.workshops.aws/workshops/47782ec0-8e8c-41e8-b873-9da91e822b36/ja-JP/advanced/autoscaling
【構成図】

目次
IAM ロール の作成
今回は、EC2インスタンスのCPU利用率を意図的に上げて、Auto Scalingの発動を確認します。
CPU利用率を意図的に上げるための事前準備して、AWS Systems Manager 用の IAM ロール を作成します。
検索ボックスに 「ロール」 と入力し、「ロール」をクリックします。
「ロールを作成」 をクリックします。

信頼されたエンティティタイプは、「AWSのサービス」を選択します。

ユースケースは、EC2 インスタンス にロールをアタッチするので、「EC2」 を選択し、「次へ」をクリックします。

検索ボックスに 「AmazonSSMManagedInstanceCore」 と入力して「Enter」を押下します。
表示されたポリシーにチェックを付けて、「次へ」をクリックします。

ロール名 に 「access_ssm_role_handson」 と入力します。
※「AmazonSSMManagedInstanceCore」 は、AWS Systems Manager (SSM) によって管理されるEC2インスタンスやオンプレミスサーバーなどのリソースに、特定の権限を付与するためのIAMロールの名前です。このロールをアタッチすることで、SSMエージェントがこれらのリソースを管理できるようになります。
ステップ 1~ステップ 3は、デフォルトのままで「ロールを作成」をクリックします。

IAM ロール 「access_ssm_role_handson」 が作成されていることを確認します。

Amazon EC2 Auto Scaling で負荷調整の自動化
下図のように、二つの Auto Scaling グループ を作成していきます。
CPU 使用率の平均値の変更により、Amazon EC2 Auto Scaling でEC2インスタンスの数が自動的にスケールアウト、スケールインされるよう設定していきます。
EC2インスタンスは、CPU使用率の状況により2台から4台(スケールアウト)、4台から2台(スケールイン)するようになります。

Auto Scaling の起動テンプレート作成
検索ボックスに EC2 と入力し、表示された「EC2」をクリックします。
起動テンプレート を選択、起動テンプレートを作成 をクリックします。

起動テンプレートの名前として launchtemplate-ユーザ名 と入力します。(例:launchtemplate-user1)
EC2 Auto Scaling で使用できるテンプレートをセットアップする際に役立つガイダンスを提供 にチェックを付けます。

「アプリケーションおよびOSイメージ(Amazon マシーンイメージ)- 必須」の「自分の AMI」タブをクリック、「自己所有」を選択、Amazon マシンイメージ(AMI) にハンズオンで作成した AMI を選択します。(例:wordpress-user1)
「インスタンスタイプ」 に、「t2.micro」 を選択します。

キーペア(ログイン)は、デフォルトのままとします。

「サブネット」は、デフォルトのまま(起動テンプレートの設定に含めない)とします。
ファイアウォール(セキュリティグループ) は、「既存のセキュリティグループを選択する」 を選択します。
「セキュリティグループ」は、ハンズオンで作成した セキュリティグループ である 「web-ユーザ名」 を選択します。(例:web-user1)

「高度なネットワーク設定」 を展開し、「ネットワークインターフェイスを追加」 ボタンをクリックします。
「パブリック IP の自動割り当て」 で、「有効化」 を選択します。

「ストレージ(ボリューム)」、「リソースタグ」は、デフォルトのままとします。
「高度な詳細」 を展開し、「IAM インスタンスプロフィール」 として 作成したIAMロール「access_ssm_role_handson」 を選択します。(オプショナル、Auto Scaling の実証も行いたい場合)
CloudWatch モニタリングの詳細 に、「有効化」 を選択します。

その他はデフォルトのままとし、「起動テンプレートを作成」をクリックします。

起動テンプレートの作成が成功したら、「起動テンプレートを表示」 をクリックします。
起動テンプレートが作成されました。

Auto Scaling グループ作成
作成した 起動テンプレート である launchtemplate-ユーザ名(例:launchtemplate-user1) をもとに、Auto Scaling グループを作成します。
起動テンプレート名 (launchtemplate-user1)の左側にチェックを入れ、アクション > Auto Scaling グループを作成をクリックします。

Auto Scaling グループ名 に asgroup-ユーザ名と入力します。(例:asgroup-user1)
起動テンプレートとして作成した launchtemplate-ユーザ名 を選択します。(例:launchtemplate-user1)
「次へ」をクリックします。

ハンズオンで作成された VPC である handson-ユーザ名 を選択します。(例:handson-user1)
パブリックサブネット-1a と パブリックサブネット-1c をプルダウンから選択、それ以外はデフォルトのままで「次へ」をクリックします。

「既存のロードバランサーにアタッチ」 を選択します。
「ロードバランサーのターゲットグループから選択」を選択します。
ハンズオンで作成したターゲットグループである target-ユーザ名 をプルダウンから選択します。(例:target-user1)

「VPC Lattice統合オプション」、「Application Recovery Controller(ARC)のゾーンシフト – 新規」、「ヘルスチェック」は、デフォルトのままとします。

今回は、最小のインスタンス数を2個、最大のインスタンス数を4個と設定します。
「グループサイズ」の「希望するキャパシティ」を「2」に設定します。
「スケーリング」の「最小の希望する容量」を「2」、「最大の希望する容量」を「4」に設定します。
「自動スケーリング – 省略可能」で「ターゲット追跡スケーリングポリシー」を選択します。
「メトリクスタイプ」は、「平均 CPU 使用率」 を選択します。
「ターゲット値」は、 「40」 を選択します。
「インスタンスのウォームアップ」は、 「10」 と入力します。

「その他の設定」で「CloudWatch 内でグループメトリクスの収集を有効にする」にチェックを入れます。
「次へ」をクリックします。

「通知を追加する – 省略可能」は、何もせず「次へ」をクリックします。
これから起動されるEC2インスタンスにタグをつけるように設定します。
「タグを追加する」 をクリックします。
キー に 「Mode」 と入力
値 – オプション に 「autoscaling」 と入力します。
新しいインスタンスをタグ付けする に チェックをつけます。
「次へ」 をクリックします。

設定内容を確認し、「Auto Scaling グループを作成」 をクリックします。
Auto Scalingグループが作成できました。
※一度作成に失敗して削除したため、名前に「2」が入っていますがご了承ください

AWS Systems Manager を使い、Auto Scaling を実証
Auto Scaling の機能を実証していきます。
AWS Systems Manager を使い、Auto Scaling グループの中の全ての EC2 インスタンス の CPU 使用率を上げる・下げることで、Amazon EC2 Auto Scaling で作成された Auto Scaling を実証していきます。
SSM Agent 経由で CPU 使用率を上げるためのコマンドを実行して、CPU使用率が閾値の40%以上になるようにします。

EC2 インスタンス の CPU 使用率の平均値が閾値(40%)を超えると、EC2 インスタンス を自動的にスケールアウトさせます(今回の設定では4個まで)。

一方、CPU 使用率の平均値が40%以下に戻ると、EC2 インスタンス を自動的にスケールイン(デフォルト設定の2個)させます。
Auto Scaling の初期状態を確認
最初は2個のインスタンスが起動されていることを確認しておきます。
EC2 のページで左ペインにある Auto Scaling グループ をクリックします。
以前作成した asgroup-ユーザ名 (例:asgroup-user1) で2個のインスタンスが起動されていることを確認します。

AWS Systems Manager で Auto Scaling グループ の中の全ての EC2 インスタンス の CPU 使用率を上げる
Auto Scalingグループを開いたブラウザのタブは閉じず、新しいタブで AWS コンソール を開きます。
検索ボックスに Systems Manager と入力して、Systems Manager をクリックします。
左ペインの「Run Command」を選択、「コマンドを実行する」をクリックします。

検索ボックスに CPU-Stress と入力し、AWSFIS-Run-CPU-Stress を選択します。

Duration Seconds に 300 と入力します。
ターゲット のところで インスタンスタグの指定 が選択されていることを確認します。
キー に Mode と入力します。
値 に autoscaling と入力します。
Add をクリックして反映されることを確認します。
その他はデフォルトのままとし、実行 をクリックします。
これで、コマンドが Auto Scaling グループ の中の全ての EC2 インスタンス に対して実行され、CPU の使用率が5分間の期間で100%まで上がっていきます。


コマンド実行後の画面

Auto Scaling の結果を確認(スケールアウト)
EC2 インスタンス の CPU 使用率が40%を超えている間にスケールアウトが行われるかを確認していきます。
以前のタブに戻り、asgroup-ユーザ名 をクリックします。(例:asgroup-user1)
モニタリング タブを開きます。
EC2 を選択します。
CPU 使用率(割合) を見て、CPU 使用率が40%を超えていることを確認します。


インスタンス管理 タブを開きます。
インスタンス数が4個までスケールアウトされていくかを確認(5分~10分ぐらい時間がかかる)します。

Auto Scaling の結果を確認(スケールイン)
インスタンス数が4個までスケールアウトされてから、5分後に モニタリング タブを開きます。
CPU 使用率(割合) を見て、CPU 使用率が40%以下に戻ったかを確認します。
CPU 使用率が40%以下に戻ったことを確認できたら、インスタンス管理 タブを開きます。
2個のインスタンスが停止されていくかを確認(5分~10分ぐらい時間がかかる)します。

これでAmazon Systems Manager を使い、意図的に EC2 インスタンス のワークロードを変更することにより、インスタンスの数が自動的にスケールアウト・スケールインされたのを実証できました。
Auto Scaling リソースの削除
Auto Scaling グループの削除
Auto Scaling グループを削除すると、Amazon EC2 Auto Scaling で起動された EC2 インスタンス も自動的に削除されます。
※削除は、少し時間がかかります
検索ボックスに EC2 と入力し、表示された EC2 をクリックします。
左ペインにある Auto Scaling グループ をクリックします。
asgroup-ユーザ名にチェックをつけます。(例:asgroup-user1)
アクション > 削除 をクリックします。
表示されるポップアップメニューで 削除 を入力、削除 をクリックします。
起動テンプレートの削除
EC2 の画面で、左ペインにある 起動テンプレート をクリックします。
launchtemplate-ユーザ名にチェックをつけます。(例:launchtemplate-user1)
アクション > テンプレートを削除 をクリックします。
表示されるポップアップメニューで 削除 をクリックします。
IAM ロール の削除
検索ボックスに ロール と入力し、表示された ロール をクリックします。
検索ボックスに access_ssm_role_handson と入力します。
表示された access_ssm_role_handson にチェックをつけます。
削除 をクリックします。

表示されるポップアップメニューで access_ssm_role_handson を入力、削除 をクリックします。

まとめ
気になったこととして、EC2コンソール > インスタンスに表示されているインスタンスがスケールインしても4台表示されていて、アクセスログも更新されていました。このあたりはまだまだ理解が追い付いていないのでおいおい勉強、検証していければと思います。
あとは、それぞれの設定値の意味を知らないと絶対できない設定だなと感じました・・・
以下、他の記事をまとめた一覧です。AWSもまとめています。