📝
ECSにおけるAuto Scaling Policyの「ターゲットスケーリング」と「ステップスケーリング」について
ECS の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%になるように努めてくれます
オートスケールの設定をする時にみなさん頭を悩ませるのがスケールインの閾値だと思いますが、これをある程度いい感じにやってもらえるのが便利です。
両スケーリングタイプの重要な違い
多分、これが結構重要なのではないかと思う。
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 ステップスケーリングポリシーの使用をサポートしていますが、
代わりにターゲット追跡ポリシーを使用することをお勧めします。
*
高度なスケーリングポリシー設定に、
ターゲット追跡スケーリングをステップスケーリングと共に使用することもできます。
たとえば、必要に応じて、使用率が一定のレベルに達したときにより積極的なレスポンスを設定できます。
基本的にターゲット追跡を使う。ケースによってはステップを併用する、ということを推奨しているのかもしれません。
Discussion