Bonnes pratiques pour Memorystore pour Valkey

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 des instances afin que Memorystore pour 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 pour Valkey utilise la règle d'éviction volatile-lru. Vous pouvez utiliser des commandes Valkey telles que EXPIRE pour définir des expulsions pour les clés.

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

Pour surveiller l'utilisation de la mémoire d'une instance Memorystore pour 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 l'utilisation des données, 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 :

Si vous rencontrez des problèmes, contactez l'assistanceGoogle Cloud .

Scaler les partitions en mode cluster activé

Lorsque vous mettez à l'échelle le nombre de partitions dans une instance, nous vous recommandons de le faire pendant les périodes de faible charge en écriture. Le scaling pendant les périodes de forte utilisation 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 à une taille d'instance 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 Valkey où vous ne souhaitez pas perdre de clés, vous ne devez réduire la taille de l'instance que si elle 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 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 à haute disponibilité. L'utilisation de deux réplicas par partition (au lieu d'un seul) fournit des ressources de processeur supplémentaires en cas d'indisponibilité. 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 /instance/cpu/maximum_utilization.

En fonction du nombre de répliques 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 réplique par nœud, vous devez cibler une valeur /instance/cpu/maximum_utilization de 0,5 seconde pour la réplique et l'instance principale.
  • Pour les instances avec deux réplicas par nœud, vous devez cibler une valeur /instance/cpu/maximum_utilization de 0,9 seconde pour le primaire et de 0,5 seconde pour les réplicas.

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 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 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 de Valkey est bloqué
  • Vérifications d'état, observabilité et réplication affamées

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

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 le client Valkey

Éviter la surcharge de connexion sur Valkey

Pour limiter 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 un benchmark pour voir si l'augmentation du nombre de connexions est utile sans saturer le nombre maximal de connexions autorisées.

  • Lorsque le client se déconnecte du serveur en raison d'un délai d'expiration du serveur, réessayez avec un intervalle exponentiel entre les tentatives avec gigue. Cela permet d'éviter que plusieurs clients surchargent le serveur simultanément.

Pour les instances avec le mode cluster activé

Votre application doit utiliser un client Valkey compatible avec les clusters lorsqu'elle se connecte à une instance Memorystore pour Valkey en mode cluster activé. 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 de l'instance pour envoyer les requêtes aux bons nœuds. Cela permet d'éviter la surcharge de performances causée par les redirections.

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 des 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 grandes 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 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 de nœuds, 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 Valkey non réactif pendant une longue période, ce qui entraîne une utilisation très élevée du processeur.

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

Utilisez le point de terminaison de découverte Memorystore pour Valkey pour effectuer la découverte des nœuds. Le point de terminaison de découverte 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écouverte tente de router les requêtes de découverte de nœuds vers les nœuds dont la vue de la topologie est la plus à jour.

Pour les instances avec le 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 dernières écritures. Votre application peut également se connecter au point de terminaison du lecteur pour lire les instances répliquées et isoler le trafic du nœud principal.

Bonnes pratiques de persistance

Cette section explique les bonnes pratiques concernant la persistance.

Persistance RDB

Pour obtenir les meilleurs résultats lors de la sauvegarde de votre instance avec des 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 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. Dans le pire des cas, l'empreinte mémoire peut être 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é, 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 l'utilisation de la mémoire pour une instance. 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.

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 êtes à l'aise avec 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.

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 à une seule zone 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.