Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Dans de nombreux cas, la séparation des fonctionnalités en différentes fonctions peut améliorer les performances et rendre une application plus facile à gérer et plus évolutive. Cependant, les « monolithes » Lambda peuvent constituer un tremplin utile pour la migration d’une application existante.
Quelle quantité de fonctionnalités doit contenir une seule fonction Lambda ?
La fonction ne doit effectuer qu'une seule tâche dans le flux de données entre les AWS services de votre microservice. Toutefois, si la tâche fonctionnelle est trop petite, cela peut entraîner une latence supplémentaire dans l’application et une surcharge liée à la gestion d’un grand nombre de fonctions. La portée exacte d’une fonction est déterminée par le cas d’utilisation.
Les applications basées sur Lambda peuvent-elles fonctionner dans plusieurs régions ?
Oui, de nombreux services sans serveur fournissent la réplication et le support pour plusieurs régions, notamment DynamoDB et Amazon S3. Les fonctions Lambda peuvent être déployées dans plusieurs régions dans le cadre d’un pipeline de déploiement, et API Gateway peut être configurée pour prendre en charge cette configuration. Consultez cet exemple d'architecture
Les fonctions Lambda peuvent-elles être exécutées selon un calendrier établi ?
Oui, vous pouvez utiliser des expressions planifiées pour les règles EventBridge afin de déclencher une fonction Lambda. Ce format utilise la syntaxe cron et peut être défini avec une granularité d’une minute. Consultez ce tutoriel pour obtenir un exemple.
Comment une fonction Lambda peut-elle conserver son état entre deux invocations ?
Dans de nombreux cas, une table DynamoDB constitue un moyen idéal de conservation, car elle fournit un accès aux données à faible latence et peut se mettre à l’échelle avec le service Lambda. Vous pouvez également stocker des données dans Amazon EFS pour Lambda
Quels types de charges de travail sont adaptés aux architectures guidées par les événements ?
Les architectures guidées par les événements communiquent entre différents systèmes à l’aide de réseaux, ce qui introduit une latence variable. Pour les charges de travail nécessitant une très faible latence, telles que les systèmes de négociation en temps réel, cette conception n’est peut-être pas le meilleur choix. Toutefois, pour les charges de travail hautement évolutives et disponibles, ou celles dont les modèles de trafic sont imprévisibles, les architectures guidées par les événements peuvent constituer un moyen efficace de répondre à ces demandes.
Pourquoi le service Lambda impose-t-il une limite de 15 minutes pour les fonctions ?
Les fonctions Lambda existent pour traiter les événements et la plupart des événements sont traités très rapidement, généralement en moins d’une seconde pour la majorité des invocations de production. La durée d’une fonction est déterminée par le temps nécessaire pour traiter un événement. Certaines charges de travail de calcul intensif peuvent prendre plusieurs minutes, mais très peu d’entre elles nécessitent 15 minutes.
Si vous estimez que vous avez besoin d’une durée plus longue, assurez-vous que votre code de fonction traite des événements uniques, exécute des tâches uniques et applique les pratiques exemplaires décrites dans ce document. Dans de nombreux cas, les fonctions peuvent être repensées pour traiter des événements uniques et réduire le temps nécessaire au traitement.
Pourquoi une fonction dotée d’une simultané réservée ne s’adapte-t-elle pas au trafic entrant ?
La simultanéité réservée pour une fonction Lambda constitue également une valeur de capacité maximale. L’augmentation de la limite flexible de la simultanéité totale n’a pas d’incidence sur ce comportement. Si vous avez besoin d'une fonction avec simultanéité réservée pour traiter davantage de trafic, vous pouvez mettre à jour la valeur de simultanéité réservée, ce qui augmente le débit maximal de votre fonction.
Pourquoi une fonction dotée d'une simultanéité provisionnée connaît-elle toujours des démarrages à froid ?
Vous pouvez mesurer les démarrages à froid à mesure que Lambda prend de l’ampleur en ajoutant la surveillance X-Ray à votre fonction. Une fonction utilisant la simultanéité provisionnée ne présente pas de comportement de démarrage à froid puisque l'environnement d'exécution est préparé avant l'invocation. Cependant, la simultanéité provisionnée doit être appliquée à une version ou à un alias spécifique d'une fonction, et non à la version $LATEST. Dans les cas où le comportement de démarrage à froid persiste, assurez-vous que vous invoquez la version de l'alias avec la configuration de la simultanéité provisionnée.
Quel est l’environnement d’exécution le plus adapté à ma fonction Lambda ?
Lambda est indépendant de votre choix d'environnement d'exécution. Pour les fonctions simples, les langages interprétés tels que Python et Node.js offrent les performances les plus rapides. Pour les fonctions nécessitant des calculs plus complexes, les langages compilés tels que Java sont souvent plus lents à initialiser, mais s’exécutent rapidement dans le gestionnaire Lambda. Le choix de l'environnement d'exécution est également influencé par les préférences du développeur et sa connaissance du langage.
Comment m’assurer que la version du kit SDK ne change pas ?
Le contenu intégré SDKs peut être modifié sans préavis au fur et à mesure AWS de la sortie de nouveaux services et fonctionnalités. Vous pouvez verrouiller une version du kit SDK en créant une couche Lambda avec la version spécifique requise. La fonction utilise alors toujours la version de la couche, même si la version intégrée au service change.
Comment puis-je vérifier qu’une application basée sur Lambda peut se mettre à l’échelle pour répondre au trafic attendu ?
Pour garantir que votre application se met à l’échelle comme prévu, utilisez des tests de charge dans votre processus de développement pour simuler le niveau de trafic attendu.
Quelles charges de travail sont adaptées à la simultanéité provisionnée ?
La simultanéité provisionnée est conçue pour rendre les fonctions disponibles avec des temps de réponse à deux chiffres en millisecondes. En général, ce sont les charges de travail interactives qui tirent le meilleur parti de cette fonctionnalité. Il s’agit des applications dont les utilisateurs lancent des requêtes, telles que les applications Web et mobiles, et qui sont les plus sensibles à la latence. Les charges de travail asynchrones, telles que les pipelines de traitement des données, sont souvent moins sensibles à la latence et ne nécessitent donc généralement pas de provisionnement simultané.
Pourquoi ma fonction Lambda n'enregistre-t-elle aucune sortie ?
Si une fonction Lambda ne se connecte pas CloudWatch, assurez-vous d'abord que la fonction est invoquée par l'appelant. Consultez les journaux du service d'appel et tous CloudWatch les indicateurs indiquant qu'un événement a déclenché la fonction. Ensuite, vérifiez la fonction dans les CloudWatch journaux. Toutes les fonctions Lambda journalisent trois lignes, même s’il n’existe aucune autre journalisation explicite dans le code personnalisé de la fonction :
Si aucune journalisation n'apparaît CloudWatch malgré l'appel de la fonction, vérifiez les autorisations de la fonction. Le rôle IAM doit inclure des autorisations de journalisation, sinon la fonction ne peut pas écrire de journaux sur le service. Vous pouvez associer la AWSLambdaBasicExecutionRolepolitique au rôle d'exécution de votre fonction pour accorder ces autorisations.
