Cinq étapes pour résoudre une dégradation soudaine des performances dans AWS RDS

Une dégradation soudaine des performances dans une base de données de production est l'un des problèmes les plus critiques auxquels les équipes d'exploitation sont confrontées. Amazon Relational Database Service (RDS) simplifie la gestion des bases de données, mais le dépannage des ralentissements inattendus—se manifestant par une latence élevée, des délais d'attente de transactions ou des erreurs d'application—nécessite toujours une approche systématique et ciblée.

Ce guide décrit cinq étapes pratiques et actionnables pour identifier rapidement la cause racine des baisses de performances dans votre instance AWS RDS, en se concentrant sur l'utilisation des outils de surveillance intégrés AWS et des techniques de diagnostic standard des bases de données. En suivant cette méthodologie séquentielle, vous pouvez passer efficacement de l'analyse des symptômes à la résolution.

---

Étape 1 : Analyse immédiate des métriques via CloudWatch et Performance Insights

La première étape de toute enquête sur les performances consiste à quantifier le goulot d'étranglement. AWS CloudWatch fournit les métriques de haut niveau nécessaires pour diagnostiquer si le problème est lié au calcul, aux E/S ou aux connexions.

Métriques clés à examiner

Analysez les métriques suivantes, en regardant spécifiquement la période immédiatement avant et pendant la dégradation, en vous concentrant sur les pics corrélés :

1. Utilisation CPU : Un pic soudain approchant 100 % indique généralement une charge de travail excessive, de mauvais plans de requêtes ou une tâche d'arrière-plan massive.
2. IOPS en lecture/écriture et latence : Une latence élevée combinée à des IOPS maximales indique que la base de données est en attente de stockage. Cela peut se produire lorsque la charge de travail dépasse les IOPS ou le débit provisionné, ou lorsque la capacité de burst est épuisée sur des configurations de stockage utilisant un comportement de burst.
3. Connexions à la base de données : Une augmentation brutale des connexions actives peut épuiser la mémoire ou atteindre la limite max_connections, entraînant des échecs de connexion et une contention des ressources.
4. Mémoire libre : Une baisse rapide ou une mémoire libre constamment basse peut indiquer un cache de requêtes inefficace ou des processus utilisant une mémoire excessive, entraînant du swapping (qui est intensif en E/S et lent).

Utilisation de Performance Insights

Pour les moteurs RDS pris en charge, Performance Insights (PI) est souvent l'outil le plus rapide pour cette étape. PI représente visuellement la charge de la base de données (DB Load), vous aidant à voir ce qui a dominé le pic :

• PI décompose la charge de la base de données par État d'attente (par exemple, CPU, attente E/S, attente de verrou) et Top SQL, fournissant une visibilité instantanée sur la source du goulot d'étranglement.

Astuce : Si la charge de la base de données augmente mais que la majorité de l'attente est catégorisée comme CPU, le problème est un traitement complexe de requêtes. Si l'attente est principalement E/S, le problème est la lecture ou l'écriture de données depuis le stockage.

Étape 2 : Examiner les sessions actives et les événements d'attente

Une fois que les métriques confirment où se trouve le goulot d'étranglement (par exemple, CPU élevé), l'étape suivante consiste à déterminer qui ou quoi cause la charge en ce moment.

À l'aide de Performance Insights, identifiez les Top SQL consommant le plus de charge de base de données pendant la période de dégradation. Si PI n'est pas activé, vous devez vous connecter directement à l'instance de base de données.

Commandes de session spécifiques à la base de données

MySQL/MariaDB

Utilisez SHOW PROCESSLIST pour afficher les requêtes en cours d'exécution. Recherchez les transactions de longue durée (valeur Time élevée) ou les commandes bloquées dans les états Sending data ou Locked.

SHOW FULL PROCESSLIST; 

PostgreSQL

Interrogez la vue pg_stat_activity pour trouver les requêtes actives et leurs événements d'attente. Recherchez les requêtes avec wait_event_type non nul et des temps query_start élevés.

SELECT pid, datname, usename, client_addr, application_name, backend_start,
       state, wait_event_type, wait_event, query_start, query
FROM pg_stat_activity
WHERE state = 'active'
ORDER BY query_start ASC;

Se concentrer sur les événements d'attente (par exemple, les événements d'attente de verrou lock) révèle immédiatement les problèmes de concurrence ou la contention de verrouillage de schéma qui pourraient bloquer l'ensemble du système.

Étape 3 : Diagnostiquer et optimiser les requêtes lentes

Souvent, une dégradation soudaine est causée par un changement récemment déployé—une nouvelle requête, un plan de requête obsolète ou un index manquant. Utilisez le journal des requêtes lentes (MySQL/MariaDB) ou pg_stat_statements (PostgreSQL) combiné aux données de Performance Insights pour identifier les requêtes ayant le plus d'impact.

Analyse des plans d'exécution

