Set scheduled autoscaling for instance groups bases on time for scale up and down?
Should be a possibility to autoscale based on scheduled time in conjunction with other metrics. This is because, for example, I'm expecting several events during the month on specific days during specific range hours.
Luis Arcega
shared this idea
We have generally not found scheduled autoscaling to be necessary in Google Cloud, unlike some other clouds. The technology behind our Load Balancers is the same as Google uses on all its sites, and we don’t need to do these types of tricks.
We do get this request from time to time, but most customers find it is not needed, and several large web hosters have scrapped their own custom scheduling and pre-spinning approaches when migrating to GCP. Our instance provisioning and boot times are low enough that they work well for many use cases, and App Engine in particular is well suited to very fast and high scaling.
The one thing we can’t affect would be if your particular application server requires a long time to configure itself at instance startup time. The best way to deal with that, at present, would be to try not to do that. :/ Preconfiguring and installing a VM image so it can boot quickly is a good best practice for things with very dynamic scaling needs.
So… please try it and see, odds are it will “just work!”
6 comments
-
Alex
commented
Depending on how your application is designed, Cloud Scheduler would allow you to resize your compute engine instances on a scheduled basis. As an exemple, using Cloud Functions "Create a set of jobs with Cloud Scheduler that schedule instances to run 09:00-17:00, Monday-Friday to match typical business hours."
See more details on https://cloud.google.com/scheduler/docs/start-and-stop-compute-engine-instances-on-a-schedule.
-
edxz101
commented
@Paul Nash, In my case is necessary. We have cluster's in GCP and server take 1:30 minutes to start and setup environment for the application, time that the application can be down while autoscaling instance groups. Generally we know the moments of massive traffic and could program the autoscaling and avoid downtimes.
-
Anonymous
commented
We are running a CI system on top of an Instance Group where each node represents an agent running tests, and we find ourselves writing a resizing cron job in a VM because we don't want these agents to run during the night.
An option of scheduling a resize based on a time would be very helpful for us.
Just my 2 cents. Thank you!
-
Peter Mounce
commented
I'd like to schedule a rolling replace of all instances within a group on a nightly basis.
These instances are totally stateless. They are the jenkins ***** cluster. Their disks fill up with build artifacts, at which point they die horribly.
I'm not interested in investing effort into cleanup compared to just burning and replacing the instances each night when there's no traffic.
-
Thanks for describing your use case, Vishnu, this is very helpful. Certainly a large variable here is the amount of time it takes for your application to boot and be ready to serve. For some customers that's a few seconds, and for some customers it can be many minutes. We'll continue evaluating the use case for this type of calendaring capability, however we also do see a trend where newer deployment and development models are reducing the need for more static deployment patterns (e.g., serverless "boots" in milliseconds), so fewer and fewer customers are telling us they need calendared scaling.
-
Vishnu
commented
Hi @paul,
I will have to disagree on this because, we are a stock market broker and during market hours the traffic is 100x that non-market hours. The only ideal way to scale is to do it time based. Just an hour before maket opens, we keep like 3-4 large instances ready and during market, let the auto scale group do the magic using CPU metrics n stuff based on requests or whatever, and post market, we bring it down to 1 large server.
At market open we get over 1k logins per second, now lets say CPU spikes gradually, the chances of having 1000s of drop off is extremely high because it takes time to spin a new instance (even if its few seconds, in our case even slight delay is worth so much $) and add to load balancer. Thats why we prefer to have decently large set of servers ready at market opening to server massive traffic.