Bonnes pratiques pour Memorystore pour Valkey

Cette page fournit des conseils pour utiliser Memorystore for Valkey 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 des stratégies de gestion de la mémoire des instances afin que Memorystore for Valkey fonctionne efficacement pour votre application.

Concepts de gestion de la mémoire

• Utilisation de la mémoire : quantité de mémoire utilisée par votre instance. Vous disposez d'une capacité de mémoire fixe. Vous pouvez utiliser des métriques pour surveiller la quantité de mémoire que vous utilisez.

• Règle d'éviction : Memorystore for Valkey utilise la volatile-lru règle d'éviction. Vous pouvez utiliser des commandes Valkey telles que la commande EXPIRE pour définir des évictions pour les clés.

Surveiller l'utilisation de la mémoire d'une instance

Pour surveiller l'utilisation de la mémoire d'une instance Memorystore for Valkey, nous vous recommandons d'afficher la métrique /instance/memory/maximum_utilization. Si l'utilisation de la mémoire de l'instance approche les 80% et que vous prévoyez une augmentation de la consommation des données, alors augmentez la taille de l'instance pour faire de la place pour les nouvelles données.

Si l'instance utilise beaucoup de mémoire, procédez comme suit pour améliorer les performances :

• Augmentez la taille de l'instance.
• Réduisez le maxmemory paramètre de configuration.

Si vous rencontrez des problèmes, contactez le service client Google Cloud .

Mettre à l'échelle les segments en mode cluster activé

Lorsque vous mettez à l'échelle le nombre de segments dans une instance, nous vous recommandons de le faire pendant les périodes de faible écriture. La mise à l'échelle pendant les périodes de forte utilisation peut exercer une pression sur la mémoire de votre instance en raison de la surcharge de mémoire causée par la réplication ou la migration des emplacements.

Si votre cas d'utilisation Valkey utilise des évictions de clés, la mise à l'échelle vers une taille d'instance plus petite peut réduire votre taux d'accès au cache. Dans ce cas, vous n'avez pas à vous soucier de la perte de données, car l'éviction de clés est attendue.

Pour les cas d'utilisation Valkey où vous ne souhaitez pas perdre de clés, vous ne devez réduire l'échelle que vers une instance plus petite qui dispose encore de suffisamment d'espace pour vos données. Votre nouveau nombre cible de segments doit permettre d'allouer au moins 1,5 fois la mémoire utilisée par les données. En d'autres termes, vous devez provisionner suffisamment de segments pour 1,5 fois la quantité de données de votre instance. Vous pouvez utiliser la métrique /instance/memory/total_used_memory pour voir 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 instance sont réduites en raison de la perte de capacité des nœuds de la zone indisponible. Nous vous recommandons d'utiliser des instances à haute disponibilité. L'utilisation de plusieurs instances dupliquées par segment (au lieu d'une seule) fournit des ressources de processeur supplémentaires en cas de panne. Vous pouvez avoir jusqu'à cinq instances dupliquées par segment.

De plus, nous vous recommandons de gérer l'utilisation du processeur des nœuds afin qu'ils disposent d'une surcharge de processeur suffisante pour gérer le trafic supplémentaire provenant de la perte de capacité en cas de panne zonale inattendue. Vous devez surveiller l'utilisation du processeur pour les instances principales et dupliquées à l'aide de la métrique Main Thread CPU Seconds /instance/cpu/maximum_utilization.

En fonction du nombre d'instances dupliquées que vous provisionnez par nœud, nous vous recommandons les cibles d'utilisation du processeur /instance/cpu/maximum_utilization suivantes :

• Pour les instances avec une instance dupliquée par nœud, ciblez une valeur /instance/cpu/maximum_utilization de 0,5 seconde pour l'instance principale et de 0,5 seconde pour l'instance dupliquée.
• Pour les instances avec deux instances dupliquées par nœud ou plus, ciblez une valeur /instance/cpu/maximum_utilization de 0,9 seconde pour l'instance principale et de 0,5 seconde pour chaque instance dupliquée.

Si les valeurs de la métrique dépassent ces recommandations, nous vous recommandons d'augmenter le nombre de segments dans votre instance. Si votre instance comporte moins de cinq instances dupliquées, vous pouvez également augmenter le nombre d'instances dupliquées, jusqu'à un maximum de cinq.

