Edit

Share via

Quickstart: Set up autoscale for applications in the Azure Spring Apps Standard consumption and dedicated plan

  • Article

Note

The Basic, Standard, and Enterprise plans will be deprecated starting from mid-March, 2025, with a 3 year retirement period. We recommend transitioning to Azure Container Apps. For more information, see the Azure Spring Apps retirement announcement.

The Standard consumption and dedicated plan will be deprecated starting September 30, 2024, with a complete shutdown after six months. We recommend transitioning to Azure Container Apps. For more information, see Migrate Azure Spring Apps Standard consumption and dedicated plan to Azure Container Apps.

This article applies to: ✅ Standard consumption and dedicated (Preview) ❎ Basic/Standard ❎ Enterprise

This article describes how to set up autoscale rules for your applications in Azure Spring Apps Standard consumption and dedicated plan. The plan uses an Azure Container Apps environment to host your Spring applications, and provides the following management and support:

  • Manages automatic horizontal scaling through a set of declarative scaling rules.
  • Supports all the scaling rules that Azure Container Apps supports.

For more information, see Azure Container Apps documentation.

Prerequisites

Scale definition

Scaling is defined by the combination of limits and rules.

  • Limits are the minimum and maximum number of instances that your Spring allows.

    Scale limit Default value Min value Max value
    Minimum number of instances per deployment 1 0 30
    Maximum number of instances per deployment 10 1 30

    By default, the minimum instance count of your Spring application is set to 1 to ensure that your deployment is always running. If you want to scale in to zero, you can set the minimum instance count to zero.

  • Rules are the criteria that the autoscaling abides by to add or remove instances. The scale rules include HTTP, TCP, and Custom rules as described in the Scale rules section of Set scaling rules in Azure Container Apps.

    If you define more than one scale rule, the autoscaling begins when the first condition of any rule is met.

  • The polling interval and cooldown period are two time spans that occur during autoscaling.

    • The polling interval defines the time span between each polling action of real time data as defined by your rules. The polling interval is set to 30 seconds by default.
    • The cooldown period applies only when scaling to zero - for example, to wait five minutes after the last time autoscaling checked the message queue and it was empty.

Set up autoscale settings

You can set up autoscale settings for your application by using the Azure portal or Azure CLI.

Use the following steps to define autoscale settings and rules.

  1. Sign in to the Azure portal.
  2. Select Azure Spring Apps under Azure services.
  3. In the Name column, select the Azure Spring Apps instance that you want to autoscale.
  4. On the overview page for your Azure Spring Apps instance, select Apps in the navigation pane.
  5. Select the application that you want to autoscale.
  6. On the overview page for the selected app, select Scale out in the navigation pane.
  7. On the Scale out (Preview) page, select the deployment you want to autoscale.
  8. Set up the instance limits of your deployment.
  9. Select Add to add your scale rules.

Screenshot of the Azure portal preview version showing the Scale out page for an app in an Azure Spring Apps instance.

Custom scaling rules

For information on defining custom rules, see Keda scalers. The following sections show two examples of setting scale rules on MySQL and Cron.

Set up auto scaling rules on MySQL database

The following CLI commands show you how to autoscale your Spring application based on Keda MySQL Scaler. First, create a secret to store your SQL connection string. This secret is used for your scale rule authentication. Then, set up a rule which scales the app based on the rows count of a table.

Note

Microsoft recommends using the most secure authentication flow available. The authentication flow described in this procedure, such as for databases, caches, messaging, or AI services, requires a very high degree of trust in the application and carries risks not present in other flows. Use this flow only when more secure options, like managed identities for passwordless or keyless connections, are not viable. For local machine operations, prefer user identities for passwordless or keyless connections.

az spring app update \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-service-instance-name> \
    --name <app-name> \
    --secrets mysqlconnectionstring="<username>:<pwd>@tcp(<server name>:3306)/<database name>" 

az spring app scale \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-service-instance-name> \
    --name <app-name> \
    --scale-rule-type mysql \
    --scale-rule-name <your rule name> \
    --scale-rule-auth "connectionString=mysqlconnectionstring" \
    --scale-rule-metadata queryValue=4 query="SELECT count(*) FROM mytable" \
    --min-replicas 0 \
    --max-replicas 3

Create a rule based on Linux cron

The following commands show you how to set up a rule based on Keda Cron Scaler. The replicas are scaled to the desired number during the cron time interval.

az spring app scale \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-service-instance-name> \
    --name <app-name> \
    --scale-rule-type cron \
    --scale-rule-name testscalerule \
    --scale-rule-metadata timezone="Asia/Shanghai" \
                          start="10 * * * *" \
                          end="15 * * * *" \
                          desiredReplicas="3" \
    --min-replicas 0 \
    --max-replicas 3

Scaling events

You can find the scaling events from the system logs of your underlying container app, and filter the EventSource by using KEDA, as shown in the following example:

ContainerAppSystemLogs_CL 
| where ContainerAppName_s == 'YourAppName' and EventSource_s == 'KEDA'

Clean up resources

Be sure to delete the resources you created in this article when you no longer need them. To delete the resources, just delete the resource group that contains them. You can delete the resource group using the Azure portal. Alternately, to delete the resource group by using Azure CLI, use the following commands:

echo "Enter the Resource Group name:" &&
read resourceGroupName &&
az group delete --name $resourceGroupName &&
echo "Press [ENTER] to continue ..."

Next steps

Map a custom domain to Azure Spring Apps with the Standard consumption and dedicated plan