Bonnes pratiques pour Memorystore pour Valkey

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 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 évictions 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 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 aux nouvelles données.

Si l'utilisation de la mémoire de l'instance est élevée, procédez comme suit pour améliorer les performances :

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

Procéder au scaling des segments en mode Cluster activé

Lorsque vous ajustez le nombre de segments dans une instance, nous vous recommandons de le faire pendant les périodes de faible activité d'écriture. Le scaling pendant les périodes d'utilisation intensive 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 de Valkey utilise des évictions de clés, le scaling vers une 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 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 capacité que vers une instance plus petite qui dispose encore de suffisamment d'espace pour vos données. Le nouveau nombre de segments cible 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 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

Si une panne zonale inattendue se produit, 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 plusieurs instances répliquées par segment (par opposition à une instance répliquée par segment) fournit des ressources de processeur supplémentaires en cas de panne. Vous pouvez avoir jusqu'à cinq instances répliqué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 capacité perdue en cas de panne zonale inattendue. Vous devez surveiller l'utilisation du processeur pour les instances dupliquées principales et secondaires à l'aide de la métrique Secondes de processeur du thread principal /instance/cpu/maximum_utilization.

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, ciblez une valeur /instance/cpu/maximum_utilization de 0,5 seconde pour l'instance principale et de 0,5 seconde pour l'instance répliquée.
  • Pour les instances comportant au moins deux instances répliquées par nœud, ciblez une valeur /instance/cpu/maximum_utilization de 0,9 seconde pour l'instance principale et de 0,5 seconde pour chaque instance répliqué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 vous avez moins de cinq instances répliquées pour votre instance, vous pouvez également augmenter le nombre d'instances répliquées, jusqu'à un maximum de cinq.

Si votre instance utilise beaucoup de ressources de processeur ou si ses ressources sont épuisées (par exemple, en raison d'un trop grand nombre de connexions), elle peut ne pas fonctionner correctement 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 avant expiration du client
  • Saturation 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, 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 qui consomment beaucoup de ressources et vous propose des alternatives plus économes en ressources.

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 seuils de scaling

Les scénarios de seuil de scaling se répartissent dans les catégories suivantes :

  • Scaling pour l'utilisation de la mémoire
  • Scaling pour l'utilisation du processeur
  • Scaling pour atténuer les hotspots

Si votre charge de travail repose sur l'éviction de clés, Google ne recommande pas de réduire l'utilisation du processeur ou de la mémoire. Dans ces charges de travail, l'utilisation de la mémoire atteint fréquemment sa capacité maximale avant que les évictions ne se produisent automatiquement. Les pics de mémoire qui en résultent bloquent les opérations de réduction d'échelle.

Les sections suivantes décrivent les scénarios courants et les seuils de métriques qui peuvent justifier un scaling.

Scaling de l'utilisation de la mémoire

Pour déterminer quand effectuer un scaling en fonction de l'utilisation de la mémoire, surveillez les métriques /instance/memory/average_utilization et /instance/memory/maximum_utilization. Pour en savoir plus sur ces métriques, consultez Métriques de surveillance compatibles.

Si votre instance remplit l'une des conditions suivantes, envisagez de déclencher une opération de scaling horizontal :

  • L'utilisation moyenne de la mémoire de votre instance dépasse le seuil suggéré de 70%.
  • L'utilisation maximale de la mémoire dépasse 80% et l'utilisation moyenne de la mémoire dépasse 50%.

Si votre instance remplit l'une des conditions suivantes, envisagez de déclencher une opération de scaling horizontal (diminution) :

  • L'utilisation moyenne de la mémoire de votre instance passe en dessous du seuil suggéré de 50%.
  • L'utilisation maximale de la mémoire passe en dessous de 60% et l'utilisation moyenne de la mémoire passe en dessous de 40%.

Scaling de l'utilisation du processeur

Pour déterminer quand effectuer un scaling en fonction de l'utilisation du processeur, surveillez les métriques /instance/cpu/average_utilization et /instance/cpu/maximum_utilization.

Si votre instance remplit l'une des conditions suivantes, envisagez de déclencher une opération de scaling horizontal :

  • L'utilisation moyenne du processeur de votre instance dépasse le seuil suggéré de 70%.
  • L'utilisation maximale du processeur dépasse 80% et l'utilisation moyenne du processeur dépasse 50%.

Si votre instance remplit l'une des conditions suivantes, envisagez de déclencher une opération de scaling horizontal (diminution) :

  • L'utilisation moyenne du processeur de votre instance passe en dessous du seuil suggéré de 50%.
  • L'utilisation maximale du processeur passe en dessous de 60% et l'utilisation moyenne du processeur passe en dessous de 40%.

Scaling pour atténuer les hotspots

Memorystore pour Valkey fournit des variations moyennes et maximales de la même métrique, que vous pouvez utiliser pour identifier les hotspots de cette famille de métriques. La valeur maximale représente le nœud d'instance le plus chargé, tandis que la valeur moyenne représente la charge de l'instance entière. Si la valeur maximale est nettement supérieure à la valeur moyenne, cela indique qu'un nœud spécifique est chargé de manière disproportionnée (un point d'accès). Pour résoudre ce problème, nous vous recommandons d'effectuer un scaling horizontal de votre instance. Pour en savoir plus, consultez Faire évoluer la capacité d'une instance.

