Cette page a été traduite par l'API Cloud Translation.

Bonnes pratiques générales

Cette page fournit des conseils pour utiliser Memorystore pour Redis de manière optimale. Elle souligne également les problèmes potentiels à éviter.

Pour obtenir la liste des scénarios de dépannage, consultez la page Dépannage.

Exportation RDB

Lorsque vous exportez une sauvegarde RDB, suivez les conseils ci-dessous :

Exécutez une exportation pendant une période présentant un faible taux d'écriture.
Si vous procédez à l'exportation pendant une période présentant un taux d'écriture élevé, abaissez temporairement la configuration de maxmemory à 50 % de la capacité de l'instance afin de maintenir une surcharge suffisante pour une opération réussie.

Opérations exigeantes en ressources

Pour les instances Redis de niveau standard, les opérations suivantes utilisent de la mémoire supplémentaire pendant toute la durée de l'opération :

En raison de la réplication, les opérations de mise à niveau de la version, de scaling et de basculement manuel utilisent de la mémoire supplémentaire (pour les instances de niveau standard). Ces opérations suivent le processus de réplication décrit dans la section Comportement de la mise à niveau des instances de niveau standard.

Les opérations d'importation et d'exportation nécessitent de la mémoire supplémentaire en raison du processus Redis dupliqué et de la gestion de données de copie pour écriture associées à ces opérations.

Afin de limiter les inconvénients des opérations exigeantes en ressources, vous devez effectuer les opérations suivantes :

Abaisser la configuration de maxmemory à 80 % de la capacité de l'instance pendant la durée de l'opération. Cela permet de maintenir une surcharge suffisante pour une opération réussie.
Surveiller la métrique du taux d'utilisation de la mémoire système et vous assurer que cette métrique est inférieure à 80 % avant d'exécuter l'une de ces opérations.
Exécuter ces opérations pendant les périodes où le trafic de l'instance est faible (par exemple, la nuit, le week-end, etc.).
Mettre en place une logique de nouvelle tentative avec un intervalle exponentiel entre les tentatives avant d'exécuter ces opérations.

Opérations et scénarios nécessitant une nouvelle tentative de connexion

Les opérations et scénarios suivants interrompent la connexion entre votre réseau et l'instance Redis :

Mise à niveau de la version
Scaling à la hausse/à la baisse
Importation…
Basculement manuel
Maintenance du système
La rotation des autorités de certification pour les instances Redis pour lesquelles le chiffrement en transit est activé
Basculement d'urgence

Ces opérations modifient votre instance, ce qui nécessite une interruption temporaire de la connexion. Vous devez mettre en place une logique de nouvelle tentative avec un intervalle exponentiel entre les tentatives avant de pouvoir exécuter ces opérations, afin que votre application se reconnecte automatiquement et continue à fonctionner normalement.

Maintenance de routine

Les instances Memorystore pour Redis font l'objet d'une maintenance périodique. Pour en savoir plus, consultez la stratégie de maintenance de Memorystore pour Redis.

Mettez en œuvre les bonnes pratiques suivantes pour vous préparer à la maintenance de routine :

Définissez un intervalle de maintenance indiquant quand les mises à jour de maintenance peuvent avoir lieu.
- Planifiez les intervalles de maintenance pour les périodes de faible trafic d'instance et de surcharge de mémoire suffisante. Pour en savoir plus, consultez la section Impact des mises à jour de maintenance.
Activez les notifications d'intervalles de maintenance pour être informé des prochains événements.
Vous devez mettre en place une logique de nouvelle tentative avec un intervalle exponentiel entre les tentatives.
Pour les instances de niveau standard, vous pouvez simuler un événement de maintenance en utilisant le basculement manuel pour voir comment le basculement causé par la maintenance affecte votre application.
Pour les instances de niveau de base, vous pouvez simuler l'impact d'une mise à jour de maintenance en effectuant un scaling temporaire de l'instance vers une taille plus grande. Après avoir observé l'impact, vous pouvez revenir à la taille d'origine.

Gestion de la mémoire

