まあ色々あって、インフラ方面の技術の勉強を全力でやっております、高橋です。
今回は AWSの Auto Scaling を一から調べてみて、動作確認とかしてみたので、ブログ書いてみます。
概要を知りたい人
2019-10-02 時点での AWSの公式Youtubeの動画ですが、これがあるだけでガイドラインを頭に入れる事は出来ると思います。
私は オートスケーリング のサービスについて EC2 Auto Scaling というサービスしか知らなかったですし、オートスケーリングの動的スケーリングの手法として 簡易スケーリング と呼ばれるものしか知りませんでした。
今は オートスケーリングのサービスは AWS Auto Scaling 、 EC2 Auto Scaling 、 Application Auto Scaling と複数種類のサービスが展開されていますし、 「簡易スケーリング」 だけでなく ステップスケーリング、 ターゲット追跡スケーリング などの手法もサポートされています。
この動画では AWS Auto Scaling は 「まだまだ発展途上」という言及がされていますが、 EC2のオートスケーリングを行う際は AWS Auto Scaling の 予測スケーリング機能 と EC2 Auto Scaling の ターゲット追跡スケーリングを使っていくのが良いと言及されていて予めしっておく方がググるにも良いと思います。
今回はオートスケーリングの動的スケーリングの内、自動スケーリングについて試してみたので書いてみておきます。
ターゲット追跡スケーリングを設定してみる
個人アカウントで試してみたのですが、 大体50円ぐらいで動作チェックとか出来るので誤差レベルだな〜って感じでした。
ターゲット追跡スケーリングとは
ターゲット追跡スケーリングは EC2 Auto Scaling、Application Auto Scaling にてサポートされているスケーリング手法です。
一つのメトリクス（例えば CPU使用率） において目標値をセットする事で、その目標値を満たすように スケールアウト・イン がされます。
例えば... CPU平均使用率の目標値が 30% という前提で Auto Scaling Group 内には1台しかEC2 インスタンスが無いと仮定します。
あるタイミングにて 1台のEC2のCPU使用率の平均が50% になったとします。
そうすると EC2 Auto Scaling サービスが ポリシーを実行して EC2 を一台スケールアウトします。
ASG内のEC2 が2台構成になり1台のEC2のCPU使用率が50%、もう1台は10%と仮定するとASG内のEC2の平均CPU使用率は30%になり、目標値を満たされます。
このように目標値だけを考えてASG内のインスタンス数はAWSにマネージドしてもらうというのがターゲット追跡スケーリングです。
Auto Scaling の方針
オートスケーリングを設定するにあたっては以下2つを構成する必要があります。
- 起動テンプレート
- Auto Scaling Group ( ASG )
起動テンプレートでは AutoScalingサービスがスケールアウトする際にどのような構成のEC2インスタンスを立てるかを設定します。
- AMI ( Amazon Machine Image )
- インスタンスサイズ
- Security Group
などを設定しておくことが出来ますし、高度な設定として シャットダウンの動作の規定だったりEBS最適化とかが設定できます。
ASG では 起動テンプレートを指定して Group内のEC2インスタンス の希望台数や 最小・最大のインスタンス数の設定します。
という事で諸々準備して行きます。
オートスケールする為の元となるイメージを作る
index.php が動く Webサーバーを作ってそのイメージを作成します。
ubuntu 18.04 のEC2インスタンスを起動して以下を実行します。
sudo apt-get update sudo apt-get -y upgrade sudo apt-get -y dist-upgrade sudo apt-get install -y apache2 sudo systemctl start apache2 sudo systemctl enable apache2 echo '<?= $_SERVER["SERVER_ADDR"]; ?>' | sudo tee /var/www/html/index.php
全部完了したら、EC2のコンソールからAMIを作成します。
イメージの作成が完了したらコンソールは以下のようになります。
起動テンプレートを定義
EC2のコンソールのメニューから インスタンス > テンプレートの起動 と選択して 起動テンプレートを定義します。
ASG を作成する
テンプレートまで作成するとASGを作成していきます。
ロードバランサーのターゲットグループを指定します。ターゲットグループは下記のコンソールの場所から作成出来るので指定します。
スケーリングオプションはこんな感じで設定します
先述した通り ターゲット追跡スケーリング の目標値を設定しました。 今回は 平均のCPU 使用率 が 30% であることとしました。
ASG の作成完了
成功すればこんな感じで EC2 instance が立ち上がってくるはずです。
先程、 希望する容量 を 1 と設定していたので 今回は1台のみが立ち上がりました。
ターゲット追跡スケーリングの設定に応じてスケールアウトするのを確認する
という事でスケールアウトする所も確認してみたいと思います。
テストとしては以下です。
・ EC2 インスタンスを1台選択して、CPU使用率を50%ぐらいにする. ・ スケールアウトされる事をチェック ・ ASG内でのCPU使用率が30%を切るのでそれ以上スケールアウトしない事を確認する
CPU使用率を上げる
CPU使用率を50%ぐらいにする.
とは言っても普通にindex.php しか置いてないサーバーなのでCPU使用率を50% ぐらいにするのは簡単じゃ無さそうです。
そこで ソフトウェアを使います。 （公式のサイトが不明だった。 manpage . ubuntu なので一旦以下を載せておきます！）
日本語化情報としては以下にあります。
という事で インストール及び 50% 程度でCPU負荷をかけてみます。
$ sudo apt-get install stress-ng $ stress-ng -c 1 -l 50
Top で見るとこんな感じでCPUを50% 程度で負荷を与えてくれています。
待つこと 5分...
EC2インスタンスが構築されて
TargetGroup に追加されました！！
（ブログ書きながら色々やってたので3台ぐらい配置されてしまった... ので画像はサンプルとさせてくだせぇ・・・）
自動スケーリングしたので問題なさそう。 stress-ng を終了させてみました。
スケールインを待つ・・
スケールインとスケールアウトのアラームは Cloud Watch で管理されています。
- TargetTracking-xxx-AlarmLow-UUID ： スケールイン条件
- TargetTracking-xxx-AlarmHigh-UUID ： スケールアウト条件
AlarmHighは3分間で調査されます。 今回の場合に置き換えると 3分間で ランダムにCPU使用率のメトリクスを3つ取得してそれらが全て 30% を超えていれば アラーム発動 という事です。
AlarmLow は15分間で調査されます。 15 分内の15データポイントのCPUUtilization < 21 という風になってました。 21% とかは自動で決まるのだと思いますが、 スケールイン条件を今回にあてはめると 15分間でランダムにCPU使用率のメトリクスを15個取得しれそれらが全て(?) 21% を下回っていればスケールインされる、という事みたいです。
という事で15分待ってみます。
ちょっと途中で間違っちゃったのを含めてですが、 希望キャパシティが 1 => 2 => 3 => 2 => 1 とダウンしているのが分かります！！
まとめと今後の展望
オートスケーリングの設定についてはAWS Black Belt Online Seminarもあって大分掴めてきました。 まあ、基礎知識と言われればそうだと思うので日頃の研鑽をつまないといけないな、ってのは痛感してはいるものの前を向けるレベルにはなったかな、って感じですね。
結構オートスケーリングってビビってる部分もあるのですが、本番では これ + 予想スケーリング というので設定が出来るそうで大分マネージドに頼る事が出来そう。
予想スケーリングは試してみたかったんですけど、機械学習で負荷を学習させるのに2週間分のデータが必要らしく諦めましたｗ またの機会に試してみたいと思います。
今後の展望なんですけど、オートスケールをする際の AMIの作成だったりの運用あたりを考えていかないといけないのかな、って考えています。
例えば 本番運用だと AMIに取り込まれたソースコードが必ずしも最新だとは限らないので git pull を自動でしてくれるようにする、とか色々。。
その辺はまず何が出来るのか、から調べていかないといけないですね。 ゴールデンイメージ っていう単語だったりで調べていって 色んな方の運用ノウハウを吸収していきたいなと思います。
という事でがんばるぞ〜。
