Introduction

Dans mon article Amazon DevOps Guru pour les applications sans serveur - Partie 10 Détection d'anomalies sur Aurora Serverless v2, nous avons appris que DevOps Guru était capable de détecter avec succès les anomalies avec la base de données PostgreSQL Aurora (Serverless v2) en cas de fonction Lambda avec Java 21 géré le runtime y était connecté via JDBC. Nous avons fait évoluer notre base de données uniquement de 0,5 à 1 ACU et créé une charge très élevée sur la base de données en appelant la fonction Lambda pour récupérer le produit par identifiant plusieurs centaines de fois simultanément pendant plusieurs minutes. Nous avons vu que DevOps Guru a correctement souligné la somme accrue de connexions à la base de données et la charge constamment élevée de la base de données (CPU). Dans cet article, j'aimerais savoir si DevOps Guru détectera l'anomalie en effectuant la même expérience mais en utilisant l'API Data pour Aurora Serverless v2 avec AWS SDK pour Java au lieu de JDBC.

Détection d'anomalies sur Aurora Serverless v2 avec Data API

Examinons notre exemple d'application et utilisons le modèle SAM pour créer l'infrastructure et déployer l'application décrite dans l'image suivante :

L'application crée des produits stockés dans la base de données Aurora Serverless v2 PostgreSQL et les récupère par identifiant à l'aide de l'API Data. La fonction Lambda pertinente que nous utiliserons pour récupérer le produit par son identifiant est GetProductByIdViaAuroraServerlessV2DataApi et son implémentation de gestionnaire est GetProductByIdViaAuroraServerlessV2DataApiHandler.

Comme dans l'article précédent, nous utilisons Hey Tool pour effectuer le test de résistance comme celui-ci

hey -z 15m -c 300 -H "X-API-Key: XXXa6XXXX" https://XXX.execute-api.eu-central-1.amazonaws.com/prod/productsWithDataApi/1   

Dans cet exemple, nous invoquons le point de terminaison API Gateway avec 300 conteneurs simultanés pendant 15 minutes. Derrière le point de terminaison prod/productsWithoutDataApi, la fonction Lambda GetProductByIdViaAuroraServerlessV2WithoutDataApi sera invoquée pour récupérer le produit par identifiant 1 à partir de la base de données Aurora Serverless v2 PostgreSQL.