Si votre instance connaît une utilisation élevée du processeur ou si ses ressources sont épuisées (par exemple, en raison d'un nombre excessif de connexions), elle peut se comporter de manière anormale et des métriques externes peuvent être manquantes.

Commandes Valkey gourmandes en ressources

Nous vous recommandons vivement d'éviter d'utiliser des commandes Valkey gourmandes en ressources. L'utilisation de ces commandes peut entraîner les problèmes de performances suivants :

• Latence élevée et délais d'attente du client
• 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 Valkey est bloqué
• Vérifications d'état, observabilité et réplication insuffisantes

Le tableau suivant liste des exemples de commandes Valkey gourmandes en ressources et vous propose des alternatives efficaces.

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

Pour savoir quelles commandes de longue durée vous utilisez, utilisez SLOWLOG. Cet outil vous fournit une liste des commandes dont l'exécution est la plus longue. Vous connaissez ainsi les commandes qui causent des problèmes de latence. Pour déterminer des alternatives efficaces pour ces commandes, consultez le tableau suivant.

Catégorie	Commande gourmande en ressources	Alternative efficace
Exécuter pour l'ensemble de l'espace de clés	KEYS	SCAN
Exécuter pour un ensemble 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 le client Valkey

Éviter la surcharge de connexion sur Valkey

Pour atténuer l'impact causé par un afflux soudain de connexions, nous vous recommandons de procéder comme suit :

• Déterminez la taille du pool de connexions client qui vous convient le mieux. Une bonne taille de départ pour chaque client est d'une connexion par nœud Valkey. Vous pouvez ensuite effectuer des tests comparatifs pour voir si davantage de connexions sont utiles sans saturer le nombre maximal de connexions autorisées.

• Lorsque le client se déconnecte du serveur parce que le serveur a expiré, réessayez avec un intervalle exponentiel entre les tentatives et une gigue. Cela permet d'éviter que plusieurs clients ne surchargent le serveur simultanément.

Pour les instances en mode cluster activé

Votre application doit utiliser un client Valkey compatible avec les clusters lorsqu'elle se connecte à une instance Memorystore for Valkey en mode cluster activé. Pour obtenir des exemples de clients compatibles avec les clusters et des exemples de configurations, consultez la section Exemples de code de la bibliothèque cliente. Votre client doit conserver un mappage des emplacements de hachage vers les nœuds correspondants de l'instance pour envoyer des requêtes aux nœuds appropriés. Cela évite la surcharge de performances causée par les redirections.

Mappage client

Les clients doivent obtenir une liste complète des emplacements et des nœuds mappés dans les situations suivantes :

• Lors de l'initialisation du client, il doit remplir le mappage initial des emplacements vers 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 l'instance dupliquée, ou en cas de resegmentation lorsque les 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 dupliquée.

• De plus, les clients doivent actualiser périodiquement la topologie pour les préparer à tout changement et 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 d'instance dupliquée sont ajoutés. Notez que toutes les connexions obsolètes doivent également être fermées dans le cadre 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étection du client

La détection du client s'effectue généralement en émettant une commande SLOTS, NODES ou CLUSTER SHARDS au serveur Valkey. Nous vous recommandons d'utiliser la commande CLUSTER SHARDS. CLUSTER SHARDS remplace la commande SLOTS (obsolète) en fournissant une représentation plus efficace et extensible de l'instance.

La taille de la réponse pour les commandes de détection du client peut varier en fonction de la taille et de la topologie de l'instance. Les instances plus grandes avec plus de nœuds produisent une réponse plus importante. Par conséquent, il est important de s'assurer que le nombre de clients effectuant la détection de la topologie des nœuds ne croît pas de manière illimitée.

Ces actualisations de la topologie des nœuds sont coûteuses sur le serveur Valkey, 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étection à 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étection des nœuds, une erreur courante consiste à ce que l'application cliente effectue plusieurs requêtes de reconnexion et de détection sans ajouter d' intervalle exponentiel entre les tentatives. Cela peut rendre le serveur Valkey non réactif pendant une période prolongée, ce qui entraîne une utilisation très élevée du processeur.

Utiliser un point de terminaison de détection pour la détection des nœuds

Utilisez le point de terminaison de détection Memorystore for Valkey pour effectuer la détection des nœuds. Le point de terminaison de détection est disponibilité élevée et l'équilibrage de charge est effectué sur tous les nœuds de l'instance. De plus, le point de terminaison de détection tente de router les requêtes de détection des nœuds vers les nœuds dont la vue de la topologie est la plus récente.

Pour les instances en mode cluster désactivé

Lorsque vous vous connectez à une instance en mode cluster désactivé, votre application doit se connecter au point de terminaison principal pour écrire dans l'instance et récupérer les écritures les plus récentes. Votre application peut également se connecter au point de terminaison du lecteur pour lire à partir des instances dupliquées et isoler le trafic du nœud principal.

Si vous utilisez la stratégie de création avant destruction lorsque vous effectuez la maintenance de votre instance, vous pouvez recevoir le message d'erreur suivant :

READONLY You can't write against a read only replica.

Pour résoudre ce problème, arrêtez la connexion à votre instance. Recréez ensuite la connexion.

Bonnes pratiques concernant la persistance

Cette section explique les bonnes pratiques concernant la persistance.

Persistance RDB et ajout d'instances dupliquées

Pour obtenir les meilleurs résultats lors de la sauvegarde de votre instance avec des instantanés RDB ou de l'ajout d'instances dupliquées à 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 touchées par les écritures sont copiées. L'espace mémoire utilisé 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é, conservez ou définissez maxmemory à 80% de la capacité du nœud afin que 20% soient réservés à la surcharge. Cette surcharge de mémoire, en plus de la surveillance des instantanés, vous aide à gérer votre charge de travail pour que les instantanés soient réussis. De plus, lorsque vous ajoutez des instances dupliquées, réduisez autant que possible le trafic d'écriture. Pour en savoir plus, consultez la section Surveiller l'utilisation de la mémoire d'une instance.

Remarque : Si vous ajoutez une instance dupliquée à une instance qui utilise plus de 80% de la mémoire maximale de l'instance, l'opération échoue et vous recevez un message d'erreur.

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

• Réduisez l'espace mémoire utilisé de votre instance à moins de 80% de la mémoire maximale autorisée du nœud.
• Mettez à l'échelle le type de nœud de votre instance afin qu'il dispose de plus de mémoire.

Une fois que l'utilisation de la mémoire de votre instance est inférieure au seuil de 80 %, ajoutez à nouveau l'instance dupliqué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, telles qu'une modification de schéma. Si vous craignez de récupérer à partir d'un instantané obsolète, vous pouvez désactiver la fonctionnalité de persistance RDB. Une fois que vous avez réactivé la persistance, un instantané est pris lors du prochain intervalle d'instantané planifié.

Impact des instantanés RDB sur les performances

En fonction de votre modèle de charge de travail, les instantanés 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 les planifiant pour qu'ils s'exécutent pendant les périodes de faible trafic d'instance si vous êtes à l'aise avec des instantanés moins fréquents.

Par exemple, si votre instance a un faible trafic entre 1h et 4h, vous pouvez définir l'heure de début sur 3h et l'intervalle sur 24 heures.

Si votre système a une charge constante et nécessite des instantanés fréquents, nous vous recommandons d'évaluer soigneusement l'impact sur les performances et de peser les avantages de l'utilisation d'instantanés RDB pour la charge de travail.

Ajouter une instance dupliquée

L'ajout d'une instance dupliquée nécessite un instantané RDB. Pour en savoir plus sur les instantanés RDB, consultez la section Gestion de la mémoire.

Quand utiliser une instance à zone unique

Si vous configurez une instance de sorte qu'elle n'utilise pas d'instances dupliquées, nous vous recommandons d'utiliser une instance à zone unique. Voici pourquoi :

Coût et performances

Si votre objectif principal est de minimiser vos coûts et d'obtenir des performances optimales pour vos clients situés dans la même région, nous vous recommandons de choisir une instance à zone unique.

Minimiser l'impact des pannes

Lorsque vous choisissez une instance à zone unique, les pannes zonales sont moins susceptibles d'avoir un impact sur votre instance. En plaçant tous les nœuds dans une seule zone, le risque qu'une panne zonale affecte votre serveur passe de 100% à 33%. Il y a 33% de chances que la zone où se trouve votre instance soit en panne, 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 zonale pour une instance à zone unique, Memorystore for Valkey simplifie la récupération de vos données. Vous pouvez provisionner rapidement une nouvelle instance dans une zone fonctionnelle et rediriger votre application pour des opérations peu interrompues.

Activer le protocole TLS (Transport Layer Security)

Cette section explique les avantages en termes de sécurité et les implications sur les 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 d'usurpation d'identité du serveur, telles que les attaques de l'intercepteur.
• Chiffrement en transit: Google Cloudle chiffrement intégré de protège le trafic au sein du réseau de Google au niveau de l'infrastructure. Toutefois, cela implique de faire confiance à la fois à l'hôte et aux piles 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 qui ont établi une session TLS peuvent reprendre la session 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'attente de connexion. Cela peut provoquer un effet boule de neige, car Memorystore for Valkey tente de rétablir les connexions ayant expiré, ce qui augmente les ressources qu'il utilise pour établir des connexions.

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

Recommandations

Lorsque vous décidez d'activer ou non TLS, nous vous recommandons d'évaluer vos règles de sécurité tout 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 réduit 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 de l'instance du client peut entraîner une brève interruption causée par la première négociation 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 instances.