Scale an Azure Cache for Redis instance

Azure Cache for Redis has different tier offerings that provide flexibility in the choice of cache size and features. Through scaling, you can change the size, tier, and number of nodes after creating a cache instance to match your application needs. This article shows you how to scale your cache using the Azure portal, plus tools such as Azure PowerShell and Azure CLI.

Types of scaling

There are fundamentally two ways to scale an Azure Cache for Redis Instance:

  • Scaling up increases the size of the Virtual Machine (VM) running the Redis server, adding more memory, Virtual CPUs (vCPUs), and network bandwidth. Scaling up is also called vertical scaling. The opposite of scaling up is Scaling down.

  • Scaling out divides the cache instance into more nodes of the same size, increasing memory, vCPUs, and network bandwidth through parallelization. Scaling out is also referred to as horizontal scaling or sharding. The opposite of scaling out is Scaling in. In the Redis community, scaling out is frequently called clustering.

Scope of availability

Tier Basic and Standard Premium
Scale Up Yes Yes
Scale Down Yes Yes
Scale Out No Yes
Scale In No Yes

When to scale

You can use the monitoring features of Azure Cache for Redis to monitor the health and performance of your cache. Use that information to determine when to scale the cache.

You can monitor the following metrics to determine if you need to scale.

  • Redis Server Load
    • High Redis server load means that the server is unable to keep pace with requests from all the clients. Because a Redis server is a single threaded process, it's typically more helpful to scale out rather than scale up. Scaling out by enabling clustering helps distribute overhead functions across multiple Redis processes. Scaling out also helps distribute TLS encryption/decryption and connection/disconnection, speeding up cache instances using TLS.
    • Scaling up can still be helpful in reducing server load because background tasks can take advantage of the more vCPUs and free up the thread for the main Redis server process.
  • Memory Usage
    • High memory usage indicates that your data size is too large for the current cache size. Consider scaling to a cache size with larger memory. Either scaling up or scaling out is effective here.
  • Client connections
    • Each cache size has a limit to the number of client connections it can support. If your client connections are close to the limit for the cache size, consider scaling up to a larger tier. Scaling out doesn't increase the number of supported client connections.
    • For more information on connection limits by cache size, see Azure Cache for Redis Pricing.
  • Network Bandwidth
    • If the Redis server exceeds the available bandwidth, clients requests could time out because the server can't push data to the client fast enough. To see how much server-side bandwidth is being used, check "Cache Read" and "Cache Write" metrics. If your Redis server is exceeding available network bandwidth, you should consider scaling out or scaling up to a larger cache size with higher network bandwidth.
    • For more information on network available bandwidth by cache size, see Azure Cache for Redis planning FAQs.
  • Internal Defender Scans
    • On C0 and C1 Standard caches, while internal Defender scanning is running on the VMs, you might see short spikes in server load not caused by an increase in cache requests. You see higher latency for requests while internal Defender scans are run on these tiers a couple of times a day. Caches on the C0 and C1 tiers only have a single core to multitask, dividing the work of serving internal Defender scanning and Redis requests. You can reduce the effect by scaling to a higher tier offering with multiple CPU cores, such as C2.
    • The increased cache size on the higher tiers helps address any latency concerns. Also, at the C2 level, you have support for as many as 2,000 client connections.

For more information on determining the cache pricing tier to use, see Choosing the right tier and Azure Cache for Redis planning FAQs.

Note

For more information on how to optimize the scaling process, see the best practices for scaling guide

Prerequisites/limitations of scaling Azure Cache for Redis

You can scale up/down to a different pricing tier with the following restrictions:

  • You can't scale from a higher pricing tier to a lower pricing tier.
    • You can't scale from a Premium cache down to a Standard or a Basic cache.
    • You can't scale from a Standard cache down to a Basic cache.
  • You can scale from a Basic cache to a Standard cache but you can't change the size at the same time. If you need a different size, you can later do a scaling operation to the wanted size.
  • You can't scale from a Basic cache directly to a Premium cache. First, scale from Basic to Standard in one scaling operation, and then from Standard to Premium in the next scaling operation.
  • You can't scale from a larger size in to the C0 (250 MB) size. However, you can scale in to any other size within the same pricing tier. For example, you can scale in from C5 Standard to C1 Standard.

You can scale out/in with the following restrictions:

  • Scale out is only supported on the Premium tiers.
  • Scale in is only supported on the Premium tier.
  • On the Premium tier, clustering must be enabled first before scaling in or out.
  • On the Premium tier, support for scale out up to 10 shards is generally available. Support for up to 30 shards is in preview. (For caches with two replicas, the shard limit is 20. With three replicas, shard limit is 15.)

How to scale - Basic, Standard, and Premium tiers

Scale up and down using the Azure portal

  1. To scale your cache, browse to the cache in the Azure portal and select Scale from the Resource menu.

    Screenshot showing Scale on the resource menu.

  2. Choose a pricing tier in the working pane and then choose Select.

    Screenshot showing the Azure Cache for Redis tiers.

  3. While the cache is scaling to the new tier, a Scaling Redis Cache notification is displayed.

    Screenshot showing the notification of scaling.

  4. When scaling is complete, the status changes from Scaling to Running.

Note

When you scale a cache up or down using the portal, both maxmemory-reserved and maxfragmentationmemory-reserved settings automatically scale in proportion to the cache size. For example, if maxmemory-reserved is set to 3 GB on a 6-GB cache, and you scale to 12-GB cache, the settings automatically get updated to 6 GB during scaling. When you scale down, the reverse happens.

Scale up and down using PowerShell

You can scale your Azure Cache for Redis instances with PowerShell by using the Set-AzRedisCache cmdlet when the Sizeor Sku properties are modified. The following example shows how to scale a cache named myCache to a 6-GB cache in the same tier.

   Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -Size 6GB

For more information on scaling with PowerShell, see To scale an Azure Cache for Redis using PowerShell.

Scale up and down using Azure CLI

To scale your Azure Cache for Redis instances using Azure CLI, call the az redis update command. Use the sku.capcity property to scale within a tier, for example from a Standard C0 to Standard C1 cache:

az redis update --cluster-name myCache --resource-group myGroup --set "sku.capacity"="2"

Use the 'sku.name' and 'sku.family' properties to scale up to a different tier, for instance from a Standard C1 cache to a Premium P1 cache:

az redis update --cluster-name myCache --resource-group myGroup --set "sku.name"="Premium" "sku.capacity"="1" "sku.family"="P"

For more information on scaling with Azure CLI, see Change settings of an existing Azure Cache for Redis.

Note

When you scale a cache up or down programatically (e.g. using PowerShell or Azure CLI), any maxmemory-reserved or maxfragmentationmemory-reserved are ignored as part of the update request. Only your scaling change is honored. You can update these memory settings after the scaling operation has completed.