Architecture d’Azure Managed Redis (préversion)

Azure Managed Redis (préversion) s’exécute sur la pile Redis Entreprise, ce qui offre des avantages significatifs par rapport à l’édition communautaire de Redis. Les informations suivantes fournissent plus de détails sur l’architecture d’Azure Managed Redis, y compris des informations qui peuvent être utiles aux utilisateurs avec pouvoir.

Comparaison avec Azure Cache pour Redis

Les niveaux Essentiel, Standard et Premium d’Azure Cache pour Redis étaient basés sur l’édition communautaire de Redis. Cette version de Redis présente plusieurs limitations significatives, notamment l’utilisation d’un thread unique par conception. Cela réduit considérablement les performances et rend la mise à l’échelle moins efficace, car plus de processeurs virtuels ne sont pas entièrement utilisés par le service. Une instance Azure Cache pour Redis classique utilise une architecture semblable à celle-ci :

Notez que deux machines virtuelles sont utilisées : une principale et un réplica. Ces machines virtuelles sont également appelées « nœuds ». Le nœud principal contient le processus Redis principal et accepte toutes les écritures. La réplication est effectuée de manière asynchrone sur le nœud réplica pour fournir une copie de sauvegarde pendant la maintenance, la mise à l’échelle ou une défaillance inattendue. Chaque nœud est capable d’exécuter un seul processus de serveur Redis en raison de la conception à thread unique de Redis communautaire.

Améliorations architecturales d’Azure Managed Redis

Azure Managed Redis utilise une architecture plus avancée qui ressemble à ceci :

Il existe plusieurs différences :

• Chaque machine virtuelle (ou « nœud ») exécute plusieurs processus de serveur Redis (appelés « partitions ») en parallèle. Plusieurs partitions permettent une utilisation plus efficace des processeurs virtuels sur chaque machine virtuelle et des performances plus élevées.
• Toutes les partitions Redis principales ne se trouvent pas sur la même machine virtuelle ou sur le même nœud. Au lieu de cela, les partitions principales et de réplica sont réparties entre les deux nœuds. Étant donné que les partitions principales utilisent plus de ressources de processeur que les partitions de réplica, cette approche permet d’exécuter plus de partitions principales en parallèle.
• Chaque nœud dispose d’un processus de proxy hautes performances pour gérer les partitions, gérer la gestion des connexions et déclencher la réparation automatique.

Cette architecture offre des performances supérieures et des fonctionnalités avancées telles que la géoréplication active

Clustering

Étant donné que Redis Entreprise est en mesure d’utiliser plusieurs partitions par nœud, chaque instance d’Azure Managed Redis est configurée en interne pour utiliser le clustering, sur tous les niveaux et références SKU. Cela inclut des instances plus petites qui sont configurées uniquement pour utiliser une seule partition. Le clustering est un moyen de diviser les données dans l’instance Redis sur plusieurs processus Redis, également appelé « partitionnement ». Azure Managed Redis offre deux stratégies de cluster qui déterminent le protocole disponible pour les clients Redis pour la connexion à l’instance de cache.

Stratégies du cluster

Azure Managed Redis propose deux options pour la stratégie de clustering : OSS et Entreprise. La stratégie de cluster OSS est recommandée pour la plupart des applications parce qu’elle prend en charge un débit maximal plus élevé, mais il y a des avantages et des inconvénients à chaque version.

La stratégie de clustering OSS implémente la même API Cluster Redis que l’édition communautaire de Redis. L’API Cluster Redis permet au client Redis de se connecter directement aux partitions sur chaque nœud Redis, de réduire la latence et d’optimiser le débit du réseau, ce qui permet au débit de s’adapter quasiment linéairement au fur et à mesure que le nombre de partitions et de processeurs virtuels augmente. La stratégie de clustering OSS offre généralement les meilleures performances de latence et de débit. Toutefois, la stratégie de cluster OSS nécessite que votre bibliothèque cliente prenne en charge l’API Cluster Redis. Aujourd’hui, presque tous les clients Redis prennent en charge l’API Cluster Redis, mais la compatibilité peut être un problème pour les anciennes versions clientes ou les bibliothèques spécialisées. La stratégie de clustering OSS ne peut pas non plus être utilisée avec le module RediSearch.

