4.2 - Dépannage des performances et de la limitation
L'objectif 4.2 de l'AWS Certified Developer Associate couvre le dépannage et l'optimisation des performances. Quand une fonction Lambda renvoie parfois TooManyRequestsException (429) en charge, ses exécutions concurrentes atteignent la limite de concurrence : on augmente la concurrence réservée ou on demande une limite de compte plus élevée. Quand une Lambda Node.js ouvre une nouvelle connexion HTTPS aux services AWS à chaque invocation, ajoutant de la latence, régler AWS_NODEJS_CONNECTION_REUSE_ENABLED à 1 réutilise la connexion entre invocations. Quand un producteur Kinesis reçoit par intermittence ProvisionedThroughputExceededException, une partition (shard) chaude en est la cause ; utiliser une clé de partition à plus forte cardinalité répartit les enregistrements plus uniformément sur les shards. Tu dois aussi connaître les partitions chaudes DynamoDB, le backoff exponentiel et le cache. Attends-toi à des mises en situation demandant la bonne cause ou correction.
Lambda 429 en charge = limite de concurrence atteinte (l'augmenter). Nouvelle connexion HTTPS par invocation (Node.js) = régler AWS_NODEJS_CONNECTION_REUSE_ENABLED=1. Kinesis ProvisionedThroughputExceeded = shard chaud ; clé de partition à plus forte cardinalité.
Questions d'entraînement
1. Une fonction Lambda expire souvent sur un appel aval lent. Quels réglages traitent le plus directement cela ? (Choisissez la meilleure réponse unique.)
- Augmenter le délai de la fonction et optimiser l'appel aval (bonne réponse)
- Supprimer le rôle d'exécution IAM de la fonction puis le recréer
- Désactiver la journalisation CloudWatch de la fonction
- Réduire la mémoire de la fonction au minimum
Augmenter le délai (jusqu'à 15 min) évite l'arrêt prématuré pendant que vous optimisez ou mettez en cache la dépendance lente. Supprimer le rôle ou désactiver les journaux casserait ou aveuglerait la fonction.
2. Une lecture DynamoDB renvoie ProvisionedThroughputExceededException lors de pics courts sur une table provisionnée. Quel changement gère le mieux des rafales imprévisibles ?
- Baisser les unités de capacité de lecture provisionnées de la table
- Ajouter une seconde passerelle Internet au VPC
- Basculer la table en mode de capacité à la demande (bonne réponse)
- Désactiver les relances automatiques dans le client SDK
Le mode de capacité à la demande s'adapte instantanément au trafic sans planification de capacité, éliminant la limitation due aux rafales imprévisibles (paiement par requête). Baisser les RCU ou désactiver les relances aggrave le problème.
3. Une Lambda lisant un flux Kinesis prend du retard, et IteratorAge ne cesse de croître. Quel changement augmente le plus directement le débit ?
- Ajouter des shards et/ou augmenter le facteur de parallélisation (bonne réponse)
- Réduire la mémoire de la fonction pour économiser
- Désactiver entièrement les journaux CloudWatch de la fonction concernée
- Basculer le flux vers une file SQS standard
Un IteratorAge croissant signifie que le traitement est en retard sur l'ingestion. Plus de shards augmentent la capacité du flux, et un facteur de parallélisation plus élevé permet à plusieurs lots concurrents de traiter un shard, augmentant le débit du consommateur.
4. Une charge DynamoDB à forte lecture a besoin d'une latence en microsecondes pour les lectures en cache sans trop changer la logique de lecture de l'application. Quel service aide ?
- Amazon ElastiCache configuré manuellement
- Une capacité de lecture provisionnée plus grande
- DynamoDB Accelerator (DAX) (bonne réponse)
- Des index secondaires globaux sur toutes les clés
DAX est un cache en mémoire conçu pour DynamoDB, offrant des lectures en microsecondes via un client compatible DynamoDB avec un minimum de changements de code. Il met en cache les éléments et résultats de requête.
5. Une Lambda derrière API Gateway renvoie par intermittence un HTTP 502 Bad Gateway. Quelle cause fréquente un développeur doit-il vérifier ?
- Le TTL du cache de l'étape d'API est trop élevé
- Le quota du plan d'usage est entièrement consommé
- La fonction a renvoyé une charge de réponse malformée (bonne réponse)
- La Lambda a trop de concurrence réservée
Avec l'intégration proxy Lambda, un 502 signifie généralement que la fonction a renvoyé une réponse malformée (mauvaise structure, non-JSON, ou erreur non gérée). Un quota épuisé renvoie 429 ; le TTL du cache affecte la fraîcheur, pas le 502.
6. Le coût d'une fonction Lambda est élevé car elle est surprovisionnée. Quel outil recommande le réglage mémoire optimal à partir de données d'invocation réelles ?
- Les vérifications de stockage AWS Trusted Advisor
- Les résultats de vulnérabilités Amazon Inspector
- Une politique d'auto scaling de capacité DynamoDB
- AWS Lambda Power Tuning (outil Step Functions) (bonne réponse)
AWS Lambda Power Tuning est une machine à états Step Functions qui exécute la fonction à différentes tailles mémoire et trace coût vs performance, révélant le réglage mémoire optimal. Plus de mémoire augmente aussi le CPU, réduisant parfois le coût.