La traduction de l'article a été préparée spécifiquement pour les étudiants du cours . Intéressé à évoluer dans cette direction ? Regardez la master class d'Egor Zuev (TeamLead chez InBit) et rejoignez le prochain groupe de cours : commence le 26 septembre.
De plus en plus de personnes optent pour AWS Lambda pour son évolutivité, ses performances, ses économies et sa capacité à traiter des millions, voire des milliards de demandes par mois. Pour ce faire, vous n'avez pas besoin de gérer l'infrastructure sur laquelle le service s'exécute. Et l'autoscaling vous permet de traiter des milliers de requêtes simultanées par seconde. Je pense qu'AWS Lambda peut à juste titre être considéré comme l'un des services AWS les plus populaires.
AWS Lambda
AWS Lambda est un service informatique sans serveur piloté par événements qui vous permet d'exécuter du code sans provisionner ni gérer de serveurs et d'étendre d'autres services AWS à l'aide d'une logique personnalisée. Lambda répond automatiquement à divers événements (appelés déclencheurs), tels que les requêtes HTTP via Amazon API Gateway, les modifications apportées aux données dans les compartiments Amazon S3 ou les tables Amazon DynamoDB ; ou vous pouvez exécuter votre code via des appels d'API à l'aide du kit SDK AWS et des transitions d'état dans AWS Step Functions.
Lambda exécute le code sur une infrastructure informatique hautement disponible et est entièrement responsable de l'administration de la plate-forme sous-jacente, y compris la maintenance du serveur et du système d'exploitation, l'approvisionnement en ressources, la mise à l'échelle automatique, la surveillance du code et la journalisation. Autrement dit, il vous suffit de télécharger votre code et de configurer comment et quand il doit être exécuté. À son tour, le service se chargera de son lancement et assurera la haute disponibilité de votre application.
Quand passer à Lambda ?
AWS Lambda est une plate-forme informatique pratique qui convient à une variété de cas d'utilisation, à condition que le langage et l'environnement d'exécution de votre code soient pris en charge par le service. Si vous souhaitez vous concentrer sur votre code et votre logique métier tout en externalisant la maintenance, le provisionnement et la mise à l'échelle du serveur à un coût raisonnable, AWS Lambda est définitivement la voie à suivre.
Lambda est idéal pour créer des interfaces de programmation et, lorsqu'il est utilisé conjointement avec API Gateway, vous pouvez réduire considérablement les coûts et commercialiser plus rapidement. Il existe différentes manières d'utiliser les fonctions et options Lambda pour organiser une architecture sans serveur - chacun peut choisir quelque chose d'approprié en fonction de son objectif.
Lambda vous permet d'effectuer un large éventail de tâches. Ainsi, grâce au support CloudWatch, vous pouvez créer des tâches différées et automatiser des processus individuels. Il n'y a aucune restriction sur la nature et l'intensité d'utilisation du service (la consommation mémoire et le temps sont pris en compte), et rien ne vous empêche de travailler systématiquement sur un microservice à part entière basé sur Lambda.
Ici, vous pouvez créer des actions orientées service qui ne s'exécutent pas en continu. Un exemple typique est la mise à l’échelle de l’image. Même dans le cas de systèmes distribués, les fonctions Lambda restent pertinentes.
Donc, si vous ne souhaitez pas vous soucier de l'allocation et de la gestion des ressources informatiques, essayez AWS Lambda ; si vous n'avez pas besoin de calculs lourds et gourmands en ressources, essayez également AWS Lambda ; si votre code s'exécute périodiquement, c'est vrai, vous devriez essayer AWS Lambda.
sécurité
Jusqu'à présent, il n'y a aucune plainte concernant la sécurité. D'un autre côté, étant donné que de nombreux processus internes et fonctionnalités de mise en œuvre de ce modèle sont cachés à l'utilisateur de l'environnement d'exécution géré AWS Lambda, certaines règles généralement acceptées en matière de sécurité du cloud deviennent inutiles.
Comme la plupart des services AWS, Lambda est fourni sur une base de sécurité et de conformité partagée entre AWS et le client. Ce principe réduit la charge opérationnelle du client, puisqu'AWS assume les tâches de maintenance, d'administration et de surveillance des composants de service - du système d'exploitation hôte et de la couche de virtualisation à la sécurité physique des actifs de l'infrastructure.
En ce qui concerne spécifiquement AWS Lambda, AWS est responsable de la gestion de l'infrastructure sous-jacente, des services sous-jacents associés, du système d'exploitation et de la plate-forme d'applications. Tandis que le client est responsable de la sécurité de son code, du stockage des données confidentielles, du contrôle de l'accès à celui-ci, ainsi qu'au service et aux ressources Lambda (Identity and Access Management, IAM), y compris dans la limite des fonctions utilisées.
Le diagramme ci-dessous montre le modèle de responsabilité partagée tel qu'il s'applique à AWS Lambda. La responsabilité AWS est orange et la responsabilité client est bleue. Comme vous pouvez le constater, AWS assume davantage de responsabilité pour les applications déployées sur le service.
Modèle de responsabilité partagée applicable à AWS Lambda
Exécution Lambda
Le principal avantage de Lambda est qu'en remplissant une fonction en votre nom, le service alloue lui-même les ressources nécessaires. Vous pouvez éviter de perdre du temps et des efforts en matière d’administration système et vous concentrer sur la logique métier et le codage.
Le service Lambda est divisé en deux plans. Le premier est le plan de contrôle. Selon Wikipédia, le plan de contrôle est la partie du réseau responsable du transport du trafic de signalisation et du routage. Il s'agit du principal composant qui prend les décisions globales concernant le provisionnement, la maintenance et la distribution des charges de travail. De plus, le plan de contrôle fait office de topologie réseau du fournisseur de solutions, responsable du routage et de la gestion du trafic.
Le deuxième plan est le plan des données. Comme le plan de contrôle, il a ses propres tâches. Le plan de contrôle fournit des API pour gérer les fonctions (CreateFunction, UpdateFunctionCode) et contrôle la façon dont Lambda communique avec d'autres services AWS. Le plan de données contrôle l'API Invoke, qui exécute les fonctions Lambda. Une fois qu'une fonction est appelée, le plan de contrôle alloue ou sélectionne un environnement d'exécution existant pré-préparé pour cette fonction, puis exécute le code qu'il contient.
AWS Lambda prend en charge une variété de langages de programmation, notamment Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2 et autres, via leurs environnements d'exécution respectifs. AWS les met régulièrement à jour, distribue des correctifs de sécurité et effectue d'autres activités de maintenance sur ces environnements. Lambda vous permet également d'utiliser d'autres langages, à condition que vous implémentiez vous-même le runtime approprié. Et puis vous devrez vous occuper de son entretien, notamment en surveillant sa sécurité.
Comment tout cela fonctionne-t-il et comment le service remplira-t-il vos fonctions ?
Chaque fonction s'exécute dans un ou plusieurs environnements dédiés, qui n'existent que pendant la durée de vie de cette fonction et sont ensuite détruits. Chaque environnement n'effectue qu'un seul appel à la fois, mais il est réutilisé s'il existe plusieurs appels en série vers la même fonction. Tous les environnements d'exécution s'exécutent sur des machines virtuelles dotées d'une virtualisation matérielle, appelées microVM. Chaque microVM est attribuée à un compte AWS spécifique et peut être réutilisée par les environnements pour exécuter différentes fonctions au sein de ce compte. Les MicroVM sont regroupées dans les éléments constitutifs de la plate-forme matérielle Lambda Worker, détenue et exploitée par AWS. Le même environnement d'exécution ne peut pas être utilisé par différentes fonctions, et les microVM ne sont pas non plus uniques à différents comptes AWS.
Modèle d'isolation AWS Lambda
L'isolation des environnements d'exécution est mise en œuvre à l'aide de plusieurs mécanismes. Au niveau supérieur de chaque environnement se trouvent des copies distinctes des composants suivants :
- Code de fonction
- Toutes les couches Lambda sélectionnées pour la fonction
- Environnement d'exécution des fonctions
- Espace utilisateur minimal basé sur Amazon Linux
Les mécanismes suivants sont utilisés pour isoler différents environnements d'exécution :
- groupes de contrôle - limitent l'accès aux ressources CPU, mémoire, stockage et réseau pour chaque environnement d'exécution ;
- espaces de noms - regroupement des ID de processus, des ID d'utilisateur, des interfaces réseau et d'autres ressources gérées par le noyau Linux. Chaque runtime s'exécute dans son propre espace de noms ;
- seccomp-bpf - restreint les appels système pouvant être utilisés dans le runtime ;
- iptables et tables de routage - isolation des environnements d'exécution les uns des autres ;
- chroot - fournit un accès limité au système de fichiers sous-jacent.
Combinés aux technologies d'isolation propriétaires AWS, ces mécanismes garantissent une séparation fiable des temps d'exécution. Les environnements ainsi isolés ne peuvent pas accéder ni modifier les données d'autres environnements.
Bien que plusieurs environnements d'exécution du même compte AWS puissent s'exécuter sur une seule microVM, les microVM ne peuvent en aucun cas être partagées entre différents comptes AWS. AWS Lambda utilise uniquement deux mécanismes pour isoler les microVM : les instances EC2 et Firecracker. L'isolation des invités dans Lambda basée sur les instances EC2 existe depuis 2015. Firecracker est un nouvel hyperviseur open source spécialement conçu par AWS pour les charges de travail sans serveur et introduit en 2018. Le matériel physique exécutant les microVM est partagé entre les charges de travail de différents comptes.
Sauvegarde des environnements et des états de processus
Bien que les runtimes Lambda soient propres à différentes fonctions, ils peuvent appeler la même fonction à plusieurs reprises, ce qui signifie que le runtime peut survivre plusieurs heures avant d'être détruit.
Chaque environnement d'exécution Lambda dispose également d'un système de fichiers accessible en écriture via le répertoire /tmp. Son contenu n’est pas accessible à partir d’autres environnements d’exécution. En ce qui concerne la persistance de l'état du processus, les fichiers écrits dans /tmp existent pendant tout le cycle de vie de l'environnement d'exécution. Cela permet d'accumuler les résultats de plusieurs appels, ce qui est particulièrement utile pour les opérations coûteuses telles que le chargement de modèles d'apprentissage automatique.
Transfert de données d'appel
L'API Invoke peut être utilisée dans deux modes : le mode événement et le mode requête-réponse. En mode événement, l'appel est ajouté à une file d'attente pour une exécution ultérieure. En mode requête-réponse, la fonction est appelée instantanément avec la charge utile fournie, après quoi la réponse est renvoyée. Dans les deux cas, la fonction s'exécute dans un environnement Lambda, mais avec des chemins de charge utiles différents.
Lors des appels de demande-réponse, la charge utile circule depuis une API de traitement de demande (API Caller), telle qu'AWS API Gateway ou AWS SDK, vers l'équilibreur de charge, puis vers le service d'appel Lambda (Invoke Service). Ce dernier détermine l'environnement approprié pour exécuter la fonction et y transmet la charge utile pour terminer l'appel. L'équilibreur de charge reçoit le trafic protégé par TLS sur Internet. Le trafic au sein du service Lambda, après l'équilibreur de charge, passe par un VPC interne dans une région AWS spécifique.
Modèle de traitement des appels AWS Lambda : mode requête-réponse
Les appels d'événements peuvent être effectués immédiatement ou ajoutés à une file d'attente. Dans certains cas, la file d'attente est implémentée à l'aide d'Amazon SQS (Amazon Simple Queue Service), qui transmet les appels au service de traitement des appels Lambda via un processus d'interrogation interne. Le trafic transmis est protégé par TLS et il n'y a aucun cryptage supplémentaire des données stockées dans Amazon SQS.
Les appels d'événements ne renvoient pas de réponses : le Lambda Worker ignore simplement les informations de réponse. Les appels basés sur des événements provenant d'Amazon S3, d'Amazon SNS, de CloudWatch et d'autres sources sont traités par Lambda en mode événement. Les appels provenant des flux Amazon Kinesis et DynamoDB, des files d'attente SQS, des appels Application Load Balancer et API Gateway sont traités de manière demande-réponse.
Surveillance
Vous pouvez surveiller et auditer les fonctions Lambda à l'aide de divers mécanismes et services AWS, notamment les suivants.
Amazon Cloud Watch
Collecte diverses statistiques telles que le nombre de requêtes, la durée des requêtes et le nombre de requêtes qui ont échoué.
Amazon CloudTrail
Vous permet de consigner, de surveiller en continu et de conserver les informations sur l'activité des comptes associées à votre infrastructure AWS. Vous disposerez d'un historique complet des actions effectuées à l'aide d'AWS Management Console, du SDK AWS, des outils de ligne de commande et d'autres services AWS.
Rayons X AWS
Fournit une visibilité complète sur toutes les étapes de traitement des demandes dans votre application sur la base d’une cartographie de ses composants internes. Vous permet d'analyser les applications pendant le développement et dans les environnements de production.
Configuration AWS
Vous serez en mesure de suivre les modifications apportées à la configuration des fonctions Lambda (y compris la suppression) et aux environnements d'exécution, aux balises, aux noms de gestionnaires, à la taille du code, à l'allocation de mémoire, aux paramètres de délai d'expiration et de concurrence, ainsi qu'au rôle d'exécution Lambda IAM, aux sous-réseaux et aux liaisons de groupe de sécurité. .
Conclusion
AWS Lambda propose un ensemble d'outils puissants pour créer des applications sécurisées et évolutives. De nombreuses pratiques de sécurité et de conformité dans AWS Lambda sont les mêmes que dans d'autres services AWS, à quelques exceptions près. Depuis mars 2019, Lambda est conforme aux normes SOC 1, SOC 2, SOC 3, PCI DSS, Health Insurance Portability and Accountability Act (HIPAA) et à d'autres réglementations. Ainsi, lorsque vous envisagez de mettre en œuvre votre prochaine application, pensez au service AWS Lambda : il est peut-être celui qui convient le mieux à votre tâche.
Source: habr.com