Définir le gestionnaire de fonctions Lambda dans Ruby

Le gestionnaire de fonction Lambda est la méthode dans votre code de fonction qui traite les événements. Lorsque votre fonction est invoquée, Lambda exécute la méthode du gestionnaire. Votre fonction s’exécute jusqu’à ce que le gestionnaire renvoie une réponse, se ferme ou expire.

Notions de base sur Ruby Handler

Dans l'exemple suivant, le fichier function.rb définit une méthode de gestionnaire nommée handler. La fonction de gestion prend deux objets en entrée et renvoie un JSON document.

Exemple function.rb

require 'json'

def handler(event:, context:)
    { event: JSON.generate(event), context: JSON.generate(context.inspect) }
end

Dans la configuration de votre fonction, le paramètre handler indique à Lambda où trouver le gestionnaire. Pour l'exemple précédent, la valeur correcte pour ce paramètre est function.handler. Elle inclut deux noms séparées par un point : le nom du fichier et le nom de la méthode de gestionnaire.

Vous pouvez également définir votre méthode de gestionnaire dans une classe. L'exemple suivant définit une méthode de gestionnaire nommée process sur une classe nommée Handler dans un module appelé LambdaFunctions.

Exemple source.rb

module LambdaFunctions
  class Handler
    def self.process(event:,context:)
      "Hello!"
    end
  end
end

Dans ce cas, le paramètre de gestionnaire est source.LambdaFunctions::Handler.process.

Les deux objets qui sont acceptés par le gestionnaire sont l'événement d'invocation et le contexte. L'événement est un objet Ruby qui contient la charge utile qui est fournie par le mécanisme d'invocation. Si la charge utile est un JSON document, l'objet de l'événement est un hachage Ruby. Sinon, il s'agit d'une chaîne. L'objet de contexte contient des méthodes et des propriétés qui fournissent des informations sur l'invocation, la fonction et l'environnement d'exécution.

Le gestionnaire de fonction est exécuté chaque fois que votre fonction Lambda est invoquée. Le code statique à l'extérieur du gestionnaire est exécuté une fois par instance de la fonction. Si votre gestionnaire utilise des ressources telles que des SDK clients et des connexions à des bases de données, vous pouvez les créer en dehors de la méthode du gestionnaire afin de les réutiliser pour plusieurs appels.

Chaque instance de votre fonction peut traiter plusieurs événements d'invocations, mais elle ne traite qu'un événement à la fois. Le nombre d'instances traitant un événement à un moment donné est la simultanéité de votre fonction. Pour plus d'informations sur l'environnement d'exécution Lambda, consultez Comprendre le cycle de vie de l'environnement d'exécution Lambda.

Bonnes pratiques en matière de code pour les fonctions Ruby Lambda

Respectez les directives de la liste suivante pour utiliser les meilleures pratiques de codage lors de la création de vos fonctions Lambda :

• Séparez le gestionnaire Lambda de votre logique principale. Cela vous permet de créer une fonction testable plus unitaire. Par exemple, dans Ruby, cela peut ressembler à ceci :

  def lambda_handler(event:, context:)
      foo = event['foo']
      bar = event['bar']
      
      result = my_lambda_function(foo:, bar:)
  
  end
  
  def my_lambda_function(foo:, bar:)
      // MyLambdaFunction logic here
      
  end
  

• Contrôlez les dépendances du package de déploiement de vos fonctions. L'environnement AWS Lambda d'exécution contient un certain nombre de bibliothèques. Pour le runtime Ruby, il s'agit notamment du AWS SDK. 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 complexité de vos dépendances. Privilégiez les infrastructures plus simples qui se chargent rapidement au démarrage de l’environnement d’exécution.

• Réduisez la taille de votre package de déploiement selon ses besoins d’exécution. Cela contribue à réduire le temps nécessaire au téléchargement et à la décompression de votre package de déploiement avant l’invocation. Pour les fonctions créées dans Ruby, évitez de télécharger l'intégralité de la AWS SDK bibliothèque dans le cadre de votre package de déploiement. Dépendez plutôt de manière sélective des gemmes qui récupèrent les composants dont SDK vous avez besoin (par exemple, les gemmes DynamoDB ou Amazon SDK S3).

• Tirez parti de la réutilisation de l’environnement d’exécution pour améliorer les performances de votre fonction. Initialisez les SDK clients et les connexions à la base de données en dehors du gestionnaire de fonctions et mettez en cache les actifs statiques localement dans le /tmp répertoire. Les invocations ultérieures traitées 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 invoquez 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.

• É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’invocations 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 toutes les invocations de la fonction pendant que vous mettez à jour le code.

• N'utilisez pas de code non documenté ni public APIs dans votre code de fonction Lambda. Pour les AWS Lambda environnements d'exécution gérés, Lambda applique régulièrement des mises à jour de sécurité et fonctionnelles aux applications internes de Lambda. APIs Ces API mises à jour internes peuvent être rétroincompatibles, ce qui peut entraîner des conséquences imprévues, telles que des échecs d'invocation si votre fonction dépend de ces mises à jour non publiques. APIs Voir la API référence pour une liste des documents accessibles au publicAPIs.

• Écriture du code idempotent. L’écriture de code idempotent pour vos fonctions garantit ne gestion identique des événements dupliqués. Votre code doit valider correctement les événements et gérer correctement les événements dupliqués. Pour de plus amples informations, veuillez consulterComment faire en sorte que ma fonction Lambda soit idempotente ?.