Auto Scalingは、AWSでインフラを構築する際に、重要機能なので軽く触れるようになっておきたい。そのためチュートリアル的な構成で実際に構築してみた。
構築する構成
ELB(ALB)で、EC2インスタンス上のWebアプリケーションに振り分ける。
EC2インスタンスは、オートスケーリングにより、増減する。
構築する
ネットワーキングの設定
VPCの作成
- 今回の指定値（抜粋）
- VPC名: autoscale-demo-vpc
- IPv4 CIDRブロック: 10.0.0.0/16
- VPC名: autoscale-demo-vpc
サブネットの作成
2つのAZにまたがる構成を作成するため、サブネット作成時にAZを指定する。
- 今回の指定値（抜粋）
- 1つ目
- 名前: autoscale-demo-subnet-1a
- AZ: ap-northeast-1a
- CIDR: 10.0.1.0/24
- 2つ目
- 名前: autoscale-demo-subnet-1c
- AZ: ap-northeast-1c
- CIDR: 10.0.2.0/24
- 1つ目
インターネットゲートウェイの作成
- 今回の指定値（抜粋）
- 名前: autoscale-demo-igw
作成後、VPCにアタッチする
ルートテーブルの設定
- ルート設定の編集（インターネット向けルート設定の追加）
- 送信先: 0.0.0.0/0
- ターゲット: インターネットゲートウェイ
- サブネットの関連付けの編集
- 今回作成した2つのサブネットを関連付ける
セキュリティグループの作成
- 今回の指定値（抜粋）
- 名前: web-server-sg
- VPC: autoscale-demo-vpc(今回作成したVPC)
- インバウンドルール: HTTP(tcp/80)とSSH(tcp/22)を許可
- アウトバウンドルール: すべてのトラフックを許可
ロードバランシングの設定
ターゲットグループの作成
- 今回の指定値（抜粋）
- ターゲットグループ名: autoscale-demo-tg
- ターゲットの種類: インスタンス
- プロトコル: HTTP
- ポート: 80
- VPC: autoscale-demo-vpc
ロードバランサーの作成
- 今回の指定値（抜粋）
- ロードバランサーの種類: ALB(Application Load Balancer)
- 名前: autoscale-demo-elb
- スキーム: インターネット向け
- リスナー: HTTP 80
- アベイラビリティゾーン: 1aと1cにチェックを入れる。
- セキュリティグループ: web-server-sgを選択
- ターゲットグループ: autoscale-demo-tg（上記で作成したもの）
- ターゲットの登録：ここでは特にしない
セキュリティ設定の構成で、セキュアリスナーを使っていないと注意されるが、今回は本番環境ではないので気にしない。
Auto Scalingの設定
起動設定の作成
- 今回の指定値（抜粋）
- AMI: Amazon Linux 2 AMI
- インスタンスタイプ: t2.micro
- 起動設定の名前: autoscale-demo-launchconfig
- ユーザデータ: httpdのインストールや表示ページを作るスクリプトを記載（後述）
- IPアドレスタイプ: パブリックIPアドレスを各インスタンスに割り当てます
- セキュリティグループ: web-server-sgを選択
セキュリティグループをこの画面で作成すると、デフォルトVPCに紐づいてしまって、以降のAuto Scalingグループの作成時に下記のようなエラーになってはまった。
セキュリティグループは、事前に作成しているものを使うことで回避できる。
One or more security groups in the launch configuration are not linked to the VPCs configured in the Auto Scaling group
ユーザデータでは、今回は、負荷分散先のEC2が特定できるような情報を付与しておく。
#cloud-config
packages:
- httpd
timezone: Asia/Tokyo
runcmd:
- "echo \"<html>\" > /var/www/html/index.html"
- "echo \"<h1>hello world</h1>\" >> /var/www/html/index.html"
- "echo \"created at \" `date` \"</br>\" >> /var/www/html/index.html"
- "ec2-metadata -i >> /var/www/html/index.html"
- "echo \"</html>\" >> /var/www/html/index.html"
- "systemctl start httpd"
- "systemctl enable httpd"
Auto Scaling グループを作成する
- 今回の指定値（抜粋）
- Auto Scaling グループの詳細設定
- 起動設定: autoscale-demo-launchconfig（上記で作成したもの）
- グループ名: autoscale-demo-asg
- グループサイズ: 2
- ネットワーク: 今回作成したVPCを選択
- サブネット: 今回作成した2つのサブネットを選択
- ロードバランシング: ロードバランサーからトラフックを受信するについてチェックを入れる
- ターゲットグループ: autoscale-demo-tg（今回作成したもの）
- ヘルスチェックのタイプ: ELBを選択
- スケーリングポリシーの設定
- 「スケーリングポリシーを使用して、このグループのキャパシティを調整する」を選択
- スケーリング範囲：「2」および「4」インスタンス
- スケールグループサイズ: 「ステップスケーリングポリシーまたは簡易スケーリングポリシーを使用した Auto Scaling グループのスケーリング」を選択すると、グループサイズの増加、グループサイズの減少の設定項目が表示される
- グループサイズの増加
- 名前: Increase Group Size
- ポリシー
- Average CPC使用率 >= 60 %
- アラーム名: autoscale-demo-hiCPU-alarm
- アクション: 追加 2 capacity units
- グループサイズの減少
- 名前: Decrease Group Size
- ポリシー
- Average CPU使用率 <= 20 %
- アラーム名: autoscale-demo-rowCPU-alarm
- アクション: 削除 2 capacity units
- 通知の設定：今回は設定しない
- タグ：今回は設定しない
- Auto Scaling グループの詳細設定
動作確認する
Auto Scaling グループ 作成直後の状態の確認
EC2リソース作成確認
インスタンス一覧を確認。インスタンスが２つ作成されている。
Webサーバへのアクセス確認
ELBのDNS名をコピーして、Webブラウザに張り付けて、Webページ(Hello world)が見れる。
この時、ブラウザでウェブページを更新（F5ボタン押下）すると表示内容が変わることから、ELBによる振り分けが機能していることがわかる。
（index.htmlにEC2インスタンスのinstance-idも表示するようにした）
スケールアウトの確認
試しにCPU使用率をあげる
両方のWebサーバ（EC2インスタンス）にSSHでログインして
CPU使用率を上げるような処理を動かす
$ yes > /dev/null
CloudWatchの画面で、「autoscale-demo-hiCPU-alarm」のアラームを確認すると、平均CPU使用率が急上昇していき、60%のラインを超えると、アラート状態になる
Auto Scalingグループが動作していることを確認
Auto Scalingグループのアクティビティ履歴を確認すると、新しく2つのEC2インスタンスを起動させたメッセージが出ている。
インスタンス一覧の画面では、runningのインスタンスが2つ増えていることが確認できる。
ブラウザでウェブページを更新（F5ボタン押下）すると表示内容が4パターンになっていることから、ELBによる振り分けが機能していることがわかる。
スケールインの確認
CPU負荷を下げる
CPU負荷を上げるために実行していたコマンドを停止する
CloudWatchの画面で、「autoscale-demo-rowCPU-alarm」のアラームを確認すると、平均CPU使用率が下がっていき、20%以下になると、アラーム状態になる。
Auto Scalingグループが動作していることを確認
Auto Scalingグループのアクティビティ履歴を確認すると、新しく2つのEC2インスタンスを停止しているメッセージが出ている。
数分後、インスタンス一覧の画面では、runningのインスタンスが2つに戻っていることが確認できる。（2つ停止されたことが確認できる）
ブラウザでウェブページを更新（F5ボタン押下）すると表示内容が2パターンになっていることから、ELBによる振り分けが機能していることがわかる。