Autoscaling

While deploying a service, you can provision multiple instances of your container (pod in the kubernetes world) so that the incoming traffic is load-balanced between the multiple instances. We refer to each such instance as a replica in TrueFoundry. While deploying at TrueFoundry, the default value of a replica is 1. While this is fine for development purposes, a single replica is not the best choice for production workloads because of the following reasons:

1. If one replica goes down because of any reason, the entire service goes down. Having 2-3 replicas at minimum helps provide more fault-tolerance.
2. A single replica might not be able to take all of the incoming traffic and hence cause client side errors.

To increase the number of replicas, we can either set it to a fixed higher value or enable autoscaling so that the number of replicas is automatically adjusted based on some configuration of incoming traffic, or cpu usage.

​

Setting Fixed Number of Replicas

This can be a good choice if the incoming traffic remains constant and we have a good idea of the number of replicas needed. To set the replicas using the UI, you can follow the steps below:

​

Enable Autoscaling

When the traffic or resource usage of the service is not constant, we ideally want the number of replicas to go up and down based on the incoming traffic. We need to define the minimum and maximum number of replicas in this case and the autoscaling strategy will decide what should be the number of replicas between the min and max replicas. We can enable autoscaling based on the following parameters:

1. CPU Usage: If the application’s cpu usage goes up when traffic increases, this can be a good parameter to autoscale on. For e.g., let’s say your application (one replica) consumes 0.3 vCPU on steady state - however, as traffic goes up, the CPU usage starts increasing to a max of 1 CPU. In this case, setting autoscaling to trigger when CPU usage is greater than 0.6 can be a good idea.
2. Requests Per Second (RPS): This is the easiest to reason about and calculate. We can benchmark our service to decide how many requests per second can be served by one replica using benchmarking tools like Locust. Let’s say one replica can serve 10 requests per second without an degradation in quality (increase in latency or errors). If we expect the traffic to vary from 50 requests per second to 200 requests per second, we can set the minimum replicas to 5, maximum to 20 and set the rps autoscaling metric to 10.
3. Time Based Autoscaling: This can be useful if the traffic patterns shift based on timezones, or you want to shut down dev workloads during non-office hours. For e.g, if you want to scale up replicas only between Monday to Friday 9AM to 9PM, you can set time based scheduling with cron start schedule as 0 9 * * 1-5 and end schedule as 0 21 * * 1-5.

​

Configure Autoscaling for an Application

The key things to configure for autoscaling are:

1. Min Replicas: The minimum number of replicas to scale down to.
2. Max Replicas: The maximum number of replicas to scale up to.
3. Autoscaling Metric: The metric to autoscale on.
4. Autoscaling Value: The value of the metric to autoscale on.
5. Polling Interval (Advanced): This defines the time interval at which the metrics are checked to decide if the service needs to be scaled up/down. The default values is 30 seconds. You can make it lower to 10 seconds in case you want to scale more quickly.

​

How to decide the autoscaling metric value

If you are using CPU as the autoscaling metric, it is usually a safe bet to autoscale when CPU usage is greater than 70%. You can further tune this value based on your application’s behaviour like time to startup (We might want to scale up at a lower cpu percentage like 60% in this case) or reliability requirements.

If you are using time as the autoscaling metric, you can derive the cron expression of the start and end times to scale up and down.

For setting up requests/second as the autoscaling metric, we need to benchmark the service to decide the number of requests per second that can be served by one replica. Benchmarking in general is useful because of the following reasons:

• Determining the service’s capacity in terms of handling requests per second.
• Assessing the threshold of concurrent requests, indicating the number of users the service can accommodate simultaneously.
• Analyzing how latency fluctuates with increasing traffic volume.

​

How to benchmark a service

There are multiple tools to benchmark your service like Locust, Gatling, K6, hey. This guide will outline how to use Locust to benchmark your service - since its quite easy to setup, use and is widely used by datascientists and engineers. You can follow the steps mentioned below:

pip install locust

from locust import FastHttpUser, task

class HelloWorldUser(FastHttpUser):
    @task
    def hello_world(self):
        self.client.post(
            # No need to mention host here
            "/path/to/your/endpoint",  
            # Add your request payload here
            json={
                "model": "<Add your deployed service name>",
                "prompt": [
                    "This is a test prompt"
                ],
                "max_tokens":80,
                "ignore_eos":True
            }
        )

locust -f locust_benchmark.py

from locust import FastHttpUser, task

class HelloWorldUser(FastHttpUser):
    @task
    def hello_world(self):
        self.client.post(
            # No need to mention host here
            "/path/to/your/endpoint",  
            # Add your request payload here
            json={
                "model": "<Add your deployed service name>",
                "prompt": [
                    "This is a test prompt"
                ],
                "max_tokens":80,
                "ignore_eos":True
            }
        )