ECS on FargateでAuto Scaling を設定したくて、色々ググっていたのですが、
スケーリングタイプに以下の2つがあるらしく
- ターゲットスケーリング
- ステップスケーリング
使い分けがよく分からなかったので、調査。
結論（のようなもの）
以下のような使い分けがされるみたい。
- 通常のスケールアウト・イン → ターゲット追跡スケーリング
- 負荷スパイク時のスケールアウト・イン → ステップスケーリング
実際に、Auto Scaling を運用に乗せる時には、
一旦「ターゲット追跡スケーリング」を設定してみて、
必要に応じて「ステップスケーリング」を検討する、という形でいいのかな。
両スケーリングタイプの特徴
ステップスケーリング
指定した閾値に基づいてスケールアウト/インを行うオートスケールです。
スケールアウト/インを段階的に定義できるのが特徴で、例えば以下のような設定が可能です。
CPUの平均使用率が61-70% -> コンテナを1つ増やす
CPUの平均使用率が71-80% -> コンテナを3つ増やす
CPUの平均使用率が81%以上 -> コンテナを5つ増やす
CPUの平均使用率が50%以下 -> コンテナを1つ減らす
適切な値を設定する難易度は低くないですが、うまく使うとリソースを急激に変化させることができます。
ターゲットスケーリング
指定したメトリクスが指定した数値になるようにスケールアウト/インを行うオートスケールです。
イメージとしてはKubernetesのHorizontal Pod Autoscalerが近いと思います。
例えばCPUの平均使用率が60%となるように指定した場合
CPUの平均使用率が70% -> スケールアウト
CPUの平均使用率が50% -> スケールイン
というような振る舞いをし、CPUの平均使用率が60%になるように努めてくれます
オートスケールの設定をする時にみなさん頭を悩ませるのがスケールインの閾値だと思いますが、これをある程度いい感じにやってもらえるのが便利です。
https://tech.timee.co.jp/entry/2020/08/31/191612 より引用両スケーリングタイプの重要な違い
多分、これが結構重要なのではないかと思う。
Cloud Watch Alarmを自前で定義できるか否か
ターゲット追跡スケーリングの場合、
Scaling Policy作成時に、以下のCloud Watch Alarmが自動作成されます。
- 3分以内の3データポイントのメトリクス > 閾値
- 15分以内の15データポイントのメトリクス < 閾値 -数%
そのため「1分以内にCPU 平均使用率が50%を超えたら、アラームを発動する」のように、発動条件の厳しいアラームを自前で作成することができません。（できないよね…?）
一方、ステップスケーリングではCloud Watch Alarm を自前で用意するので、上記のような厳し目のアラームを作成することができます。
つまり、ステップスケーリングでは
- Cloud Watch Alarmを自前で用意
- スケーリングポリシーで「急激な負荷が増大した場合には多めにタスクを増やす」という設定を設ける
ことで、ターゲット追跡スケーリングに比べて急激な負荷に対応できる、みたいです。
補足
公式ドキュメントには、以下の記載もありました。
Amazon ECS サービスの Auto Scaling は Application Auto Scaling ステップスケーリングポリシーの使用をサポートしていますが、代わりにターゲット追跡ポリシーを使用することをお勧めします
高度なスケーリングポリシー設定に、ターゲット追跡スケーリングをステップスケーリングと共に使用することもできます。たとえば、必要に応じて、使用率が一定のレベルに達したときにより積極的なレスポンスを設定できます。
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-autoscaling-stepscaling.html より引用
基本的にターゲット追跡を使う。ケースによってはステップを併用する、ということを推奨しているのかもしれません。
コメント