Une traduction de l'article a été préparée spécialement pour les étudiants du cours Cloud Services . Est-il intéressant de se développer dans cette direction? Regardez une master class par Egor Zuev (TeamLead at InBit) «AWS EC2 Service» et rejoignez le groupe de cours le plus proche: commencez le 26 septembre.

De plus en plus de personnes passent à AWS Lambda pour l'évolutivité, les performances, les économies de coûts et la capacité de 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 fonctionne. Et la mise à l'échelle automatique vous permet de traiter des milliers de demandes simultanées par seconde. Je pense qu'AWS Lambda peut à juste titre être appelé l'un des services AWS les plus populaires.

AWS Lambda

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

Lambda exécute du code sur une infrastructure informatique hautement accessible 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'allocation des 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 une haute disponibilité de votre application.

Quand passer à Lambda?

AWS Lambda est une plate-forme informatique pratique adaptée à de nombreux scénarios d'application, bien sûr, si la langue et le temps d'exécution de votre code sont pris en charge par le service. Si vous souhaitez vous concentrer sur le code et la logique métier avec la maintenance, le provisionnement et la mise à l'échelle du serveur vers un fournisseur tiers pour un prix raisonnable, vous devez absolument passer à AWS Lambda.

Lambda est idéal pour créer des interfaces logicielles, et si vous utilisez le service avec la passerelle API, vous pouvez réduire considérablement les coûts et pénétrer le marché plus rapidement. Il existe différentes manières d'utiliser les fonctions et les options Lambda pour organiser une architecture sans serveur - chacun pourra choisir quelque chose qui conviendra en fonction de son objectif.

Lambda vous permet d'effectuer un large éventail de tâches. Ainsi, grâce à la prise en charge de CloudWatch, vous pouvez créer des tâches en attente et automatiser des processus individuels. Il n'y a pas de restrictions sur la nature et l'intensité d'utilisation du service (la consommation de 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 sont pas constamment effectuées. Un exemple typique est la mise à l'échelle de l'image. Même dans le cas de systèmes distribués, les fonctions Lambda ne perdent pas leur pertinence.

Donc, si vous ne souhaitez pas vous lancer dans l'allocation et l'administration des ressources informatiques, essayez AWS Lambda; si vous n'avez pas besoin d'une informatique lourde et gourmande en ressources, essayez également AWS Lambda; si votre code s'exécute périodiquement - tout est correct, vous devriez essayer AWS Lambda.

La sécurité

Jusqu'à présent, il n'y a aucune plainte concernant la sécurité. En revanche, étant donné que de nombreux processus internes et fonctionnalités d'implémentation de ce modèle sont cachés à l'utilisateur du runtime géré AWS Lambda, certaines règles de sécurité cloud généralement acceptées ne sont plus pertinentes.

Comme la plupart des services AWS, Lambda est fourni sur la base d'une responsabilité partagée entre AWS et le client en matière de sécurité et de conformité réglementaire. Ce principe réduit la charge opérationnelle du client, car AWS assume les tâches de maintenance, d'administration et de contrôle des composants du service - du système d'exploitation hôte et du niveau de virtualisation à la sécurité physique des objets d'infrastructure.

S'agissant spécifiquement d'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'application. Si le client est responsable de la sécurité de son code, du stockage des données confidentielles, du contrôle d'accès à ces derniers, ainsi qu'aux services et ressources de Lambda (Identity and Access Management, IAM), y compris dans le cadre des fonctions utilisées.

Le diagramme ci-dessous montre le modèle de responsabilité partagée applicable à AWS Lambda. La zone de responsabilité d'AWS est orange et la responsabilité du client est bleue. Comme vous pouvez le voir, AWS prend plus de responsabilité pour les applications déployées sur le service.

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

Lambda Runtime

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

Le service Lambda est divisé en deux avions. Le premier est le plan de contrôle. Selon Wikipedia, le plan de contrôle est la partie du réseau qui est responsable de la signalisation du trafic et du routage. C'est le principal composant qui prend des décisions globales concernant l'allocation, la maintenance et la répartition des charges de travail. De plus, le plan de contrôle agit comme la topologie réseau du fournisseur de solutions, qui est responsable du routage et de la gestion du trafic.

Le deuxième plan est le plan de données. Comme le plan de contrôle, il a 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 est contrôlé par l'API Invoke, qui appelle les fonctions Lambda. Après avoir appelé la fonction, le plan de contrôle sélectionne ou sélectionne le runtime existant préparé à l'avance pour cette fonction, puis y exécute le code.

AWS Lambda prend en charge de nombreux langages de programmation, notamment Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2 et d'autres, via leurs environnements d'exécution respectifs. AWS les met à jour régulièrement, distribue des correctifs de sécurité et effectue d'autres opérations de maintenance sur ces environnements. Lambda vous permet d'utiliser d'autres langues, à condition que vous implémentiez vous-même le runtime approprié. Et puis vous devrez vous occuper de sa maintenance, y compris la surveillance de la sécurité.

Comment tout cela fonctionne-t-il et comment le service remplira-t-il vos fonctions?

Chaque fonction fonctionne dans un ou plusieurs environnements sélectionnés qui n'existent que pendant le cycle de vie de cette fonction, puis sont détruits. Dans chaque environnement, un seul appel est effectué à la fois, mais il est réutilisé s'il existe de nombreux appels série de la même fonction. Tous les runtimes s'exécutent sur des machines virtuelles avec virtualisation matérielle - sur le soi-disant microVM. Chaque microVM est affectée à un compte AWS spécifique et peut être réutilisée par les environnements pour exécuter diverses fonctions sur ce compte. Les microVM sont regroupés dans les blocs de construction de la plate-forme matérielle Lambda Worker, qu'AWS possède et exploite. Le même runtime ne peut pas être utilisé par différentes fonctions, tout comme les microVM sont uniques à différents comptes AWS.

Modèle d'isolement AWS Lambda

L'isolation d'exécution est implémentée à l'aide de plusieurs mécanismes. Au niveau le plus élevé de chaque environnement, il existe des copies distinctes des composants suivants:

• Code de fonction
• Toutes les couches Lambda sélectionnées pour la fonction
• Exécution de la fonction
• Espace utilisateur minimum d'Amazon Linux

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

• cgroups - restriction de l'accès aux ressources CPU, à la mémoire, à la bande passante du lecteur et au réseau pour chaque environnement d'exécution;
• espaces de noms - regroupement des ID de processus, des ID 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 - restriction des appels système pouvant être utilisés dans l'environnement d'exécution;
• iptables et tables de routage - isolation des environnements d'exécution entre eux;
• chroot - offre un accès limité au système de fichiers sous-jacent.

Combinés à la technologie d'isolation AWS propriétaire, ces mécanismes garantissent une séparation fiable des environnements d'exécution. Les supports ainsi isolés ne peuvent pas accéder ni modifier les données d'autres supports.

Bien que plusieurs runtimes du même compte AWS puissent s'exécuter sur la même microVM, en aucun cas les microVM ne peuvent être partagés entre différents comptes AWS. AWS Lambda utilise seulement deux mécanismes pour isoler les microVM: les instances EC2 et Firecracker. L'isolement des invités dans Lambda sur la base des instances EC2 est utilisé depuis 2015. Firecracker est le nouvel hyperviseur open source spécialement conçu par AWS pour les charges de travail sans serveur et introduit en 2018. L'équipement physique sur lequel les microVM s'exécutent est partagé entre les charges de travail de différents comptes.

Enregistrement des environnements et des états de processus

Bien que les exécutions Lambda soient uniques pour différentes fonctions, elles peuvent appeler à plusieurs reprises la même fonction, c'est-à-dire que l'exécution peut durer plusieurs heures avant d'être détruite.

Chaque runtime Lambda possède également un système de fichiers de droits d'écriture, accessible via le répertoire / tmp. Son contenu n'est pas accessible depuis d'autres runtimes. Concernant la conservation des états de processus, les fichiers enregistrés dans / tmp existent tout au long du cycle de vie du runtime. De ce fait, il est possible d'accumuler les résultats de plusieurs appels, ce qui est particulièrement utile pour des 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: en mode événement et en mode demande-réponse. En mode événement, l'appel est ajouté à la file d'attente pour une exécution ultérieure. En mode "demande-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 est exécutée dans l'environnement Lambda, mais avec différents chemins de charge utile.

Lors des appels de réponse à la demande, la charge utile provient de l'API de traitement des demandes (appelant API), comme la passerelle API AWS ou le kit SDK AWS, à l'équilibreur de charge, puis au service d'exécution des appels Lambda (service d'appel). Ce dernier détermine l'environnement approprié pour exécuter la fonction et y transfère la charge utile pour terminer l'appel. L'équilibreur de charge reçoit du trafic avec une protection TLS sur Internet. Le trafic au sein du service Lambda - après l'équilibreur de charge - passe par le VPC interne dans une région AWS spécifique.

