Azure Cache pour Redis et la fiabilité

Article
11/14/2023

Azure Cache pour Redis fournit un magasin de données en mémoire basé sur le logiciel Redis (Remote Dictionary Server). Il s’agit d’un cache de données sécurisé et d’un répartiteur de messagerie qui permet aux applications d’accéder aux données via un débit élevé et une faible latence.

Les concepts clés et les bonnes pratiques de fiabilité sont les suivants :

Les sections suivantes incluent des considérations relatives à la conception, une check-list de configuration et des options de configuration recommandées spécifiques à Azure Cache pour Redis.

Remarques relatives à la conception

Le Contrat de niveau de service d’Azure Cache pour Redis concerne uniquement les caches de niveau Standard et Premium. Le niveau de base n’est pas concerné.

Redis est un cache en mémoire pour les paires clé/valeur. Il bénéficie d’une haute disponibilité par défaut, sauf pour le niveau de base. Il existe trois niveaux pour Azure Cache pour Redis :

De base : Non recommandé pour les charges de travail de production. Le niveau de base est idéal pour :
- Nœud unique
- Tailles multiples
- Développement
- Test
- Charges de travail non critiques
Standard : cache répliqué dans une configuration avec un cache à deux nœuds (primaire et secondaire), géré par Microsoft et assorti d’un contrat SLA garantissant une haute disponibilité.
Premium : comprend toutes les fonctionnalités de niveau Standard et comprend les autres fonctionnalités suivantes :
- Un matériel plus rapide et de meilleures performances par rapport au niveau De base ou Standard.
- Un plus grand cache, jusqu’à 120GB.
- Persistance des données, qui comprend un fichier RDB et un fichier AOF.
- Prise en charge du réseau virtuel.
- Clustering
- Géoréplication : un cache secondaire se trouve dans une autre région et réplique les données du cache principal pour la récupération d’urgence. Pour basculer vers le cache secondaire, vous devez d’abord détacher les caches manuellement. Le cache secondaire deviendra alors disponible pour les écritures. L’application qui écrit dans Redis doit être mise à jour avec la chaîne de connexion du cache secondaire.
- Zones de disponibilité : déployez le cache et les réplicas entre les zones de disponibilité.
  
  Notes
  
  Par défaut, chaque déploiement comportera un réplica par partition. La persistance, le clustering et la géoréplication sont tous désactivés à ce stade pour les déploiements qui ont plusieurs réplicas. Vos nœuds seront répartis uniformément entre toutes les zones. Le nombre de réplicas doit être >= nombre de zones.
- Importation et exportation.

Microsoft garantit que les clients disposeront d’une connectivité entre les points de terminaison du cache et la passerelle Internet de Microsoft pendant au moins 99.9% du temps.

Liste de contrôle

Avez-vous configuré Azure Cache pour Redis en tenant compte de la résilience ?

planifier les mises à jour ;
Monitorer le cache et définir des alertes.
Déployer le cache sur un réseau virtuel.
Évaluer une stratégie de partitionnement au sein du cache Redis.
Configurer la persistance des données pour enregistrer une copie du cache dans le Stockage Azure ou utiliser la géoréplication, selon les besoins de l’entreprise.
Implémenter des stratégies de nouvelle tentative dans le contexte d’Azure Cache pour Redis.
Utiliser une implémentation statique ou singleton du multiplexeur de connexion à Redis et suivre le guide des bonnes pratiques.
Lire le Guide pratique pour administrer Azure Cache pour Redis.

Recommandations relatives à la configuration

Explorez le tableau de recommandations suivant dans le but d’optimiser votre configuration Azure Cache pour Redis et d’accroître la fiabilité du service :

Recommandation	Description
planifier les mises à jour ;	Planifiez les jours et les heures auxquels les mises à jour du serveur Redis doivent être appliquées au cache (cela n’inclut pas les mises à jour Azure ni les mises à jour du système d’exploitation de la machine virtuelle).
Monitorer le cache et définir des alertes.	Définissez des alertes pour les exceptions, l’utilisation élevée du processeur ou de la mémoire, la charge serveur et les clés supprimées afin de savoir quand mettre à l’échelle le cache. Si le cache doit être mis à l’échelle, il est important de savoir à quel moment vous pouvez le faire, car la mise à l’échelle entraîne l’augmentation de l’utilisation du processeur pour la migration des données.
Déployer le cache sur un réseau virtuel.	Cela donne au client davantage de contrôle sur le trafic qui peut se connecter au cache. Vérifiez que le sous-réseau dispose de suffisamment d’espace d’adressage pour déployer les nœuds de cache et les partitions (cluster).
Évaluer une stratégie de partitionnement au sein du cache Redis.	Le partitionnement d’un magasin de données Redis implique la répartition des données entre les instances du serveur Redis. Chaque instance constitue une partition. Azure Cache pour Redis fait abstraction des services Redis qui sont situés derrière une façade et ne les expose pas directement. La méthode la plus simple pour implémenter le partitionnement consiste à créer plusieurs instances de cache Redis Azure et à répartir les données entre elles. Vous pouvez associer chaque élément de données à un identificateur (une clé de partition) qui indique dans quel cache l’élément est stocké. La logique de l’application cliente peut ensuite utiliser cet identificateur pour acheminer les demandes vers la partition appropriée. Ce schéma est simple mais, si le schéma de partitionnement change (par exemple si d’autres instances d’Azure Cache pour Redis sont créées), vous devrez peut-être reconfigurer les applications clientes.
Configurer la persistance des données pour enregistrer une copie du cache dans le Stockage Azure ou utiliser la géoréplication, selon les besoins de l’entreprise.	Persistance des données : si l’instance maître et le réplica redémarrent, les données seront chargées automatiquement à partir du compte de stockage. Géoréplication : le cache secondaire doit être détaché du cache principal. Le cache secondaire devient alors le cache principal et peut recevoir des écritures.
Implémenter des stratégies de nouvelle tentative dans le contexte d’Azure Cache pour Redis.	La plupart des services Azure et des kits de développement logiciel (SDK) client incluent un mécanisme de nouvelle tentative. Ces mécanismes sont différents car chaque service présente des caractéristiques et des exigences qui lui sont propres. Chaque mécanisme de nouvelle tentative est réglé sur un service spécifique.
Lire le Guide pratique pour administrer Azure Cache pour Redis.	Découvrez comment les redémarrages du cache peuvent provoquer une perte de données et comment tester l’application à des fins de résilience.

Artefacts sources

Pour identifier les instances Redis qui n’ont pas le niveau Premium, utilisez la requête suivante :

Resources 
| where type == 'microsoft.cache/redis'
| where properties.sku.name != 'Premium'

Étape suivante

Azure Cache pour Redis et excellence opérationnelle

Partager via