La stratégie de clustering Enterprise est une configuration plus simple qui utilise un seul point de terminaison pour toutes les connexions clientes. L’utilisation de la stratégie de clustering Enterprise achemine toutes les demandes vers un seul nœud Redis qui est ensuite utilisé comme proxy, acheminant en interne les demandes vers le nœud approprié dans le cluster. L’avantage de cette approche est qu’Azure Managed Redis ne semble pas utiliser de clusters pour les utilisateurs. Cela signifie que les bibliothèques clientes Redis n’ont pas besoin de prendre en charge le clustering Redis pour obtenir certains des avantages en matière de performances de Redis Entreprise, ce qui améliore la compatibilité descendante et simplifie la connexion. L’inconvénient est que le proxy mono-nœud peut être un goulot d’étranglement, que ce soit dans l’utilisation du calcul ou le débit réseau. La stratégie de clustering Enterprise est la seule qui peut être utilisée avec le module RediSearch. Bien que la stratégie de cluster d’entreprise fait passer une instance Azure Managed Redis pour non clusterisée auprès des utilisateurs, elle présente toujours certaines limitations avec les commandes à plusieurs clés.

Scale-out ou ajout de nœuds

Le logiciel Redis Entreprise de base est capable d’effectuer un scale-up (à l’aide de machines virtuelles plus volumineuses) ou d’effectuer un scale-out (en ajoutant davantage de nœuds/machines virtuelles). En fin de compte, l’une ou l’autre action de mise à l’échelle accomplit la même chose, c’est-à-dire ajouter plus de mémoire, plus de processeurs virtuels et plus de partitions. En raison de cette redondance, Azure Managed Redis n’offre pas la possibilité de contrôler le nombre spécifique de nœuds utilisés dans chaque configuration. Ce détail d’implémentation est caché à l’utilisateur afin d’éviter toute confusion, complexité et configurations non optimales. Au lieu de cela, chaque référence SKU est conçue avec une configuration de nœud pour optimiser les processeurs virtuels et la mémoire. Certaines références SKU d’Azure Managed Redis utilisent seulement deux nœuds, tandis que d’autres en utilisent davantage.

Commandes multi-clés

Étant donné que les instances Azure Managed Redis sont conçues avec une configuration clusterisée, vous risquez de voir des exceptions CROSSSLOT sur les commandes qui fonctionnent sur plusieurs clés. Le comportement varie en fonction de la stratégie de clustering utilisée. Si vous utilisez la stratégie de clustering OSS, les commandes multi-clés ont besoin que toutes les clés soient mappées au même emplacement de hachage.

Vous risquez aussi de voir des erreurs CROSSSLOT avec la stratégie de clustering Enterprise. Seules les commandes multi-clés suivantes sont autorisées sur les emplacements avec clustering Enterprise : DEL, MSET, MGET, EXISTS, UNLINK et TOUCH.

Dans les bases de données en mode Actif-Actif, les commandes d’écriture multi-clés (DEL, MSET, UNLINK) ne peuvent être exécutées que sur les clés situées dans le même emplacement. Les commandes multi-clés suivantes sont toutefois autorisées sur les emplacements des bases de données en mode Actif-Actif : MGET, EXISTS et TOUCH. Pour plus d’informations, consultez Clustering de bases de données.

Configuration du partitionnement

Chaque référence SKU d’Azure Managed Redis est configurée pour exécuter un nombre spécifique de processus serveur Redis, partitions en parallèle. La relation entre les performances de débit, le nombre de partitions et le nombre de processeurs virtuels disponibles sur chaque instance est compliquée. L’ajout de partitions augmente généralement les performances, car les opérations Redis peuvent être exécutées en parallèle. Toutefois, si les partitions ne sont pas en mesure d’exécuter des commandes car aucun processeur virtuel n’est disponible pour exécuter des commandes, les performances peuvent réellement chuter. Le tableau suivant présente la configuration de partitionnement pour chaque référence SKU d’Azure Managed Redis. Ces partitions sont mappées pour optimiser l’utilisation de chaque processeur virtuel tout en réservant des cycles de processeurs virtuels pour le proxy Redis Entreprise, l’agent de gestion et les tâches système du système d’exploitation qui affectent également les performances.

