Azure Cache Redis
Azure Redis Cache is low-latency, scalable, secure, and highly available in-memory Redis data store available for Azure.
Deployments
27
Made by
Massdriver
Official
Yes
No
Compliance
Clouds
Tags
azure-cache-redis
Azure Cache for Redis leverages Redis—a multipurpose open-source, in-memory data store—to improve performance scaling for applications with large numbers of concurrent users. As a result, it can dramatically increase throughput and lower latency by using server memory to cache frequently used data. This service is fully managed so that you can focus on development.
Use Cases
Azure Cache for Redis is a versatile solution that can address a number of common application architectures.
Improved application performance
Caching improves application performance by buffering frequently used data in memory. Querying a relational database can slow down your application, but by buffering the most common queries, Azure Cache for Redis can improve latency and reduce the provisioning requirements for your database.
Store session data
Storing too much session data in a cookie can impede performance, so cookies for shopping carts and other similar use cases often point to entries in a relational database. Azure Cache for Redis can speed up connecting a cookie to the correct user data by caching that data in memory rather than requiring a call to the full database.
Communicate between services
Azure Cache for Redis can also route messages between services in real time and provide a distributed queue for applications.
Configuration Presets
Development
The development preset sets capacity to 6 GB to handle small workloads and sets replicas per primary to 1 for high availability. Use this preset for development only.
Production
The production preset sets capacity to 26 GB to handle moderate workloads and sets replicas per primary to 2 for high availability. This preset has sufficient performance for production environments.
Design
Our bundle includes the following design choices to help simplify your deployment:
High availability
The premium tier of Azure Cache for Redis ensures high availability by provisioning two server nodes, a primary and a replica which is continually updated as a backup. In this way, your application instance can remain available even when the primary node goes down, regardless of whether the outage is planned. If the primary node goes offline for any reason, the replica automatically takes over as the new primary.
Premium Redis cache
Azure Cache for Redis uses the premium tier because of the tier’s included VNet integration features. The premium SKU allows the Redis cache instance to create a private IP address and associate it with the default subnet of your virtual network.
Redis clustering
Redis clustering offers a number of important advantages. It provides sharding, the ability to split your data set automatically among multiple nodes, and it provides the ability to continue operations when a subset of nodes is experiencing failures or is unable to communicate with the rest of the cluster. Both throughput and memory will increase linearly as you increase the number of shards. Sharding data massively improves scaling, as the data set can be larger than what a single node can support.
Failover and patching
Azure Cache for Redis improves application resiliency through automatic failover protection. With our bundle, you always have a primary node and a replica node. When the primary node goes down (either for planned maintenance or some unexpected event), the replica node automatically takes over the role of primary node, ensuring application continuity. When the old primary node comes back online, it will see that the other node is the primary and automatically designate itself as the new replica, and your application will continue operating as normal.
Best Practices
The bundle includes a number of best practices without needing any additional work on your part.
Data persistence
Redis data persistence allows you to persist data stored in Redis in the event of a failure. You can also take snapshots and back up the data. If there’s a hardware failure, you load the data.
Which persistence model should I choose?
- AOF: Append-only file persistence saves every write to a log, which has significant effect on throughput. Choose AOF persistence if your primary goal is to minimize data loss, and you can handle a lower throughput on your cache.
- RDB: Redis database persistence saves backups based on the configured backup interval with minimal effect on performance. Choose RDB persistence if you wish to maintain optimal throughput on your cache, but still want a mechanism for data recovery.
Should I use a second storage account with AOF? Use a second storage account for AOF persistence when you believe you’ve higher than expected set operations on the cache. Setting up the secondary storage account helps ensure your cache doesn’t reach storage bandwidth limits.
Private VNet integration
As noted above, it uses the premium tier to enable private VNet integration.
High availability
Every cluster comes with at least one read replica across availability zones in order to ensure high availability.
Automatic patching
We handle patching automatically to keep you up to date.
Security
TLS encryption
We enable TLS encryption by default using version 1.2. Make sure your client supports TLS.
Non-SSL port disabled
The non-SSL port (6379) is disabled by default, which requires all connections to be on the SSL port (6380). Users can optionally enable the non-SSL port, but this is not recommend it as it will allow unencrypted communication with the Redis server, which poses a security risk.
No public network access
In order to improve security, we disable public network access.
Authenticated clients
Also, by default, you can access clusters only via authenticated clients.
Observability
Massdriver provides you with visibility into the health of your systems. By default, Redis cache instances will be created with alarms connected to Massdriver to alert you when performance drops below a key threshold or fails completely. You will be notified when the memory, CPU, or server load exceeds 90%.
Trade-offs
Because of the need for private VNet integration, we use only the Redis premium SKU. We also do not support standard or enterprise Redis SKUs. We also do not currently support the following:
- Switching between different modes of data persistence
- Disabling data persistence without destroying the cache
- Geo-replication (due to the need for data persistence support)
| Variable | Type | Description |
|---|---|---|
| cluster.enable_cluster | boolean | Redis cluster automatically shards data across multiple Redis nodes, so you can create workloads of bigger memory sizes and get better performance. This cannot be disabled after deployment. |
| monitoring.mode | string | Enable and customize Function App metric alarms. |
| redis.capacity | integer | The size of the Redis memory cache. |
| redis.non_ssl_port | boolean | Enable the non-SSL (6379) port. SSL port (6380) is enabled by default. Enabling this is not recommended as it will allow unencrypted communication, which poses a security risk. |
| redis.persistence | string | Redis persistence allows you to persist data stored in Redis in the event of an outage. This cannot be changed after deployment |
| redis.redis_version | string | Azure Cache for Redis offers the latest major version of Redis and at least one previous version. The version can be upgraded, but not downgraded. |
| redis.replicas_per_primary | integer | Number of read replicas per primary node. When the primary VM becomes unavailable, the replica detects that and takes over as the new primary automatically. This cannot be changed after deployment. |
