Fewer slow requests when the sale starts
Reactive against predictive on traffic the model never saw. Synthetic, so read it as the mechanism and not as a forecast for your system.
What being early costs
Pod-minutes used in one hour of traffic, averaged over the same traces.
| Pattern | Fixed at peak | Reactive | Predictive |
|---|
Questions
What has actually been run?
The scaling logic, the Flask API, the control loop (against stubbed Prometheus and gateway calls) and the browser port are covered by tests and agree with each other numerically. The Kubernetes and OpenFaaS manifests were written from the project documentation and have not been run against a live cluster yet. Treat the deploy guide as a first run and expect to fix small things.
Why a random forest?
The input is a handful of numbers: the last six request rates, their trend, and the position in the cycle. A forest learns that shape in seconds, evaluates in microseconds every ten seconds, needs no feature scaling, and exports to plain JSON, which is how the same model runs in your browser here.
What if the forecast is wrong?
The policy sizes for the larger of the forecast and the live load, so a bad forecast can only add pods, never remove them below what a reactive scaler would run. The price is cost. In the benchmark predictive scaling used between 5% and 10% more pod-time than reactive.
Why not just provision for the peak?
It works: nothing goes slow. It also costs two to five times the pod-time in this benchmark, because the peak is paid for all hour. The table above puts a number on it for each pattern.
Does it help with random bursts?
Partly. In the generated bursts the rate ramps over about thirty seconds, so the trend features see it coming and slow-request share fell from 12.5% to 7.0%. A burst that arrives at full strength in one tick cannot be forecast by anything, and no policy beats the cold start there.
How is this different from HPA or KEDA?
Out of the box, the Kubernetes Horizontal Pod Autoscaler reacts to a metric after it moves, and KEDA scales on event sources, including down to zero. Neither forecasts. This project is a forecasting layer; here it calls the OpenFaaS scale API, but the same decision could feed either of them.
Why simulate instead of just measuring?
A cluster run takes an hour per pattern and varies from run to run. The simulator replays identical traffic against every policy, so any difference comes from the policy and nothing else. The cluster scripts exist so you can then check the simulator against reality.
Can I train it on my own traffic?
Yes. loadtest/collect_data.py reads the request rate from Prometheus at ten-second steps and writes a CSV. scaler/train.py --csv data.csv trains on it, and the Docker build uses data.csv automatically when it is present.