Amazon EC2 Auto Scaling インスタンスの自動作成、削除の検証


この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので十分ご注意ください。

 

今回、Auto Scaling を使用して EC2 インスタンスが自動的に追加または削除が行われているかの
検証を行います。

 

Amazon EC2 Auto Scaling とは

Amazon EC2 Auto Scaling は、アプリケーションの負荷を処理するために適切な数の Amazon EC2 インスタンスを利用できるようにします。Auto Scaling グループと呼ばれる EC2 インスタンスの集合を作成します。各 Auto Scaling グループ内のインスタンスの最小数を指定することができ、Amazon EC2 Auto Scaling グループはこのサイズよりも小さくなることはありません。各 Auto Scaling グループ内のインスタンスの最大数を指定することができ、Amazon EC2 Auto Scaling グループはこのサイズよりも大きくなることはありません。グループの作成時、またはそれ以降の任意の時点で、希望するキャパシティーを指定した場合、Amazon EC2 Auto Scaling によって、グループのインスタンス数はこの数に設定されます。スケーリングポリシーを指定する場合、Amazon EC2 Auto Scaling でアプリケーションに対する需要の増減に応じて、インスタンスを起動または終了できます。

引用 : AWS公式サイト

 

 

事前準備

 

  • 事前準備としてVPC、パブリックサブネット、セキュリティグループ、ターゲットグループ、ALBを作成しています

※ 今回はシンガポールリージョンで検証していきます

 

VPCは以下の設定値で作成しています

パブリックサブネットを2台作成しています。設定値は以下の通りです

1a

1c

 

セキュリティグループはEC2用とALB用の2つ作成、設定値は以下の通りです

グループ名 タイプ ソース
autoscaling-alb-sg HTTP 0.0.0.0/0
autoscaling-ec2-sg HTTP
SSH
ALB用のセキュリティグループ
マイIPアドレス

 

ターゲットグループの設定値は以下の通りです

項目
Choose a target type Instances
Target group name autoscaling-tg
Protocol HTTP
Port 80
VPC 任意で選択
Protocol version HTTP1
Health check protocol HTTP
Health check path /
Port Traffic port
Healthy threshold 5
Unhealthy threshold 2
Timeout 5
Interval 30
Success codes 200

※ Register targets は何も設定しません

 

ALBの設定値は以下の通りです

項目
name autoscaling-alb
Scheme Internet-facing
IP address IPv4
VPC 任意で選択
Mappings public-subet-1a
public-subet-1c
Security groups ALB用のセキュリティグループ
Protocol HTTP
Port 80
Default action 作成したターゲットグループ

 

1. 起動テンプレート作成

 

  • Austo Scaling で自動生成されるインスタンスの設定をします

AMIは Amazon Linux2、インスタンスタイプはt2.microを使用します

EC2用のセキュリティグループを選択します

パブリックIPの自動割り当てを有効化にします

リソースタグは自動生成される際のインスタンスを設定できます

CloudWatchモニタリングの詳細を有効化にします

※ 今回スケールインの際にデータを1分間隔で取得するため有効化していますが、料金が発生するため基本的には有効化しなくても大丈夫です

 

ユーザーデータを設定

Apacheのインストールなど、セットアップのコマンドを入力します。入力しておく事でインスタンスを作成した時に自動的にコマンドが実行されます。


 

#!/bin/bash
sudo yum update -y
sudo yum install -y httpd
sudo amazon-linux-extras install epel -y
sudo yum install stress -y
sudo systemctl start httpd
sudo echo `hostname` > /var/www/html/index.html
sudo echo "ClientAliveInterval 60" >> /etc/ssh/sshd_config
sudo echo "ClientAliveCountMax 120" >> /etc/ssh/sshd_config
sudo systemctl restart sshd.service

 

  • sudo yum update -y

 インストールされているパッケージをすべて最新のものにアップデート

  • sudo yum install -y httpd

 Apacheのインストール

  • sudo echo hostname > /var/www/html/index.html

 ホストネームをhtmlファイルに代入

  • sudo amazon-linux-extras install epel -y

 標準ではストレスコマンドをインストール出来ないのでepelからインストール

  • sudo yum install stress -y

 EC2インスタンスにStressコマンドをインストール

  • sudo systemctl start httpd

 Apacheの起動

 

