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.

Bonnes pratiques pour les instances gérées Lambda

Configuration du fournisseur de capacité

Séparez les fournisseurs de capacité par niveau de confiance. Créez différents fournisseurs de capacité pour les charges de travail présentant des exigences de sécurité différentes. Toutes les fonctions d'événement Lambda attribuées au même fournisseur de capacité doivent être mutuellement fiables, car les fournisseurs de capacité servent de limite de sécurité.

Utilisez des noms descriptifs. Nommez les fournisseurs de capacité pour indiquer clairement leur utilisation prévue et leur niveau de confiance (par exempleproduction-trusted,dev-sandbox). Cela permet aux équipes de comprendre l'objectif et le niveau de sécurité de chaque fournisseur de capacité.

Utilisez plusieurs zones de disponibilité. Spécifiez des sous-réseaux dans plusieurs zones de disponibilité lors de la création de fournisseurs de capacité. Lambda lance trois instances par défaut pour la résilience AZ, garantissant ainsi la haute disponibilité de vos fonctions.

Sélection du type d'instance

Laissez Lambda choisir les types d'instances. Par défaut, Lambda choisit les types d'instances les mieux adaptés à votre charge de travail. Nous vous recommandons de laisser les instances gérées Lambda choisir les types d'instances à votre place, car la restriction du nombre de types d'instances possibles peut entraîner une baisse de disponibilité.

Spécifiez les types d'instances pour des besoins spécifiques. Si vous avez des exigences matérielles spécifiques, définissez les types d'instances autorisés dans une liste d'instances compatibles. Par exemple :

Configuration de la fonction

Choisissez les paramètres de mémoire et de vCPU appropriés. Sélectionnez des configurations de mémoire et de vCPU qui prennent en charge les exécutions simultanées de votre fonction. La taille de fonction minimale prise en charge est de 2 Go et 1 vCPU.

Configurez la simultanéité maximale de manière appropriée. Lambda choisit des valeurs par défaut raisonnables pour une simultanéité maximale qui équilibre la consommation de ressources et le débit. Ajustez ce paramètre en fonction de l'utilisation des ressources de votre fonction :

Notez que les environnements d'exécution présentant une très faible simultanéité peuvent être confrontés à des ralentissements et à des difficultés de mise à l'échelle.

Long-running fonctions

Les fonctions des instances AWS Lambda gérées peuvent s'exécuter pendant 90 minutes (5 400 secondes) par appel pour les invocations asynchrones et pour les invocations de mappage des sources d'événements, à l'exception des mappages des sources d'événements Amazon MQ et Amazon DocumentDB, qui restent limités à 15 minutes. Les appels synchrones et la phase d'initialisation des fonctions restent également limités à 15 minutes. Pour plus d'informations sur la définition du délai d'expiration, voir Configurer le délai d'expiration de la fonction Lambda. Étant donné que votre fonction peut s'exécuter plus longtemps, prenez en compte les considérations suivantes pour les composants de nature éphémère, tels que les connexions réseau et les informations d'identification.

Tenez compte des délais d'inactivité des connexions. Assurez-vous que les délais de connexion inactifs sur les services en aval tels qu'Amazon RDS ElastiCache, Amazon et les API externes tiennent compte de la durée complète des fonctions. Si votre fonction achemine le trafic via une passerelle NAT, envoyez des paquets keep-alive pour éviter que les connexions inactives ne soient abandonnées après le délai d'inactivité de 350 secondes de la passerelle NAT.

Respectez les valeurs TTL du DNS. Respectez les valeurs TTL du DNS lorsque vous résolvez des noms d'hôtes externes. Les AWS SDK gèrent cela automatiquement, mais les clients HTTP personnalisés peuvent mettre en cache des résolutions DNS au-delà de leur TTL.

Actualisez les informations d'identification temporaires. Si votre fonction acquiert des informations d'identification ou des jetons temporaires, vérifiez qu'ils restent valides pendant toute la durée d'exécution ou actualisez-les en arrière-plan.

Conception axée sur l'idempuissance. Lambda ne garantit pas un traitement en une seule fois. Au fur et à mesure que les fonctions s'allongent, la fenêtre de nouvelles tentatives et de doublons de livraisons augmente. Utilisez Powertools for AWS Lambda pour implémenter l'idempotencie pour des opérations telles que les paiements ou les écritures de base de données, afin qu'elles produisent le même résultat même si elles sont exécutées plusieurs fois. Si vous utilisez les fonctions durables Lambda, les étapes ont une sémantique d'exécution au moins une fois : le SDK d'exécution durable ignore les étapes terminées pendant la rediffusion, mais les étapes qui échouent avant le point de contrôle peuvent être exécutées à nouveau. Vous pouvez utiliser les noms d'exécution comme clés d'idempuissance.

