Amazon EC2 Auto Scaling のCPU使用率に基づくスケーリングをAmazon CloudWatchから確認してみた
2024.03.14Amazon EC2 Auto Scaling CPU使用率に基づくスケーリングの動作を確認したい
おのやんです。
みなさん、Amazon EC2（以下、EC2）インスタンスをスケールイン・スケールアウトしたいと思ったことはありませんか？私はあります。
EC2 Auto Scaling（以下、Auto Scaling）を使用すれば、例えばEC2インスタンスに対してアクセスがスパイクするなどして負荷が上がった際に、臨時でEC2インスタンスを増設し、負荷を軽減することができます。
このAuto Scalingの動作を、実際にCPU負荷実験を行い検証したいと思います。
AWS Fault Injection Simulator Serviceについて
AWS Fault Injection Simulator Service（以下、FIS）は、EC2インスタンスやAmazon RDSなどのリソースに対して、意図的に障害を発生させることができるサービスです。カオスエンジニアリングに考えに基づいて設計されており、障害発生時のアプリケーションの動作を検証することができます。
今回はAuto ScalingののCPU使用率に基づくスケーリングを設定したEC2インスタンス2台に、FISを用いてCPUの負荷をかけ、EC2インスタンスがスケールイン・スケールアウトするかどうか検証します。
また同時に、CPUの負荷が収まった場合に、EC2インスタンスがスケールインするかどうかも検証していきたいと思います。
検証
それでは実際に検証していきます。今回の検証では、最初にAuto ScalingやFISによる実験を設定した後に、Amazon CloudWatch（以下、CloudWatch）アラームからAuto Scalingの動作を確認します。
Auto Scalingの設定
今回検証するAuto Scaligの設定は以下の通りです。EC2インスタンスのCPU使用率が50%を超えると、EC2インスタンスを1台増やして負荷を軽減させます。
| 項目 | 値 | 備考 |
|---|---|---|
| 希望（desired） | 2 | Auto Scalingグループを作成した際のEC2インスタンスの初期台数 |
| 最小（min） | 2 | 最小のEC2インスタンス台数 ※手動もしくは自動で、最小サイズ制限よりもEC2インスタンス台数を減らすことはできない |
| 最大（mix） | 3 | 最大のEC2インスタンス台数 ※手動もしくは自動で、最大サイズ制限よりもEC2インスタンス台数を増やすことはできない |
| 動的スケーリングポリシータイプ | ターゲット追跡スケーリング | ターゲットのメトリクス値に基づいてAuto Scaling グループのリソースを自動的にスケーリング |
| メトリクスタイプ | 平均CPU使用率 | Auto Scaling時に参考にするメトリクス値 |
| ターゲット値 | 50 | 平均CPU使用率をメトリクスタイプとして設定した場合、単位は% |
実際に、マネジメントコンソール上ではこのように設定を確認できます。
動的スケーリングポリシーも確認できます。
これらが正常に設定されていると、自動でEC2インスタンスが作成されます。今回はdesiredの値を2に設定しているため、2台のEC2インスタンスが作成されているのが確認できます。
FISによる実験の設定
今回実施するFISの実験では、EC2インスタンスに対してCPU負荷をかけていきます。FISの実験テンプレートを適当に作成して、詳細画面に移ります。「実験を開始」というボタンがあるので、こちらを押下します。
このように、状態がRunningになっていたら、正常にFISの実験が実行されていると判断できます。
実際にEC2インスタンスのCPU使用率メトリクスを見てみると、時間が経過するにつれてCPU使用率が上昇していることが確認できます（今回は検証用にEC2インスタンスを作成したため、グラフがかなり短くなっています）。
CloudWatchアラームの確認
ここでCloudWatchを確認してみましょう。Auto Scalingでは、ターゲット追跡スケーリングポリシーを設定したタイミングでCloudWatch アラームが作成されます。このアラームは、今回のケースだとEC2インスタンスのCPU使用率を監視していることになります。
実際にCloudWatchの管理画面に移動し、「すべてのアラーム」ページを確認してみると、2つのCloudWatchアラームが作成されているのが確認できます。それぞれ「CPU使用率が50%を上回った場合にEC2インスタンスをスケールアウトする」「CPU使用率が50%を下回った場合にEC2インスタンスをスケールインする」といった具体的な条件が設定されています。
ここで、AlarmHighというIDが付与されている方のCloudWatchアラームを見てみましょう。
今回の場合、EC2インスタンスの使用率が50%を超えた段階でデータポイントのカウントが始まります。この高負荷の状態が1５分間で15データポイントにて記録された場合、アラームが発出されてAuto Scalingが発動します。実際に、CloudWatchアラームからもCPU使用率（CPUUtilization）が確認できます。
今回のFISの実験ではCPUに負荷をかける時間を15分に設定していましたので、一定時間経過後にこのようなアラームが発出されます。
このアラームが、Auto Scalingのスケールアウトの合図となります。実際にEC2画面を見てみると、新しいEC2インスタンスが作成されているのがわかります。
これでAuto Scalingのスケールアウトの動作検証は完了しました。ここで、一旦手動でFISのCPU負荷実験を停止したいと思います。FISの実験一覧画面にて実験を選択し、「実験を停止」ボタンを押下します。
AlarmHighのCloudWatchアラームを見ると確認できますが、CPU使用率が低下し、アラーム発出状態が解除されているのがわかります。
それでは反対に、AlarmLowというIDが付与されたCloudWatchアラームを見てみましょう。こちらは、15分以内の15データポイントにてCPU使用率が35%を下回った場合、EC2インスタンスがスケールインされるようになっています。
FISの実験を停止したタイミングでCPU使用率が低下し始め、一定時間が経過した後にアラームが発出されているのがわかります。
このアラームが、Auto Scalingのスケールインの合図となります。実際にEC2画面を見てみると、EC2インスタンスが削除されて、もとの台数に戻っていることが確認できます。
Auto Scalingによって増設されたEC2インスタンスは自動で消去される
以上の検証を行うことで、Auto ScalingによるEC2インスタンスの増減を確認できました。個人的に「スケールアウトで増設されたEC2インスタンスは、どういった処理を経て削除されるんだろう？」という悩みを持っていたので、検証できてよかったです。
Auto Scalingの動作がいまいちわかっていない、みたいな場合に、今回の記事が参考になれば幸いです。では！
