動的スケーリングポリシーとは、CPU利用率などを元にスケーリングを行うポリシーです。
スケジュールドスケーリングポリシーとは、特定時刻にインスタンスを増やしたり減らしたり、○○分間隔で繰り替えしインスタンスを増やしたり減らしたり、というスケーリングを行うポリシーです。
スケーリングポリシーの概要については、以前まとめた記事がありますので、良かったらご参考ください。
<iframe id="zenn-embedded__1d2bd0c2f75cf" src="https://embed.zenn.studio/card#zenn-embedded__1d2bd0c2f75cf" data-content="https%3A%2F%2Fzenn.dev%2Ftaroman_zenn%2Farticles%2F8a07d4e08f8219" frameborder="0" scrolling="no" loading="lazy"></iframe><a href="https://zenn.dev/taroman_zenn/articles/8a07d4e08f8219" style="display:none" target="_blank">https://zenn.dev/taroman_zenn/articles/8a07d4e08f8219</a>
さて、Auto Scaling を学ぶために説明を読んでいて、ふと、こんな風に思いました。
「動的スケーリングポリシーとスケジュールドスケーリングポリシーって一緒に使ったら意味ないんか？」
動的スケーリングポリシーでは常にDesired Capacityを調整してくれていて、そこにスケジュールドスケーリングポリシーが横やりを入れても、すぐに元に戻されるはず...？
でもそんなことをわざわざ説明している記事が無い。
というわけで、多分考えた通りのことが起こるとは思うのですが、検証してみました。
<h2 id="%E5%8B%95%E7%9A%84%E3%82%B9%E3%82%B1%E3%83%BC%E3%83%AA%E3%83%B3%E3%82%B0%E3%83%9D%E3%83%AA%E3%82%B7%E3%83%BC%E3%82%92%E8%A8%AD%E5%AE%9A%E3%81%97%E3%81%9Fauto-scaling%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97%E3%82%92%E7%94%A8%E6%84%8F">
<a class="header-anchor-link" href="#%E5%8B%95%E7%9A%84%E3%82%B9%E3%82%B1%E3%83%BC%E3%83%AA%E3%83%B3%E3%82%B0%E3%83%9D%E3%83%AA%E3%82%B7%E3%83%BC%E3%82%92%E8%A8%AD%E5%AE%9A%E3%81%97%E3%81%9Fauto-scaling%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97%E3%82%92%E7%94%A8%E6%84%8F" aria-hidden="true"></a> 動的スケーリングポリシーを設定したAuto Scalingグループを用意</h2>
まず、AutoScalingグループを以下の設定で作成しました。
<ul>
<li>min: 1</li>
<li>max: 2</li>
<li>Desired Capacity: 1</li>
</ul>
<img src="https://storage.googleapis.com/zenn-user-upload/2a8e5c4994d5-20220212.png" alt="初期設定" loading="lazy" class="md-img">
動的スケーリングポリシーの中の、ターゲット追跡ポリシーを付与しました。
CPU利用率が50%をキープするように設定します。
特に何もインスタンスに負荷を掛けていないので、常にインスタンス数は1です。
<h2 id="%E3%82%B9%E3%82%B1%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AB%E3%83%89%E3%82%B9%E3%82%B1%E3%83%BC%E3%83%AA%E3%83%B3%E3%82%B0%E3%83%9D%E3%83%AA%E3%82%B7%E3%83%BC%E3%82%92%E8%A8%AD%E5%AE%9A">
<a class="header-anchor-link" href="#%E3%82%B9%E3%82%B1%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AB%E3%83%89%E3%82%B9%E3%82%B1%E3%83%BC%E3%83%AA%E3%83%B3%E3%82%B0%E3%83%9D%E3%83%AA%E3%82%B7%E3%83%BC%E3%82%92%E8%A8%AD%E5%AE%9A" aria-hidden="true"></a> スケジュールドスケーリングポリシーを設定</h2>
ここに、スケジュールドスケーリングポリシー設定します。
<img src="https://storage.googleapis.com/zenn-user-upload/8cc251a50a03-20220212.png" alt="スケジュールドスケーリングポリシー設定" loading="lazy" class="md-img">
こんな感じ。
Desired Capacityを2, maxを2に設定します。minは1のままで行きます。
予測される結果は以下になります。
「2022/02/10 22:30になるとインスタンス数が2になるが、動的スケーリングポリシーによって数分以内にDesired Capacityが1に戻され、インスタンス数も1になる。」
結果を確認してみましょう。
<h2 id="%E7%B5%90%E6%9E%9C">
<a class="header-anchor-link" href="#%E7%B5%90%E6%9E%9C" aria-hidden="true"></a> 結果</h2>
結論から言うと、予想通りの結果になりました。
CloudWatchのメトリクスで確認すると、以下のように表示されました。
<img src="https://storage.googleapis.com/zenn-user-upload/0d554b5c58a2-20220212.png" alt="メトリクス" loading="lazy" class="md-img">
メトリクスの時刻はUTC表示なので、22:30 - 9:00 = 13:30 となっています。
13:30にDesiredCapacityが2に上げられますが、10分後には1に戻っています。
それに伴い、インスタンス数も1になりました。
せっかくなので、どれくらいの時間で一連の動きが起こったかも、アクティビティから確認してみましょう。
<img src="https://storage.googleapis.com/zenn-user-upload/71f327a8c38f-20220212.png" alt="ログ" loading="lazy" class="md-img">
（必要ないかもですが、id系は隠しています。）
10:30:02 にスケジュールドスケーリングポリシーが実行されています。2秒遅れですね。ちなみに、スケジュールドスケーリングポリシーはぴったりに実行されないよーという公式の説明もあります。
10:30:12に Desired Capacityが1から2に変更された旨が、Launching a new instance のログに書いてあります。スケジュールドスケーリングポリシーの実行→Desired Capacityの変更が10秒かかってますね。
10:30:14 に実際にインスタンスが起動されたようです。
10:36:21 に動的スケーリングポリシーによってDesired Capacityが2から1に変更されています。
13:36:27 にはインスタンスの停止と終了が行われています。
スケジュールドスケーリングポリシーによってDesired Capacityが2に変更されてから約6分で、インスタンスの終了までが行われていますね。今回はEC2の詳細モニタリングを有効にしていないので、そのせいもあるかもしれません。
<h2 id="%E5%8B%95%E7%9A%84%E3%82%B9%E3%82%B1%E3%83%BC%E3%83%AA%E3%83%B3%E3%82%B0%E3%83%9D%E3%83%AA%E3%82%B7%E3%83%BC%E3%81%A8%E3%82%B9%E3%82%B1%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AB%E3%83%89%E3%82%B9%E3%82%B1%E3%83%BC%E3%83%AA%E3%83%B3%E3%82%B0%E3%83%9D%E3%83%AA%E3%82%B7%E3%83%BC%E3%82%92%E5%90%8C%E6%99%82%E3%81%AB%E4%BD%BF%E3%81%86%E3%81%93%E3%81%A8%E3%81%AF%E3%81%82%E3%82%8B%E3%81%AE%E3%81%8B%EF%BC%9F">
<a class="header-anchor-link" href="#%E5%8B%95%E7%9A%84%E3%82%B9%E3%82%B1%E3%83%BC%E3%83%AA%E3%83%B3%E3%82%B0%E3%83%9D%E3%83%AA%E3%82%B7%E3%83%BC%E3%81%A8%E3%82%B9%E3%82%B1%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AB%E3%83%89%E3%82%B9%E3%82%B1%E3%83%BC%E3%83%AA%E3%83%B3%E3%82%B0%E3%83%9D%E3%83%AA%E3%82%B7%E3%83%BC%E3%82%92%E5%90%8C%E6%99%82%E3%81%AB%E4%BD%BF%E3%81%86%E3%81%93%E3%81%A8%E3%81%AF%E3%81%82%E3%82%8B%E3%81%AE%E3%81%8B%EF%BC%9F" aria-hidden="true"></a> 動的スケーリングポリシーとスケジュールドスケーリングポリシーを同時に使うことはあるのか？</h2>
私は実運用したことがないので、本当のところは分かりません。
考えられるユースケースとしては
テレビで紹介される時刻が決まっていて、その時刻に合わせて前もってスケールアウトしておきたいとき、や
業務開始時間前にスケールアウトしておきたい
などでしょうか。
あらかじめスケールアウト、インをしておきたいときにはある程度使えるかもしれません。 
前もって増やしておきたいとき、動的スケーリングポリシーによって戻されないようにする設定も入れる必要があるでしょうが、その辺りは分かっていません...
また、min, maxの値を変えるためだけに使うのであれば、動的スケーリングポリシーとの競合もしないので、使い勝手が良さそうです。
実運用でスケジュールドスケーリングポリシーを使うパターンがあれば、ぜひ聞いてみたいです。
<h2 id="%E6%9C%80%E5%BE%8C%E3%81%AB">
<a class="header-anchor-link" href="#%E6%9C%80%E5%BE%8C%E3%81%AB" aria-hidden="true"></a> 最後に</h2>
AWSの細かいところを探れてよかったです！
またAWS関連で気になったところを記事にしていきます！

EC2 Auto Scaling で 動的スケーリングとスケジュールドスケーリングを両方設定したら意味が無いのか試してみた

動的スケーリングポリシーを設定したAuto Scalingグループを用意

スケジュールドスケーリングポリシーを設定

動的スケーリングポリシーとスケジュールドスケーリングポリシーを同時に使うことはあるのか？

EC2 Auto Scaling で動的スケーリングとスケジュールドスケーリングを両方設定したら意味が無いのか試してみた

Discussion