Ajustez les mappages des sources d'événements pour un traitement plus long. Pour Amazon SQS, définissez le délai de visibilité de la file d'attente à au moins six fois le délai d'expiration de la fonction, afin que Lambda dispose de suffisamment de temps pour réessayer un lot si la fonction est limitée. Lambda valide cela lorsque vous créez le mappage des sources d'événements, mais n'empêche pas les modifications ultérieures de la file d'attente ou de la fonction qui créent une incompatibilité. Pour Amazon Kinesis Data Streams et Amazon DynamoDB Streams, configurez la fenêtre de traitement par lots maximale et le facteur de parallélisation afin de prendre en compte les délais de traitement plus longs par lot, et activez le signalement partiel des défaillances de lots afin que seuls les enregistrements ayant échoué soient réessayés au lieu du lot complet.

Configuration de la mise à l'échelle

Définissez une utilisation cible appropriée des ressources. Par défaut, Lambda conserve une marge de manœuvre suffisante pour que votre trafic double en 5 minutes sans limitation. Ajustez cela en fonction des caractéristiques de votre charge de travail :

Planifiez la croissance du trafic. Si votre trafic double plus que dans les 5 minutes, vous risquez de constater des ralentissements à mesure que Lambda augmente le nombre d'instances et d'environnements d'exécution. Concevez votre application de manière à gérer les ralentissements potentiels pendant les périodes de mise à l'échelle rapide.

Sécurité

Appliquez le moindre privilège pour PassCapacityProvider les autorisations. N'accordez lambda:PassCapacityProvider des autorisations qu'aux fournisseurs de capacité nécessaires. Utilisez les autorisations au niveau des ressources pour limiter les fournisseurs de capacité que les utilisateurs peuvent affecter aux fonctions.

Surveillez l'utilisation des fournisseurs de capacité. AWS CloudTrail À utiliser pour surveiller les attributions des fournisseurs de capacité et les modèles d'accès. Cela permet d'identifier les tentatives d'accès non autorisées et de garantir le respect des politiques de sécurité.

Séparez les charges de travail non fiables. Ne vous fiez pas aux conteneurs pour isoler la sécurité entre les charges de travail non fiables. Utilisez différents fournisseurs de capacité pour séparer les charges de travail qui ne sont pas mutuellement fiables.

Optimisation des coûts

Utilisez les options de tarification EC2. Profitez des plans EC2 Savings Plans et des instances réservées pour réduire les coûts. Ces options de tarification s'appliquent au calcul EC2 sous-jacent (les frais de gestion de 15 % ne sont pas réduits).

Optimisez les charges de travail en régime permanent. Les instances gérées Lambda sont particulièrement adaptées aux fonctions en régime permanent avec un volume de trafic élevé prévisible. Pour les modèles de trafic en rafale, Lambda (par défaut) peut être plus rentable.

Surveillez l'utilisation des ressources. Suivez CloudWatch les métriques pour comprendre l'utilisation du processeur et de la mémoire. Ajustez l'allocation de mémoire des fonctions et la sélection du type d'instance en fonction des modèles d'utilisation réels afin d'optimiser les coûts.

Surveillance et observabilité

Surveillez les indicateurs des fournisseurs de capacité. Suivez les indicateurs au niveau des fournisseurs de capacité, MemoryUtilization notamment l'utilisation du processeur et la disponibilité de vCPUAvailable, et vérifiez que des ressources suffisantes sont disponibles MemoryAvailable pour vos charges de travail.

Surveillez les métriques de l'environnement d'exécution. Suivez les indicateurs au niveau de l'environnement d'exécution, notamment ExecutionEnvironmentConcurrency ExecutionEnvironmentConcurrencyLimit pour comprendre le comportement de dimensionnement et identifier les ralentissements potentiels.

Configurez des CloudWatch alarmes. Créez des CloudWatch alarmes pour les indicateurs clés afin d'identifier les problèmes de manière proactive :

Language-specific considérations

Suivez les meilleures pratiques spécifiques à la langue. Chaque langage de programmation gère différemment la multisimultanéité. Consultez les guides spécifiques aux langues pour obtenir des recommandations détaillées :

Testez les problèmes de sécurité et de simultanéité des threads. Avant le déploiement en production, testez soigneusement vos fonctions pour détecter les problèmes de sécurité des threads, les conditions de course et l'isolation correcte des états sous charge simultanée.

Étapes suivantes