Fargate Auto Scaling Policyに関する調査
techno.kokiクールダウン期間とは
前回のスケーリングアクティビティが有効になるまでの待機時間のこと
スケールアウト・インダウン期間について
以下2種類のクールダウン期間がある
- スケールアウトクールダウン期間
Auto Scaling によって正常にスケールアウトすると、クールダウン時間の計測が開始される。
スケーリングポリシーは、「より大きなスケーリングポリシーがトリガーされる」か「クールダウン期間が終了しない」限り、必要なタスクを増加させない。
クールダウン期間中は、
スケールアウトアクティビティにより追加された容量は、次のスケールアウトアクティビティに予定される容量の一部として計算される。
- スケールインクールダウン期間
スケールインは控えめに行ってアプリケーションの可用性を保護されることを目的としているため、
スケールインアクティビティは、クールダウン期間が終了されるまでブロックされる。
ただし、スケールダウン中に別のアラームによりスケールアウトアクティビティをトリガーした場合、
Auto Scale によりターゲットが即座にスケールアウトされる。
この場合、スケールインクールダウン期間は停止して、完了されない。
参考
techno.kokiスケールアウトクールダウン期間（ScaleOutCooldown）は、
可能な限り低い値に設定することで最適なスケーリングが可能。
だが、低すぎると、スケーリングするメトリクスの平均値判定のための十分な時間を確保できない場合もあるので、
十分に高い値に設定する。
スケールインクールダウン期間（ScaleInCooldown）は、
フラッピング（コンテナの頻繁な増減）しないように十分な長さの値を設定。
参考
techno.kokiスケールアウトする閾値との兼ね合いで決まるみたい。
どういうこと
- 閾値に達して、スケールアウト開始
- スケールアウト完了
- クールダウン期間が入る
- 閾値次第でスケールアウト・イン
なので、
スケールアウト後に即座に次にスケールアウトが必要だが、クールダウン期間に中だとスケールアウトできない、となってしまい、急激な負荷増大に対応できなくなってしまう。
閾値が高すぎる場合、スケールアウトが間に合わない
閾値が低すぎる場合、無駄にスケールアウトしてコストが無駄
参考
techno.koki短くしすぎる、スケールアウト後のメトリクスの変化が十分に評価されないまま、次のスケールアウト・インを繰り返して、コンテナ数が不必要に増減してしまう
長くしすぎると、負荷の急増に素早く対応できない、
という兼ね合いの中で、
スケールアウトのクールダウンタイムは60s辺りに設定しているケースが多そうな印象。
なので、
Scale-out cooldown period 60sec
Scale-in cooldown period 180sec
ぐらいがまずは妥当かな。
参考
techno.kokiターゲット追跡ポリシーの場合:
ターゲット追跡ポリシーは、定義したメトリクスとターゲット値に基づいて、スケーリング調整 (つまり、タスクの必要数) を計算します。ステップスケーリングポリシーで行うように、スケーリングアクションを設定する必要はありません。これは、ターゲット追跡ポリシーによって、指定したターゲット値またはそれに近い状態でメトリクスを維持するために、必要に応じて容量を追加または削除するためです。
なので、ターゲット追跡ポリシーの場合、
スケールアウトする時のタスク数が、AWS側が計算して自動的に決めてくれるらしい。
一方、段階ポリシーの場合、
各段階に応じた追加するタスク数が自前で定義する必要がある＝「自前で負荷を見たりして最適そうな値を決める必要がある」