Bonnes pratiques pour Memorystore for Redis Cluster

Cette page fournit des conseils pour utiliser Memorystore pour Redis Cluster de manière optimale. Elle souligne également les problèmes potentiels à éviter.

Remarque : Pour afficher des exemples de configuration de client de cluster Redis, consultez Exemples de code de la bibliothèque cliente.

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 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_utilization atteint 65 % ou plus.

• Les charges d'écriture modérément élevées peuvent poser problème si /cluster/memory/maximum_utilization atteint 85 % ou plus.

Dans ces scénarios, 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 a une charge d'écriture élevée, contactez l'assistanceGoogle Cloud .

Mettre à l'échelle les partitions

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 plusieurs réplicas par segment (par opposition à un réplica par segment) fournit des ressources de processeur supplémentaires en cas d'indisponibilité. Vous pouvez avoir jusqu'à cinq instances répliquées par segment.

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 provenant de la capacité perdue en cas d'indisponibilité zonale inattendue. Vous devez surveiller l'utilisation du processeur pour les nœuds principaux et les répliques à l'aide de la métrique Secondes d'utilisation du processeur du thread principal /cluster/cpu/maximum_utilization.

En fonction du nombre de réplicas que vous provisionnez par nœud, nous vous recommandons les cibles d'utilisation du processeur /cluster/cpu/maximum_utilization suivantes :

• Pour les instances avec un réplica par nœud, visez une valeur /cluster/cpu/maximum_utilization de 0,5 seconde pour le primaire et de 0,5 seconde pour le réplica.
• Pour les instances comportant deux réplicas par nœud ou plus, ciblez une valeur /cluster/cpu/maximum_utilization de 0,9 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 dans votre instance. Si votre instance comporte moins de cinq instances dupliquées, vous pouvez également augmenter leur nombre jusqu'à un maximum de cinq.

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.

Conseil : En plus d'être gourmands en ressources, ces commandes deviennent plus coûteuses à mesure que la taille totale de vos données augmente.

Pour identifier les commandes de longue durée que vous utilisez, exécutez SLOWLOG. Cet outil vous fournit une liste des commandes qui mettent le plus de temps à s'exécuter. Vous connaissez donc les commandes qui provoquent des problèmes de latence. Pour déterminer des alternatives économes en ressources pour ces commandes, consultez le tableau suivant.

Catégorie	Commande gourmande en ressources	Alternative économe en ressources
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 conserver un mappage 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 MOVED est 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 CLUSTERDOWN est reçue du serveur ou que les connexions à un serveur particulier expirent de manière persistante.

• Lorsqu'une erreur READONLY est 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 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 réparti 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'écriture 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 le snapshot, conservez ou définissez maxmemory sur 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.

Remarque : Si vous ajoutez un réplica à un cluster qui utilise plus de 80 % de la mémoire maximale du cluster, l'opération échoue et un message d'erreur s'affiche.

Pour résoudre ce problème, réduisez l'utilisation de la mémoire de votre cluster de l'une des manières suivantes :

• Réduisez l'empreinte mémoire de votre cluster à moins de 80 % de la mémoire maximale autorisée du nœud.
• Faites évoluer le type de nœud de votre cluster pour qu'il dispose de plus de mémoire.

Une fois que l'utilisation de la mémoire de votre cluster est inférieure au seuil de 80 %, ajoutez à nouveau le réplica.

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 devoir effectuer une récupération à 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 interrompues 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.

Activer le protocole TLS (Transport Layer Security)

Cette section explique les avantages en termes de sécurité et les implications en termes de performances de l'utilisation du protocole TLS (Transport Layer Security), ainsi que des recommandations pour son activation.

Avantages de sécurité

En utilisant TLS, vous bénéficiez des avantages de sécurité suivants :

• Authentification Identity and Access Management (IAM) : TLS utilise ce type d'authentification pour se protéger contre les attaques par usurpation d'identité du serveur, telles que les attaques de type "man-in-the-middle".
• Chiffrement en transit : le chiffrement intégré àGoogle Cloudprotège le trafic au sein du réseau Google au niveau de l'infrastructure. Toutefois, cela implique de faire confiance aux piles hôte et réseau de Google. Bien que ce chiffrement soit transparent et activé par défaut, il n'est pas de bout en bout. En revanche, TLS utilise le chiffrement en transit au niveau de la couche application. Ce chiffrement de bout en bout vous offre plus de contrôle sur vos clés et processus de chiffrement.
• Protection des jetons d'authentification : si vous utilisez l'authentification IAM, l'activation de TLS minimise le risque d'exposition et de fuite de vos jetons d'authentification.

Implications en termes de performance

TLS a un impact sur les performances des manières suivantes :

• Établir des connexions : un client et un serveur ayant établi une session TLS peuvent la reprendre sans répéter le processus gourmand en ressources d'établissement de la connexion entre le client et le serveur. En activant la reprise TLS, vous réduisez la surcharge liée à l'établissement d'une connexion entre le client et le serveur.

  Si vous n'établissez pas de reprise TLS, l'établissement de connexions est gourmand en ressources. Pour les connexions nouvelles et existantes, de nombreuses connexions entre le client et le serveur peuvent entraîner des délais d'expiration de la connexion. Cela peut entraîner un effet boule de neige, car Memorystore pour Redis Cluster tente de rétablir les connexions expirées, ce qui augmente les ressources qu'il utilise pour établir les connexions.

• Chiffrer et déchiffrer des données : le chiffrement et le déchiffrement des données impliquent des opérations gourmandes en ressources processeur qui ont un impact à la fois sur le client et sur le serveur. Cela peut réduire la capacité de votre cluster et augmenter sa latence.

Recommandations

Lorsque vous envisagez d'activer TLS, nous vous recommandons d'évaluer vos règles de sécurité en tenant compte des avantages et des inconvénients de TLS. Si vous choisissez d'activer TLS, tenez compte des points suivants :

• L'activation de la reprise TLS permet d'atténuer la surcharge liée à l'établissement de connexions. Une connexion entre le client et le serveur n'est requise que pour la connexion initiale. Toutefois, une expansion soudaine de la taille du cluster du client peut entraîner une brève interruption causée par la première handshake complète de chaque nouvel hôte client.
• Bien que certaines bibliothèques clientes n'offrent pas de contrôles intégrés pour activer TLS, vous pouvez utiliser du code personnalisé pour intégrer cette fonctionnalité à vos clusters.