Redis Cache is a well know caching technology and you can run it in Azure as a fully managed service. Being a fully managed service, you do not need to worry about provisioning the underlying infrastructure. If you have experience with on-premises cache servers you will know how difficult it is to build a 3-node load-balanced cache or worry about patching it. So as a Managed Service it leaves you to concentrate on building solutions that require a caching service.
There are many patterns out there where a cache is important. These may include cache-Aside, write-behind, write-through, read-through and refresh ahead. Whichever pattern you decide, Azure is a great place to build out the services.
AZURE REDIS CACHE TIERS
There are many tiers to select from, Azure gives you a great choice.
If you need geo-replication capability then basic and standard are not high enough for you. Naturally, as you go up the tiers, the higher the cost.
Many enterprises will opt for premium onwards where the combination of horizontal scaling, private link, data persistence and geo-replication are key requirements for projects. The underlying architecture is complex and fully built by Microsoft and looks like the below for premium tiers onwards.
When using the premium tier, you can actually choose between 1-3 Availability zones, many will opt for 3 zones which does make sense for maximum resiliency.
BUILDING A REDIS CACHE
Within the Azure Portal, find Azure Cache for Redis.
Fill in the basics (the location should be where your app is):
Click on the pricing details hyperlink. This is where we can select the tier you want, which we discussed in the earlier part of the blog.
You can see quite a difference in pricing from 53GB cache to 120GB cache. Important note, the basic tier should never be used for production.
From a networking perspective, you will likely opt for a private link. The ability to connect with a private IP for backend applications is important. 
The next section is about the build.
Let’s discuss this section. If you’re using the premium tier, this means you have the ability to increase shard counts. The above image shows 2 shard counts meaning 12GB cache available, this will increase costs. Obviously, the main benefit is having more GBs but it also gives you the ability to continue operations when a node is experiencing failures or is unable to communicate with the rest of the cluster allowing for more throughput capability. You can have up to 10 shards in the cluster.
Also, notice for more availability, I decide to use 3 availability zones, you can actually select 1 or 2. If you opt for a persistent storage strategy, then you need Azure Storage and ideally, you will want to access that without keys but via Managed Identity. Managed Identities are an extremely powerful concept where we no longer need to manage credentials between connecting cloud services and with no extra costs.
DATA PERSISTENCE
Why would you want to persist data? If a complete hardware failure occurs and all caches are offline, we use the persistent storage to reconstruct it from the most recent snapshot, this is called RDB persistence, there is something else called AOF where all writes are saved to a log and rebuilt from that. Check out this document for an in-depth analysis of the pros and cons: https://redis.io/topics/persistence#aof-advantages.
The data persistence screen is shown below.
Some important points regarding data persistence:
- You can’t enable both types, only one at a given time.
- Don’t forget the logged data within the storage account has associated costs assigned to it.
- If you are dealing with high throughput data then you will probably want your storage account to be premium tier.
- RDB files are backed up to storage are stored in the form of page blobs.
Now we are ready to deploy and create the cache.
You can build many different applications for your Azure Redis Cache service which includes .NET, ASP.NET, Java, Node JS, Python and even Rust apps. The prerequisites to build these apps are that you need to get the hostname, port number and access keys which you can find within the Azure portal under the settings section.
Please see the following example from Microsoft documentation: https://learn.microsoft.com/en-us/azure/azure-cache-for-redis/cache-web-app-howto.
You can confirm that Redis is online and running via the Redis console in Azure.
Click it and issue the INFO command.
TIPS FOR USING AZURE REDIS CACHE
Here are some general tips when using Azure Redis Cache
- The location of the Redis Cache service should be close to your application.
- Data structures within Redis mean that larger key-value sizes lead to fragmentation of memory space. And these larger memory requirements mean more network data transfer. Redis states to use 100KB maximum.
- Creating connections is expensive (can cause latency) so reuse connections or at least close older ones before releasing them.
- You should be thinking about expiration times and expiration sliding strategies.
- Some Redis commands are single threaded so use them with caution, for example, KEYS command may ruin performance.
- You need to cater for possible failover issues. An unplanned failover might happen because of hardware failure, network failure, or other unexpected outages to the primary node. Developers should use the runtime maintenance notifications on a publish/subscribe (pub/sub) channel called AzureRedisEvents. Many popular Redis client libraries support subscribing to pub/sub channels. Receiving notifications from the AzureRedisEventschannel which is usually a simple addition to your client application.
- Consider tweaking memory policies to improve system responsiveness. There are 3 key settings. These are called max memory policy, max memory reserved and max memory fragmentation memory-reserved. Microsoft covers these settings in depth here: https://learn.microsoft.com/en-us/azure/azure-cache-for-redis/cache-configure#memory-policies.
CONCLUSION
As you can see from this blog post, Azure Redis is a very mature cache technology which can be built with ease via the Azure Portal. Well-built integrations with components such as Azure Storage, private link, managed identity and support for various languages means building a cloud-native solution at a cost-effective price point is very much possible
If you’re interested in Transparity helping you implement in Azure Redis Cache, just get in touch.
