[WORKFLOWS-44] Add Managed Scaling #53
Conversation
… when deploying task definition revisions
| TerminationPolicies: | ||
| - OldestLaunchConfiguration | ||
| - OldestInstance |
There was a problem hiding this comment.
any reason why not just let AWS manage this with Default setting?
There was a problem hiding this comment.
Yes, I want to be explicit about how this is going to behave so that anyone supporting it knows what to expect. It's also a little different from the default behavior. You can look that up.
| MinimumScalingStepSize: 1 | ||
| MaximumScalingStepSize: 1 | ||
| TargetCapacity: 90 |
There was a problem hiding this comment.
The docs seem to indicate that if status is set to enabled then AWS auto scales for you. I think that means that it will just ignore these scaling params? or am i reading it wrong?..
The ManagedScaling property specifies the settings for the Auto
Scaling group capacity provider.
When managed scaling is enabled, Amazon ECS manages the scale-in
and scale-out actions of the Auto Scaling group. Amazon ECS manages a
target tracking scaling policy using an Amazon ECS-managed CloudWatch
metric with the specified targetCapacity value as the target value for the
metric. For more information, see Using Managed Scaling in the Amazon
Elastic Container Service Developer Guide.
If managed scaling is disabled, the user must manage the scaling of the
Auto Scaling group.
There was a problem hiding this comment.
@zaro0508 Good question. It's the opposite of how you're reading it; in my experience with clusters there's always some metric or metrics used as the measure so that it knows when to autoscale. Now, TargetCapacity is not a required value so I assume there's some default value they're using, but they don't specify what it is. I went with 90 because the aws-samples code I was looking at used that value; it works well enough so I left it at that.
Look at this set of instructions for creating the capacity provider in the console -- there's more explanation at #9. You can also read the deep dive blog post.
Adds a CapacityProvider to implement managed scaling. This allows the cluster to add an instance which will accommodate a new, updated task before spinning down the old one. It takes 5-6 minutes for this turnover to happen and then another ~15 minutes to shut down the second cluster instance. Possibly we could shorten the latter by adjusting TargetCapacity -- but this seems to be working nicely now.