AWSのAuto Scalingでターゲット追跡スケーリングを導入してみた

自分が所属しているプロジェクトチームで、Auto Scalingのターゲット追跡スケーリングを導入してみました。
そのログとか感想とかになります。

ターゲット追跡スケーリングとは？

Auto ScalingでEC2のインスタンス数を動的に調整してくれる設定の一つです。
ざっくりというと以下のように動いてくれます。

• メトリクスを指定する
  • CPU使用率、メモリ使用率、リクエスト数から選択
• メトリクスに対するターゲット値を指定する
  • 50%、1000リクエストなど
• するとAWS側でターゲット値が続くようにいい感じに台数を調整してくれる

詳しくはドキュメントを読んでください。
docs.aws.amazon.com

実際に使ってみる

設定画面

既にAuto Scalingグループは作成使用されている状態です。

• AWS → EC2 → Auto Scaling を選択していき、Auto Scalingのコンソールを開く
• 対象のAuto Scalingグループをチェック
• 動的スケーリングポリシーの項目で作成
• 設定画面で以下を入力
  • ポリシータイプで「ターゲット追跡スケーリング」を選択
  • スケーリングポリシー名を入力
  • メトリクスタイプを選択
  • ターゲット値を入力
  • 必要であれば、ウォームアップの秒数とスケールインの無効にチェック

ぶっちゃけ画像をはった画面一つだけで設定は終わります。

CloudWatchAlarm

ターゲット追跡スケーリングを設定するとCloudWatchAlarmが自動で作成されます。
今回はスケールインも有効にしているので、スケールアウト用のCloudWatchAlarmとスケールイン用のCloudWatchAlarmの二つが自動で作成されました。

CloudWatchAlarmの詳細を見てみます。

アラームの条件（スケールアウトやスケールインの条件）などがあります。
この場合は15分以内に15データポイントで平均CPU使用率は40.5%を下回るとアラーム状態になるようです。
期間が1分間なので、15分連続で平均CPU使用率は40.5%を下回るとアラーム状態になると判断できそうです。
また、この自動作成されたCloudWatchAlarmは編集も削除もできません。

導入してみた感想

導入自体はかなり楽！
以前はCPU使用率を元に動的スケールをしようとすると、CloudWatchAlarmを自作して、運用しながら閾値や増減する台数を調整する必要がありましたが、その手間を省略できています。

また、CloudWatchAlarmの編集ができないのが不安に思ってましたが、実際に導入してみるとインスタンス数の増減によってCloudWatchAlarmが更新され平均CPU使用率の閾値が変更になっていました。
インスタンス数によって閾値もいい感じに調整してくれるみたいです。

副次的な効果ですが、今のプロジェクトでの通常運用台数の見直しにも繋がったのも大きな影響だったと思います。
RIで買っているためか、常に20%を下回るくらいに余裕がありすぎる台数で運用してきたので、常にスケールインのアラーム状態であり、適切な台数を模索するように持っていくことができました。
次にRIを買う時の台数の参考にもなりますしね。

動的な台数調整がかなり楽に任せることができるようになっているので、便利になったし導入の敷居が低くなったと思います。
調べている中で不安だったCloudWatchAlarmの条件もAWS側でいい感じに調整してくれているのも分かって安心できました。
導入を検討してみてはどうでしょう？