Amélioration de la résilience des bases de données avec l'observabilité et les tests de résilience par le chaos

Dans l'écosystème dynamique du web, les systèmes évoluent et deviennent de plus en plus distribués, ce qui renforce l'importance de l'observabilité, de l'automatisation et de cadres de tests robustes. À la tête du développement de systèmes résilients se trouve l'ingénierie du chaos, une pratique dans laquelle des défaillances sont intentionnellement injectées dans le système pour identifier les faiblesses avant qu'elles ne provoquent de réels problèmes. New Relic mène des tests de résilience par le chaos hebdomadaires dans son environnement préproduction afin de découvrir et de résoudre les pannes potentielles des systèmes, en particulier dans des environnements complexes comme les bases de données relationnelles.

Amazon Aurora, entre autres bases de données, pose des défis uniques compte tenu de sa nature distribuée, de son architecture et de sa méthode de basculement pour assurer une haute disponibilité. Cet article explique comment tirer parti de l'observabilité et de l'ingénierie du chaos pour garantir que vos services peuvent gérer les dégradations des bases de données.

Tests de résilience par le chaos pour les bases de données

Les tests de résilience par le chaos fournissent des informations précieuses et détaillées sur la résilience des systèmes et préparent les équipes à des scénarios du monde réel. Voici les principaux avantages des tests de résilience par le chaos au niveau des bases de données :

• Validation du basculement et robustesse des applications : ces tests mettent en évidence les faiblesses au niveau de la gestion des erreurs dans les applications et les configurations des pilotes, et offrent ainsi la possibilité de renforcer les défenses du système.

• Atténuation des pannes potentielles et protection des données : les tests de résilience par le chaos menés régulièrement réduisent les surprises, minimisent les pannes et protègent contre la perte de données en améliorant les temps de réponse aux incidents.

• Assurance d'une observabilité et d'alertes efficaces : des scénarios de chaos testent notre infrastructure de monitoring et nos mécanismes d'alerte, ce qui permet aux équipes d'affiner leurs stratégies de réponse aux incidents.

• Meilleure compréhension du système et amélioration de la documentation : les équipes améliorent leurs connaissances et créent une documentation complète, ce qui facilite les dépannages et la gestion des incidents futurs.

• Optimisation de la capacité et des performances : le test de résilience par le chaos met l'accent sur les points de stress et les limites de capacité, et aide ainsi les équipes à planifier et à faire évoluer leur infrastructure avec plus de précision.

Démarrage

Pour réussir l'implémentation du test de résilience par le chaos, il est essentiel de mettre en place l'observabilité et le monitoring. Nous détaillons ci-dessous les composants clés :

• Agent d'infrastructure New Relic : un composant essentiel qui effectue le monitoring des performances de votre système. Avec ses intégrations spéciales pour MySQL et PostgreSQL, il fournit des informations détaillées spécifiques à ces bases de données.

• Flux de métriques entre Amazon CloudWatch et New Relic avec l'utilisation de Kinesis Firehose : utilisez les flux de métriques AWS CloudWatch pour envoyer un flux continu de métriques AWS CloudWatch vers New Relic, y compris des données de monitoring en temps réel pour les bases de données Aurora.

• Flux de logs New Relic avec l'utilisation de Kinesis Firehose : effectuez la configuration pour diffuser les logs Aurora MySQL et PostgreSQL directement dans New Relic pour une analyse complète des logs et l'observabilité.

Agent Go de New Relic pour l'APM : New Relic for Go monitore votre application et vos microservices en langage Go pour vous aider à identifier et à résoudre les problèmes de performances.

En intégrant ces composants dans votre architecture cloud, vous pouvez poser les bases d'une observabilité détaillée qui est essentielle pour mener des tests de résilience par le chaos et en tirer des enseignements.

Préparation à l'observabilité des bases de données

Il est important non seulement de voir les changements du système, mais aussi de les observer —  pour comprendre le contexte et les implications au fil du temps grâce au monitoring automatisé qui transforme les données brutes en informations détaillées exploitables.

Côté client

Il est essentiel de monitorer le comportement de l'application lorsqu'elle interagit avec la base de données. Utilisez New Relic APM pour le monitoring en temps réel des performances des applications à observer :

• Taux d'erreur : monitorez la fréquence des erreurs dans l’application pendant les tests de résilience par le chaos.

• Débit : faites le suivi du nombre de transactions traitées par votre application.

• Temps de réponse : mesurez le temps nécessaire à votre application pour répondre aux demandes lors des différentes phases de test.

• Alertes : configurez des alertes pour les anomalies de taux d'erreur et de débit, ce qui vous permettra de répondre rapidement aux problèmes que le test de résilience par le chaos pourrait révéler.

Côté serveur

Il est également nécessaire de monitorer ce qui se passe au sein du service de bases de données lui-même. Voici les éléments à surveiller :

• Les métriques CloudWatch Aurora : tirez parti d'Amazon CloudWatch pour faire le suivi des indicateurs de performances clés (KPI) d'Aurora, dont l'utilisation du CPU, les opérations d'entrée/sortie par seconde (IOPS), etc.

