Mise à l'échelle et contrôle de la simultanéité

Applications sans serveur avec AWS Lambda

Claudio Canales

Senior DevOps Engineer

La mise à l'échelle en un coup d'œil

Plus de demande -> plus d'exécutions en parallèle.
Chaque exécution utilise un environnement d'exécution.
Simultanéité = exécutions en cours.

Pointe de demande -> plus d'environnements

Qu'est-ce que la simultanéité ?

Une invocation = une unité de travail.
Simultanéité = combien s'exécutent maintenant.
Si 10 s'exécutent, simultanéité = 10.

Invocations en parallèle

Estimer la simultanéité requise

Règle pratique : concurrency = rps * duration.
Réduire la durée réduit la simultanéité.
Servez-vous-en pour dimensionner les limites en toute sécurité.

Formule de simultanéité

Exemple : 50 rps à 200 ms

200 ms = 0,2 seconde.
50 * 0,2 = 10 exécutions simultanées.
Un code plus rapide = moins d'exécutions parallèles.

Exemple de calcul de simultanéité

Limites : bassin du compte vs part de fonction

La simultanéité est limitée au niveau du compte.
Réservez une partie du bassin pour une fonction critique.
Les autres fonctions partagent le reste.

Bassin de simultanéité du compte

Simultanéité réservée : plafond strict

Une soupape de sécurité.
Limite le travail en parallèle.
Au‑delà du plafond, les invocations sont bridées.
Une fonction bruyante ne peut pas épuiser la capacité.

Plafond de simultanéité réservée

Bridage : à quoi ça ressemble

Lambda bride au seuil de simultanéité.
L'appelant n'obtient pas une exécution normale.
Vous voyez ces bridages en surveillance.

Signaux de bridage

Simultanéité provisionnée : capacité chaude

Un bassin d'environnements préinitialisés.
Souvent derrière un alias.
Les requêtes démarrent plus vite.

Bassin chaud de simultanéité provisionnée

Démarrage à froid vs provisionné

Démarrage à froid

Un délai d'initialisation unique.
La première requête paie le coût de préparation.

Provisionnée

Le travail d'init est fait d'avance.
La première requête n'en paie pas le coût.

Chronologie : froid vs provisionné

Réservée vs provisionnée (problèmes différents)

La « réservée » contrôle la charge.
La « provisionnée » contrôle la latence de démarrage.
En production, beaucoup combinent les deux.

Comparaison réservée vs provisionnée

Protéger les systèmes en aval

Une base de données gère un nombre limité de connexions.
Un plafond de simultanéité la protège.
Une pointe de trafic peut devenir une panne.

Le plafond de simultanéité protège une base de données

Pointes vs trafic stable

Les pointes créent plusieurs environnements parallèles.
Des gestionnaires lents maintiennent une forte simultanéité.
Des plafonds peuvent aplanir la pointe.
Réduire la durée est aussi une stratégie d'échelle.

Trafic en pointe vs régime stable

Défaillances et reprises augmentent la charge

Les reprises après échec amplifient le trafic.
Les limites de simultanéité réduisent l'impact.
Une boucle d'échecs peut saturer les dépendances.

Les reprises multiplient la charge

Un flux simple d'optimisation

Commencez par mesurer.
Plafonnez la simultanéité quand apparaissent bridages ou pression.
Ajoutez de la capacité provisionnée si le démarrage à froid nuit à la latence.

Mesurer -> plafonner -> préchauffer

Points clés

La simultanéité aide à penser la mise à l'échelle.
Estimation : rps * duration.
La « réservée » plafonne la charge ; surveillez les bridages.
La « provisionnée » réduit la latence de démarrage à froid.

Principaux points sur la simultanéité

Passons à la pratique !

Applications sans serveur avec AWS Lambda