この記事は公開されてから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.ターゲット追跡スケーリング
- インスタンスが自動生成、削除されるか検証していきます
- 負荷をかけてスケールアウト
サーバーに負荷をかけてインスタンスが自動生成されるか実施します
↓
しきい値 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名をコピーして検索
↓
リロードして確認します
↓
新しく作成されたインスタンスへの接続が確認できました。次はスケールインを実施していきます
- 負荷を止めてスケールイン
- 今かけている負荷を止めてインスタンスが停止するか検証します
サーバーに戻ってストレスコマンドを終了(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 スケーリング基礎編