Cette page fournit des conseils pour utiliser Memorystore pour Redis Cluster de manière optimale. Elle souligne également les problèmes potentiels à éviter.
Bonnes pratiques pour la gestion de la mémoire
Cette section décrit les stratégies de gestion de la mémoire des instances afin que Memorystore pour Redis Cluster fonctionne efficacement pour votre application.
Concepts de gestion de la mémoire
Charge d'écriture : volume et vitesse auxquels vous ajoutez ou mettez à jour des clés sur votre cluster Redis. Votre charge d'écriture peut varier de normale à très élevée en fonction de votre cas d'utilisation de Redis et des habitudes d'utilisation de votre application.
Règle d'éviction : Memorystore for Redis Cluster utilise la règle d'éviction
volatile-lru. Vous pouvez utiliser des commandes telles que EXPIRE pour définir des expulsions pour les clés.
Surveiller un cluster avec une charge d'écriture normale
Consultez la métrique /cluster/memory/maximum_utilization. Si /cluster/memory/maximum_utilization est à 100 % ou moins, votre cluster Redis fonctionne correctement lorsque vous utilisez une charge d'écriture normale.
Toutefois, si l'utilisation de la mémoire approche les 100 % et que vous prévoyez une augmentation de l'utilisation des données, vous devez augmenter la taille de votre cluster pour faire de la place pour les nouvelles données.
Surveiller un cluster avec une charge d'écriture élevée
Consultez la métrique /cluster/memory/maximum_utilization. En fonction de la gravité de votre charge d'écriture élevée, votre cluster peut rencontrer des problèmes de performances aux seuils suivants :
Des problèmes peuvent survenir en cas de charge d'écriture très élevée si
/cluster/memory/maximum_utilizationatteint 65 % ou plus.Les charges d'écriture modérément élevées peuvent poser problème si
/cluster/memory/maximum_utilizationatteint 85 % ou plus.
Dans ce cas, vous devez augmenter la taille de votre cluster pour améliorer les performances.
Si vous rencontrez des problèmes ou si vous pensez que votre instance présente une charge d'écriture élevée, contactez l'assistanceGoogle Cloud .
Faire évoluer les segments
Lorsque vous modifiez le nombre de partitions dans une instance, vous devez le faire pendant les périodes de faible charge en écriture. Le scaling pendant les périodes de forte charge d'écriture peut mettre de la pression sur votre instance en raison d'une surcharge de mémoire due à la réplication ou à la migration de slots.
Si votre cas d'utilisation Redis utilise des évictions de clés, le scaling à une taille de cluster plus petite peut réduire votre taux d'accès au cache. Dans ce cas, vous n'avez pas à vous inquiéter de perdre des données, car l'éviction de la clé est prévue.
Pour les cas d'utilisation de Redis où vous ne souhaitez pas perdre de clés, vous ne devez réduire la taille du cluster que si celui-ci dispose encore de suffisamment d'espace pour vos données. Votre nouveau nombre cible de partitions doit permettre d'utiliser au moins 1,5 fois la mémoire utilisée par les données. En d'autres termes, vous devez provisionner suffisamment de partitions pour 1,5 fois la quantité de données actuellement dans votre cluster. Vous pouvez utiliser la métrique /cluster/memory/total_used_memory pour connaître la quantité de données stockées dans votre instance.
Bonnes pratiques concernant l'utilisation du processeur
En cas de panne zonale inattendue, les ressources de processeur de votre cluster sont réduites en raison de la perte de capacité des nœuds de la zone indisponible. Nous vous recommandons d'utiliser des clusters à haute disponibilité. L'utilisation de deux réplicas par shard (au lieu d'un) fournit des ressources de processeur supplémentaires pendant une panne. Nous vous recommandons également de gérer l'utilisation du processeur des nœuds afin qu'ils disposent d'une marge suffisante pour gérer le trafic supplémentaire en cas de perte de capacité due à une panne zonale inattendue. Vous devez surveiller l'utilisation du processeur pour les instances principales et les répliques à l'aide de la métrique /cluster/cpu/maximum_utilization.
En fonction du nombre de répliques que vous provisionnez par nœud, nous vous recommandons les cibles d'utilisation du processeur /cluster/cpu/maximum_utilization suivantes :
- Pour les instances avec une réplique par nœud, visez une valeur
/cluster/cpu/maximum_utilizationde 0,5 seconde pour l'instance principale et de 0,5 seconde pour la réplique, lorsque la réplique est désignée comme réplique en lecture. - Pour les instances comportant deux réplicas par nœud, visez une valeur
/cluster/cpu/maximum_utilizationde 0,8 seconde pour le réplica principal et de 0,5 seconde pour chaque réplica.
Si les valeurs de la métrique dépassent ces recommandations, nous vous conseillons d'augmenter le nombre de partitions ou de réplicas dans votre instance.
Commandes Redis gourmandes en ressources
Nous vous recommandons vivement d'éviter d'utiliser des commandes Redis gourmandes en ressources. L'utilisation de ces commandes peut entraîner les problèmes de performances suivants :
- Latence élevée et délais avant expiration des clients
- Pression sur la mémoire causée par des commandes qui augmentent l'utilisation de la mémoire
- Perte de données lors de la réplication et de la synchronisation des nœuds, car le thread principal Redis est bloqué
- Vérifications d'état, observabilité et réplication affamées
Le tableau suivant liste des exemples de commandes Redis gourmandes en ressources et vous propose des alternatives plus efficaces.
| Catégorie | Commande gourmande en ressources | Alternative écoénergétique |
|---|---|---|
| Exécuter pour l'ensemble de l'espace de clés | KEYS |
SCAN |
| Exécuter pour une collection de clés de longueur variable | LRANGE |
Limitez la taille de la plage que vous utilisez pour une requête. |
ZRANGE |
Limitez la taille de la plage que vous utilisez pour une requête. | |
HGETALL |
HSCAN |
|
SMEMBERS |
SSCAN |
|
| Bloquer l'exécution d'un script | EVAL |
Assurez-vous que votre script ne s'exécute pas indéfiniment. |
EVALSHA |
Assurez-vous que votre script ne s'exécute pas indéfiniment. | |
| Supprimer des fichiers et des liens | DELETE |
UNLINK |
| Publier et s'abonner | PUBLISH |
SPUBLISH |
SUBSCRIBE |
SSUBSCRIBE |
Bonnes pratiques concernant les clients Redis
Votre application doit utiliser un client Redis compatible avec les clusters lorsqu'elle se connecte à une instance Memorystore pour Redis Cluster. Pour obtenir des exemples de clients compatibles avec les clusters et des exemples de configurations, consultez Exemples de code de la bibliothèque cliente. Votre client doit tenir à jour une carte des emplacements de hachage vers les nœuds correspondants du cluster afin d'envoyer les requêtes aux bons nœuds et d'éviter la surcharge de performances causée par les redirections de cluster.
Mappage des clients
Les clients doivent obtenir la liste complète des emplacements et des nœuds mappés dans les situations suivantes :
Lorsque le client est initialisé, il doit remplir le mappage initial entre les emplacements et les nœuds.
Lorsqu'une redirection
MOVEDest reçue du serveur, par exemple en cas de basculement lorsque tous les emplacements desservis par l'ancien nœud principal sont repris par le réplica, ou en cas de re-partitionnement lorsque des emplacements sont déplacés du nœud principal source vers le nœud principal cible.Lorsqu'une erreur
CLUSTERDOWNest reçue du serveur ou que les connexions à un serveur particulier expirent de manière persistante.Lorsqu'une erreur
READONLYest reçue du serveur. Cela peut se produire lorsqu'une instance principale est rétrogradée en instance répliquée.De plus, les clients doivent actualiser régulièrement la topologie pour que les clients restent actifs en cas de modifications et pour en savoir plus sur les modifications qui peuvent ne pas entraîner de redirections ni d'erreurs du serveur, par exemple lorsque de nouveaux nœuds de réplique sont ajoutés. Notez que toutes les connexions obsolètes doivent également être fermées lors de l'actualisation de la topologie afin de réduire la nécessité de gérer les connexions ayant échoué lors de l'exécution des commandes.
Découverte du client
La découverte du client se fait généralement en envoyant une commande CLUSTER SLOT, CLUSTER NODE ou CLUSTER SHARDS au serveur Redis. Nous vous recommandons d'utiliser la commande CLUSTER SHARDS. CLUSTER SHARDS remplace la commande CLUSTER SLOTS (obsolète) en fournissant une représentation plus efficace et extensible du cluster.
La taille de la réponse aux commandes de découverte des clients du cluster peut varier en fonction de la taille et de la topologie du cluster. Les clusters plus volumineux avec plus de nœuds génèrent une réponse plus importante. Il est donc important de s'assurer que le nombre de clients effectuant la découverte de la topologie du cluster ne croît pas de manière illimitée.
Ces actualisations de la topologie sont coûteuses sur le serveur Redis, mais elles sont également importantes pour la disponibilité des applications. Il est donc important de s'assurer que chaque client effectue une seule requête de découverte à un moment donné (et met en cache le résultat en mémoire), et que le nombre de clients effectuant les requêtes reste limité pour éviter de surcharger le serveur.
Par exemple, lorsque l'application cliente démarre ou perd la connexion au serveur et doit effectuer la découverte du cluster, une erreur courante consiste à ce que l'application cliente effectue plusieurs demandes de reconnexion et de découverte sans ajouter d'intervalle exponentiel entre les tentatives. Cela peut rendre le serveur Redis non réactif pendant une longue période, ce qui entraîne une utilisation très élevée du processeur.
Éviter la surcharge de découverte sur Redis
Pour limiter l'impact causé par un afflux soudain de demandes de connexion et de découverte, nous vous recommandons de procéder comme suit :
Implémentez un pool de connexions client de taille finie et réduite pour limiter le nombre de connexions entrantes simultanées provenant de l'application cliente.
Lorsque le client se déconnecte du serveur en raison d'un délai d'inactivité, réessayez avec un intervalle exponentiel entre les tentatives avec gigue. Cela permet d'éviter que plusieurs clients submergent le serveur en même temps.
Utilisez le point de terminaison de découverte Memorystore for Redis Cluster pour découvrir les clusters. Le point de terminaison de découverte est disponibilité élevée et l'équilibrage de charge est effectué sur tous les nœuds du cluster. De plus, le point de terminaison de découverte tente d'acheminer les requêtes de découverte de cluster vers les nœuds dont la vue de la topologie est la plus à jour.
Bonnes pratiques de persistance
Cette section explique les bonnes pratiques concernant la persistance.
Persistance RDB et ajout d'instances répliquées
Pour obtenir les meilleurs résultats lors de la sauvegarde de votre instance avec des instantanés RDB ou de l'ajout de réplicas à votre instance, suivez les bonnes pratiques suivantes :
Gestion de la mémoire
Les instantanés RDB utilisent un fork de processus et un mécanisme de copie sur écriture pour prendre un instantané des données de nœud. En fonction du modèle d'écritures dans les nœuds, la mémoire utilisée par les nœuds augmente à mesure que les pages concernées par les écritures sont copiées. L'empreinte mémoire peut atteindre le double de la taille des données dans le nœud.
Pour vous assurer que les nœuds disposent de suffisamment de mémoire pour effectuer l'instantané, définissez ou conservez maxmemory à 80 % de la capacité du nœud afin que 20 % soient réservés aux frais généraux. Cette surcharge de mémoire, en plus des instantanés de surveillance, vous aide à gérer votre charge de travail pour obtenir des instantanés réussis. De plus, lorsque vous ajoutez des réplicas, réduisez le trafic en écriture autant que possible. Pour en savoir plus, consultez Surveiller un cluster avec une charge d'écriture élevée.
Instantanés obsolètes
La récupération de nœuds à partir d'un instantané obsolète peut entraîner des problèmes de performances pour votre application, car elle tente de réconcilier une quantité importante de clés obsolètes ou d'autres modifications apportées à votre base de données, comme un changement de schéma. Si vous craignez de récupérer des données à partir d'un instantané obsolète, vous pouvez désactiver la fonctionnalité de persistance RDB. Une fois la persistance réactivée, un instantané est créé lors du prochain intervalle d'instantanés planifié.
Impact des instantanés RDB sur les performances
En fonction de votre modèle de charge de travail, les snapshots RDB peuvent avoir un impact sur les performances de l'instance et augmenter la latence de vos applications. Vous pouvez minimiser l'impact des instantanés RDB sur les performances en planifiant leur exécution pendant les périodes de faible trafic d'instance, si vous acceptez des instantanés moins fréquents.
Par exemple, si votre instance enregistre un trafic faible de 1h à 4h du matin, vous pouvez définir l'heure de début sur 3h du matin et l'intervalle sur 24 heures.
Si votre système a une charge constante et nécessite des instantanés fréquents, vous devez évaluer attentivement l'impact sur les performances et peser les avantages de l'utilisation d'instantanés RDB pour la charge de travail.
Ajouter une instance répliquée
L'ajout d'un réplica nécessite un instantané RDB. Pour en savoir plus sur les instantanés RDB, consultez Gestion de la mémoire.
Choisissez une instance à zone unique si votre instance n'utilise pas de réplicas.
Lorsque vous configurez une instance sans répliques, nous vous recommandons d'utiliser une architecture à zone unique pour améliorer la fiabilité. Voici pourquoi :
Minimiser l'impact des pannes
Les pannes zonales sont moins susceptibles d'affecter votre instance. En plaçant tous les nœuds dans une seule zone, la probabilité qu'une panne zonale affecte votre serveur passe de 100 % à 33 %. En effet, il y a 33 % de chances que la zone dans laquelle se trouve votre instance soit hors service, contre 100 % de chances que les nœuds situés dans la zone indisponible soient affectés.
Récupération rapide
En cas de panne de zone, la récupération est simplifiée. Vous pouvez répondre en provisionnant rapidement une nouvelle instance dans une zone fonctionnelle et en redirigeant votre application pour que les opérations soient le moins perturbées possible.
Bonnes pratiques concernant Lettuce
Cette section décrit les bonnes pratiques à suivre pour utiliser Lettuce afin de se connecter à une instance Memorystore pour Redis Cluster.
Mettre à jour les valeurs des paramètres
Lorsque vous utilisez Lettuce, remplacez le paramètre validateClusterNodeMembership par false. Sinon, lorsque la topologie change, vous risquez d'obtenir des erreurs unknownPartition.