Azure Managed Redis Deep Dive

Key Concepts

• Redis: An open-source, in-memory data structure store, used as a database, cache, and message broker.
• In-Memory Database: A database that stores data in the main memory (RAM) of a computer for faster access.
• Key-Value Store: A type of database that uses a simple method of storing data as a collection of key-value pairs.
• Data Structures in Redis: Strings, Lists, Sets, Hashes.
• Application Patterns: Caching, Session Management, Token Storage, API Payloads, AI Inferencing Caching, Message Queues, Leaderboards.
• Azure Managed Redis: A fully managed, enterprise-ready Redis solution on Azure.
• High Availability (HA): A system design that ensures a desired level of operational performance for a longer period.
• Availability Zones: Distinct physical locations within an Azure region that are isolated from failures in other zones.
• Asynchronous Replication: Data replication where the primary system does not wait for confirmation from the replica before acknowledging the transaction.
• Sharding: A database architecture that partitions data across multiple database servers.
• Primary/Replica: In replication, the primary is the source of truth, and the replica is a copy that can be used for read operations or failover.
• RDB (Redis Database): A point-in-time snapshot of Redis data.
• AOF (Append-Only File): A Redis persistence option that logs every write operation received by the server.
• Geo-replication: Replicating data across different geographic regions.
• Active Geo-replication: A configuration where multiple geo-replicated instances are active and can serve read/write requests.
• Conflict-Free Replicated Data Types (CRDTs): Data structures that allow concurrent updates from multiple replicas without conflicts.
• SKUs (Stock Keeping Units): Different pricing and performance tiers for Azure Managed Redis.
• Flash-based Solution: A Redis option that uses flash storage for less frequently accessed data, offering lower cost but reduced performance.
• Private Endpoints: A network interface that connects privately and securely to an Azure service.
• Entra Integrated Authentication: Azure Active Directory (now Microsoft Entra ID) authentication for Azure services.
• Maintenance Window: A scheduled period for performing system maintenance.

Redis Fundamentals and Application Patterns

Redis is an in-memory database that stores its entire dataset in the computer's RAM, enabling incredibly low latencies for interactions. It operates as a key-value store, where each piece of data is associated with a unique key. While the fundamental data type is a string (text or binary), Redis supports more complex data structures:

• Lists: Ordered sequences of strings that support operations like pushing and popping elements.
• Sets: Unordered collections of unique strings.
• Hashes: Structures that store field-value pairs, where the key represents multiple fields and their corresponding values.

The primary application pattern for Redis is caching for more durable data stores like relational databases or NoSQL databases (e.g., Cosmos DB). The cache-aside pattern (also known as lazy loading) involves an application first checking the Redis cache. If the data is found (a "hit"), it's returned quickly. If not (a "miss"), the application queries the primary database, retrieves the data, and then writes it to the Redis cache for future requests. This reduces database load and improves transaction speed.

While Redis itself doesn't have built-in read-through capabilities, this logic can be implemented within the application or facilitated by frameworks. Alternatively, serverless functions (like Azure Functions) can subscribe to database change feeds (e.g., Cosmos DB's change feed) to automatically update the cache.

Beyond database caching, Redis is used for:

• Short-lived web sessions: Storing user session data.
• Tokens: Caching JSON Web Tokens (JWTs) or OAuth 2.0 tokens.
• Rendered HTML: Caching pre-rendered web page fragments.
• API payloads: Caching frequently requested API responses.
• AI Inferencing Caching: This is a significant emerging use case. For large language models (LLMs), prompts can be embedded into vector representations. If a semantically similar question has been asked before, the cached response can be returned, saving inference time and token costs. This is demonstrated with a semantic cache that identifies similar prompts within a tolerance.

Non-caching scenarios include:

• Message Queues/Streams/Pub-Sub: Facilitating asynchronous communication.
• Real-time counters.
• Leaderboards.

Azure Managed Redis: Enterprise-Ready Solution

Azure Managed Redis provides a fully managed, enterprise-ready deployment built on the enterprise version of Redis. This managed service offers enhanced capabilities beyond open-source Redis.

Additional Modules and Data Types

Azure Managed Redis supports additional modules that can be configured at instance creation time, with no extra cost:

• JSON: Native support for storing and querying full JSON documents.
• Search: Real-time indexing, querying, and searching of data, including support for vectors (embeddings) and integration with frameworks like the Microsoft Agent Framework.
• Time Series: Ingesting and processing high-volume, high-velocity telemetry data (logs, IoT data).
• Probabilistic Bloom Filters: A space-efficient probabilistic data structure used to test whether an element is a member of a set, useful for scenarios like fraud detection.

