AWSクラウドプラクティショナーの勉強をしていて、是非やってみたかったことがあります。それが、Auto Scalingです。
実際にやってみた内容、感想などを紹介します。
AWS Auto Scalingとは
システムの負荷が高くなったら、自動的にリソースを増やす仕組みです。
具体的には、冗長化されたマシンの台数を自動的に増やします。
Auto Scalingを試す際に参考にした内容
AWSクラウドプラクティショナー試験対策本（記事）内で紹介されていた内容を参考にしました。
「ELBとAuto Scalingを使用したスケーラブルなWebアプリケーション」という項目で紹介されていた内容を実際にやってみました。
※ただし、CloudWatchがややこしかったので、とりあえずロードバランサーとAuto Scaling機能だけ試してみました。
実際にやった内容（Auto Scalingの作成）
ロードバランサーの作成
Auto Scalingを実現するためにまずロードバランサーを作成します。
ロードバランサーの種類選択
今回はWebサーバをAuto Scalingする想定なので、ロードバランサーの種類はApplication Load Balancerを選択します。
ロードバランサーの設定（リスナー、アベイラビリティーゾーン）
ロードバランサーの名前、リスナー、アベイラビリティーゾーンを設定します。
HTTPでアクセスがあったら、2つのアベイラビリティーゾーンに振り分けるロードバランシング設定ですね。
セキュリティグループ設定
※この前にセキュリティ設定（HTTPSに対応させる）というのがあるのですがテストのため割愛しています。
ロードバランサーへのアクセスのためのセキュリティグループを設定します。
どこからもHTTPアクセスを許可する設定ですね。セキュリティ甘々です。
ルーティングの設定（ターゲットグループ、ヘルスチェック）
ロードバランシング先のターゲットグループとヘルスチェックの設定を行います。
ターゲット登録（ここでは何もしない）
実際にロードバランシング先は、Webサーバ（EC2マシン）ですが、ここでは指定しません。なぜなら、Auto Scalingグループを別途作ってそこで設定するので。
ロードバランサー完成
ロードバランサーの完成です。
起動設定の作成
次にAuto Scalingのための起動設定を作成します。
“起動設定”という名前をみるだけでは何ぞやと思うでしょうが、端的に言うと、Auto Scalingが実行された時に起動するマシンの内容です。
以下のマシンを起動するようにしています。
- OSは、Amazon Linux
- タイプは、t2.micro
- OS上で起動するアプリ（Webサーバ）
※これはユーザデータのコマンドを指定します。 - ストレージは、最小構成
- セキュリティグループでアクセス許可設定
- マシンにSSH接続するためのキーペア作成
起動するマシンのAMIを選択
ここは少しつまづきました。AMIの選択するときにAMI番号からしか検索ができなかったので、事前にAMI番号を調べておいて選択しました。
インスタンスタイプの選択
テストなので無料枠の t2.microを選択です。
高度な設定でWebサーバが起動する設定
これは慣れていないと難しいです。
要は、マシンを起動した後にWebサーバをインストールして、Webサーバの設定を行うという内容を、コマンド形式で指定しておきます。
#!/bin/bash -ex
yum -y update
yum -y install httpd
systemctl enable httpd.service
systemctl start httpd.service
AZ=`curl --silent http://169.254.169.254/latest/meta-data/placement/availability-zone`
INSTANCE_ID=`curl --silent http://169.254.169.254/latest/meta-data/instance-id`
IP_ADDRESS=`curl --silent http://169.254.169.254/latest/meta-data/public-ipv4`
echo $AZ\<br\> >> /var/www/html/index.html
echo $INSTANCE_ID\<br\> >> /var/www/html/index.html
echo $IP_ADDRESS >> /var/www/html/index.htmlストレージ設定
最小構成で。
セキュリティグループ設定
ロードバランサーから起動したマシンにアクセス（HTTPアクセス）するためのセキュリティ設定です。あと、マシン自身にSSH接続するためのアクセス許可（SSH接続）を設定しておきます。
キーペアの作成
起動したマシンにアクセスするためのキーペア設定です。
新しいキーペアを作りました。
起動設定の完成
無事、起動設定も完成しました。
Auto Scalingグループの作成
マシンをどこで起動するかの設定が、”Auto Scalingグループ”です。
起動設定を選択
事前に作った起動設定を選択しておきます。
Auto Scalingが発動したら、ここで選択した起動設定のマシンが起動します。
ネットワーク設定
マシンを起動するネットワークを設定します。ここでは、ロードバランサーと同じネットワークを選択しましょう。
詳細オプションでロードバランサーを選択
ここで事前に作ったロードバランサーの設定を入れます。
そろそろ、頭が混乱して内容についていけなくなってきますね。
ヘルスチェック設定は自動で設定されていた
ヘルスチェックの項目は、自動でEC2が選択されていました。
ロードバランサを選んだからなのか、このあたりの詳細仕様は不明です。
スケーリングポリシーの設定（サイズ）
恐らくこれがAuto Scalingグループの肝部分ですね。
負荷がかかった時、何台までマシンを増やすかの設定です。
最小2台、最大10台に設定しました。
ちなみに希望する容量は謎です。後でも書きますが勝手に変わります。ここで指定させる意味とは・・
スケーリングポリシーの設定（トリガー）
実はここは後で追加することもできるので、なしでも良いのですが、お試しのためデフォルト設定にしておきます。
- 「ターゲット追跡」を選択。
- 平均CPU使用率が50%を超えた場合に発動。
Auto Scalingグループの完成
とりあえず完成です。
CloudWatchとの連携などは後で修正できますので、とりあえず今回はここまで。
実際にやった内容（Auto Scalingのテスト）
早速 Auto Scalingで2台のマシンが起動
Auto Scalingを設定した時点で、早速 EC2マシンが作成されます。
平均CPU使用率が50を超えないので、最小台数である2台のマシンが起動します。
負荷をかけてみた・・
起動したマシン2台にログインして、負荷をかけるコマンドを実行してみました。
すると、CPU負荷がどんどんあがり、Auto Scalingが発動してマシンが増えました。素晴らしい・・
どんどんマシンが増える・・
平均CPU使用率が50%を閾値にしているのに、なぜかマシンがどんどん増えます。
結局、最大マシン数の10台まで増えてしましました・・。
これは想定外動作です。2台増えて4台くらいになってほしかった。
CPU負荷がさがったら、マシンは2台に戻った。
その後、負荷をかけていたコマンドが勝手に終了しました。
（なぜ勝手に終了したんだろう・・）
すると、マシン台数もしばらくして2台に戻っていました。
CPU使用率の変化、平均が取れているのか不安
マシン2台に100%の負荷をかけたのですが、そうすれば2台追加して4台になった時点で平均CPU使用率は50%になるはずです。
しかし、後でCPU使用率の推移を確認したらそのような動きになっていませんでした。
判定のタイムラグなのか分かりませんが、もうちょっと適切にAuto Scalingさせるためにはカスタマイズが必要そうです。
まとめ
１．何はともあれ、はじめてAuto Scalingを動かすことはできました。
２．ロードバランサー、起動設定、Auto Scalingグループと設定する項目は多くはじめてやるには慣れが必要です。
３．CloudWatchとの連携を設定すれば、より細かいAuto Scalingができそうです。
※今回、最大マシン数（10台）までAuto Scalingが発動してしまいましたが、このあたりはCloudWatchを設定すれば制御できると思います。
コメント