Configurer AWS Lambda pour la production

Déployer des applications sur AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Ça marchait en test

La fonction a réussi tous les tests
En production, elle expire et est limitée
Le code allait bien ; la configuration non

Une fonction serverless validée en test mais en difficulté en production, avec réglages de mémoire et de délai d'expiration

Configuration Lambda essentielle en production

Logo Lambda au centre avec quatre boîtes de configuration de production : Memory avec cadran de montée en charge CPU, Timeout avec horloge, Ephemeral Storage, et Concurrency montrant des exécutions parallèles

Memory : augmente aussi CPU et réseau
Timeout : secondes max avant arrêt de la fonction
Ephemeral storage : espace temporaire dans /tmp
Concurrency : nombre d'exécutions simultanées

Dimensionner la mémoire et lien avec le CPU

Plus de mémoire = plus de CPU proportionnel
Une fonction liée au CPU peut aller plus vite avec plus de mémoire
Durée plus courte = coût potentiellement plus bas
Dimensionnez par test, pas au hasard

Courbe mémoire/coût : la durée chute fortement avec la mémoire puis se stabilise ; le coût total forme un U avec un point optimal au milieu

Concurrence : réservée vs provisionnée

Concurrence réservée

Limite les exécutions simultanées max
Protège les systèmes en aval et les autres fonctions

Concurrence provisionnée

Pré-chauffe des instances, pas de cold start
Pour les fonctions sensibles à la latence, côté utilisateur

Emballer la configuration et le code partagé

Variables d'environnement : config par environnement
Layers : partager code et dépendances entre fonctions
Extensions : s'exécutent à côté pour les outils
Gardez la config hors du paquet de déploiement

Options d'empaquetage Lambda : variables d'environnement pour la config externe, layers partageant des bibliothèques communes entre fonctions, et extensions s'exécutant aux côtés du handler pour la supervision ou les secrets

Connecter Lambda à un VPC

Lambda connecté à un VPC privé via des ENI dans des sous-réseaux privés, groupe de sécurité contrôlant la sortie, et une passerelle NAT fournissant l'accès Internet

Attachez Lambda à des sous-réseaux privés pour les ressources internes
Lambda crée des ENI dans votre VPC
Les groupes de sécurité contrôlent ce qu'elle peut atteindre
Besoin d'un NAT ou d'un point de terminaison VPC pour l'accès externe

Gérer les échecs avec destinations et DLQ

Les invocations asynchrones réessaient automatiquement en cas d'échec
Lambda Destinations : router onSuccess et onFailure
File d'attente de messages morts (DLQ) : capter les événements jamais réussis
Ne jamais abandonner un événement en échec

Gestion des échecs async Lambda : boucle de réessai menant à Lambda Destinations avec branches onSuccess et onFailure, et une DLQ capturant les événements après tous les réessais

Passons à la pratique !