Bonnes pratiques d'utilisation des fonctions AWS Lambda - AWS Lambda

Bonnes pratiques d'utilisation des fonctions AWS Lambda

Les bonnes pratiques suivantes sont recommandées pour l'utilisation d' AWS Lambda:

Pour plus d'informations sur les bonnes pratiques concernant les applications Lambda, consultez Conception d'applications dans le Guide de l'opérateur Lambda.

Code de fonction

  • Séparez le gestionnaire Lambda de votre logique principale. Cela vous permet de créer une fonction testable plus unitaire. Dans Node.js, vous obtenez ce qui suit :

    exports.myHandler = function(event, context, callback) { var foo = event.foo; var bar = event.bar; var result = MyLambdaFunction (foo, bar); callback(null, result); } function MyLambdaFunction (foo, bar) { // MyLambdaFunction logic here }
  • Tirez parti de la réutilisation de l'environnement d'exécution pour améliorer les performances de votre fonction. Initialisez les clients SDK et les connexions à la base de données en dehors du gestionnaire de fonctions et mettez en cache les actifs statiques localement dans le répertoire /tmp. Les appels ultérieurs traités par la même instance de votre fonction peuvent réutiliser ces ressources. Cela permet d'économiser des coûts, tout en réduisant le temps d'exécution de la fonction.

    Pour éviter des éventuelles fuites de données entre les invocations, n'utilisez pas l'environnement d'exécution pour stocker des données utilisateur, des événements ou d'autres informations ayant un impact sur la sécurité. Si votre fonction repose sur un état réversible qui ne peut pas être stocké en mémoire dans le gestionnaire, envisagez de créer une fonction distincte ou des versions distinctes d'une fonction pour chaque utilisateur.

  • Utilisez une directive keep-alive pour maintenir les connexions persistantes. Lambda purge les connexions inactives au fil du temps. Si vous tentez de réutiliser une connexion inactive lorsque vous appelez une fonction, cela entraîne une erreur de connexion. Pour maintenir votre connexion persistante, utilisez la directive Keep-alive associée à votre environnement d'exécution. Pour obtenir un exemple, consultez Réutilisation des connexions avec Keep-Alive dans Node.js.

  • Utilisez des variables d'environnement pour transmettre des paramètres opérationnels à votre fonction. Par exemple, si vous écrivez dans un compartiment Amazon S3 au lieu de coder en dur le nom du compartiment dans lequel vous écrivez, configurez le nom du compartiment comme variable d'environnement.

  • Contrôlez les dépendances de votre package de déploiement des fonctions. L'environnement d'exécution AWS Lambda contient un certain nombre de bibliothèques telles que le kit AWS SDK pour les runtimes Node.js et Python (la liste complète est disponible ici : Environnements d’exécution (runtimes) Lambda). Pour activer le dernier ensemble de mises à jour des fonctionnalités et de la sécurité, Lambda met régulièrement à jour ces bibliothèques. Ces mises à jour peuvent introduire de subtiles modifications dans le comportement de votre fonction Lambda. Pour disposer du contrôle total des dépendances que votre fonction utilise, empaquetez toutes vos dépendances avec votre package de déploiement.

  • Réduisez la taille de votre package de déploiement à ses strictes nécessités de runtime. Cela contribue à réduire le temps nécessaire au téléchargement et à la décompression de votre package de déploiement avant l'appel. Pour les fonctions créées dans Java ou .NET Core, évitez de charger la totalité de la bibliothèque du SDK AWS comme partie intégrante de votre package de déploiement. À la place, appuyez-vous de façon sélective sur les modules qui sélectionnent les composants du kit SDK dont vous avez besoin (par exemple, DynamoDB, modules du kit SDK Amazon S3 et bibliothèques principales Lambda).

  • Réduisez le temps que Lambda met à décompresser les packages de déploiement créés dans Java en plaçant vos fichiers .jar de dépendance dans un répertoire /lib distinct. Cette solution est plus rapide que le placement de tout le code de votre fonction dans un seul fichier .jar comprenant une multitude de fichiers .class. Pour obtenir des instructions, consultez Déployer des fonctions Lambda en Java avec des archives de fichiers .zip ou JAR.

  • Réduisez la complexité de vos dépendances. Privilégiez les infrastructures plus simples qui se chargent rapidement au démarrage de l'environnement d'exécution. Par exemple, préférez les infrastructures d'injection (IoC) de dépendances Java plus simples comme Dagger ou Guice, à des plus complexes comme Spring Framework.

  • Évitez d'utiliser du code récursif dans votre fonction Lambda, dans lequel la fonction s'appelle elle-même automatiquement jusqu'à ce que certains critères arbitraires soient réunis. Cela peut entraîner un volume involontaire d'appels de fonction et des coûts accrus. Si vous le faites par inadvertance, définissez immédiatement la simultanéité réservée de la fonction sur 0 afin de bloquer tous les appels à la fonction pendant que vous mettez à jour le code.

Configuration de la fonction

  • Le test de performance de votre fonction Lambda est une partie cruciale pour garantir que vous choisissez la configuration de taille mémoire optimale. Toute augmentation de la taille mémoire déclenche une augmentation équivalente de l'UC disponible pour votre fonction. L'utilisation de la mémoire pour votre fonction est déterminée par appel, et est visible dans Amazon CloudWatch. À chaque appel une entrée REPORT: est créée, comme indiqué ci-dessous :

    REPORT RequestId: 3604209a-e9a3-11e6-939a-754dd98c7be3 Duration: 12.34 ms Billed Duration: 100 ms Memory Size: 128 MB Max Memory Used: 18 MB

    En analysant le champ Max Memory Used:, vous pouvez déterminer si votre fonction a besoin de plus de mémoire ou si vous avez surdimensionné la taille mémoire de votre fonction.

    Pour trouver la bonne configuration de mémoire pour vos fonctions, nous vous recommandons d'utiliser le projet open source Power Tuning AWS Lambda. Pour plus d'informations, consultez Power Tuning AWS Lambda sur GitHub.

    Pour optimiser les performances des fonctions, nous vous recommandons également de déployer des bibliothèques capables d'exploiter Advanced Vector Extensions 2 (AVX2). Cela vous permet de traiter des charges de travail exigeantes, comme l'inférence du machine learning, le traitement multimédia, le calcul haute performance (HPC), les simulations scientifiques et la modélisation financière. Pour plus d'informations, consultez Créer des fonctions AWS Lambda plus rapides avec AVX2.

  • Effectuez un test de charge de votre fonction Lambda pour déterminer une valeur de délai d'expiration optimale. Il importe d'analyser comment votre fonction s'exécute afin que vous puissiez mieux déterminer les problèmes de service de dépendance qui peuvent accroître la simultanéité de la fonction au-delà de ce que vous attendez. Cet aspect est particulièrement important quand votre fonction Lambda effectue des appels réseau aux ressources qui peuvent ne pas gérer la mise à l'échelle de Lambda.

  • Utilisez les autorisations les plus restrictives lors de la définition des stratégies IAM. Maîtrisez les ressources et les opérations dont votre fonction Lambda a besoin et limitez le rôle d'exécution à ces autorisations. Pour de plus amples informations, veuillez consulter Autorisations AWS Lambda.

  • Familiarisez-vous avec Quotas Lambda. La taille de la charge utile, les descripteurs de fichiers et l'espace /tmp sont souvent ignorés lors de la détermination des limites des ressources.

  • Supprimez les fonctions Lambda que vous n'utilisez plus. En procédant ainsi, les fonctions inutilisées n'interviendront plus inutilement dans la limite de taille de votre package de déploiement.

  • Si vous utilisez Amazon Simple Queue Service en tant que source d'événement, assurez-vous que la valeur de la durée de l'appel prévue de la fonction ne dépasse pas la valeur Délai de visibilité de la file d'attente. Cela s'applique à CreateFunction et UpdateFunctionConfiguration.

    • Dans le cas de CreateFunction, AWS Lambda échouera lors de l'exécution du processus de création de la fonction.

    • Dans le cas de UpdateFunctionConfiguration, cela peut entraîner des appels en double de la fonction.

Métriques et alarmes

  • Utilisez Utilisation des métriques de fonction AWS Lambda et des alarmes CloudWatch au lieu de créer ou de mettre à jour une métrique à partir du code de votre fonction Lambda. C'est une manière beaucoup plus efficace de suivre l'état de vos fonctions Lambda, qui vous permet de détecter de façon précoce d'éventuels problèmes dans le processus de développement. Par exemple, vous pouvez configurer une alarme basée sur la durée attendue de l'appel de votre fonction Lambda afin de pouvoir prendre en compte les goulots d'étranglement ou les latences du code de votre fonction.

  • Mettez à profit votre bibliothèque de journalisation et les dimensions et métriques AWS Lambda pour intercepter les erreurs d'application (par exemple, ERR, ERROR, WARNING, etc.)

Utilisation des flux

  • Testez différentes tailles de lot et d'enregistrement de telle sorte que la fréquence d'interrogation de chaque source d'événement soit réglée sur la vitesse à laquelle votre fonction peut exécuter sa tâche. Le paramètre BatchSize CreateEventSourceMapping contrôle le nombre maximal de registres qui peuvent être envoyés à votre fonction lors de chaque appel. Une taille de lot plus grande peut souvent absorber plus efficacement l'appel sur un plus large ensemble d'enregistrements, ce qui accroît votre débit.

    Par défaut, Lambda appelle votre fonction dès que des enregistrements sont disponibles dans le flux. Si le lot que Lambda lit à partir du flux ne comprend qu'un seul enregistrement, Lambda envoie un seul enregistrement à la fonction. Pour éviter d'appeler la fonction avec un petit nombre d'enregistrements, vous pouvez indiquer à la source d'événement de les mettre en mémoire tampon pendant jusqu'à cinq minutes en configurant une fenêtre de traitement par lots. Avant d'appeler la fonction, Lambda continue à lire les enregistrements du flux jusqu'à avoir rassemblé un lot complet, ou jusqu'à l'expiration de la fenêtre de traitement par lots.

  • Augmentez le débit de traitement du flux Kinesis en ajoutant des partitions. Un flux Kinesis est composé d'une ou plusieurs partitions. Lambda interroge chaque partition avec au plus un appel simultané. Par exemple, si le flux comprend 100 partitions actives, il y aura au plus 100 appels de fonctions Lambda s'exécutant simultanément. L'augmentation du nombre de partitions entraîne directement celle du nombre maximum d'appels simultanés de fonctions Lambda, et peut accroître le débit de traitement de votre flux Kinesis. Si vous augmentez le nombre de partitions dans un flux Kinesis, assurez-vous d'avoir choisi une clé de partition appropriée (consultez Clés de partition) pour vos données, de façon à ce que les enregistrements associés se retrouvent sur les mêmes partitions et que vos données soient correctement distribuées.

  • Utilisez Amazon CloudWatch sur IteratorAge pour déterminer si votre flux Kinesis est en cours de traitement. Par exemple, configurez une alarme CloudWatch en définissant la valeur maximum de 30 000 (30 secondes).