Cette page fournit des conseils pour utiliser Memorystore pour Valkey de manière optimale. Cette page indique é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 d'instance afin que Memorystore pour Valkey fonctionne efficacement pour votre application.
Concepts de gestion de la mémoire
Charge d'écriture : volume et vitesse à laquelle vous ajoutez ou modifiez des clés sur votre instance Valkey. Votre charge d'écriture peut varier de normale à très élevée, en fonction de votre cas d'utilisation de Valkey et des habitudes d'utilisation de votre application.
Règle d'éviction : Memorystore pour Valkey utilise la règle d'éviction
volatile-lru. Vous pouvez utiliser les commandes Valkey comme la commande EXPIRE pour définir les évictions des clés.
Surveiller une instance dont la charge d'écriture est normale
Affichez la métrique /instance/cpu/maximum_utilization. Si /instance/cpu/maximum_utilization correspond à
à 100% ou moins, votre instance Valkey est performante avec une charge d'écriture normale.
Cependant, si votre utilisation de la mémoire approche de 100% et que vous vous attendez à une augmentation de l'utilisation des données, vous devez augmenter la taille de votre instance pour faire de la place aux nouvelles données.
Surveiller une instance présentant une charge d'écriture élevée
Affichez la métrique /instance/memory/maximum_utilization. Selon la gravité de votre charge d'écriture élevée, votre instance peut rencontrer des problèmes de performances lorsque les seuils suivants sont atteints:
Des charges d'écriture très élevées peuvent entraîner des problèmes si
/instance/memory/maximum_utilizationatteint 65 % ou plus.Les charges d'écriture modérément élevées peuvent rencontrer des problèmes si
/instance/memory/maximum_utilizationatteint 85 % ou plus.
Dans ces scénarios, vous devez augmenter la taille de votre instance pour améliorer les performances.
Si vous rencontrez des problèmes ou si vous craignez que votre instance ait une charge d'écriture élevée, contactez l'assistance Google Cloud.
Évoluer les segments
Lorsque vous effectuez le scaling du nombre de segments dans une instance, vous devez effectuer le scaling lors des périodes de faibles écritures. Le scaling pendant les périodes de charge d'écriture élevée peut exercer une pression sur la mémoire de votre instance en raison d'une surcharge de mémoire causée par la réplication ou la migration d'emplacements.
Si votre cas d'utilisation Valkey utilise des évictions de clés, le scaling à une taille d'instance plus petite peut réduire votre taux d'accès au cache. Toutefois, dans ce cas, vous n'avez pas à vous soucier de perdre des données, car l'éviction des clés est attendue.
Pour les cas d'utilisation de Valkey où vous ne souhaitez pas perdre de clés, vous ne devez réduire la taille que vers une instance plus petite qui dispose encore de suffisamment d'espace pour vos données. Le nouveau nombre de segments cibles devrait 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 segments pour 1,5 fois la quantité de données actuellement dans votre instance. Vous pouvez utiliser la métrique /instance/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 de zone 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 hautement disponibles. L'utilisation de deux réplicas par shard (au lieu d'un seul) fournit des ressources de processeur supplémentaires en cas d'indisponibilité. En outre, nous vous recommandons de gérer l'utilisation du processeur des nœuds afin qu'ils disposent de suffisamment de ressources pour gérer le trafic supplémentaire lié à la perte de capacité en cas d'indisponibilité zonale inattendue. Vous devez surveiller l'utilisation du processeur pour les principaux et les réplicas à l'aide de la métrique Main Thread CPU Seconds /instance/cpu/maximum_utilization (Secondes de processeur du thread principal).
En fonction du nombre d'instances répliquées que vous provisionnez par nœud, nous vous recommandons les objectifs d'utilisation du processeur /instance/cpu/maximum_utilization suivants:
- Pour les instances avec une instance répliquée par nœud, vous devez cibler une valeur
/instance/cpu/maximum_utilizationde 0,5 seconde pour l'instance principale et l'instance répliquée. - Pour les instances comportant deux instances répliquées par nœud, vous devez cibler une valeur
/instance/cpu/maximum_utilizationde 0,9 seconde pour l'instance principale et de 0,5 seconde pour les instances répliquées.
Si les valeurs de la métrique dépassent ces recommandations, nous vous recommandons d'augmenter le nombre de fragments ou de réplicas de votre instance.
Commandes Valkey gourmandes en ressources processeur
Vous devez éviter les commandes Valkey dont l'exécution est coûteuse pour diverses raisons. Cette section fournit des exemples de raisons pour lesquelles certaines commandes sont coûteuses, mais cette liste n'est pas exhaustive.
Commandes qui opèrent sur tout l'espace de clés
- KEYS
Commandes qui fonctionnent sur un jeu de clés de longueur variable
- LRANGE
- ZRANGE
- HGETALL
Commandes qui bloquent l'exécution d'un script
- ÉVALUATION
- EVALSHA
Risques liés à l'utilisation de commandes coûteuses
- Latence élevée et expiration du délai 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, en raison du blocage du thread principal de Valkey.
- Vérifications de l'état, observabilité et réplication bloquées.
Bonnes pratiques pour le client Valkey
Votre application doit utiliser un client Valkey compatible avec les clusters lors de la connexion à une instance Memorystore pour Valkey. Pour obtenir des exemples de clients compatibles avec les clusters et des exemples de configurations, consultez la section Exemples de code de bibliothèque cliente. Votre client doit conserver un mappage des emplacements de hachage avec les nœuds correspondants de l'instance afin d'envoyer les requêtes aux nœuds appropriés et d'éviter les problèmes de performances causés par les redirections.
Mappage des clients
Les clients doivent obtenir une liste complète des emplacements et des nœuds mappés dans les situations suivantes :
Lorsque le client est initialisé, il doit renseigner le mappage de l'emplacement initial aux nœuds.
Lorsqu'une redirection
MOVEDest reçue du serveur, par exemple en cas de basculement lorsque tous les emplacements servis par l'ancien nœud principal sont repris par le réplica, ou de re-partitionnement lorsque des emplacements sont déplacés de l'emplacement principal source vers le nœud principal cible.Lorsqu'une erreur
CLUSTERDOWNest reçue du serveur ou que les connexions à un serveur particulier rencontrent des délais d'inactivité de manière persistante.Lorsqu'une erreur
READONLYest reçue du serveur. Cela peut se produire lorsqu'une adresse e-mail principale est rétrogradée en instance répliquée.De plus, les clients doivent actualiser régulièrement la topologie pour rester prêts à tout changement et connaître les modifications qui ne peuvent pas entraîner de redirections ni d'erreurs de la part du serveur, par exemple lorsque de nouveaux nœuds de réplication 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 le besoin de gérer les connexions défaillantes pendant l'exécution de la commande.
Découverte de clients
La découverte de clients se fait généralement en envoyant 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 aux commandes de découverte du client peut varier en fonction de la taille et de la topologie de l'instance. Les instances plus importantes avec plus de nœuds génèrent une réponse plus importante. Par conséquent, il est important de s'assurer que le nombre de clients effectuant la découverte de la topologie des nœuds n'augmente pas illimité.
Ces actualisations de topologie de 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 ne lance qu'une seule requête de découverte à un moment donné (et qu'il met en cache le résultat en mémoire), et que le nombre de clients qui envoient des requêtes est limité pour éviter de surcharger le serveur.
Par exemple, lorsque l'application cliente démarre ou perd la connexion au serveur et doit effectuer une découverte de nœuds, une erreur courante consiste à effectuer plusieurs requêtes de reconnexion et de découverte sans ajouter d'intervalle exponentiel entre les tentatives lors de la nouvelle tentative. Le serveur Valkey peut alors ne pas répondre pendant une période prolongée, ce qui entraîne une utilisation très élevée du processeur.
Éviter la surcharge de découverte sur Valkey
Pour atténuer l'impact d'un afflux soudain de requêtes de connexion et de découverte, nous vous recommandons de procéder comme suit :
Implémentez un pool de connexions client de taille limitée et de petite taille pour le nombre de connexions entrantes simultanées en provenance du client application.
Lorsque le client se déconnecte du serveur en raison d'un délai avant expiration, réessayez avec un intervalle exponentiel entre les tentatives avec gigue. Cela permet d'éviter que plusieurs clients sur le serveur en même temps.
Utiliser le point de terminaison de découverte Memorystore for Valkey pour effectuer des découverte. Le point de terminaison de découverte est disponibilité élevée et à équilibrage de charge sur tous les nœuds de l'instance. De plus, le point de terminaison de découverte tente pour acheminer les requêtes de découverte de nœuds vers les nœuds disposant "Topologie".
Bonnes pratiques de persistance
Cette section décrit les bonnes pratiques concernant la persistance.
Persistance RDB
Pour obtenir les meilleurs résultats lors de la sauvegarde de votre instance à l'aide d'instantanés RDB, 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 lors de l'écriture" pour créer un instantané des données de nœud. En fonction du schéma d'écriture sur les nœuds, la mémoire utilisée des nœuds augmente à mesure que les pages concernées par les écritures sont copiées. Dans le pire des cas, l'espace mémoire peut doubler la taille des données dans le nœud.
Pour vous assurer que les nœuds disposent de suffisamment de mémoire pour créer l'instantané, vous devez conserver ou définir maxmemory sur 80% de la capacité du nœud, de sorte que 20% soient réservés aux frais généraux. Pour en savoir plus, consultez Surveiller une instance présentant une charge d'écriture élevée. Cette surcharge de mémoire, en plus des instantanés Monitoring, vous aide à gérer votre charge de travail de façon à obtenir des instantanés réussis.
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 un nombre important de clés obsolètes ou d'autres modifications apportées à votre base de données, telles qu'un changement 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 la persistance réactivée, un instantané est créé au prochain intervalle d'instantanés planifié.
Impact des instantanés RDB sur les performances
Selon le modèle de votre charge de travail, les instantanés RDB peuvent affecter les performances de l'instance et augmenter la latence de vos applications. Vous pouvez minimiser l'impact sur les performances des instantanés RDB en planifiant leur exécution lors des périodes de faible trafic d'instance si la fréquence des instantanés ne vous convient pas.
Par exemple, si le trafic de votre instance est faible 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 est soumis à 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.
Choisissez une instance à zone unique si votre instance n'utilise pas de réplicas.
Lorsque vous configurez une instance sans réplicas, nous vous recommandons d'utiliser une architecture à zone unique pour améliorer la fiabilité. Voici pourquoi :
Réduire au maximum 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, le risque d'indisponibilité de zone affectant votre serveur de 100% à 33%. En effet, il y a 33% de chances que la zone est défaillante, alors qu'il y a 100% de chances que les nœuds situés la zone indisponible sont affectées.
Récupération rapide
En cas de panne de zone, la reprise est simplifiée. Vous pouvez y répondre en provisionnant rapidement une nouvelle instance dans une zone de fonctionnement et en redirigeant votre application pour que les opérations soient le moins interrompues possible.