4 ms·

Until elastic beanstalk supports time scheduled scaling, I will be sad. Every morning my app servers go from zero to a million miles an hour and it takes about

Until elastic beanstalk supports time scheduled scaling, I will be sad. Every morning my app servers go from zero to a million miles an hour and it takes about 20 minutes to scale up. Does anyone actually use this at scale?

everettForth 12y ago
I believe you could write code to do this, as long as you have amazon credentials on a server at that time in the morning. Did you write your own app, or do you need to hire a consultant to do this?
rschmitty 12y ago
We use CloudFormation to do this, but I thought beanstalk had similar cloudwatch metrics to scale with. We don't use chef/puppet/ansible/salt in production or any code deploy stuff. Basically use your provisioning tool of choice to setup an instance like you would a local vm, deploy your code, then package that all up as an AMI. When the server spins up there is some minor config that gets set depending on the zone it is in and we are off to the races. Takes about 2 minutes to fully register with ELB and start serving traffic. Each step you remove from a new instance to become 'ready' decreases your load time and lets you run at higher margins so you arent stuck with a Cloudwatch alert of 30% cpu -> scale up because it takes 20 minutes for chef to config the server, git to deploy code, run whatever compilation of assets/configs, then finally register with ELB Downside of course is you are always making AMIs to do a new push. If you follow semver, you could add a small step to handle a pull of your latest .PATCH version so you are only creating AMIs for MAJOR.MINOR. Or if you prefer only doing MAJOR ami creations tldr: reduce # of steps a new instance has to take in order to start handling traffic = higher cloudwatch thresholds = more server utilization = cheaper bill and faster scaling!
h1karu 12y ago
Autoscaling isn't really intended for bursting, it works better when you have predictable traffic patterns. But if I understand it correctly you can use EB with custom Cloudwatch metrics and that lets you do some pretty cool, predictive things that autoscale based on external factors such as: volume of Twitter mentions, Google Analytics data, number of active user sessions, etc. In theory you could write some app code that uses custom cloudwatch metrics to initiate scale-up during certain timeframes. right ?
- michaelmior 12y ago
  > Every morning my app servers go from zero to a million miles an hour Sounds pretty predictable to me.
imperialWicket 12y ago
Elastic beanstalk uses auto scaling groups which support as-put-scheduled-update-group-action in the cli or http://docs.aws.amazon.com/AutoScaling/latest/APIReference/API_PutScheduledUpdateGroupAction.html http://docs.aws.amazon.com/AutoScaling/latest/APIReference/A... to set time-based scaling.
- MichaelGlass 12y ago
  lovely. I had a consultation with an Amazon rep after reading this http://aws.amazon.com/application-management/ http://aws.amazon.com/application-management/ and they confirmed their own incorrect documentation.
cddotdotslash 12y ago
Use AWS OpsWorks. It allows you to setup time based instances easily.

everettForth 12y ago

I believe you could write code to do this, as long as you have amazon credentials on a server at that time in the morning. Did you write your own app, or do you need to hire a consultant to do this?

rschmitty 12y ago

We use CloudFormation to do this, but I thought beanstalk had similar cloudwatch metrics to scale with. We don't use chef/puppet/ansible/salt in production or any code deploy stuff. Basically use your provisioning tool of choice to setup an instance like you would a local vm, deploy your code, then package that all up as an AMI. When the server spins up there is some minor config that gets set depending on the zone it is in and we are off to the races. Takes about 2 minutes to fully register with ELB and start serving traffic. Each step you remove from a new instance to become 'ready' decreases your load time and lets you run at higher margins so you arent stuck with a Cloudwatch alert of 30% cpu -> scale up because it takes 20 minutes for chef to config the server, git to deploy code, run whatever compilation of assets/configs, then finally register with ELB Downside of course is you are always making AMIs to do a new push. If you follow semver, you could add a small step to handle a pull of your latest .PATCH version so you are only creating AMIs for MAJOR.MINOR. Or if you prefer only doing MAJOR ami creations tldr: reduce # of steps a new instance has to take in order to start handling traffic = higher cloudwatch thresholds = more server utilization = cheaper bill and faster scaling!

h1karu 12y ago

Autoscaling isn't really intended for bursting, it works better when you have predictable traffic patterns. But if I understand it correctly you can use EB with custom Cloudwatch metrics and that lets you do some pretty cool, predictive things that autoscale based on external factors such as: volume of Twitter mentions, Google Analytics data, number of active user sessions, etc. In theory you could write some app code that uses custom cloudwatch metrics to initiate scale-up during certain timeframes. right ?

michaelmior 12y ago
> Every morning my app servers go from zero to a million miles an hour Sounds pretty predictable to me.

imperialWicket 12y ago

Elastic beanstalk uses auto scaling groups which support as-put-scheduled-update-group-action in the cli or http://docs.aws.amazon.com/AutoScaling/latest/APIReference/API_PutScheduledUpdateGroupAction.html http://docs.aws.amazon.com/AutoScaling/latest/APIReference/A... to set time-based scaling.

MichaelGlass 12y ago
lovely. I had a consultation with an Amazon rep after reading this http://aws.amazon.com/application-management/ http://aws.amazon.com/application-management/ and they confirmed their own incorrect documentation.

cddotdotslash 12y ago

Use AWS OpsWorks. It allows you to setup time based instances easily.