Une fois une requête candidate identifiée, utilisez l'outil de plan d'exécution de la base de données (EXPLAIN ou EXPLAIN ANALYZE) pour comprendre comment la base de données exécute la requête.

1. Identifier les analyses complètes de table : Un tueur de performances courant. Si une requête analyse une table massive sans utiliser d'index, les performances chuteront.
2. Examiner l'utilisation des index : Assurez-vous que la base de données utilise des index optimaux pour les clauses WHERE, les conditions JOIN et les clauses ORDER BY.

Exemple : Vérification d'un plan de requête

EXPLAIN ANALYZE 
SELECT * FROM large_table WHERE column_a = 'value' AND column_b > 100;

Si le plan montre une mauvaise utilisation des index, la résolution immédiate consiste souvent à créer un nouvel index ciblé. Pour les requêtes critiques et de longue durée, envisagez de simplifier les jointures ou de diviser les opérations complexes.

Meilleure pratique : L'optimisation des requêtes est la solution à long terme la plus fréquente. Priorisez l'optimisation des requêtes responsables de la charge CPU ou E/S la plus élevée.

Étape 4 : Vérifier la configuration de l'instance et du groupe de paramètres

Si la charge semble normale mais que les ressources (comme la mémoire ou les connexions) sont saturées, le problème peut être un sous-dimensionnement ou des paramètres de configuration sous-optimaux.

Taille et type de l'instance

1. Vérification du crédit des instances T : Si vous utilisez des instances burstables (série T), vérifiez le solde de crédit CPU dans CloudWatch. Si le solde a atteint zéro, l'instance peut être limitée, entraînant de graves baisses de performances. Passez à une classe de performances fixes si la base de données a une charge soutenue.
2. Limites des ressources : Vérifiez si la classe d'instance fournit suffisamment de RAM et d'IOPS pour le profil de charge de travail actuel. Si la base de données swappe fréquemment ou atteint les limites PIOPS, une mise à niveau (mise à l'échelle verticale) est nécessaire.

Examen du groupe de paramètres

Vérifiez les paramètres critiques, qui sont souvent mis à l'échelle automatiquement en fonction de la taille de l'instance mais peuvent avoir été remplacés ou définis trop bas :

• max_connections : Assurez-vous que ce paramètre (dérivé de la mémoire de l'instance) est adéquat pour la charge de pointe.
• innodb_buffer_pool_size (MySQL) ou shared_buffers (PostgreSQL) : Cette zone mémoire est critique pour la mise en cache des données. Si elle est trop petite, la base de données dépend fortement des E/S disque lentes.

Étape 5 : Examiner la maintenance du système et les opérations secondaires

Parfois, la dégradation des performances est transitoire et causée par des tâches système automatisées ou des processus de réplication en arrière-plan.

Sauvegardes automatisées et fenêtre de maintenance

Vérifiez les paramètres de Fenêtre de maintenance et Fenêtre de sauvegarde dans la console RDS. Les instantanés automatisés peuvent introduire une latence E/S temporaire, surtout si la charge de travail est déjà élevée. Si la baisse de performances correspond exactement à la fenêtre de sauvegarde, envisagez de déplacer la fenêtre à un moment moins critique ou d'allouer suffisamment de PIOPS pour gérer la charge pendant la sauvegarde.

Retard de réplication

Si l'application dépend de réplicas en lecture, une dégradation soudaine des performances sur l'instance principale peut provoquer un retard de réplication sévère. Un retard de réplication élevé indique que l'instance principale ne peut pas traiter les changements assez rapidement, ce qui renvoie souvent aux problèmes trouvés à l'étape 3 (requêtes lentes) ou à l'étape 4 (ressources sous-dimensionnées).

Surveillez la métrique ReplicaLag dans CloudWatch. Si le retard est significatif, concentrez les efforts de dépannage sur le taux de transaction et l'optimisation de l'instance principale.

Journalisation binaire et activité WAL

Dans les environnements à transactions élevées, la journalisation binaire dans MySQL ou la journalisation write-ahead dans PostgreSQL peut ajouter une pression E/S significative, surtout lorsque la réplication ou la restauration à un moment donné est activée. Si la latence E/S est le goulot d'étranglement, vérifiez le volume de transactions, l'état de santé des réplicas, le comportement des points de contrôle et si un travail récent a commencé à écrire beaucoup plus de données que d'habitude.

---

Gardez la réponse à l'incident ciblée

Pendant l'incident, apportez le plus petit changement qui supprime la pression : arrêtez un travail incontrôlé, annulez un mauvais déploiement, réduisez la concurrence des travailleurs, ajoutez un index sûr ou mettez à l'échelle l'instance si la charge de travail a clairement dépassé ses capacités. Après coup, capturez la première mauvaise métrique, le principal événement d'attente, la principale SQL ou opération, et le correctif. Ce dossier est ce qui transformera le prochain ralentissement RDS en une enquête plus courte.