Analyse détaillée d'AWS Lambda

La traduction de l'article a été préparée spécialement pour les étudiants du cours «Services Cloud». Vous êtes intéressé à développer dans ce domaine ? Regardez le masterclass d'Egor Zuev (TeamLead chez InBit) «Service AWS EC2» et rejoignez le prochain groupe du cours : début le 26 septembre.

De plus en plus de personnes passent à AWS Lambda pour sa scalabilité, ses performances, ses économies et sa capacité à traiter des millions, voire des trillions de requêtes par mois. Il n'est pas nécessaire de gérer l'infrastructure sur laquelle le service fonctionne. L'auto-scaling permet de traiter des milliers de requêtes simultanées par seconde. Je pense qu'on peut à juste titre considérer AWS Lambda comme l'un des services les plus demandés d'AWS.

AWS Lambda

AWS Lambda est un service de calcul sans serveur orienté événements, qui permet d'exécuter du code sans provisionner ni administrer des serveurs et de compléter d'autres services AWS en fonction de la logique utilisateur. Lambda réagit automatiquement à divers événements (les fameux déclencheurs), par exemple aux requêtes HTTP via Amazon API Gateway, aux modifications de données dans les compartiments Amazon S3 ou dans les tables Amazon DynamoDB ; ou vous pouvez exécuter votre code via des appels API, en utilisant AWS SDK et les transitions d'état dans AWS Step Functions.

Lambda exécute le code sur une infrastructure de calcul hautement disponible et s'occupe entièrement de l'administration de la plateforme sous-jacente, y compris la gestion des serveurs et du système d'exploitation, la provision de ressources, l'auto-scaling, la surveillance du code et la gestion des logs. Vous n'avez donc qu'à télécharger votre code et à configurer comment et quand il doit être exécuté. Le service se chargera de son exécution et garantira la haute disponibilité de votre application.

Quand passer à Lambda ?

AWS Lambda est une plateforme de calcul pratique, adaptée à de nombreux scénarios d'utilisation, à condition bien sûr 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 le code et la logique commerciale, en confiant la maintenance des serveurs, la provision de ressources et le scaling à un fournisseur tiers à un coût raisonnable, vous devriez définitivement passer à AWS Lambda.

Lambda est idéal pour créer des interfaces de programme, et si vous utilisez le service avec API Gateway, vous pouvez réduire considérablement les coûts et accélérer votre mise sur le marché. Il existe différentes manières d'utiliser les fonctions Lambda et d'organiser une architecture sans serveur — chacun peut choisir quelque chose de adapté en fonction des objectifs fixés.

Lambda permet d'exécuter un large éventail de tâches. Grâce à la prise en charge de CloudWatch, vous pouvez créer des tâches planifiées et automatiser certains processus. Il n'y a aucune restriction concernant la nature et l'intensité d'utilisation du service (seules la mémoire et le temps sont pris en compte), et rien ne vous empêche de travailler progressivement sur un microservice complet basé sur Lambda.

Ici, vous pouvez créer des actions orientées services qui ne s'exécutent pas en permanence. Un exemple typique est la mise à l'échelle des images. Même dans le cas de systèmes distribués, les fonctions Lambda conservent leur pertinence.

Ainsi, si vous ne souhaitez pas vous occuper de l'allocation et de l'administration 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 — vous avez raison, vous devriez essayer AWS Lambda.

Sécurité

Pour l'instant, aucun problème de sécurité n'a été signalé. D'autre part, étant donné que de nombreux processus internes et caractéristiques de mise en œuvre de ce modèle sont masqués pour l'utilisateur du runtime géré d'AWS Lambda, certaines règles de sécurité cloud établies perdent de leur pertinence.

Comme la plupart des services AWS, Lambda est fourni selon le principe de responsabilité partagée entre AWS et le client en matière de sécurité et de conformité. Ce principe réduit la charge opérationnelle pour le client, car AWS prend en charge les tâches de maintenance, d'administration et de contrôle des composants du service — depuis le système d'exploitation hôte et le niveau de virtualisation jusqu'à la sécurité physique des infrastructures.

En ce qui concerne spécifiquement AWS Lambda, AWS est responsable de la gestion de l'infrastructure sous-jacente, des services de base associés, du système d'exploitation et de la plateforme d'applications. Tandis que le client est responsable de la sécurité de son code, du stockage des données sensibles, du contrôle d'accès à celles-ci, ainsi qu'au service et aux ressources Lambda (Identity and Access Management, IAM), y compris au sein des fonctions utilisées.

Le schéma ci-dessous présente le modèle de responsabilité partagée applicable à AWS Lambda. La zone de responsabilité d'AWS est colorée en orange, tandis que la responsabilité du client est en bleu. Comme vous pouvez le voir, AWS assume une plus grande part de responsabilité pour les applications déployées sur le service.

