Feature Request: Implement Rolling Window for Vote Evaluation Based on Last N Scrapes

[bpretto]

Currently, the autoscaler scrapes metrics from GCP at a set interval and creates votes, such as upscaleVotes and downscaleVotes. After a set time period, the autoscaler evaluates all the votes since the last evaluation and decides whether scaling should occur.

Issue:

The current system uses a fixed time window for evaluation. After a set interval between scrapes, it evaluates all votes that have been collected. However, this approach is not ideal because it doesn't evaluate continuously based on the most recent data. For example, if the system scrapes metrics every 30 seconds and evaluates every 3 minutes, it will only evaluate after a fixed period.

The issue here is that votes are only evaluated at the end of each fixed window, and this prevents real-time decision-making. If scaling votes are generated right before the evaluation period ends, they might not be taken into account until the next evaluation cycle, which could cause a delay in scaling actions.

Suggested Improvement:

• Instead of evaluating all votes in fixed time windows, implement a rolling window for vote evaluation. This would mean evaluating votes based on the most recent N scrapes (e.g., the last 3 or 5 scrapes) at any given time.
• Each time a new scrape happens, the autoscaler should evaluate the votes based on the last N scrapes, rolling over as new data is collected. For example, if the autoscaler scrapes every 30 seconds and the window is set to the last 3 scrapes, after each new scrape, the system would evaluate the current state based on the most recent 3 scrapes, ensuring that scaling decisions are made in real time and not delayed.

Expected Behavior:

• Every time a new scrape occurs, the autoscaler should evaluate the scaling decision based on the most recent N scrapes (e.g., the last 3 or 5).
• This would provide continuous, real-time scaling decisions based on the most recent data, improving responsiveness and allowing for quicker scaling actions.

Additional Information:

• The number of scrapes to consider (e.g., 3 or 5) should be configurable based on the environment and use case.
• This change would allow the autoscaler to act immediately on new data, without waiting for a fixed time window to accumulate, improving system responsiveness and scalability.