Nous avons configuré dans notre [modèle SAM]((https://github.com/Vadym79/AWSLambdaJavaAuroraServerlessV2DataApi/blob/master/template.yaml) le cluster de base de données Aurora pour passer d'une capacité minimale de 0,5 à une capacité maximale de 1 ACU (ce qui est très petite taille de base de données) en cas de charge accrue à des fins de réduction des coûts.

  AuroraServerlessV2Cluster:
    Type: 'AWS::RDS::DBCluster'
...
      ServerlessV2ScalingConfiguration:
        MinCapacity: 0.5
        MaxCapacity: 1

La base de données Aurora (Serverless v2) gère le nombre maximal de connexions à la base de données disponibles proportionnellement à la taille de la base de données (dans notre cas, le paramètre ACU) également avec l'API de données pour Aurora Serverless v2 (ce qui constitue une énorme différence par rapport à la v1 qui deviendra hors support fin 2024 (où il y avait un quota strict de 1 000 connexions à la base de données par seconde). Pour plus d'informations, veuillez lire la documentation sur les connexions maximales pour Aurora Serverless v2. Ainsi, avec l'augmentation du nombre d'appels, nous prévoyons d'atteindre bientôt le nombre maximal de connexions à la base de données disponibles et la charge élevée de la base de données (CPU), de sorte que la base de données ne sera pas en mesure de répondre aux nouvelles requêtes de la fonction Lambda pour récupérer le produit en id (Lambda sera alors également rencontré). Avec cela, nous provoquerons l'anomalie et aimerions savoir si DevOps Guru sera capable de la détecter. Et c'était capable, en quelque sorte.... L'information suivante a été générée :

Et les mesures anormales agrégées suivantes ont été identifiées :

En comparant les métriques anormales agrégées identifiées en cas d'utilisation de JDBC au lieu de l'API de données décrites dans mon article Amazon DevOps Guru pour les applications sans serveur - Partie 10 Détection d'anomalies sur Aurora Serverless v2, nous oublions complètement les métriques anormales de la base de données Aurora : connexion à la base de données la somme et la base de données (CPU) se chargent mais voient correctement l'erreur dans Lambda qui a duré dans le délai défini sur 15 secondes car la base de données ne pouvait pas répondre.

.

Alors, quelle est la différence ? Explorons les deux incidents que nous avons reproduits sur le cluster PostgreSQL Aurora Serverless v2 avec JDBC (Non Data API) et Data API :

En termes d'utilisation/de mise à l'échelle de l'ACU, ils se ressemblent tous les deux :

En ce qui concerne d'autres métriques de base de données telles que : utilisation du processeur, DatabaseConnection DBLoad (CPU), il existe d'énormes différences :

• L'utilisation du processeur est la même pour les cas JDBC (API non-données) et API de données. Mais DevOps Guru ne semble pas prendre en compte cette métrique, car nous ne l'avons pas vue même pour l'expérience JDBC
• DBLoad(CPU) qui est très faible pour l'utilisation de l'API de données. Il semble que pour l'API Dat, il existe un équilibreur de charge devant la base de données Aurora Serverless v2 qui surveille l'utilisation de la connexion et protège la base de données contre la surcharge.
• La métrique DatabaseConnection n’est pas affichée (ou affichée comme 0) pour l’utilisation de l’API de données. La raison en est que nous ne gérons pas la connexion à la base de données pour l'API Data, cela est fait de l'autre côté pour nous. Bien sûr, ils jouent toujours un rôle important que nous avons appris dans Connexions maximales pour Aurora Serverless v2, mais cette métrique semble être exposée à l'extérieur dans les métriques CloudWatch et même DevOps Guru n'a aucun accès aux chiffres réels.

Avec cela et un DBLoad (CPU) très faible, aucune information DevOps Guru pour le cluster Aurora Serverless v2 avec utilisation de l'API de données n'a été générée par rapport au cas d'utilisation de JDBC.

J'ai fait la deuxième expérience en me connectant directement au cluster Aurora Serverless v2 et j'ai écrit le script pour créer le test de charge en écrivant le script qui récupère le produit par identifiant plusieurs centaines de fois en utilisant la méthode standard (API non Data). Similaire à ce que nous avons fait avec l'outil Hey, mais en accédant directement à la base de données au lieu d'invoquer Api Gateway. Après avoir mis la base de données sous charge, j'ai commencé la même expérience avec l'outil hey comme décrit ci-dessus et je voulais voir ce qui se passerait. Les mêmes informations ont été générées, mais cette fois avec les métriques anormales suivantes :

Nous voyons maintenant au moins une métrique anormale supplémentaire pour la somme des connexions à la base de données Aurora Serverless v2, mais les métriques DBLoad (CPU) sont toujours manquantes.

Les anomalies graphiques ressemblent à ceci :

Bien sûr, l'expérience n'a pas été propre, car j'ai fait 2 tests de charge l'un après l'autre et partiellement en parallèle : le premier se connectant directement à la base de données sans utiliser API Gateway et le second en utilisant Data API. Cela a confirmé mon hypothèse initiale selon laquelle les métriques de la somme des connexions à la base de données sont un critère très important pour générer des informations DevOps Guru pour Aurora Serverless v2 (et pour RDS en général) et qu'elles ne sont pas exposées en général en cas d'utilisation de l'API de données.
J'ai déjà contacté l'équipe Devops Guru et partagé avec eux mes idées et l'espoir qu'ils amélioreront le service. Ou tout d'abord, l'exposition de la connexion à la base de données en tant que métrique CloudWatch sera corrigée pour l'utilisation d'Aurora Serverless v2 avec l'API de données.

Conclusion

Dans cet article, nous avons appris que DevOps Guru pouvait détecter avec succès les anomalies avec la base de données PostgreSQL Aurora (Serverless v2) dans le cas d'une fonction Lambda avec un runtime géré Java 21 connecté via l'API de données, mais ne pouvait afficher que les métriques anormales liées à la fonction Lambda. le délai a été expiré car la base de données n'a pas répondu. La principale raison en est que la connexion à la base de données en tant que métrique CloudWatch n'est pas exposée (ou toujours affichée comme 0) en cas d'utilisation d'Aurora Serverless v2 avec l'API de données. Les métriques de la base de données Aurora Serverless v2 (somme des connexions à la base de données) n'ont été affichées que lors de la deuxième expérience artificielle.