• Logs des bases de données : gérez les données de logs de la base de données et examinez les résultats d'Aurora pour identifier tout modèle ou problème atypique détecté côté serveur lors du test.

• Analyse du débit : comparez le débit avant, pendant et après le test de résilience par le chaos pour comprendre son impact sur les performances.

En associant les données côté application de New Relic APM avec les métriques CloudWatch, nous obtenons une vue avec de multiples facettes, qui est cruciale pour réaliser et tirer une valeur maximale des tests par le chaos.

N'oubliez pas : l'observabilité n'est pas une simple liste de contrôle — c'est aussi la décision stratégique de ce qu'il faut mesurer, en configurant correctement les alertes et en comprenant bien la façon dont les données du stack nous fournissent les informations détaillées nécessaires pour émettre des hypothèses, les valider et les itérer.

Exécution d'un basculement Aurora

Le basculement est une procédure critique qui permet de maintenir la disponibilité des données en cas de perturbations inattendues. Le processus de basculement d'Amazon Aurora est conçu pour minimiser les temps d'arrêt en redirigeant automatiquement les opérations de base de données vers une instance de secours. Une bonne compréhension de cette opération peut vous guider dans la préparation à la résilience de vos systèmes.

Voici un bref aperçu de ce qui se produit lors d'un basculement Aurora :

1. Sélection de l'instance : Aurora choisit une instance en lecture seule appropriée pour la promouvoir au statut d'instance principale. La sélection prend en compte les spécifications de l'instance, sa zone de disponibilité et les priorités de basculement prédéfinies. Pour un examen approfondi de ce processus, AWS fournit des détails complets dans sa section sur la haute disponibilité pour Amazon Aurora.

2. Promotion de l'instance : l'instance en lecture seule sélectionnée est redémarrée en mode lecture/écriture pour servir de nouvelle instance principale.

3. Rétrogradation de l'instance principale : parallèlement, l'ancien nœud principal est redémarré en mode lecture seule, ce qui le prépare à rejoindre le pool d'instances en lecture seule.

4. Mises à jour du point de terminaison DNS : pour refléter les nouveaux rôles, Aurora met à jour ses enregistrements DNS. Le point de terminaison de l'enregistreur pointe vers la nouvelle instance principale, tandis que le point de terminaison du lecteur regroupe l’ancien nœud principal dans sa liste de lecteurs. La modification du DNS utilise une configuration TTL (durée de vie) de 5 secondes, mais la mise en cache côté client peut affecter la rapidité avec laquelle cette modification est reconnue.

Pendant la transition de basculement, de brèves interruptions de connexion sont attendues. Les clients doivent se préparer à quelques secondes de perturbation pendant qu'Aurora redirige le trafic vers le nouvel enregistreur (WRITER) et ajuste la configuration du lecteur (READER). Selon les observations documentées par AWS pour le basculement, ces interruptions durent environ 5 secondes en règle générale.

La facilitation d'un basculement en douceur exige que nos applications et nos pilotes sachent s'adapter pour gérer aisément ces transitions. Dans les sections suivantes, nous discutons de la configuration des pilotes et des paramètres optimaux pour les applications client afin de gérer ces transitions avec un impact minimal.

Identification et dépannage des problèmes de pilotes

Le monitoring des erreurs des pilotes et systèmes est fondamental pour bien comprendre comment vos applications résistent au basculement de base de données. Surveillez les erreurs d'APM côté client et celles des bases de données enregistrées côté serveur dans les logs pour détecter les erreurs liées à l'écriture sur un rôle de lecteur/réplica.

APM et événements de log

Voici quelques exemples d'erreurs que vous pourriez rencontrer lorsqu'une base de données MySQL ou PostgreSQL passe en lecture seule pendant le basculement, ce qui indique que l'application a tenté une opération d'écriture qui n'est pas autorisée :

PostgreSQL :

nested exception is org.postgresql.util.PSQLException: 
ERROR: cannot execute nextval() in a read-only transaction

MySQL:

Error 1290 (HY000): The MySQL server is running with the 
--read-only option so it cannot execute this statement

Les applications MySQL écrite en Go peuvent enregistrer des erreurs qui mettent l'accent sur la nature en lecture seule de la base de données suite à un basculement :

Error 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement
                                                                               main.(*Env).execQueryHandler (/src/handlers.go:204)
                                                             http.HandlerFunc.ServeHTTP (/usr/local/go/src/net/http/server.go:2136)
…in.configureServer.WrapHandleFunc.WrapHandle.func19 (/src/vendor/github.com/newrelic/go-agent/v3/newrelic/instrumentation.go:98)
                                                             http.HandlerFunc.ServeHTTP (/usr/local/go/src/net/http/server.go:2136)
          main.configureServer.WrapHandleFunc.func10 (/src/vendor/github.com/newrelic/go-agent/v3/newrelic/instrumentation.go:184)
                                                             http.HandlerFunc.ServeHTTP (/usr/local/go/src/net/http/server.go:2136)
                                                           mux.(*Router).ServeHTTP (/src/vendor/github.com/gorilla/mux/mux.go:212)
                                                             http.(*ServeMux).ServeHTTP (/usr/local/go/src/net/http/server.go:2514)
                                                           http.serverHandler.ServeHTTP (/usr/local/go/src/net/http/server.go:2938)
                                                                     http.(*conn).serve (/usr/local/go/src/net/http/server.go:2009)
                                                                        runtime.goexit (/usr/local/go/src/runtime/asm_amd64.s:1650)