SSH 接続が短時間で切断されないように、サーバ側のsshdの設定を変更のため以下のコマンドを入力

  • sudo echo "ClientAliveInterval 60" >> /etc/ssh/sshd_config

 sshd が一定期間クライアントと通信していないときに、指定した秒数ごとに応答確認を行う

  • sudo echo "ClientAliveCountMax 120" >> /etc/ssh/sshd_config

 応答確認を行う回数、/etc/ssh/sshd_config に以下を追記する

  • sudo systemctl restart sshd.service

 設定を反映するために、sshdを再起動する

 

起動テンプレートの作成完了です

 

2. Auto Scaling グループ作成

  • 次に Auto Scaling グループを作成していきます

グループ名を設定し、作成した起動テンプレートを選択します

VPCとサブネットを設定します

事前準備で作成したALBとターゲットグループを選択します


 

今回は、まず2台起動するために希望容量を2に設定。スケールアウトの最大値、スケールインの最小値を設定します

ターゲット追跡スケーリングポリシーを選択、CPUが80%を超えるとスケールアウトするように設定

内容を確認して作成します

グループの作成が完了したらCloudWatchアラームが作成されているのを確認します

スケールアウト、スケールインする際のアラームが作成されています

・AlarmHigh → スケールアウトする際のアラーム 
・AlarmLow → スケールインする際のアラーム
 

3.ターゲット追跡スケーリング

  • インスタンスが自動生成、削除されるか検証していきます
     
  1. 負荷をかけてスケールアウト

サーバーに負荷をかけてインスタンスが自動生成されるか実施します

しきい値 3分内の3データポイントのCPUUtilization > 80

・3回連続で80%を越えるとアラームが発動しスケールアウトします。データは1分回間に1度取得するので3分ほどでアラームが発動します

 

サーバーに負荷をかけるため、自動で生成されているインスタンス2台にSSH接続していきます

※今回は EC2 instance Connect を利用して接続します

インスタンスを選択して接続をクリック

EC2 instance Connect を選択して接続をクリック

サーバーに負荷をかけるストレスコマンドを実行していきます
※もう1台のサーバーにも同じようにコマンドを実行

stress -c 1

CloudWatchの画面に戻りCPU使用率が上がっているか確認していきます。数分待つとCPU使用率が80%を3回超えてアラーム状態になりました

スケーリングが行われてるか AutoScalingグループのアクティビティを確認すると
【Launching a new EC2 instance】インスタンスを2台から3台、1台追加する動きが行われていました

インスタンスが追加されているかを確認します

2台起動していたインスタンスに1台追加されているのが確認できました

 

次に、インターネットから新しく作成されたインスタンスに接続できるかの確認をします

※ 起動テンプレート作成のユーザーデータで接続時にホスト名を表示する設定をしています

ALBのDNS名をコピーして検索

リロードして確認します

新しく作成されたインスタンスへの接続が確認できました。次はスケールインを実施していきます

 

  1. 負荷を止めてスケールイン
  • 今かけている負荷を止めてインスタンスが停止するか検証します

サーバーに戻ってストレスコマンドを終了(Ctrl+C)します
※もう1台のサーバーも同じように終了

CloudWatchに戻りスケールイン(AlarmLow)の動きを確認します

しきい値 15分内の15データポイントのCPUUtilization < 60

・CPU使用率が60%を下回る期間が15分間続くとスケールインする

15分ほど待つとアラーム状態になりスケールインします

スケーリングが行われているかAutoScalingグループのアクティビティを確認すると
【Terminating EC2 instance】インスタンスの削除が行われて、4台から3台、3台から2台にする動きが行われていました

※ 最大値を4に設定していたのでストレスコマンドを停止する前に4台目のインスタンスが作成されています

スケールアウト、インスタンスが削除されているか確認します

4台から3台、3台から2台とスケールインする動きが確認できました

 

 

 

最後に

Auto Scaling を利用してインスタンスの自動生成、削除を実施しました。Auto Scalingは自動でサーバの増減を実現できる、非常に便利な機能です。自動でサーバの増減が可能になるため、運用における人的リソースも削減ですることが可能です。様々な機能があり非常に便利な機能である一方で、運用面で考慮すべきことも多いことも特徴です。運用する際には目的に沿ったスケーリングの使い分けをしていきたいと思います。

 

参考資料 : Amazon EC2 Auto Scaling スケーリング基礎編

 

Last modified: 2024-02-07

Author