Modèle de traitement des appels AWS Lambda: mode demande-réponse

Les appels d'événement peuvent être effectués immédiatement ou ajoutés à la file d'attente. Dans certains cas, la file d'attente est implémentée à l'aide du service Amazon SQS (Amazon Simple Queue Service), qui transfère les appels au service d'exécution des appels Lambda via un processus d'interrogation interne. Le trafic transmis est protégé par TLS, et aucun cryptage supplémentaire des données stockées dans Amazon SQS n'est fourni.

Les appels d'événement ne renvoient pas de réponses - Lambda Worker ignore simplement les informations de réponse. Les appels basés sur Amazon S3, Amazon SNS, CloudWatch et d'autres sources sont traités par Lambda en mode événement. Les appels provenant des flux Amazon Kinesis et DynamoDB, les appels des files d'attente SQS, l'équilibreur de charge d'application et les API de passerelle sont gérés en mode réponse-demande.

Suivi

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

Amazon cloudwatch
Il recueille diverses statistiques, telles que le nombre de demandes, la durée des demandes et le nombre de demandes qui ont échoué.

Amazon CloudTrail
Vous permet de vous connecter, de surveiller en continu et d'enregistrer les informations sur l'activité du compte associées à votre infrastructure AWS. Vous disposerez d'une chronologie complète des actions effectuées à l'aide d'AWS Management Console, du SDK AWS, des outils de ligne de commande et d'autres services AWS.

AWS X-Ray
Fournit une visibilité complète de toutes les étapes du traitement des demandes dans votre application sur la base d'une carte de ses composants internes. Vous permet d'analyser les applications pendant le développement et dans l'environnement de production.

AWS Config
Vous pourrez suivre les modifications apportées à la configuration des fonctions Lambda (y compris leur suppression) et les temps d'exécution, les balises, les noms des gestionnaires, la taille du code, l'allocation de mémoire, les paramètres de latence et de concurrence, ainsi que le rôle d'exécution Lambda IAM, le sous-réseau et les liaisons de groupe 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é réglementaire dans AWS Lambda ne sont pas différentes de celles utilisées dans d'autres services AWS, bien qu'il existe des exceptions. Depuis mars 2019, Lambda est conforme à SOC 1, SOC 2, SOC 3, PCI DSS, à la loi américaine Health Insurance Continuity and Accountability Act (HIPAA) et à d'autres réglementations. Par conséquent, lorsque vous pensez à implémenter une autre application, pensez au service AWS Lambda - il est peut-être le mieux adapté à votre tâche.