Lorsque vous observez une divergence significative entre les variations moyenne et maximale, vous pouvez exécuter les commandes INFO memory et INFO cpu sur les nœuds de l'instance pour collecter des données en temps réel directement à partir de l'instance. Pour en savoir plus sur l'utilisation de ces commandes, consultez INFO dans la documentation Valkey.

Bonnes pratiques concernant les clients Valkey

Éviter la surcharge de connexion sur Valkey

Pour limiter l'impact d'un afflux soudain de connexions, nous vous recommandons de procéder comme suit :

  • Déterminez la taille de 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 une analyse comparative pour voir si l'ajout de connexions est utile sans saturer le nombre maximal de connexions autorisé.

  • 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 ne surchargent le serveur simultanément.

Détecter et gérer les connexions qui ne répondent pas

Nous vous recommandons vivement de configurer votre application cliente pour détecter les connexions qui ne répondent pas à Memorystore pour Valkey. Lorsqu'une connexion qui ne répond pas est détectée, le client doit la réinitialiser. Pour créer une application résiliente, nous vous recommandons les configurations client suivantes :

  • Configurez les paramètres TCP keep-alive : définissez les paramètres TCP keepalive time, TCP keepalive interval et TCP keepalive probes de sorte que les clients détectent et suppriment de manière proactive les connexions qui ne répondent pas, même lorsqu'elles sont inactives. Par exemple, si vous définissez le paramètre TCP keepalive time sur 30 secondes, TCP keepalive interval sur 10 secondes et TCP keepalive probes sur 3, les clients réinitialisent les connexions inactives qui ne répondent pas dans un délai d'une minute.
  • Configurer les délais avant expiration TCP de l'utilisateur : définissez ce délai avant expiration dans vos clients pour réinitialiser les connexions qui ont des requêtes en attente et qui ne répondent plus. Par exemple, si vous définissez le délai avant expiration sur 15 secondes, les clients réinitialisent les connexions qui ne répondent pas et qui ont des requêtes en attente après 15 secondes.

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 avec le 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 conserver un mappage des emplacements de hachage vers les nœuds correspondants dans l'instance pour envoyer des requêtes aux nœuds appropriés. Cela évite les frais généraux de performances causés par les redirections.

Mappage client

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 renseigner 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 diffusés par l'ancien nœud principal sont repris par l'instance répliquée, ou en cas de re-sharding 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 répliquée.

  • De plus, les clients doivent actualiser régulièrement la topologie pour rester informés des modifications et prendre connaissance de celles qui n'entraînent pas de redirections ni d'erreurs de la part du serveur, par exemple lorsque de nouveaux nœuds d'instance répliquée 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é pendant l'exécution de la commande.

Découverte des clients

La découverte des clients s'effectue 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 volumineuses avec plus de nœuds produisent une réponse plus volumineuse. 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 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é de l'application. Il est donc important de s'assurer que chaque client n'effectue qu'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 soit 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 à envoyer plusieurs requêtes de reconnexion et de découverte sans ajouter de temporisation de retransmission lors de la nouvelle tentative. 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écouverte pour la découverte de nœuds

Utilisez le point de terminaison de découverte Memorystore pour Valkey pour effectuer la découverte de 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 d'acheminer les requêtes de découverte de nœuds vers les nœuds disposant de la vue de topologie la plus récente.

Pour les instances avec le mode cluster désactivé

Lorsque votre application se connecte à une instance en mode cluster désactivé, elle 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 les instances répliquées et isoler le trafic du nœud principal.

Étant donné que les instances avec le mode cluster désactivé ne comportent qu'un seul segment, elles n'utilisent pas de topologie en mémoire. Par conséquent, l'actualisation de la topologie n'est pas applicable.

Lors des basculements et des événements de maintenance, les connexions à l'instance sont interrompues. Pour vous assurer que votre application se reconnecte correctement après ces événements, implémentez un mécanisme de nouvelle tentative avec intervalle exponentiel entre les tentatives.