Avec une mauvaise configuration des pilotes, le taux d'erreur après le basculement peut continuer à être élevé indéfiniment, ce qui peut être vu ici avec New Relic APM :

Il est crucial d'identifier rapidement ces messages d'erreur pour vite répondre aux incidents. Que vous utilisiez New Relic APM pour analyser les performances des applications ou que vous plongiez dans des données de logs plus granulaires, il est important de rester attentif à ces modèles d'erreurs pendant et après un basculement, car cela peut grandement vous aider dans votre processus de dépannage.

Configuration des pilotes et bonnes pratiques

Les pilotes de connexion aux bases de données doivent être correctement réglés pour gérer les basculements lors des opérations de maintenance planifiées ainsi que pour les scénarios imprévus.

Configuration des pilotes

Pour résister aux perturbations liées aux événements de basculement, les pilotes de connexion aux bases de données nécessitent un réglage précis. Cela prépare non seulement votre système à la maintenance planifiée, mais pose également les bases pour s'adapter à des scénarios imprévus.

Voici ce que vous devez garder à l’esprit pour configurer votre base de données et vos pilotes de cache :

• Paramètres DNS TTL : assurez-vous que votre système d'exploitation, toute couche de gestion DNS et le pilote de la base de données suivent la politique DNS TTL de 5 secondes d'AWS.

• Utilisez les pilotes de base de données intelligents : optez pour des pilotes qui gèrent efficacement la mise en cache du DNS et monitorez les états de l'instance pour une reconnexion automatique en cas de changement de l'état principal.

• Spécifiez les options du pilote : pour les bases de données AWS, envisagez le pilote JDBC pour MySQL spécialisé et pilote JDBC pour PostgreSQL. Si les pilotes intelligents ne sont pas disponibles, gérez les paramètres de durée de vie de la connexion pour garantir que les connexions sont actualisées conformément au DNS TTL.

Configurez la durée de vie maximale de la connexion : sans l'option d'un pilote de base de données intelligent, une option alternative consiste à configurer votre pooler de connexions pour avoir une durée de vie maximale pour chaque connexion. Après avoir dépassé le seuil X, il doit être fermé puis rouvert. L'utilisation d’un paramètre comme celui-ci contribuera à assurer le respect de la politique DNS.

Exemple de configuration des pilotes de service Go :

// de la base de données. Ajustez la configuration du pilote de la base de données et
// la référence au comportement du pool de connexions : https://go.dev/doc/database/manage-connections
// Limiter le nombre total de connexions à cette instance d'application
// peut être utilisé sur le serveur de base de données.
db.SetMaxOpenConns(10)
// Limiter le nombre de connexions inactives maintenues.
db.SetMaxIdleConns(3)
// Rouvrir périodiquement les connexions pour garantir que les basculements RW sont suivis dans un délai d'une minute.
db.SetConnMaxLifetime(60 * time.Second)
// Fermer les connexions inactives après une période de 30 secondes d'inactivité.
db.SetConnMaxIdleTime(30 * time.Second)

Observabilité, métriques et alertes

Dans l’environnement chaotique des tests de basculement, l'observabilité efficace remplace vos yeux et vos oreilles. Le monitoring et les alertes structurés garantissent que vous restez informés et prêts à agir.

• New Relic APM : il vous aide à comprendre le point de vue côté client. Que voit l'application pour sa propre activité par rapport au serveur de base de données ? Quels ont été le temps de réponse, le débit et le taux d'erreur ?

• Agent d'infrastructure avec des intégrations pour les bases de données : monitore les performances de votre système. Avec ses intégrations spéciales pour MySQL et PostgreSQL, il fournit des informations détaillées spécifiques à ces bases de données.

• Flux de métriques entre Amazon CloudWatch et New Relic avec l'utilisation de Kinesis Firehose : utilisez les flux de métriques pour envoyer un flux continu de métriques CloudWatch dans New Relic, y compris des données de monitoring en temps réel pour les bases de données Aurora.

• Alertes : configurez les alertes correspondant à votre situation. Les bons candidats sont souvent le taux d'erreur, le débit et le temps de réponse. Pour les situations de basculement, le taux d'erreur est particulièrement important, mais le monitoring du débit d'écriture et du temps de réponse peuvent apporter une valeur supplémentaire dans de nombreuses situations.

Ce taux d'erreur représente l'expérience positive contenue dans une minute.

Tests de résilience par le chaos futurs

À mesure que vous continuez à affiner vos stratégies de résilience, la portée et la complexité de vos tests par le chaos peuvent s’étoffer. Anticipez l'exploration de nouveaux services, l’impact de différents modèles d’échelle et de charge, ainsi que des simulations de pannes plus sophistiquées.