La traduko de la artikolo estis preparita specife por la kursanoj . Ĉu vi interesas disvolvi ĉi tiun direkton? Spektu la majstran klason de Egor Zuev (TeamLead ĉe InBit) kaj aliĝu al la sekva kursgrupo: komenciĝas la 26-an de septembro.
Pli da homoj migras al AWS Lambda por skaleblo, rendimento, ŝparado kaj la kapablo trakti milionojn aŭ eĉ duilionojn da petoj monate. Por fari tion, vi ne bezonas administri la infrastrukturon, sur kiu funkcias la servo. Kaj aŭtoskalo permesas vin servi milojn da samtempaj petoj je sekundo. Mi pensas, ke AWS Lambda prave povas esti nomita unu el la plej popularaj AWS-servoj.
AWS Lambda
AWS Lambda estas evento-movita senservila komputika servo, kiu ebligas al vi ruli kodon sen provizi aŭ administri servilojn kaj etendi aliajn AWS-servojn uzante kutiman logikon. Lambda aŭtomate respondas al diversaj eventoj (nomitaj ellasiloj), kiel HTTP-petoj per Amazon API Gateway, ŝanĝoj al datumoj en Amazon S3 siteloj aŭ Amazon DynamoDB-tabloj; aŭ vi povas ruli vian kodon per API-vokoj uzante la AWS SDK kaj ŝtatajn transirojn en AWS Step Functions.
Lambda prizorgas kodon sur tre disponebla komputika infrastrukturo kaj plene respondecas pri administrado de la subesta platformo, inkluzive de prizorgado de servilo kaj operaciumo, provizado de rimedoj, aŭtomata skalo, koda monitorado kaj protokolo. Tio estas, vi nur bezonas alŝuti vian kodon kaj agordi kiel kaj kiam ĝi estu ekzekutita. Siavice, la servo zorgos pri sia lanĉo kaj certigos altan haveblecon de via aplikaĵo.
Kiam ŝanĝi al Lambda?
AWS Lambda estas oportuna komputika platformo, kiu taŭgas por diversaj uzkazoj, kondiĉe ke la lingvo kaj rultempo de via kodo estas subtenataj de la servo. Se vi volas koncentriĝi pri via kodo kaj komerca logiko dum subkontraktado de servila prizorgado, provizo kaj skalo je racia kosto, AWS Lambda estas sendube la vojo por iri.
Lambda estas ideala por krei programajn interfacojn, kaj kiam uzata kune kun API Gateway, vi povas signife redukti kostojn kaj atingi la merkaton pli rapide. Estas malsamaj manieroj uzi Lambda-funkciojn kaj opciojn por organizi senservila arkitekturo - ĉiu povas elekti ion taŭgan laŭ sia celo.
Lambda permesas al vi plenumi ampleksan gamon de taskoj. Tiel, danke al CloudWatch-subteno, vi povas krei prokrastitajn taskojn kaj aŭtomatigi individuajn procezojn. Ne estas limigoj pri la naturo kaj intenseco de uzo de la servo (memorkonsumo kaj tempo estas konsiderataj), kaj nenio malhelpas vin sisteme labori pri plenrajta mikroservo bazita sur Lambda.
Ĉi tie vi povas krei servo-orientitajn agojn, kiuj ne funkcias senĉese. Tipa ekzemplo estas bildskalo. Eĉ en la kazo de distribuitaj sistemoj, Lambda funkcioj restas gravaj.
Do, se vi ne volas trakti asignadon kaj administradon de komputikaj rimedoj, provu AWS Lambda; se vi ne bezonas pezajn, riĉegajn kalkulojn, provu ankaŭ AWS Lambda; se via kodo funkcias periode, ĝuste, vi devus provi AWS Lambda.
Sekureco
Ĝis nun ne estas plendoj pri sekureco. Aliflanke, ĉar multaj el la internaj procezoj kaj efektivigaj funkcioj de ĉi tiu modelo estas kaŝitaj de la uzanto de la AWS Lambda administrita rultempa medio, iuj ĝenerale akceptitaj reguloj de nuba sekureco fariĝas sensignivaj.
Kiel plej multaj AWS-servoj, Lambda estas provizita laŭ komuna sekureco kaj konformeco inter AWS kaj la kliento. Ĉi tiu principo reduktas la funkcian ŝarĝon sur la kliento, ĉar AWS prenas la taskojn pri konservado, administrado kaj monitorado de servokomponentoj - de la mastruma mastruma sistemo kaj la virtualiga tavolo ĝis la fizika sekureco de infrastrukturaj aktivoj.
Specife parolante pri AWS Lambda, AWS respondecas pri administrado de la subesta infrastrukturo, rilataj subaj servoj, operaciumo kaj aplika platformo. Dum la kliento respondecas pri la sekureco de sia kodo, konservante konfidencajn datumojn, kontrolante aliron al ĝi, same kiel al la Lambda-servo kaj rimedoj (Identeco kaj Aliro-Administrado, IAM), inkluzive ene de la limoj de la uzataj funkcioj.
La diagramo malsupre montras la kundividan respondecmodelon kiel ĝi validas por AWS Lambda. AWS-Respondeco estas oranĝa kaj Klienta respondeco estas blua. Kiel vi povas vidi, AWS prenas pli da respondeco pri la aplikoj deplojitaj sur la servo.
Komuna Respondec-Modelo Aplika al AWS Lambda
Lambda rultempo
La ĉefa avantaĝo de Lambda estas, ke plenumante funkcion en via nomo, la servo mem asignas la necesajn rimedojn. Vi povas eviti malŝpari tempon kaj penadon pri sistema administrado kaj koncentriĝi pri komerca logiko kaj kodigo.
La Lambda servo estas dividita en du aviadilojn. La unua estas la kontrolaviadilo. Laŭ Vikipedio, la kontrolaviadilo estas la parto de la reto respondeca por transporto de signala trafiko kaj vojigo. Ĝi estas la ĉefa komponanto, kiu faras tutmondajn decidojn pri provizado, servado kaj distribuado de laborŝarĝoj. Krome, la kontrolaviadilo funkcias kiel la retotopologio de la solvprovizanto, respondeca por vojigo kaj administrado de trafiko.
La dua ebeno estas la datuma ebeno. Ĝi, kiel la kontrolaviadilo, havas siajn proprajn taskojn. La kontrolaviadilo disponigas APIojn por administri funkciojn (CreateFunction, UpdateFunctionCode) kaj kontrolas kiel Lambda komunikas kun aliaj AWS-servoj. La datumaviadilo kontrolas la Invoke API, kiu funkciigas Lambda-funkciojn. Post kiam funkcio estas vokita, la kontrolaviadilo asignas aŭ elektas ekzistantan rultempan medion kiu estas antaŭpreparita por tiu funkcio, kaj tiam efektivigas la kodon en ĝi.
AWS Lambda subtenas diversajn programlingvojn, inkluzive de Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2, kaj aliajn, per siaj respektivaj rultempaj medioj. AWS regule ĝisdatigas ilin, distribuas sekurecajn diakilojn kaj faras aliajn prizorgajn agadojn en ĉi tiuj medioj. Lambda permesas vin uzi ankaŭ aliajn lingvojn, kondiĉe ke vi mem efektivigas la taŭgan rultempon. Kaj tiam vi devos prizorgi ĝian bontenadon, inkluzive de kontrolado de ĝia sekureco.
Kiel ĉio funkcias kaj kiel la servo plenumos viajn funkciojn?
Ĉiu funkcio funkcias en unu aŭ pluraj dediĉitaj medioj, kiuj ekzistas nur por la vivo de tiu funkcio kaj tiam estas detruitaj. Ĉiu medio faras nur unu vokon samtempe, sed ĝi estas reuzata se ekzistas pluraj seriaj vokoj al la sama funkcio. Ĉiuj rultempaj medioj funkcias per virtualaj maŝinoj kun aparatara virtualigo - tiel nomataj mikroVMoj. Ĉiu mikroVM estas asignita al specifa AWS-konto kaj povas esti reuzita de medioj por plenumi malsamajn funkciojn ene de tiu konto. MicroVMs estas enpakitaj en konstrubriketojn de la aparataro Lambda Worker, kiu estas posedata kaj operaciita de AWS. La sama rultempo ne povas esti uzata de malsamaj funkcioj, nek mikroVM-oj estas unikaj al malsamaj AWS-kontoj.
AWS Lambda Izola Modelo
Izoliĝo de rultempaj medioj estas efektivigita uzante plurajn mekanismojn. Ĉe la pinta nivelo de ĉiu medio ekzistas apartaj kopioj de la sekvaj komponentoj:
- Funkcia kodo
- Ajna Lambda tavoloj elektitaj por la funkcio
- Funkcia ekzekuta medio
- Minimuma uzantspaco bazita sur Amazon Linukso
La sekvaj mekanismoj estas uzataj por izoli malsamajn ekzekutmediojn:
- cgroups - limigi aliron al CPU, memoro, stokado kaj retaj rimedoj por ĉiu rultempa medio;
- nomspacoj - grupigprocezidentigiloj, uzantidentigiloj, retaj interfacoj kaj aliaj rimedoj administritaj de la Linukso-kerno. Ĉiu rultempo funkcias en sia propra nomspaco;
- seccomp-bpf - limigas la sistemvokojn uzeblajn en la rultempo;
- iptables and routing tables - izolado de ekzekutmedioj unu de la alia;
- chroot - provizas limigitan aliron al la subesta dosiersistemo.
Kombinite kun AWS-propraj izolaj teknologioj, ĉi tiuj mekanismoj certigas fidindan rultempan apartigon. Medioj izolitaj tiamaniere ne povas aliri aŭ modifi datumojn de aliaj medioj.
Kvankam pluraj rultempoj de la sama AWS-konto povas funkcii per ununura mikroVM, sub neniuj cirkonstancoj mikroVM-oj povas esti dividitaj inter malsamaj AWS-kontoj. AWS Lambda uzas nur du mekanismojn por izoli mikroVMojn: EC2-instancoj kaj Firecracker. Gastizoliĝo en Lambda bazita sur EC2-kazoj ekzistas ekde 2015. Firecracker estas nova malfermfonta hiperviziero specife desegnita de AWS por senservilaj laborŝarĝoj kaj lanĉita en 2018. La fizika aparataro prizorganta mikroVM-ojn estas dividita inter laborkvantoj tra malsamaj kontoj.
Konservado de medioj kaj procezaj statoj
Kvankam Lambda rultempoj estas unikaj al malsamaj funkcioj, ili povas voki la saman funkcion plurfoje, signifante ke la rultempo povas pluvivi dum pluraj horoj antaŭ esti detruita.
Ĉiu Lambda rultempo ankaŭ havas skribeblan dosiersistemon alireblan per la dosierujo /tmp. Ĝia enhavo ne estas alirebla de aliaj rultempoj. Koncerne al proceza stato-persisto, dosieroj skribitaj al /tmp ekzistas por la tuta vivociklo de la rultempa medio. Ĉi tio ebligas amasigi la rezultojn de multoblaj vokoj, kio estas speciale utila por multekostaj operacioj kiel ŝarĝi maŝinlernajn modelojn.
Voku transdono de datumoj
La Invoke API povas esti uzata en du reĝimoj: eventoreĝimo kaj peto-responda reĝimo. En okazaĵreĝimo, la voko estas aldonita al atendovico por pli posta ekzekuto. En peto-responda reĝimo, la funkcio estas tuj vokita kun la provizita utila ŝarĝo, post kiu la respondo estas resendita. En ambaŭ kazoj, la funkcio funkcias en Lambda medio, sed kun malsamaj utilaj padoj.
Dum peto-respondaj vokoj, la utila ŝarĝo fluas de peto-pretiga API (API-Alvokanto), kiel AWS API Gateway aŭ AWS SDK, al la ŝarĝbalancilo, kaj poste al la Lambda alvoka servo (Invoke Service). Ĉi-lasta determinas la taŭgan medion por ekzekuti la funkcion kaj pasas la utilan ŝarĝon tie por kompletigi la vokon. La ŝarĝbalancilo ricevas TLS-protektan trafikon tra la Interreto. Trafiko ene de la Lambda servo—post la ŝarĝo-balancilo—trapasas internan VPC en specifa AWS-regiono.
AWS Lambda Voka Pretiga Modelo: Peto-Responda Reĝimo
Eventvokoj povas esti faritaj tuj aŭ aldonitaj al atendovico. En kelkaj kazoj, la atendovico estas efektivigita uzante Amazon SQS (Amazon Simple Queue Service), kiu pasas vokojn al la Lambda voka plenumservo per interna balotprocezo. La elsendita trafiko estas protektita de TLS, kaj ne ekzistas plia ĉifrado de datumoj stokitaj en Amazon SQS.
Eventaj vokoj ne resendas respondojn—la Lambda Laboristo simple ignoras ajnajn respondinformojn. Okazaĵ-bazitaj vokoj de Amazon S3, Amazon SNS, CloudWatch kaj aliaj fontoj estas procesitaj de Lambda en eventoreĝimo. Vokoj de Amazon Kinesis kaj DynamoDB-riveretoj, SQS-vostoj, Application Load Balancer kaj API Gateway-vokoj estas procesitaj laŭ peto-responda maniero.
Monitorado
Vi povas kontroli kaj revizii Lambda-funkciojn uzante diversajn mekanismojn kaj servojn de AWS, inkluzive de la jenaj.
Amazon CloudWatch
Kolektas diversajn statistikojn kiel la nombro da petoj, la daŭro de petoj kaj la nombro da petoj malsukcesintaj.
Amazon CloudTrail
Permesas vin ensaluti, kontinue monitori kaj konservi informojn pri kontagado asociitaj kun via AWS-infrastrukturo. Vi havos kompletan historion de agoj faritaj per la AWS-Administra Konzolo, AWS SDK, komandliniaj iloj kaj aliaj AWS-servoj.
AWS X-radio
Provizas kompletan videblecon en ĉiuj stadioj de peto-traktado en via aplikaĵo bazita sur mapo de ĝiaj internaj komponentoj. Permesas al vi analizi aplikojn dum evoluo kaj en produktadmedioj.
AWS-Agordo
Vi povos spuri ŝanĝojn al Lambda-funkcia agordo (inkluzive de forigo) kaj rultempoj, etikedoj, pritraktilnomoj, kodgrandeco, memor-atribuo, tempofinaj agordoj kaj samtempaj agordoj, same kiel Lambda IAM-ekzekuta rolo, subreto kaj sekurecaj grupaj ligoj. .
konkludo
AWS Lambda ofertas potencan aron da iloj por konstrui sekurajn kaj skaleblajn aplikojn. Multaj el la sekurecaj kaj plenumaj praktikoj en AWS Lambda estas la samaj kiel en aliaj AWS-servoj, kvankam ekzistas esceptoj. Ekde marto 2019, Lambda konformas al SOC 1, SOC 2, SOC 3, PCI DSS, Sanasekuro-Portebleco kaj Respondigleĝo (HIPAA) kaj aliaj regularoj. Do, kiam vi pensas pri efektivigo de via sekva aplikaĵo, konsideru la AWS Lambda servon - ĝi eble estas la plej taŭga por via tasko.
fonto: www.habr.com