It's important to note that these modules must be enabled at creation. At the time of recording, the service is based on Redis 7.4.

Durability and High Availability

While Redis is inherently in-memory and transient, Azure Managed Redis offers options for durability and availability:

High Availability (HA)

Enabling HA creates a second identical node within the same region, deployed across different Availability Zones for resilience against zone failures. Replication between these nodes is asynchronous to maintain Redis's low-latency performance. While typically only a few milliseconds behind, this asynchronous nature is a trade-off for speed. HA configurations provide a 49 SLA.

Sharding and Cluster Configuration

In HA, data is sharded (partitioned) across different instances. The default OSS cluster configuration distributes primaries and replicas across nodes. The enterprise version uses a dense configuration where all primaries are on one node and replicas on another. A non-clustered version is available with limitations (e.g., 25 GB max size). Distributing primaries across nodes is generally more resource-efficient.

Client Interaction and Load Balancing

A load balancer provides the initial endpoint for applications. However, Redis also has a Redis proxy running on each node. When an application connects, it performs an INFO command, and the proxy returns shard configuration and port details. The application then intelligently routes requests directly to the node hosting the primary shard for that key, bypassing the load balancer for subsequent operations.

Data Persistence Options (Requires HA)

When HA is enabled, two persistence options are available:

• RDB (Redis Database): Takes snapshots of the data at configurable intervals (1, 6, or 12 hours). Each new backup deletes the old one.
• AOF (Append-Only File): Logs every write operation, flushing changes to storage approximately every second. This provides near-continuous durability, with a maximum data loss of about 1 second. This option consumes more CPU and adds a slight server load.

Geo-replication

Azure Managed Redis supports geo-replication, allowing for copies of the cache in other Azure regions. This involves creating an HA pair in a secondary region.

• Active Geo-replication: Multiple geo-replicated instances form a cluster group. Each instance has its own endpoint, and applications can be configured to connect to the closest endpoint for low latency.
• Replication Latency: The latency between regions is primarily determined by network latency.
• Multi-Region Deployments: Up to five regions can be configured.
• 59 SLA: With at least three geo-replicated regions, a 59 SLA is achievable.
• CRDTs: Conflict-free replicated data types are used to resolve concurrent updates across replicas without conflicts, ensuring data consistency.
• Use Cases: Geo-replication is used for both resiliency and for placing caches close to application instances in different geographic locations.
• Configuration: Geo-replication must be configured at the time of creation of the first instance in a cluster group. Subsequent instances join the existing group.
• Module Support: Not all modules are supported with active geo-replication (e.g., Time Series and Probabilistic Bloom are not, while JSON and Query Search are).

SKUs and Scaling

Azure Managed Redis offers various SKUs that determine the CPU to memory ratio, capacity, and performance.

• SKU Types:

  • Memory Optimized: Focuses on maximizing memory capacity.
  • General Purpose: Balanced CPU and memory.
  • Compute Optimized: Prioritizes CPU performance.
  • Flash-based Solution: Uses flash storage for less hot data, offering lower cost but significantly slower performance than memory. This option has limitations, such as not supporting geo-replication or certain modules.

• Scaling:

  • Dynamic Scaling: Instances can be scaled up or down. Scaling up is unlimited.
  • Scaling Down Limitations: Scaling down is restricted to SKUs that can support the current number of shards, as the number of shards cannot be reduced.
  • Underlying Infrastructure: While you select a CPU/memory ratio, Azure may use one or more nodes behind the scenes to meet these requirements, transparently managing the underlying infrastructure.

Networking, Authentication, and Maintenance

• Networking: The default and recommended network configuration is to use private endpoints for secure, private connectivity. Public endpoints are an option but less secure.
• Authentication: Entra integrated authentication is the preferred and most secure method. Access keys can be enabled but are generally not recommended for security-first approaches.
• Maintenance: Azure Managed Redis is a fully managed service with monthly maintenance for OS and Redis software upgrades.
  • Upgrade Process: Replicas are upgraded first, then failover occurs, and the former primary is upgraded. This is seamless for minor version upgrades.
  • Major Version Upgrades: For major version changes (e.g., 7 to 8), customers have a 90-day window to test and manually upgrade, after which it becomes automatic. This provides an opportunity to test for potential breaking changes.

Conclusion

Azure Managed Redis is a powerful, in-memory data store offering super low latency and high performance across a wide range of scenarios, from caching to complex non-caching applications. It provides robust durability and availability options, including HA, persistence, and geo-replication, allowing for deployments close to applications globally. The service is built on the enterprise version of Redis, offering advanced modules and flexible SKUs to meet diverse needs. The managed nature of the service simplifies operations, with Azure handling maintenance and upgrades.