Développement avec Azure Managed Redis(préversion)
Résilience de la connexion et charge du serveur
Lorsque vous développez des applications clientes, veillez à prendre en compte les meilleures pratiques pertinentes pour la résilience des connexions et la gestion de la charge du serveur.
Prendre en compte d’autres clés et des valeurs plus petites
Azure Managed Redis (préversion) fonctionne mieux avec des valeurs plus petites. Pour répartir les données sur plusieurs clés, envisagez de diviser les plus grandes portions de données en plus petits segments. Pour plus d’informations sur la taille idéale des valeurs, consultez cet article.
Taille importante de la demande ou de la réponse
Une demande/réponse volumineuse peut entraîner des délais d’expiration. Par exemple, supposons que la durée du délai d’expiration que vous avez configurée sur votre client soit de 1 seconde. Votre application demande deux clés (par exemple, « A » et « B ») en même temps (à l’aide de la même connexion réseau physique). La plupart des clients prennent en charge le traitement en pipeline des requêtes, de sorte que les deux requêtes A et B sont envoyées l’une après l’autre sans attendre les réponses. Le serveur renvoie les réponses dans le même ordre. Si la réponse A est volumineuse, elle peut consommer la majeure partie du délai d’expiration des requêtes suivantes.
Dans l’exemple suivant, les requêtes A et B sont envoyées rapidement au serveur. Le serveur commence rapidement à envoyer les réponses A et B. En raison des temps de transfert de données, la réponse B doit attendre l’expiration de la réponse A, même si le serveur a répondu rapidement.
|-------- 1 Second Timeout (A)----------|
|-Request A-|
|-------- 1 Second Timeout (B) ----------|
|-Request B-|
|- Read Response A --------|
|- Read Response B-| (**TIMEOUT**)
Cette demande/réponse est difficile à mesurer. Vous pouvez instrumenter votre code client pour suivre les requêtes et les réponses volumineuses.
Les solutions possibles pour la gestion des réponses volumineuses sont variées, et incluent notamment :
- Optimiser votre application pour prendre en charge un grand nombre de petites valeurs plutôt qu’un petit nombre de grandes valeurs
- La meilleure solution consiste à diviser vos données en valeurs plus petites.
- Lisez le billet What is the ideal value size range for redis? Is 100 KB too large? pour savoir pourquoi il est recommandé d’utiliser des valeurs moins élevées.
- Augmenter la taille de votre machine virtuelle pour obtenir des capacités de bande passante plus élevées
- Une plus grande quantité de bande passante sur votre machine virtuelle cliente ou serveur peut réduire le temps de transfert des données pour les réponses volumineuses.
- Comparez l’utilisation actuelle du réseau par les deux ordinateurs aux limites associées à la taille de votre machine virtuelle. Une bande passante plus élevée seulement sur le serveur ou sur le client peut ne pas suffire.
- Augmenter le nombre d’objets de connexion qu’utilise votre application
- Utilisez un tourniquet (round-robin) pour envoyer des requêtes vers différents objets de connexion.
Utilisez le traitement en pipeline
Essayez de choisir un client Redis qui prend en charge le traitement en pipeline Redis. Le traitement en pipeline permet d’utiliser efficacement le réseau et d’obtenir le meilleur débit possible.
Éviter les opérations coûteuses
Certaines opérations Redis, comme la commande KEYS, sont très coûteuses à exécuter et sont donc à proscrire. Pour connaître quelques éléments à prendre en compte concernant les commandes de longue durée, consultez Commandes de longue durée.
Choisir un niveau approprié
Azure Managed Redis offre des niveaux Mémoire optimisée, Équilibré, Optimisé pour le calcul et Optimisé pour le stockage flash. Découvrez comment choisir un niveau ici. Nous vous recommandons de tester les performances pour choisir le niveau approprié et valider les paramètres de connexion. Pour plus d’informations, consultez Test de performances.
Choisir un mode de disponibilité approprié
Azure Managed Redis offre la possibilité d’activer ou de désactiver la configuration de haute disponibilité. Lorsque le mode haute disponibilité est désactivé, les données de votre instance AMR ne sont pas répliquées et, par conséquent, votre instance Redis n’est pas disponible pendant la maintenance. Toutes les données de l’instance AMR sont également perdues en cas de maintenance planifiée ou non planifiée. Nous vous recommandons de désactiver la haute disponibilité uniquement pour vos charges de travail de développement ou de test. Les performances des instances Redis avec une haute disponibilité peuvent également être inférieures en raison de l’absence de réplication des données, ce qui est essentiel pour répartir la charge entre la partition de données principale et réplica.
Client dans la même région que l’instance Redis
Recherchez votre instance Redis et votre application dans la même région. La connexion à un Redis situé dans une autre région peut considérablement augmenter la latence et diminuer la fiabilité.
Même si vous pouvez vous connecter en dehors d’Azure, il n’est pas recommandé, en particulier lorsque vous utilisez Redis pour accélérer les performances de votre application ou de votre base de données. Si vous utilisez le serveur Redis simplement comme magasin de clés/valeurs, la latence n’est sans doute pas votre première préoccupation.
S’appuyer sur l’adresse IP non publique du nom d’hôte
L’adresse IP publique affectée à votre instance AMR peut changer à la suite d’une opération de mise à l’échelle ou d’une amélioration du back-end. Nous vous recommandons de vous appuyer sur le nom d’hôte au lieu d’une adresse IP publique explicite.
Utiliser le chiffrement TLS
Azure Managed Redis nécessite des communications chiffrées avec le protocole TLS par défaut. Les versions TLS 1.2 et 1.3 sont actuellement prises en charge. Si votre outil ou bibliothèque de client ne prend pas en charge TLS, vous pouvez activer des connexions non chiffrées.
Surveiller l’utilisation de la mémoire, les métriques d’utilisation du processeur, les connexions clientes et la bande passante réseau
Lors de l’utilisation de l’instance Azure Managed Redis en production, nous vous recommandons de définir des alertes pour les métriques « Pourcentage de mémoire utilisée », « Processeur », « Clients connectés ». Si ces métriques sont constamment supérieures à 75 %, envisagez de mettre à l’échelle votre instance vers une catégorie offrant une mémoire plus grande ou un débit supérieur. Pour plus d’informations, consultez Quand mettre à l’échelle.
Envisagez d’activer la persistance des données ou la sauvegarde de données
Redis est conçu pour les données éphémères par défaut, ce qui signifie que, dans de rares cas, vos données peuvent être perdues en raison de diverses circonstances telles que la maintenance ou les pannes. Si votre application est sensible à la perte de données, nous vous recommandons d’activer la persistance des données ou la sauvegarde périodique des données à l’aide de l’opération d’exportation de données.
La fonctionnalité de persistance des données est conçue pour fournir automatiquement un point de récupération rapide pour les données lorsqu’un cache tombe en panne. La récupération rapide est rendue possible en stockant le fichier RDB ou AOF sur un disque managé monté sur l’instance de cache. Les fichiers de persistance sur le disque ne sont pas accessibles aux utilisateurs ou ne peuvent pas être utilisés par une autre instance AMR.
De nombreux clients souhaitent utiliser la persistance pour effectuer des sauvegardes périodiques des données dans leur cache. Nous vous déconseillons d’utiliser la persistance des données de cette façon. Utilisez plutôt la fonctionnalité d’importation/exportation. Vous pouvez exporter des copies des données au format RDB directement dans le compte de stockage de votre choix et déclencher l’exportation des données aussi souvent que vous le souhaitez. Ces données exportées peuvent ensuite être importées dans n’importe quelle instance Redis. L’exportation peut être déclenchée à partir du portail ou à l’aide de l’interface CLI, de PowerShell ou des outils de SDK.
Conseils pour la bibliothèque cliente
Pour plus d’informations, consultez Bibliothèques de client Azure Managed Redis