-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(aws-autoscaling): add instance AutoScaling #1134
Conversation
It's now possible to add autoscaling policies (step scaling, target tracking, and scheduled) to AutoScalingGroup. It's also possible to add lifecycle hooks to an AutoScalingGroup, which will publish messages to SQS queues or SNS topics. ALSO IN THIS COMMIT - Fix an issue where an invalid PauseTime is generated on AutoScalingGroup. Fixes #1042, fixes #1113.
…s-cdk into huijbers/instance-autoscaling
14436b1
to
14df8af
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Went through README, API looks beautiful. This is incredibly powerful. We should write a blog post on this.
might want to scale out if the CPU usage across your cluster starts to rise, | ||
and scale in when it drops again. | ||
* **By trying to keep a certain metric around a given value** (also known as | ||
target tracking scaling); you might want to automatically scale out an in to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"an" => "and"
// ... | ||
}); | ||
|
||
// Step scaling |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks slick!
|
||
Note that in order to set up this scaling strategy, you will have to emit a | ||
metric representing your worker utilization from your instances. After that, | ||
rou would configure the scaling something like this: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"rou"?
the range they can scale over (by setting both `minCapacity` and | ||
`maxCapacity` but changing their range over time). | ||
|
||
A scheduled is expressed as a cron expression. There is a `Cron` helper class |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"schedule"
the range they can scale over (by setting both `minCapacity` and | ||
`maxCapacity` but changing their range over time). | ||
|
||
A scheduled is expressed as a cron expression. There is a `Cron` helper class |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cron: can we extract it to a common module so we can reuse it in CloudWatch Events? [not critical for this PR of course, but at least raise an issue]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe. Two points against this:
- There are a couple of Cron syntaxes floating round. For example, for application autoscaling and EC2 autoscaling, the two syntaxes look like this:
cron(0 18 * * ?)
0 18 * * *
Note the cron()
function, and the difference between * and ?
for the DOW field.
Also, I think it's convenient that you use the Cron
class from the library X if you're creating cron expression for library X. It would be less convenient if you had to find library Y to use its Cron
class.
But I'll gladly make a ticket :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could create a shared cron library and expose the relevant instance (perm cron-syntax) from the various usage points
It's now possible to add autoscaling policies (step scaling, target
tracking, and scheduled) to AutoScalingGroup. It's also possible to add
lifecycle hooks to an AutoScalingGroup, which will publish messages to
SQS queues or SNS topics.
ALSO IN THIS COMMIT
AutoScalingGroup.
Fixes #1042, fixes #1113.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license.