Bonnes pratiques générales

Cette page fournit des conseils pour utiliser Memorystore pour 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 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 aller 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 des commandes Valkey telles que la commande EXPIRE pour définir des expulsions pour les 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 est à 100% ou moins, votre instance Valkey fonctionne correctement lorsque vous utilisez une charge d'écriture normale.

Toutefois, si l'utilisation de la mémoire approche 100% et que vous prévoyez une augmentation de l'utilisation des données, vous devez augmenter la taille de votre instance pour laisser 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. En fonction de la gravité de votre charge d'écriture élevée, votre instance peut rencontrer des problèmes de performances aux seuils suivants:

  • Des charges d'écriture très élevées peuvent entraîner des problèmes si /instance/memory/maximum_utilization atteint 65% ou plus.

  • Les charges d'écriture modérément élevées peuvent rencontrer des problèmes si /instance/memory/maximum_utilization atteint 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 modifiez le nombre de segments 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 Valkey utilise des évictions de clés, le scaling vers une taille d'instance plus petite peut réduire votre taux d'accès au cache. Dans ce cas, cependant, 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 fragments cibles doit être au moins 1,5 fois supérieur à la mémoire utilisée par les données. En d'autres termes, vous devez provisionner suffisamment de shards 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 fragment (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 de réplicas que vous provisionnez par nœud, nous vous recommandons les cibles d'utilisation du processeur /instance/cpu/maximum_utilization suivantes:

  • Pour les instances avec un réplica par nœud, vous devez cibler une valeur /instance/cpu/maximum_utilization de 0,5 seconde pour l'instance principale et le réplica.
  • Pour les instances avec deux réplicas par nœud, vous devez cibler une valeur /instance/cpu/maximum_utilization de 0,9 seconde pour l'instance principale et de 0,5 seconde pour les réplicas.

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 coûteuses en CPU

Évitez d'exécuter des commandes Valkey coûteuses 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 s'appliquent à l'ensemble de 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

  • EVAL
  • EVALSHA

Risques liés à l'utilisation de commandes coûteuses

  • Latence élevée et expiration du délai client
  • Pression de 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 les clients Valkey

Votre application doit utiliser un client Valkey compatible avec le cluster lorsqu'elle se connecte à 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 gérer une carte des emplacements de hachage vers les nœuds correspondants de l'instance afin d'envoyer des requêtes aux bons nœuds et d'éviter les coûts liés aux 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 MOVED est 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 CLUSTERDOWN est reçue du serveur ou que les connexions à un serveur particulier rencontrent des délais d'expiration persistants.

  • 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 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 pour les 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. Il est donc important de s'assurer que le nombre de clients effectuant la découverte 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 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. Cela peut entraîner une indisponibilité prolongée du serveur Valkey, ce qui entraîne une utilisation très élevée du processeur.

Éviter la surcharge de la 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 petite taille et limité pour limiter le nombre de connexions entrantes simultanées de l'application cliente.

  • 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 ne submergent le serveur en même temps.

  • Utilisez le point de terminaison de détection Memorystore pour Valkey pour effectuer la détection de nœuds. Le point de terminaison de découverte est disponibilité élevée et équilibré en charge sur tous les nœuds de l'instance. De plus, le point de terminaison de découverte tente de router les requêtes de découverte de nœuds vers les nœuds disposant de la vue de topologie la plus à jour.

Bonnes pratiques concernant la persistance

Cette section décrit les bonnes pratiques à suivre pour 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 effectuer l'instantané, vous devez conserver ou définir maxmemory à 80% de la capacité du nœud afin 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 de la surveillance des instantanés, vous aide à gérer votre charge de travail pour 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

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 réduire l'impact des instantanés RDB sur les performances en les planifiant pendant les périodes de faible trafic d'instance, si vous acceptez des instantanés moins fréquents.

Par exemple, si le trafic de votre instance est faible de 1h à 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 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 indisponible, contre 100% de chances que les nœuds situés dans la zone indisponible soient concernés.

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.