Movatterモバイル変換


[0]ホーム

URL:


Skip to main content

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Download Microsoft EdgeMore info about Internet Explorer and Microsoft Edge
Table of contentsExit editor mode

What is Azure Managed Redis?

  • Applies to: ✅ Azure Managed Redis
Feedback

In this article

Azure Managed Redis provides an in-memory data store based on theRedis Enterprise software. Redis Enterprise improves the performance and reliability of the community edition of Redis, while maintaining compatibility. Microsoft operates the service, hosted on Azure, and usable by any application within or outside of Azure.For more information on how Azure Managed Redis is built, seeAzure Managed Redis Architecture.

Azure Managed Redis can improve the performance and scalability of an application that heavily uses backend data stores. It's able to process large volumes of application requests by keeping frequently accessed data in the server memory, which can be written to and read from quickly.

Redis brings a critical low-latency and high-throughput data storage solution to modern applications. Additionally, Redis is increasingly used for noncaching applications, including data ingestion, deduplication, messaging, and leaderboards

Azure Managed Redis can be deployed standalone, or deployed along with other Azure app or database services, such as Azure Container Apps, Azure App Service, Azure Functions, Azure SQL, or Azure Cosmos DB.

Key scenarios

Azure Managed Redis improves application performance by supporting common application architecture patterns. Some of the most common include the following patterns:

PatternDescription
Data cacheDatabases are often too large to load directly into a cache. It's common to use thecache-aside pattern to load data into the cache only as needed. When the system makes changes to the data, the system can also update the cache, which is then distributed to other clients. Additionally, the system can set an expiration on data, or use an eviction policy to trigger data updates into the cache.
Content cacheMany web pages are generated from templates that use static content such as headers, footers, banners. These static items shouldn't change often. Using an in-memory cache provides quick access to static content compared to backend datastores. This pattern reduces processing time and server load, allowing web servers to be more responsive. It can allow you to reduce the number of servers needed to handle loads. Azure Managed Redis provides the Redis Output Cache Provider to support this pattern with ASP.NET.
Session storeThis pattern is commonly used with shopping carts and other user history data that a web application might associate with user cookies. Storing too much in a cookie can have a negative effect on performance as the cookie size grows and is passed and validated with every request. A typical solution uses the cookie as a key to query the data in a database. When you use an in-memory cache, like Azure Managed Redis, to associate information with a user is faster than interacting with a full relational database.
DeduplicationOften, you need to determine if an action already happened in a system, such as determining if a username is taken or if a customer was already sent an email. In Azure Managed Redis, bloom filters can rapidly determine duplicates, and prevent problems.
LeaderboardsRedis offers simple and powerful support for developing leaderboards of all kinds using thesorted set data structure. Additionally, usingactive geo-replication can allow one leaderboard to be shared globally.
Job and message queuingApplications often add tasks to a queue when the operations associated with the request take time to execute. Longer running operations are queued to be processed in sequence, often by another server. This method of deferring work is called task queuing. Azure Managed Redis provides a distributed queue to enable this pattern in your application.
PowerBI/Analytics AccelerationYou can use the Redis ODBC driver to utilize Redis for BI, reporting, and analytics use-cases. Because Redis is typically much faster than relational databases, using Redis in this way can dramatically increase query responsiveness.
Distributed transactionsApplications sometimes require a series of commands against a backend data-store to execute as a single atomic operation. All commands must succeed, or all must be rolled back to the initial state. Azure Managed Redis supports executing a batch of commands as a singletransaction.

Redis version

Azure Managed Redis supports Redis version 7.4.x. For more information, seeHow to upgrade the version of your Azure Managed Redis instance.

Choosing the right tier

There are four tiers of Azure Managed Redis available, each with different performance characteristics and price levels.

Tiers and SKUs at a glance

Here are three tiers store that store data in memory:

  • Memory Optimized Ideal for memory-intensive use cases that require a high memory-to-vCPU ratio (8:1) but don't need the highest throughput performance. It provides a lower price point for scenarios where less processing power or throughput is necessary, making it an excellent choice for development and testing environments.

  • Balanced (Memory + Compute) Offers a balanced memory-to-vCPU (4:1) ratio, making it ideal for standard workloads. This tier provides a healthy balance of memory and compute resources.

  • Compute Optimized Designed for performance-intensive workloads requiring maximum throughput, with a low memory-to-vCPU (2:1) ratio. It's ideal for applications that demand the highest performance.

    An image of a table that shows a comparison of skus and tiers.

Here's the tier that stores data both in-memory and on-disk:

  • Flash Optimized (preview) Enables Redis clusters to automatically move less frequently accessed data from memory (RAM) to NVMe storage. This reduces performance, but allows for cost-effective scaling of caches with large datasets.

    An image of a table that shows Flash Optimized tiers in a table showing storage usage.

You can also use thedata persistence feature to store data on-disk for the in-memory tiers. Data persistence stores a backup copy of data on-disk for quick recovery if you experience an unexpected outage. Data persistence is different from the Flash Optimized tier, which is designed to store data on-disk for typical operations.

Storing some data on-disk using the Flash Optimized tier doesn't increase data resiliency. You can use data persistence on the Flash Optimized tier as well.

