AWS Lambda
Manuel du développeur

Bonnes pratiques d'utilisation des fonctions AWS Lambda

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

Code de fonction

  • Séparez le gestionnaire Lambda (point d'entrée) 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 du contexte d'exécution pour améliorer les performances de votre fonction. Assurez-vous que les configurations externalisées et les dépendances que votre code extrait sont stockées et référencées localement après l'exécution initiale. Limitez la réinitialisation des variables/objets sur chaque appel. Utilisez à la place l'initialisation statique/le constructeur statique, les variables globales/statiques et les singletons. Maintenez et réutilisez les connexions (HTTP, base de données, etc.) qui ont été établies lors d'un précédent appel.

  • Utilisez Variables d'environnement AWS Lambda 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 à l'adresse Runtimes AWS 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 que vous ayez le contrôle total des dépendances que votre fonction utilise, il est recommandé d'empaqueter 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. Vous réduirez ainsi 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 exemples, les modules SDK Amazon S3, DynamoDB et les bibliothèques Lambda principales).

  • Réduisez le temps mis par Lambda pour décompresser les packages de déploiement créés dans Java en plaçant vos fichiers de dépendance .jar 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 Package de déploiement AWS Lambda dans Java.

  • Réduisez la complexité de vos dépendances. Privilégiez les infrastructures plus simples qui se chargent rapidement au démarrage du contexte 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 satisfaits. 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 limite des exécutions simultanées de la fonction sur 0 afin de bloquer tous les appels à la fonction pendant que vous mettez à jour le code.

Configuration de fonctions

  • 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 peut s'afficher dans les journaux AWS 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.

  • Effectuez un test de charge de votre fonction Lambda pour déterminer une valeur de délai d'expiration. 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 en savoir plus, consultez la page Autorisations AWS Lambda.

  • Familiarisez-vous avec Limites AWS 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 d'exécution 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.

Alarmes et métriques

  • Utilisez les Métriques AWS Lambda et les alarmes CloudWatch au lieu de créer ou de mettre à jour une métrique depuis le code de votre fonction Lambda. Le suivi de l'état de vos fonctions Lambda est une solution plus efficace et vous permet d'intercepter de façon précoce les problèmes du processus de développement. Par exemple, vous pouvez configurer une alarme basée sur la durée prévue de l'exécution 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.)

Appels d'événements de 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. BatchSize contrôle le nombre maximal d'enregistrements qui peuvent être envoyés à votre fonction avec 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.

    Note

    Quand il n'y a plus assez d'enregistrements à traiter, au lieu d'attendre, la fonction de traitement de flux est appelé avec un plus petit nombre d'enregistrements.

  • Augmentez le débit du traitement de 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 contient 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 d'appels maximaux simultanés de fonctions Lambda et peut accroître le débit de traitement des flux Kinesis. Si vous augmentez le nombre de partitions d'un flux Kinesis, assurez-vous d'avoir choisi une bonne clé de partition (consultez Clés de partition) pour vos données, de telle sorte que les enregistrements associés se retrouvent sur les mêmes partitions et que vos données soient bien 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 avec une valeur maximale de 30000 (30 secondes).

Appels asynchrones

VPC Lambda

  • Le schéma suivant vous guide à travers un arbre de décision comme si vous deviez utiliser un VPC (Virtual Private Cloud) :

  • Ne placez pas votre fonction Lambda dans un VPC à moins d'y être obligé. Il n'y a aucun avantage à cela, si ce n'est de l'utiliser pour accéder aux ressources que vous ne pouvez pas exposer publiquement, comme une instance Amazon Relational Database privée. Les services comme Amazon Elasticsearch Service peuvent être sécurisés sur IAM avec les stratégies d'accès ; par conséquent, l'exposition publique du point de terminaison est sécurisée et ne nécessite pas que vous exécutiez votre fonction dans le VPC pour le sécuriser.

  • Lambda crée des interfaces réseau Elastic (ENI) dans votre VPC pour accéder à vos ressources internes. Avant de demander une augmentation simultanée, assurez-vous d'avoir une capacité ENI suffisante (la formule correspondante est disponible à l'adresse Configuration d'une fonction Lambda pour accéder aux ressources d'un Amazon VPC) et un espace d'adressage IP. Si vous n'avez pas une capacité ENI suffisante, vous devrez demander une augmentation. Si vous n'avez pas un espace d'adressage IP suffisant, vous pouvez demander à créer un sous-réseau plus grand.

  • Créez des sous-réseaux privés dédiés dans votre VPC :

    • Il vous sera ainsi plus facile d'appliquer une table de routage personnalisée pour le trafic NAT Gateway sans avoir à modifier vos autres sous-réseaux. les fonctions Lambda peuvent uniquement s'exécuter dans les sous-réseaux privés. Pour de plus amples informations, veuillez consulter Configuration d'une fonction Lambda pour accéder aux ressources d'un Amazon VPC

    • Vous pouvez ainsi dédier un espace d'adressage à Lambda sans le partager avec d'autres ressources.