Today we have made an adjustment to the automatic scaling of Beach instances. This post explains the background and explains the effects.
An instance can be automatically scaled horizontally in Beach in order to be able to react to fluctuating loads.
For this purpose, the minimum and maximum number of replicas can be defined, as well as the CPU load, which triggers scaling up if exceeded.
Settings for the automatic scaling of an instance
So far, however, the behavior in the background has not quite corresponded to what users would expect.
The actual maximum possible CPU utilization was not used as a comparison value, but a different resource metric. Although this is the standard behavior of the Kubernetes autoscaler, instances tended to be scaled up "too early" as a result.
Although this provided a comfortable buffer, it sometimes resulted in unexpectedly high numbers of replicas.
Today, we have adjusted the calculation so that the value given for the CPU load actually refers to the maximum.
On the one hand, this ensures that scaling up is no longer carried out so early - and thus the costs should also fall with the lower average number of running replicas.
In this screenshot (a very clear example) you can see how the change works: The number of replicas goes down (green curve), while the average CPU load goes up (yellow curve), using the replicas more efficiently.
CPU load and number of replicas over time
On the other hand, this can also lead to problems caused by the comparatively later scaling. This is because the buffer for load peaks with steep edges is now smaller.
We have adjusted the settings for automatic scaling in the affected projects to compensate for this effect. Nevertheless, please note: If unexpected problems occur in the near future, you can counteract them by increasing the minimum number of replicas and/or reducing the maximum CPU load.