Note

For more information on how the Flash Optimized tier is architected, seeAzure Managed Redis Architecture

Important

All in-memory tiers that use over 235 GB of storage are in Public Preview, including Memory Optimized M350 and higher; Balanced B350 and higher; and Compute Optimized X350 and higher. All these tiers and higher are in Public Preview.

All Flash Optimized tiers are in Public Preview.

Feature comparison

The following table helps describe some of the features supported by tier:

Feature DescriptionMemory OptimizedBalancedCompute OptimizedFlash Optimized
Size (GB)12 - 19200.5 - 9603 - 720250 - 4500
Service Level Agreement (SLA)YesYesYesYes
Data encryption in transitYes (Private endpoint)Yes (Private endpoint)Yes (Private endpoint)Yes (Private endpoint)
Replication and failoverYesYesYesYes
Network isolationYesYesYesYes
Microsoft Entra ID based authenticationYesYesYesYes
ScalingYesYesYesYes
High availability*Yes*Yes*Yes*Yes
Data persistenceYesYesYesYes
Geo-replicationYes (Active)Yes (Active)Yes (Active)No
Non-clustered instancesYesYesYesNo
Connection audit logsYes (Event-based)Yes (Event-based)Yes (Event-based)Yes (Event-based)
JSON data structures(that is, Redis JSON)YesYesYesYes
Search functionality (including vector search)YesYesYesNo
Probabilistic data structures (that is, Redis Bloom)YesYesYesYes
Time Series database capability (that is, Redis TimeSeries)YesYesYesYes
Import/ExportYesYesYesYes

* WhenHigh availability is enabled, Azure Managed Redis is zone redundant in regions with multiple Availability Zones.

When you use High availability (HA), an Azure Managed Redis instance is deployed with primary and replica shards across two nodes. In regions without Availability Zones, the primary and replica shards are deployed across two nodes in the same zone.

Important

The Balanced B0 and B1 SKU options don't support active geo-replication.

Note

Scaling down support is limited in some situations. For more information, seeLimitations of scaling Azure Managed Redis.

Network performance

If you have a workload that requires high throughput, network bandwidth might cause a bottleneck. You can increase bandwidth by moving up to a higher performance tier or by moving to a large instance size. Larger size instances have more bandwidth because of the underlying VM that hosts the cache. Higher bandwidth limits help you avoid network saturation that causes timeouts in your application. For more information on bandwidth performance, seePerformance testing

Maximum number of client connections

Each SKU has a maximum number of client connections. This limit increases with higher performance tiers and larger instances sizes. The following table shows the maximum client connections allowed per Azure Managed Redis SKU.

Memory Optimized, Balanced, and Compute Optimized SKUs

This table shows the max connections by tier and memory size in the Memory Optimized, Balanced, and Compute SKUs.

Size (GB)Memory
Optimized
BalancedCompute
Optimized
0.5-15,000-
1-15,000-
3-15,00030,000
6-15,00030,000
1215,00030,00075,000
2430,00075,000150,000
6075,000150,000200,000
120150,000200,000200,000
175200,000200,000200,000
235200,000200,000200,000
360 *200,000200,000200,000
480 *200,000200,000200,000
720 *200,000200,000200,000
960 *200,000200,000-
1440 *200,000--
1920 *200,000--
4500 *---

* The sizes with an asterisk are in Public Preview.

Flash Optimized SKU

This table shows the max connections by tier and memory size in the Flash optimized (preview) SKU.

Size (GB)Flash
Optimized
(preview)
235 *75,000
480 *150,000
720 *200,000
960 *200,000
1440 *200,000
1920 *200,000
4500 *200,000

* The sizes with an asterisk are in Public Preview.

High availability

Azure Managed Redis provides high availability. The SLA only covers connectivity to the cache endpoints. The SLA doesn't cover protection from data loss. For more information on the SLA, see theSLA. It's possible to disable high availability in an Azure Managed Redis instance. Disabling high availability lowers the price but results in data loss and downtime. We only recommend disabling high availability for dev/test scenarios.

Other pricing considerations

Important

Azure Managed Redis Enterprise requires an IP address for each cache instance. Currently, the IP address charge is absorbed by Azure Managed Redis and not passed on to customers. Billing can change in the future. For more information, seeIP address pricing.

Important

Using active geo-replication produces data transfer between Azure regions. These bandwidth charges are currently absorbed by Azure Managed Redis and not passed on to customers. Billing can change in the future. For more information, seeBandwidth pricing.

Availability by region

Azure Managed Redis is continually expanding into new regions. To check the availability by region, seeProducts available by region.

Moving from Azure Cache for Redis

For more information about migrating from Azure Cache for Redis to Azure Managed Redis, seeMove from Azure Cache for Redis to Azure Managed Redis.

Related content


Feedback

Was this page helpful?

YesNoNo

Need help with this topic?

Want to try using Ask Learn to clarify or guide you through this topic?

Suggest a fix?

  • Last updated on

In this article

Was this page helpful?

YesNo
NoNeed help with this topic?

Want to try using Ask Learn to clarify or guide you through this topic?

Suggest a fix?