Exécution sans le mode haute disponibilité activé

L’exécution est possible sans le mode haute disponibilité activé. Cela signifie que votre instance Redis n’a pas de réplication activée et n’a pas accès au contrat SLA de disponibilité. Nous vous déconseillons d’exécuter sans le mode haute disponibilité en dehors des scénarios de développement/test. Vous ne pouvez pas désactiver la haute disponibilité dans une instance qui a déjà été créée. Toutefois, vous pouvez activer la haute disponibilité dans une instance qui ne l’a pas. Étant donné qu’une instance s’exécutant sans haute disponibilité utilise moins de machines virtuelles/nœuds, les processeurs virtuels ne peuvent pas être utilisés aussi efficacement, de sorte que les performances peuvent être inférieures.

Mémoire réservée

Sur chaque instance Azure Managed Redis, environ 20 % de la mémoire disponible est réservée en tant que mémoire tampon pour les opérations non mises en cache, telles que la réplication pendant le basculement et la mémoire tampon de géoréplication active. Cette mémoire tampon permet d’améliorer les performances du cache et d’empêcher le manque de mémoire.

Effectuer un scale-down

Le scale-down n’est actuellement pas pris en charge sur Azure Managed Redis. Pour plus d’informations, consultez Conditions préalables/limitations de la mise à l’échelle d’Azure Managed Redis.

Niveau Flash optimisé

Le niveau Flash optimisé utilise à la fois un stockage Flash NVMe et de la RAM. Le stockage Flash étant moins coûteux, l’utilisation du niveau Flash optimisé vous permet de compenser la relative perte de performances par un prix compétitif.

Sur les instances Flash optimisé, 20 % de l’espace du cache se trouve sur la RAM, tandis que les autres 80 % utilisent le stockage Flash. Toutes les clés sont stockées sur la RAM, tandis que les valeurs peuvent être stockées dans le stockage Flash ou sur la RAM. Le logiciel Redis détermine intelligemment l’emplacement des valeurs. Les valeurs chaudes auxquelles les utilisateurs accèdent fréquemment sont stockées dans la RAM, tandis que les valeurs froides, moins utilisées, sont conservées dans la mémoire Flash. Avant d’être lues ou écrites, les données doivent être déplacées vers la RAM, devenant ainsi des données chaudes.

En raison du fait que Redis optimise le niveau de performance, l’instance remplit initialement la RAM disponible avant d’ajouter des éléments au stockage Flash. Le fait de remplir initialement la RAM entraîne des conséquences en termes de niveau de performance :

• Un niveau de performance plus élevé et une latence plus faible peuvent être observés lors de tests impliquant une faible utilisation de la mémoire. Les tests effectués avec une instance de cache complète peuvent entraîner un niveau de performance inférieur, car seule la RAM est utilisée dans la phase de test impliquant une faible utilisation de la mémoire.
• En écrivant davantage de données dans le cache, la proportion de données dans la RAM diminue comparativement au stockage Flash, ce qui entraîne généralement une diminution de la latence et des niveaux de performances liés au débit.

Charges de travail adaptées au niveau Flash optimisé

Les charges de travail susceptibles de bien fonctionner avec le niveau Flash optimisé présentent souvent les caractéristiques suivantes :

• Lecture intensive, avec un ratio élevé de commandes de lecture par rapport aux commandes d’écriture.
• L’accès est axé sur un sous-ensemble de clés qui sont utilisées beaucoup plus fréquemment que le reste du jeu de données.
• Valeurs relativement grandes par rapport aux noms de clés. (Les noms de clés étant toujours stockés dans la RAM, les valeurs de grande taille peuvent constituer un goulot d’étranglement pour la croissance de la mémoire.)

Charges de travail non adaptées au niveau Flash optimisé

Certaines charges de travail présentent des caractéristiques d’accès moins optimisées pour la conception du niveau Flash optimisé :

• Charges de travail nécessitant beaucoup d’écritures.
• Motifs d’accès aux données aléatoires ou uniformes sur une grande partie du jeu de données.
• Noms de clés longs avec des valeurs de taille relativement petite.

Étapes suivantes

• Mettre à l’échelle une instance Azure Managed Redis