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!”
11 comments
-
Vitalii
commented
Hi
The load on our CI is very sharp and sudden and autoscaling does not have time to happen because it is difficult to catch the right moment and in general raising a new instance is a relatively long process. The solution for us will be as follows:
During the working hours of our development office, we will hold 2-3 instances and after the end of working hours, we will use only 1. But it is not possible to implement it now. -
Anonymous
commented
Scaling for normal production workloads would never anticipate scaling to zero.
For staging environments, it would be useful to be able to scale the IG back to zero instances outside of business hours for cost efficiency.
-
Jose Antonio Akel
commented
Our traffic is very dependant on day of the weeb, day of the month an time. Most of our servers spend most of the time idling, just waiting for the few days when they are needed.
Please enable this feature!
-
Victor Villalobos
commented
We have peaks of charges, and long time of startup in more than django-celery vm, and the nature of our business is that we have a lot of load on the ends of the month, and null at night.
Schedule would be a great help for us.
-
Nicolai Pedersen
commented
We have a use case where we run a NLP engine (using spaCy) on realtime financial news. The app engine takes a few seconds to boot which isn’t acceptable.
If we could just scale at 7.00, 7.30, 8.00 etc. then we’d be fine but doesn’t looks like it’s easy at this point.
Let me know if something else than app engine would be appropriate
-
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.