Choose a cache tier
Redis is a key-value store, NoSQL database. Its implementation is very similar to Azure Table Storage. The main difference is Redis is very high performing by keeping the data in memory most of the time. By default, Redis also doesn’t persist the data between reboots. There are exceptions to this, but the main purpose of keeping Redis cache in memory is for fast data retrieval and fast aggregations. This allows important data to be easily accessible to an application without loading the backend data store. As a result, Redis is typically not used as a data store for an application, but used to augment the data store you’ve already selected. Imagine using Azure SQL Database as your main data repository. Your application constantly looks up sales tax for all 50 states. Some cities even have their own sales tax that’s higher than the state’s sales tax. Constantly looking this up can compete with I/O for the rest of your application’s functions. Offloading the sales tax lookup to a pinned Redis cache will not only make that lookup much faster, but will free up resources for your data repository for things like taking orders, updating addresses, awarding sales commission, and general reporting.
This is just one example of how Redis can be used. Redis has many uses, but primarily it’s a temporary storage location of data that has a longer lifespan. That data needs to be expired when it’s out of date and re-populated.
Azure Redis Cache is the Azure product built around Redis and offering it as a Platform-as-a-Service (PAAS) product.
This skill covers how to:
Choose a cache tier
Implement data persistence
Implement security and network isolation
Tune cluster performance
Integrate Redis caching with ASP.NET session and cache providers
First we need to create an Azure Redis Cache account using the Azure portal.
Log in to the Azure portal.
Click New, Databases, Redis Cache. Click Create.
In the New Redis Cache blade, specify configuration parameters (Figure 2-28).
FIGURE 2-28 Azure Redis Cache Panel
Choose a DNS name for your cache. It must be globally unique.
Choose a Subscription, Resource group, and Location for the Redis Cache. Remember to keep it close to the application that will be using it.
Choose a Pricing tier for Redis Cache.
There are three tiers of Azure Redis Cache: Basic, Standard, and Premium. Basic is the cheapest tier and allows up to 53GB of Redis Cache database size. Standard has the same storage limit, but includes replication and failover with master/slave replication. This replication is automatic between two nodes. Premium increases ten times to 530GB. It also offers data persistence, meaning that data will survive power outages. It also includes much better network performance, topping out at 40,000 client connections. Obviously, the pricing increases as you move up from Basic through Premium.
Redis peristance allows you to save data to disk instead of just memory. Additionally, you can take snapshots of your data for backup purposes. This allows your Redis cache to survive hardware failure. Redis persistence is implemented through the RDB model, where data is streamed out to binary into Azure Storage blobs. Azure Redis Cache persistence is configured through the following pane shown in Figure 2-29.
FIGURE 2-29 Redis data persistence
On this pane, you can configure the frequency of the RDB snapshot, as well as the storage account that will be the storage target.
More Info: Import/Export RDB
You can also manually import and export the RDB snapshot. More information is found here: https://docs.microsoft.com/en-us/azure/redis-cache/cache-how-to-import-export-data.
Azure Redis Cache’s primary security mechanism is done through access keys. We’ve used access keys in Azure Storage blobs, Azure Storage tables, and Azure Cosmos DB. In addition to access keys, Azure Redis Cache offers enhanced security when you use the premium offering. This is done primarily through the Virtual Network (VNET). This allows you to hide Redis Cache behind your application and not have a public URL that is open to the internet.
The VNET is configured at the bottom of the New Redis Cache pane (pictured earlier.) You can configure the virtual network when creating the Azure Redis Cache account. You cannot configure it after it has been created. Also, you can only use a VNET that exists in the same data center as your Azure Redis Cache account. Azure Redis Cache must be created in an empty subnet.
When creating an Azure Redis Cache account, select Virtual Network towards the bottom. You will see the following pane shown in Figure 2-30.
FIGURE 2-30 Azure Redis Cache Virtual Network pane
This is where you can configure your static IP address and subnet.
More Info: Virtual Networking
For more information on Azure Virtual Networking, see here: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview.
Doing this isolates your Azure Redis Cache service behind your virtual network and keeps it from being accessed from the internet.
Also with the premium service, you can implement a Redis Cluster. Redis clusters allow you to split the dataset among multiple nodes, allowing you to continue operations when a subset of the nodes experience failure, give more throughput, and increase memory (and there for total database) size as you increase the number of shards. Redis clustering is configured when you create the Azure Redis Cache account (Figure 2-31). The reason why Premium can store 10 times the data as the other two tiers is because clustering allows you to choose the number of nodes in the cluster, from 1 to 10.
FIGURE 2-31 Redis Cache Clustering
Once the cache is created, you use it just like a non-clustered cache. Redis distributes your data for you.
Session state in an ASP.NET applications is traditionally stored in either memory or a SQL Server database. Session state in memory is difficult to implement if the server is a member of a server farm and the user changes which server they’re attached to. Session state would be lost in that case. Storing session state in a SQL database solves that problem, but introduces database management of performance, latency, and license management. Often databases are already under high load and don’t need the added load of managing a high amount of session state.
Redis cache is an excellent place to store session state. To implement this, use the Redis Cache Session State Nuget package. Once added to the project, you just have to add the following line to your web.config file under the providers section:
<add name="MySessionStateStore"
host = "127.0.0.1"
port = ""
accessKey = ""
ssl = "false"
throwOnError = "true"
retryTimeoutInMilliseconds = "0"
databaseId = "0"
applicationName = ""
connectionTimeoutInMilliseconds = "5000"
operationTimeoutInMilliseconds = "5000"
/>
<add name="MySessionStateStore" type="Microsoft.Web.Redis.RedisSessionStateProvider"
host="127.0.0.1" accessKey="" ssl="false"/>
The host attribute points to the endpoint of your Azure Redis account. ApplicationName allows multiple applications to use the same Redis database. Every other attribute is self-explanatory.
There is a different Nuget packaged called the Redis Output Cache Provider. This will store page output in Redis cache for future use. It’s configured in a similar manner as the previous product.