Modèle de responsabilité partagée applicable à AWS Lambda

Environnement d'exécution Lambda

Le principal avantage de Lambda est que, en exécutant une fonction en votre nom, le service alloue lui-même les ressources nécessaires. Vous pouvez ainsi éviter de perdre du temps et de l'énergie à administrer les systèmes et vous concentrer sur la logique métier et l'écriture de code.

Le service Lambda est divisé en deux plans. Le premier est le plan de gestion. Selon Wikipédia, le plan de gestion (control plane) est la partie du réseau responsable du transport du trafic de signalisation et de la routage. C'est le composant principal qui prend des décisions globales concernant l'allocation, la maintenance et la répartition des charges de travail. De plus, le plan de gestion joue le rôle de topologie réseau du fournisseur de solutions, responsable de la routage et de la gestion du trafic.

Le deuxième plan est le plan de données. Il a, tout comme le plan de gestion, ses propres tâches. Le plan de gestion fournit une API pour gérer les fonctions (CreateFunction, UpdateFunctionCode) et contrôle l'interaction de Lambda avec d'autres services AWS. Le plan de données gère les appels API (Invoke API) qui exécutent les fonctions Lambda. Après l'appel de la fonction, le plan de gestion alloue ou choisit un environnement d'exécution existant, préalablement préparé pour cette fonction, puis exécute le code dans celui-ci.

AWS Lambda prend en charge de nombreux langages de programmation, y compris Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2, et d'autres, via des environnements d'exécution correspondants. AWS les met régulièrement à jour, distribue des correctifs de sécurité et effectue d'autres opérations de maintenance sur ces environnements. Lambda permet d'utiliser d'autres langages à condition que vous intégriez vous-même l'environnement d'exécution approprié. Vous devrez alors vous occuper de sa maintenance, y compris veiller à la sécurité.

Comment tout cela fonctionne-t-il et comment le service exécutera-t-il vos fonctions ?

Chaque fonction s'exécute dans un ou plusieurs environnements isolés, qui existent uniquement pendant le cycle de vie de cette fonction, puis sont détruits. Dans chaque environnement, une seule invocation est exécutée à la fois, mais il est réutilisé s'il y a plusieurs invocations successives de la même fonction. Tous les environnements d'exécution fonctionnent sur des machines virtuelles avec virtualisation matérielle, appelées microVM. Chaque microVM est attribuée à un compte AWS spécifique et peut être réutilisée par des environnements pour exécuter différentes fonctions dans ce compte. Les microVM sont empaquetées dans des blocs structurels de la plateforme matérielle Lambda Worker, détenue et gérée par AWS. Le même environnement d'exécution ne peut pas être utilisé par différentes fonctions, tout comme les microVM sont uniques pour différents comptes AWS.

Le modèle d'isolation dans AWS Lambda

L'isolation des environnements d'exécution est mise en œuvre à l'aide de plusieurs mécanismes. Au niveau le plus élevé, chaque environnement possède des copies distinctes des composants suivants :

• Le code de la fonction
• Tous les layers Lambda sélectionnés pour la fonction
• L'environnement d'exécution de la fonction
• Espace utilisateur minimal basé sur Amazon Linux

Les mécanismes suivants sont appliqués pour isoler différents environnements d'exécution :

• cgroups — restriction d'accès aux ressources CPU, mémoire, bande passante de stockage et réseau pour chaque environnement d'exécution ;
• namespaces — regroupement des IDs de processus, des IDs d'utilisateurs, des interfaces réseau et d'autres ressources gérées par le noyau Linux. Chaque environnement d'exécution fonctionne dans son propre espace de noms ;
• seccomp-bpf — restriction des appels système qui peuvent être utilisés dans l'environnement d'exécution ;
• iptables et tables de routage — isolation des environnements d'exécution entre eux ;
• chroot — fourniture d'un accès restreint au système de fichiers sous-jacent.

En combinaison avec les technologies propriétaires d'isolation d'AWS, les mécanismes énumérés garantissent une séparation fiable des environnements d'exécution. Les environnements ainsi isolés ne peuvent pas accéder aux données d'autres environnements ni les modifier.

Bien que plusieurs environnements d'exécution d'un même compte AWS puissent fonctionner sur une microVM, ces microVM ne peuvent en aucun cas être partagées entre différents comptes AWS. Pour l'isolation des microVM, AWS Lambda utilise seulement deux mécanismes : les instances EC2 et Firecracker. L'isolation des invités (guest isolation) dans Lambda, basée sur des instances EC2, est mise en œuvre depuis 2015. Firecracker est un nouvel hyperviseur open source, spécialement conçu par AWS pour les charges de travail sans serveur et présenté en 2018. Le matériel physique sur lequel s'exécutent les microVM est partagé par des charges de travail de différents comptes.