Vous pouvez utiliser la stratégie de création avant destruction lorsque vous effectuez une maintenance sur votre instance. Pour en savoir plus sur cette stratégie, consultez Stratégie de cycle de vie "Créer avant de détruire".

Si vous utilisez cette stratégie, vous risquez de 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. Ensuite, recréez la connexion.

Bonnes pratiques concernant la persistance

Cette section décrit les bonnes pratiques concernant la persistance.

Persistance RDB et ajout d'instances répliquées

Pour obtenir de meilleurs résultats lors de la sauvegarde de votre instance avec des instantanés RDB ou de l'ajout d'instances répliqué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 du nœud. Selon le modèle 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. L'espace mémoire utilisé peut être jusqu'à deux fois supérieur à la taille des données du nœud.

Pour vous assurer que les nœuds disposent de suffisamment de mémoire pour effectuer l'instantané, conservez ou définissez maxmemory sur 80 % de la capacité du nœud, de sorte que 20% soient réservés aux frais généraux. Cette surcharge de mémoire, en plus de la surveillance des instantanés, vous aide à gérer votre charge de travail pour réussir vos instantanés. De plus, lorsque vous ajoutez des instances répliquées, réduisez autant que possible le trafic d'écriture. Pour en savoir plus, consultez Surveiller l'utilisation de la mémoire pour une instance.

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 rapprocher une quantité importante de clés obsolètes ou d'autres modifications apportées à votre base de données, comme une modification 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 pris à l'intervalle d'instantané planifié suivant.

Impact des instantanés RDB sur les performances

Selon 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 pendant les périodes de faible trafic sur l'instance, si vous acceptez de réduire la fréquence des instantanés.

Par exemple, si votre instance enregistre un faible trafic 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, 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 répliquée

L'ajout d'une instance répliquée nécessite un instantané RDB. Pour en savoir plus sur les instantanés RDB, consultez 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 répliquées, nous vous recommandons d'utiliser une instance monozone. Voici pourquoi :

Coût et performances

Si vos principaux objectifs sont de réduire 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 monozone.

Réduire 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, la probabilité 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 tombe 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 monozone, Memorystore pour 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 que les opérations soient interrompues le moins possible.

Bonnes pratiques de planification de la capacité

Pour vous assurer que vous pouvez provisionner des ressources et créer des architectures résilientes, nous vous recommandons de suivre les bonnes pratiques de planification de la capacité suivantes :

  • Déployer sur plusieurs emplacements : si vous ne parvenez pas à créer une instance dans votre zone préférée en raison de contraintes de ressources temporaires, essayez de créer l'instance dans une autre zone de la même région ou dans une autre région.
  • Utiliser l'accès interrégional : configurez vos clients pour qu'ils accèdent à vos instances situées dans différentes régions. Si vous devez provisionner une instance située dans une autre région en raison de contraintes de ressources locales, vos clients peuvent se connecter à l'instance.
  • Utiliser la réplication interrégionale : pour promouvoir une instance secondaire dans une autre région en tant qu'instance principale en lecture ou en écriture pour la reprise après sinistre, effectuez un basculement.

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é

L'utilisation de TLS vous offre les 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é de serveur, telles que les attaques de type "person-in-the-middle".
  • Chiffrement en transit : le chiffrement intégré deGoogle Cloudprotège le trafic au sein du réseau de Google au niveau de l'infrastructure. Toutefois, cela implique de faire confiance aux piles d'hôte et à la pile 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 d'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 réduit le risque d'exposition et de fuite de vos jetons d'authentification.

Implications en termes de performance

TLS a un impact sur les performances de différentes manières :

  • Établir des connexions : un client et un serveur qui ont établi une session TLS peuvent reprendre la session sans répéter le processus d'établissement de la connexion entre le client et le serveur, qui consomme beaucoup de ressources. 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 nécessite beaucoup de ressources. Pour les connexions nouvelles et existantes, de nombreuses connexions entre le client et le serveur peuvent entraîner des délais avant expiration de la connexion. Cela peut provoquer un effet boule de neige, car Memorystore pour Valkey tente de rétablir les connexions ayant expiré, ce qui augmente les ressources utilisées pour établir les connexions.

  • Chiffrement et déchiffrement des données : le chiffrement et le déchiffrement des données impliquent des opérations gourmandes en ressources de 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 envisagez d'activer 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 des connexions. Une connexion entre le client et le serveur n'est requise que pour la connexion initiale. Cependant, une augmentation soudaine de la taille de l'instance du client peut entraîner une brève interruption causée par le handshake complet initial de chaque nouvel hôte client.
  • Bien que certaines bibliothèques clientes ne proposent pas de commandes intégrées pour activer TLS, vous pouvez utiliser du code personnalisé pour intégrer cette fonctionnalité dans vos instances.