La gestion de la mémoire peut s'avérer difficile en raison de la fragmentation de la mémoire bien connue avec Redis Open Source. Nous vous recommandons d'abaisser la configuration de maxmemory de votre instance pour vous donner de la surcharge en cas de saturation de la mémoire.

Le meilleur moyen de surveiller la saturation de la mémoire sur votre instance Memorystore est d'utiliser la métrique du taux d'utilisation de la mémoire système. Pour obtenir des instructions plus détaillées sur la gestion de la mémoire pour Memorystore pour Redis, consultez la page Bonnes pratiques pour la gestion de la mémoire.

Gérer les connexions inactives

Au fil du temps, il est possible que le nombre de connexions à votre instance Memorystore augmente si les connexions ne sont pas correctement fermées. Cela peut avoir des conséquences négatives sur les performances, en particulier si vous utilisez le chiffrement en transit, qui impose des limites sur le nombre maximum de connexions en fonction de votre niveau de capacité. Pour éviter cela, nous vous recommandons d'utiliser le paramètre de configuration Redis timeout, qui vous permet de définir le nombre de secondes avant l'arrêt automatique des connexions clientes inactives.

Noms des ressources Access Transparency

Les données sensibles ne doivent pas être stockées dans Memorystore pour Redis pour les noms de ressources. Par "noms de ressources", nous entendons les noms d'instance Memorystore pour Redis et les métadonnées d'instance, telles que les balises. Il n'est pas garanti que les données stockées dans les noms de ressources soient protégées par Access Transparency de Google Cloud. Elles peuvent entrer en conflit avec les exigences de conformité d'Access Transparency de votre organisation.

Connecteur d'accès au VPC sans serveur requis pour certains environnements sans serveur

Certains environnements sans serveur nécessitent un connecteur d'accès au VPC sans serveur pour se connecter à Memorystore pour Redis. Si vous souhaitez vous connecter à l'aide de l'un de ces environnements, configurez le connecteur d'accès au VPC sans serveur pour votre projet.

Mise en réseau

Nous vous recommandons d'utiliser le mode de connexion d'accès aux services privés. Memorystore pour Redis utilise deux modes de connexion : l'accès aux services privés et l'appairage direct. Le mode de connexion d'accès aux services privés simplifie la gestion des plages d'adresses IP et vous permet d'utiliser un VPC partagé si vous le souhaitez.

Une fois que vous avez créé une instance, le mode de connexion ne peut plus être modifié.

Pour en savoir plus, consultez la page Mise en réseau.

Surveillance et alertes

Nous vous recommandons d'utiliser la surveillance et les alertes, car elles vous fournissent des signaux clés sur l'utilisation de la mémoire de l'instance Redis. Elles vous donnent également un aperçu de l'efficacité de réponse de votre instance Redis aux requêtes de cache entrantes.

Vous devez configurer les alertes par défaut suivantes :

Bonnes pratiques concernant l'utilisation du processeur

Une mauvaise utilisation des commandes Redis coûteuses entraîne une latence élevée, une absence de réponse ou des problèmes de connectivité. Les instances de niveau standard offrent une haute disponibilité lors de la reprise après sinistre et s'appuient sur la réplication asynchrone entre les nœuds principaux et les nœuds d'instance dupliquée. Si l'un des nœuds effectue un traitement de commande coûteux qui bloque le thread principal Redis, la réplication peut être affectée. Si le problème persiste et qu'une panne se produit à un emplacement, les données les plus récentes écrites à l'emplacement de la panne peuvent ne pas être disponibles à l'autre emplacement.

Nous vous recommandons d'utiliser Cloud Monitoring pour définir des alertes pour la métrique Secondes de CPU du thread principal (redis.googleapis.com/stats/cpu_utilization_main_thread) afin de vous assurer que l'utilisation du processeur ne dépasse pas 0,9 seconde pour le nœud principal et 0,5 seconde pour chaque nœud de réplication.

Si votre instance Redis dépasse les valeurs recommandées, nous vous recommandons de l'étendre à un niveau de capacité supérieur ou de suivre les instructions de dépannage pour éviter les opérations gourmandes en processeur.