Conservation des environnements et des états des processus

Bien que les environnements d'exécution Lambda soient uniques pour différentes fonctions, il est possible de réinvoker la même fonction, c'est-à-dire que l'environnement d'exécution peut durer plusieurs heures avant d'être détruit.

Chaque environnement d'exécution Lambda dispose également d'un système de fichiers en écriture, accessible via le répertoire /tmp. Son contenu ne peut pas être accédé depuis d'autres environnements d'exécution. En ce qui concerne la conservation des états des 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 des opérations coûteuses, comme le chargement de modèles d'apprentissage automatique.

Transmission des données d'appels

L'interface Invoke API peut être utilisée en deux modes : le mode événement et le mode « demande - réponse ». En mode événement, l'appel est ajouté à une file d'attente pour une exécution ultérieure. En mode « demande - réponse », la fonction est appelée immédiatement avec la charge utile fournie, après quoi une réponse est renvoyée. Dans les deux cas, la fonction s'exécute dans l'environnement Lambda, mais avec des chemins de charge utile différents.

Lors des appels de type « requête-réponse », la charge utile provient de l'API de traitement des requêtes (API Caller), telle que AWS API Gateway ou AWS SDK, vers le répartiteur de charge, puis vers le service d'exécution des appels Lambda (Invoke Service). Ce dernier détermine l'environnement approprié pour exécuter la fonction et y transfère la charge utile pour finaliser l'appel. Le répartiteur de charge reçoit le trafic avec protection TLS via Internet. Le trafic à l'intérieur du service Lambda — après le répartiteur de charge — passe par le VPC interne dans la région AWS spécifiée.

Modèle de traitement des appels AWS Lambda : mode « requête-réponse »

Les appels basés sur des événements peuvent être exécutés immédiatement ou être mis en file d'attente. Dans certains cas, la file d'attente est mise en œuvre à l'aide du service Amazon SQS (Amazon Simple Queue Service), qui transmet les appels au service d'exécution des appels Lambda par le biais d'un processus d'interrogation interne (poller). Le trafic transmis est protégé par TLS, sans qu'aucun cryptage supplémentaire des données stockées dans Amazon SQS ne soit prévu.

Les appels basés sur des événements ne renvoient pas de réponses — toute information de réponse est simplement ignorée par Lambda Worker. 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 le service Lambda en mode événement. Les appels des flux Amazon Kinesis et DynamoDB, les appels des files d'attente SQS, du répartiteur de charge d'applications et de l'API Gateway sont traités en mode « requête-réponse ».

Surveillance

Vous pouvez surveiller et auditer les fonctions Lambda à l'aide de divers mécanismes et services AWS, y compris les suivants.

Amazon CloudWatch
Collecte diverses statistiques, telles que le nombre de requêtes, la durée des requêtes et le nombre de requêtes ayant échoué.

Amazon CloudTrail
Permet de conserver des journaux, de surveiller en continu et d'enregistrer des informations sur l'activité de votre compte, en lien avec votre infrastructure AWS. Vous aurez une chronologie complète des actions effectuées via la console de gestion AWS, l'AWS SDK, les outils de ligne de commande et d'autres services AWS.

AWS X-Ray
Fournit une visibilité complète sur toutes les étapes de traitement des requêtes dans votre application, en fonction de la carte de ses composants internes. Permet d'analyser les applications pendant le développement et en environnement de production.

AWS Config
Vous pourrez suivre les modifications de la configuration des fonctions Lambda (y compris leur suppression) et de l'environnement d'exécution, des balises, des noms de gestionnaires, de la taille du code, de la répartition de la mémoire, des paramètres de temporisation et de parallélisme, ainsi que du rôle d'exécution IAM Lambda, des sous-réseaux et des liaisons de groupes de sécurité.

Conclusion

AWS Lambda propose un puissant ensemble d'outils pour créer des applications sécurisées et évolutives. De nombreuses méthodes de sécurité et de conformité dans AWS Lambda sont similaires à celles utilisées dans les autres services AWS, bien qu'il y ait des exceptions. À compter de mars 2019, Lambda est conforme aux exigences SOC 1, SOC 2, SOC 3, PCI DSS, à la loi américaine sur la continuité et la responsabilité des soins de santé (HIPAA) et à d'autres réglementations. Ainsi, lorsque vous envisagez de mettre en œuvre une nouvelle application, envisagez le service AWS Lambda – il pourrait être parfaitement adapté à vos besoins.

Source : habr.com