Concurrence, limitation et concurrence réservée

Lambda se met à l’échelle en exécutant plusieurs exécutions concurrentes de votre fonction, une par événement simultané. Lorsque 100 requêtes arrivent en même temps, Lambda exécute 100 instances parallèles de votre fonction. AWS gère automatiquement l’infrastructure sous-jacente. La limite de concurrence au niveau du compte est de 1 000 exécutions concurrentes par Région par défaut (limite souple, qui peut être augmentée sur demande de quota de service).

La concurrence se calcule ainsi : Concurrence = Requêtes par seconde × Durée moyenne en secondes. Si votre fonction traite 500 requêtes par seconde et que chacune dure 0,2 seconde, vous avez besoin de 100 exécutions concurrentes. La compréhension de cette formule vous aide à prévoir si les limites de votre compte sont suffisantes et si vous devez demander une augmentation de quota avant une période de forte activité.

Lorsque Lambda reçoit plus de requêtes que ne l’autorise sa limite de concurrence, il limite les requêtes excédentaires. Pour les invocations synchrones (par exemple, avec la passerelle d’API), les requêtes limitées reçoivent immédiatement une erreur 429 TooManyRequestsException que l’appelant doit gérer. Pour les invocations asynchrones (par exemple, les événements S3), Lambda met les événements en file d’attente et effectue des tentatives pendant 6 heures au maximum avant de les envoyer vers une file d’attente de lettres mortes.

La concurrence réservée garantit un nombre précis d’exécutions concurrentes pour une fonction donnée en réservant ces exécutions dans le parc du compte. Elle a deux objectifs : (1) elle garantit la capacité — la fonction disposera toujours de ce nombre d’exécutions, même si d’autres fonctions consomment le quota du compte ; (2) elle plafonne la concurrence — la fonction ne pourra jamais dépasser le nombre réservé, ce qui protège les dépendances en aval contre la surcharge.

Voici un scénario d’examen important : une fonction Lambda écrit dans une base de données RDS dont la limite est de 50 connexions. Sans contrôle de la concurrence, Lambda pourrait atteindre des centaines d’exécutions concurrentes et épuiser toutes les connexions à la base de données, ce qui provoquerait des erreurs pour chaque fonction. Définir la concurrence réservée sur 40 garantit que Lambda ne dépassera jamais 40 connexions simultanées à la base de données et protège l’instance RDS. Il s’agit d’un modèle essentiel pour toute fonction Lambda qui appelle un service limité par le nombre de connexions.

La concurrence provisionnée préinitialise un nombre défini d’environnements d’exécution Lambda afin qu’ils soient prêts à répondre immédiatement, sans démarrage à froid. Cela est essentiel pour les API sensibles à la latence, pour lesquelles même un démarrage à froid de 100 ms est inacceptable. Vous payez un tarif horaire pour la concurrence provisionnée, même lorsque ces environnements sont inactifs ; associez-la donc à la mise à l’échelle automatique afin d’ajuster les niveaux provisionnés en fonction des tendances de trafic prévues.

Ces deux notions sont souvent confondues, mais elles ont des objectifs différents. La concurrence réservée limite et garantit l’allocation de capacité depuis le parc du compte — elle n’élimine NOT les démarrages à froid. La concurrence provisionnée préchauffe les environnements d’exécution pour éliminer les démarrages à froid — elle n’empêche NOT les autres fonctions d’utiliser le même parc. Utilisez la concurrence réservée pour plafonner le débit ; utilisez la concurrence provisionnée pour améliorer la latence. Vous pouvez utiliser les deux simultanément sur la même fonction.

Lambda n’atteint pas instantanément sa pleine concurrence. Il existe une limite de rafale au niveau du compte (taux de mise à l’échelle initial) qui varie selon la Région : généralement 3 000 exécutions initiales en rafale, puis 500 exécutions supplémentaires par minute jusqu’à atteindre la limite. Pour les applications qui prévoient des pics soudains et massifs (trafic viral, ventes éclair), utilisez la concurrence provisionnée afin de préchauffer suffisamment d’environnements et d’éviter que la limite de rafale ne provoque une limitation pendant la montée en charge initiale.

Surveillez la concurrence Lambda avec ces principales métriques CloudWatch :

• ConcurrentExecutions : nombre actuel d’instances en cours d’exécution
• Throttles : nombre d’invocations limitées (devrait être nul dans un système sain)
• UnreservedConcurrentExecutions : parc non réservé au niveau du compte
• ProvisionedConcurrencyUtilization : proportion de la capacité provisionnée utilisée

Définissez des alarmes sur Throttles afin d’être averti avant que la limitation n’affecte les utilisateurs finaux.

Lorsque vous concevez des systèmes qui invoquent Lambda de manière synchrone (passerelle d’API, appels directs via le SDK), implémentez une temporisation exponentielle avec gigue dans l’appelant. Les SDK AWS intègrent une logique de nouvelle tentative, mais pour Lambda placé derrière une passerelle d’API, vous devez gérer les réponses 429 dans votre application cliente. Pour Lambda déclenché par SQS, le service SQS gère lui-même les nouvelles tentatives ; définissez correctement le nombre maximal de réceptions sur la file source et configurez une DLQ pour les tentatives épuisées.

Pour les flux de données Kinesis et les flux DynamoDB, la concurrence Lambda est limitée par le nombre de fragments (Kinesis) ou de partitions (DynamoDB). Chaque fragment ou partition est traité par exactement une exécution Lambda concurrente. Si vous disposez de 10 fragments Kinesis, Lambda exécute jusqu’à 10 exécutions concurrentes pour ce déclencheur. Ainsi, les problèmes de limitation liés aux déclencheurs fondés sur des flux se résolvent généralement en augmentant le nombre de fragments plutôt qu’en relevant les limites de concurrence.

Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez appris que la concurrence réservée garantit et plafonne à la fois les exécutions concurrentes d’une fonction afin de protéger les services en aval et d’assurer la disponibilité ; que la concurrence provisionnée préinitialise les environnements pour éliminer les démarrages à froid des charges de travail sensibles à la latence ; et que la limitation se manifeste par des erreurs 429 pour les invocations synchrones et par des tentatives placées en file d’attente pour les invocations asynchrones — surveillez-la avec la métrique CloudWatch Throttles. Nous allons maintenant étudier les couches Lambda et les paquets de déploiement pour gérer les dépendances volumineuses.