Fonction sans serveur

Qu'est-ce qu'une fonction sans serveur ?

Une fonction sans serveur (serverless) est un petit morceau de code qu'un fournisseur cloud exécute à la demande en réponse à un événement, comme une requête HTTP, un envoi de fichier ou un message de file d'attente. Vous déployez le code ; le fournisseur provisionne, met à l'échelle et met à jour les serveurs, et vous payez l'exécution plutôt que des machines inactives. AWS Lambda sert d'exemple sur cette page.

Comment fonctionne une fonction sans serveur

Vous écrivez un handler et le reliez à un déclencheur. Quand un événement arrive, la plateforme a besoin d'un environnement d'exécution. S'il y en a un de prêt et libre, elle le réutilise (démarrage à chaud, warm start). Sinon, elle en crée un : elle télécharge le code, démarre le runtime et exécute votre code d'initialisation, puis seulement appelle le handler (démarrage à froid, cold start). Par défaut, chaque environnement traite une requête à la fois : plus de requêtes simultanées, c'est plus d'environnements.

AWS définit la concurrence comme le nombre de requêtes en cours en même temps et donne une formule simple : concurrence = requêtes moyennes par seconde x durée moyenne en secondes. À 100 requêtes par seconde et 500 ms par requête, cela fait 50 environnements.

Exemple

Une boutique stocke ses photos de produits dans un bucket. Chaque envoi déclenche une fonction qui crée une miniature et la réécrit. Aucun serveur à garder allumé : lors d'un import en masse, des centaines de fonctions tournent en parallèle, et la nuit aucune. Une seconde fonction derrière un endpoint d'API pourrait servir le catalogue au site.

Limites importantes (AWS Lambda)

• Délai d'expiration : jusqu'à 900 secondes (15 minutes) par invocation. Les traitements plus longs doivent être découpés ou déplacés.
• Mémoire : de 128 Mo à 10 240 Mo, le CPU étant alloué proportionnellement.
• Concurrence : 1 000 exécutions simultanées par région par défaut (quota ajustable), partagées par toutes les fonctions du compte.
• Rythme de montée en charge : chaque fonction peut ajouter au plus 1 000 environnements d'exécution toutes les 10 secondes : une rafale très soudaine peut donc être limitée.
• Charge utile : 6 Mo pour une requête ou une réponse synchrone.
• Cold starts : selon AWS, ils touchent généralement moins de 1 % des invocations et ajoutent de moins de 100 ms à plus d'1 seconde. La concurrence provisionnée initialise des environnements à l'avance pour les réduire.

Les limites et valeurs par défaut évoluent : consultez la page actuelle des quotas AWS Lambda avant de dimensionner quoi que ce soit.

Erreurs fréquentes

• Croire qu'elle monte en charge sans limite. La fonction peut s'adapter, mais la base de données, l'API tierce ou le microservice derrière souvent non. Une rafale de fonctions peut épuiser les connexions à la base.
• Juger la vitesse à la moyenne. Les cold starts se logent dans la queue de distribution. Regardez p95 et p99, voir latence.
• Mettre des traitements longs dans une fonction. Tout ce qui approche le délai d'expiration demande une file d'attente ou un autre service.
• Ne jamais tester une rafale. Une fonction à l'aise à 10 requêtes par seconde peut être limitée quand le trafic bondit ; un spike test le révèle.
• Configurer à la main. Mémoire, délai et concurrence relèvent du code, voir infrastructure as code.

Tester et superviser des fonctions sans serveur

Testez en charge l'endpoint public placé devant la fonction, souvent une API gateway, avec un profil qui dépasse le pic attendu, et comparez percentiles, taux d'erreurs et limitation. LoadFocus load testing peut envoyer ce trafic depuis 25 régions cloud avec JMeter ou k6 ; l'offre Free couvre 10 utilisateurs virtuels pendant 60 secondes. N'oubliez pas que chaque invocation de test est facturée par votre fournisseur cloud. Pour la méthode complète, voir performance testing serverless architectures (en anglais). En production, la supervision d'API, comme LoadFocus API Monitoring (les vérifications gratuites s'exécutent toutes les 5 minutes), montre le comportement de ces endpoints dans le temps, y compris le premier appel parfois lent.

Questions fréquentes

Les fonctions sans serveur n'utilisent-elles vraiment aucun serveur ?

Si. Des serveurs exécutent toujours votre code. Le terme signifie que vous ne les provisionnez, ne les mettez à jour et ne les dimensionnez pas vous-même.

Qu'est-ce qu'un cold start ?

Le temps supplémentaire quand la plateforme doit créer un nouvel environnement d'exécution avant de pouvoir lancer votre handler. Les requêtes suivantes qui réutilisent l'environnement l'évitent.

Comment une fonction sans serveur est-elle facturée ?

Pour les fonctions d'événements AWS Lambda, par requête plus la durée d'exécution multipliée par la mémoire configurée (Go-secondes). Sans requête, vous ne payez aucun calcul.

Quand éviter une fonction sans serveur ?

Pour des traitements plus longs que le délai d'expiration, pour des charges exigeant une latence très basse et stable à chaque requête, ou quand le trafic est si constant et lourd que des serveurs toujours allumés coûtent moins. Mesurez avant de décider.