{"id":37937,"date":"2019-10-31T22:20:41","date_gmt":"2019-10-31T19:20:41","guid":{"rendered":"https:\/\/prohoster.info\/blog\/detalnyj-razbor-aws-lambda\/"},"modified":"2019-10-31T22:20:41","modified_gmt":"2019-10-31T19:20:41","slug":"detalnyj-razbor-aws-lambda","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/detalnyj-razbor-aws-lambda","title":{"rendered":"Analyse d\u00e9taill\u00e9e d'AWS Lambda","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La traduction de l'article a \u00e9t\u00e9 pr\u00e9par\u00e9e sp\u00e9cialement pour les \u00e9tudiants du cours \u00abServices Cloud\u00bb<\/a><\/noindex>. Vous \u00eates int\u00e9ress\u00e9 \u00e0 d\u00e9velopper dans ce domaine ? Regardez le masterclass d'Egor Zuev (TeamLead chez InBit) \u00abService AWS EC2\u00bb<\/a><\/noindex> et rejoignez le prochain groupe du cours : d\u00e9but le 26 septembre. <\/em><\/p>\n

<\/p>\n

\"Analyse<\/p>\n

<\/p>\n

De plus en plus de personnes passent \u00e0 AWS Lambda pour sa scalabilit\u00e9, ses performances, ses \u00e9conomies et sa capacit\u00e9 \u00e0 traiter des millions, voire des trillions de requ\u00eates par mois. Il n'est pas n\u00e9cessaire de g\u00e9rer l'infrastructure sur laquelle le service fonctionne. L'auto-scaling permet de traiter des milliers de requ\u00eates simultan\u00e9es par seconde. Je pense qu'on peut \u00e0 juste titre consid\u00e9rer AWS Lambda comme l'un des services les plus demand\u00e9s d'AWS.<\/a><\/noindex><\/p>\n

<\/p>\n

AWS Lambda<\/h2>\n

<\/p>\n

AWS Lambda est un service de calcul sans serveur orient\u00e9 \u00e9v\u00e9nements, qui permet d'ex\u00e9cuter du code sans provisionner ni administrer des serveurs et de compl\u00e9ter d'autres services AWS en fonction de la logique utilisateur. Lambda r\u00e9agit automatiquement \u00e0 divers \u00e9v\u00e9nements (les fameux d\u00e9clencheurs), par exemple aux requ\u00eates HTTP via Amazon API Gateway, aux modifications de donn\u00e9es dans les compartiments Amazon S3 ou dans les tables Amazon DynamoDB ; ou vous pouvez ex\u00e9cuter votre code via des appels API, en utilisant AWS SDK et les transitions d'\u00e9tat dans AWS Step Functions.<\/p>\n

<\/p>\n

Lambda ex\u00e9cute le code sur une infrastructure de calcul hautement disponible et s'occupe enti\u00e8rement de l'administration de la plateforme sous-jacente, y compris la gestion des serveurs et du syst\u00e8me d'exploitation, la provision de ressources, l'auto-scaling, la surveillance du code et la gestion des logs. Vous n'avez donc qu'\u00e0 t\u00e9l\u00e9charger votre code et \u00e0 configurer comment et quand il doit \u00eatre ex\u00e9cut\u00e9. Le service se chargera de son ex\u00e9cution et garantira la haute disponibilit\u00e9 de votre application.<\/p>\n

<\/p>\n

Quand passer \u00e0 Lambda ?<\/h2>\n

<\/p>\n

AWS Lambda est une plateforme de calcul pratique, adapt\u00e9e \u00e0 de nombreux sc\u00e9narios d'utilisation, \u00e0 condition bien s\u00fbr que le langage et l'environnement d'ex\u00e9cution 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 \u00e0 un fournisseur tiers \u00e0 un co\u00fbt raisonnable, vous devriez d\u00e9finitivement passer \u00e0 AWS Lambda.<\/p>\n

<\/p>\n

Lambda est id\u00e9al pour cr\u00e9er des interfaces de programme, et si vous utilisez le service avec API Gateway, vous pouvez r\u00e9duire consid\u00e9rablement les co\u00fbts et acc\u00e9l\u00e9rer votre mise sur le march\u00e9. Il existe diff\u00e9rentes mani\u00e8res d'utiliser les fonctions Lambda et d'organiser une architecture sans serveur \u2014 chacun peut choisir quelque chose de adapt\u00e9 en fonction des objectifs fix\u00e9s.<\/p>\n

<\/p>\n

Lambda permet d'ex\u00e9cuter un large \u00e9ventail de t\u00e2ches. Gr\u00e2ce \u00e0 la prise en charge de CloudWatch, vous pouvez cr\u00e9er des t\u00e2ches planifi\u00e9es et automatiser certains processus. Il n'y a aucune restriction concernant la nature et l'intensit\u00e9 d'utilisation du service (seules la m\u00e9moire et le temps sont pris en compte), et rien ne vous emp\u00eache de travailler progressivement sur un microservice complet bas\u00e9 sur Lambda.<\/p>\n

<\/p>\n

Ici, vous pouvez cr\u00e9er des actions orient\u00e9es services qui ne s'ex\u00e9cutent pas en permanence. Un exemple typique est la mise \u00e0 l'\u00e9chelle des images. M\u00eame dans le cas de syst\u00e8mes distribu\u00e9s, les fonctions Lambda conservent leur pertinence.<\/p>\n

<\/p>\n

Ainsi, si vous ne souhaitez pas vous occuper de l'allocation et de l'administration des ressources informatiques \u2014 essayez AWS Lambda ; si vous n'avez pas besoin de calculs lourds et gourmands en ressources \u2014 essayez \u00e9galement AWS Lambda ; si votre code s'ex\u00e9cute p\u00e9riodiquement \u2014 vous avez raison, vous devriez essayer AWS Lambda.<\/p>\n

<\/p>\n

S\u00e9curit\u00e9<\/h2>\n

<\/p>\n

Pour l'instant, aucun probl\u00e8me de s\u00e9curit\u00e9 n'a \u00e9t\u00e9 signal\u00e9. D'autre part, \u00e9tant donn\u00e9 que de nombreux processus internes et caract\u00e9ristiques de mise en \u0153uvre de ce mod\u00e8le sont masqu\u00e9s pour l'utilisateur du runtime g\u00e9r\u00e9 d'AWS Lambda, certaines r\u00e8gles de s\u00e9curit\u00e9 cloud \u00e9tablies perdent de leur pertinence.<\/p>\n

<\/p>\n

Comme la plupart des services AWS, Lambda est fourni selon le principe de responsabilit\u00e9 partag\u00e9e entre AWS et le client en mati\u00e8re de s\u00e9curit\u00e9 et de conformit\u00e9. Ce principe r\u00e9duit la charge op\u00e9rationnelle pour le client, car AWS prend en charge les t\u00e2ches de maintenance, d'administration et de contr\u00f4le des composants du service \u2014 depuis le syst\u00e8me d'exploitation h\u00f4te et le niveau de virtualisation jusqu'\u00e0 la s\u00e9curit\u00e9 physique des infrastructures. <\/p>\n

<\/p>\n

En ce qui concerne sp\u00e9cifiquement AWS Lambda, AWS est responsable de la gestion de l'infrastructure sous-jacente, des services de base associ\u00e9s, du syst\u00e8me d'exploitation et de la plateforme d'applications. Tandis que le client est responsable de la s\u00e9curit\u00e9 de son code, du stockage des donn\u00e9es sensibles, du contr\u00f4le d'acc\u00e8s \u00e0 celles-ci, ainsi qu'au service et aux ressources Lambda (Identity and Access Management, IAM), y compris au sein des fonctions utilis\u00e9es.<\/p>\n

<\/p>\n

Le sch\u00e9ma ci-dessous pr\u00e9sente le mod\u00e8le de responsabilit\u00e9 partag\u00e9e applicable \u00e0 AWS Lambda. La zone de responsabilit\u00e9 d'AWS est color\u00e9e en orange, tandis que la responsabilit\u00e9 du client est en bleu. Comme vous pouvez le voir, AWS assume une plus grande part de responsabilit\u00e9 pour les applications d\u00e9ploy\u00e9es sur le service.<\/p>\n

<\/p>\n

\"Analyse<\/p>\n

<\/p>\n

Mod\u00e8le de responsabilit\u00e9 partag\u00e9e applicable \u00e0 AWS Lambda<\/em><\/p>\n

<\/p>\n

Environnement d'ex\u00e9cution Lambda<\/h3>\n

<\/p>\n

Le principal avantage de Lambda est que, en ex\u00e9cutant une fonction en votre nom, le service alloue lui-m\u00eame les ressources n\u00e9cessaires. Vous pouvez ainsi \u00e9viter de perdre du temps et de l'\u00e9nergie \u00e0 administrer les syst\u00e8mes et vous concentrer sur la logique m\u00e9tier et l'\u00e9criture de code.<\/p>\n

<\/p>\n

Le service Lambda est divis\u00e9 en deux plans. Le premier est le plan de gestion. Selon Wikip\u00e9dia, le plan de gestion (control plane) est la partie du r\u00e9seau responsable du transport du trafic de signalisation et de la routage. C'est le composant principal qui prend des d\u00e9cisions globales concernant l'allocation, la maintenance et la r\u00e9partition des charges de travail. De plus, le plan de gestion joue le r\u00f4le de topologie r\u00e9seau du fournisseur de solutions, responsable de la routage et de la gestion du trafic.<\/p>\n

<\/p>\n

Le deuxi\u00e8me plan est le plan de donn\u00e9es. Il a, tout comme le plan de gestion, ses propres t\u00e2ches. Le plan de gestion fournit une API pour g\u00e9rer les fonctions (CreateFunction, UpdateFunctionCode) et contr\u00f4le l'interaction de Lambda avec d'autres services AWS. Le plan de donn\u00e9es g\u00e8re les appels API (Invoke API) qui ex\u00e9cutent les fonctions Lambda. Apr\u00e8s l'appel de la fonction, le plan de gestion alloue ou choisit un environnement d'ex\u00e9cution existant, pr\u00e9alablement pr\u00e9par\u00e9 pour cette fonction, puis ex\u00e9cute le code dans celui-ci.<\/p>\n

<\/p>\n

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\u00e9cution correspondants. AWS les met r\u00e9guli\u00e8rement \u00e0 jour, distribue des correctifs de s\u00e9curit\u00e9 et effectue d'autres op\u00e9rations de maintenance sur ces environnements. Lambda permet d'utiliser d'autres langages \u00e0 condition que vous int\u00e9griez vous-m\u00eame l'environnement d'ex\u00e9cution appropri\u00e9. Vous devrez alors vous occuper de sa maintenance, y compris veiller \u00e0 la s\u00e9curit\u00e9.<\/p>\n

<\/p>\n

Comment tout cela fonctionne-t-il et comment le service ex\u00e9cutera-t-il vos fonctions ?<\/strong><\/p>\n

<\/p>\n

Chaque fonction s'ex\u00e9cute dans un ou plusieurs environnements isol\u00e9s, qui existent uniquement pendant le cycle de vie de cette fonction, puis sont d\u00e9truits. Dans chaque environnement, une seule invocation est ex\u00e9cut\u00e9e \u00e0 la fois, mais il est r\u00e9utilis\u00e9 s'il y a plusieurs invocations successives de la m\u00eame fonction. Tous les environnements d'ex\u00e9cution fonctionnent sur des machines virtuelles avec virtualisation mat\u00e9rielle, appel\u00e9es microVM. Chaque microVM est attribu\u00e9e \u00e0 un compte AWS sp\u00e9cifique et peut \u00eatre r\u00e9utilis\u00e9e par des environnements pour ex\u00e9cuter diff\u00e9rentes fonctions dans ce compte. Les microVM sont empaquet\u00e9es dans des blocs structurels de la plateforme mat\u00e9rielle Lambda Worker, d\u00e9tenue et g\u00e9r\u00e9e par AWS. Le m\u00eame environnement d'ex\u00e9cution ne peut pas \u00eatre utilis\u00e9 par diff\u00e9rentes fonctions, tout comme les microVM sont uniques pour diff\u00e9rents comptes AWS.<\/p>\n

<\/p>\n

\"Analyse<\/p>\n

<\/p>\n

Le mod\u00e8le d'isolation dans AWS Lambda<\/em><\/p>\n

<\/p>\n

L'isolation des environnements d'ex\u00e9cution est mise en \u0153uvre \u00e0 l'aide de plusieurs m\u00e9canismes. Au niveau le plus \u00e9lev\u00e9, chaque environnement poss\u00e8de des copies distinctes des composants suivants :<\/p>\n

<\/p>\n