Ang pagsasalin ng artikulo ay partikular na inihanda para sa mga mag-aaral ng kurso . Interesado sa pagbuo sa direksyong ito? Panoorin ang master class ni Egor Zuev (TeamLead sa InBit) at sumali sa susunod na grupo ng kurso: magsisimula sa Setyembre 26.
Mas maraming tao ang lumilipat sa AWS Lambda para sa scalability, performance, pagtitipid, at kakayahang pangasiwaan ang milyun-milyon o kahit trilyong mga kahilingan kada buwan. Upang gawin ito, hindi mo kailangang pamahalaan ang imprastraktura kung saan tumatakbo ang serbisyo. At binibigyang-daan ka ng autoscaling na maghatid ng libu-libong sabay-sabay na kahilingan sa bawat segundo. Sa tingin ko, ang AWS Lambda ay maaaring matawag na isa sa pinakasikat na serbisyo ng AWS.
AWS Lambda
Ang AWS Lambda ay isang serbisyo ng serverless computing na hinimok ng kaganapan na nagbibigay-daan sa iyong magpatakbo ng code nang walang provisioning o pamamahala ng mga server at palawigin ang iba pang mga serbisyo ng AWS gamit ang custom na logic. Awtomatikong tumutugon ang Lambda sa iba't ibang kaganapan (tinatawag na mga trigger), tulad ng mga kahilingan sa HTTP sa pamamagitan ng Amazon API Gateway, mga pagbabago sa data sa mga bucket ng Amazon S3 o mga talahanayan ng Amazon DynamoDB; o maaari mong patakbuhin ang iyong code sa pamamagitan ng mga tawag sa API gamit ang AWS SDK at mga transition ng estado sa AWS Step Functions.
Ang Lambda ay nagpapatakbo ng code sa isang lubos na magagamit na imprastraktura ng computing at ganap na responsable para sa pangangasiwa sa pinagbabatayan na platform, kabilang ang pagpapanatili ng server at operating system, pagbibigay ng mapagkukunan, auto-scaling, pagsubaybay sa code, at pag-log. Ibig sabihin, kailangan mo lang i-upload ang iyong code at i-configure kung paano at kailan ito dapat isagawa. Sa turn, ang serbisyo ang bahala sa paglulunsad nito at titiyakin ang mataas na kakayahang magamit ng iyong aplikasyon.
Kailan lumipat sa Lambda?
Ang AWS Lambda ay isang maginhawang platform ng computing na angkop para sa iba't ibang sitwasyon ng paggamit, hangga't ang wika at runtime ng iyong code ay sinusuportahan ng serbisyo. Kung gusto mong tumuon sa iyong code at lohika ng negosyo habang nag-outsourcing sa pagpapanatili, pag-provision, at pag-scale ng server sa isang makatwirang halaga, tiyak na ang AWS Lambda ang dapat gawin.
Ang Lambda ay mainam para sa paglikha ng mga interface ng programming, at kapag ginamit kasabay ng API Gateway, maaari mong makabuluhang bawasan ang mga gastos at mas mabilis na makapunta sa merkado. Mayroong iba't ibang paraan upang magamit ang mga function at opsyon ng Lambda para sa pag-aayos ng isang walang server na arkitektura - lahat ay maaaring pumili ng bagay na angkop batay sa kanilang layunin.
Binibigyang-daan ka ng Lambda na magsagawa ng malawak na hanay ng mga gawain. Kaya, salamat sa suporta ng CloudWatch, maaari kang lumikha ng mga ipinagpaliban na gawain at i-automate ang mga indibidwal na proseso. Walang mga paghihigpit sa uri at intensity ng paggamit ng serbisyo (ang pagkonsumo ng memory at oras ay isinasaalang-alang), at walang pumipigil sa iyo na sistematikong magtrabaho sa isang ganap na microservice batay sa Lambda.
Dito maaari kang lumikha ng mga aksyon na nakatuon sa serbisyo na hindi patuloy na tumatakbo. Ang karaniwang halimbawa ay ang pag-scale ng imahe. Kahit na sa kaso ng mga distributed system, nananatiling may-katuturan ang mga function ng Lambda.
Kaya, kung ayaw mong makitungo sa paglalaan at pamamahala ng mga mapagkukunan ng computing, subukan ang AWS Lambda; kung hindi mo kailangan ng mabibigat, masinsinang pagkalkula ng mapagkukunan, subukan din ang AWS Lambda; kung pana-panahong tumatakbo ang iyong code, tama, dapat mong subukan ang AWS Lambda.
katiwasayan
Sa ngayon ay walang mga reklamo tungkol sa kaligtasan. Sa kabilang banda, dahil marami sa mga panloob na proseso at tampok sa pagpapatupad ng modelong ito ay nakatago mula sa gumagamit ng AWS Lambda na pinapamahalaan na runtime environment, ang ilang karaniwang tinatanggap na mga panuntunan ng seguridad sa ulap ay nagiging hindi nauugnay.
Tulad ng karamihan sa mga serbisyo ng AWS, ibinibigay ang Lambda sa isang nakabahaging seguridad at batayan sa pagsunod sa pagitan ng AWS at ng customer. Binabawasan ng prinsipyong ito ang pasanin sa pagpapatakbo sa kliyente, dahil ginagawa ng AWS ang mga gawain ng pagpapanatili, pangangasiwa at pagsubaybay sa mga bahagi ng serbisyo - mula sa host operating system at layer ng virtualization hanggang sa pisikal na seguridad ng mga asset ng imprastraktura.
Partikular na pinag-uusapan ang tungkol sa AWS Lambda, ang AWS ay responsable para sa pamamahala sa pinagbabatayan na imprastraktura, mga nauugnay na pinagbabatayan na serbisyo, operating system, at platform ng application. Habang ang kliyente ay may pananagutan para sa seguridad ng kanyang code, pag-iimbak ng kumpidensyal na data, pagkontrol sa pag-access dito, pati na rin sa serbisyo at mapagkukunan ng Lambda (Identity and Access Management, IAM), kabilang ang sa loob ng mga limitasyon ng mga function na ginamit.
Ipinapakita ng diagram sa ibaba ang modelo ng shared responsibility habang nalalapat ito sa AWS Lambda. Ang Responsibilidad ng AWS ay kulay kahel at ang Responsibilidad ng Customer ay asul. Gaya ng nakikita mo, mas responsable ang AWS para sa mga application na naka-deploy sa serbisyo.
Nakabahaging Modelo ng Pananagutan na Naaangkop sa AWS Lambda
Lambda runtime
Ang pangunahing bentahe ng Lambda ay sa pamamagitan ng pagsasagawa ng isang function para sa iyo, ang serbisyo mismo ay naglalaan ng mga kinakailangang mapagkukunan. Maiiwasan mo ang pag-aaksaya ng oras at pagsisikap sa pangangasiwa ng system at tumuon sa lohika at coding ng negosyo.
Ang serbisyo ng Lambda ay nahahati sa dalawang eroplano. Ang una ay ang control plane. Ayon sa Wikipedia, ang control plane ay bahagi ng network na responsable para sa pagdadala ng signaling traffic at routing. Ito ang pangunahing bahagi na gumagawa ng mga pandaigdigang desisyon tungkol sa pagbibigay, paglilingkod, at pamamahagi ng mga workload. Bilang karagdagan, ang control plane ay gumaganap bilang topology ng network ng provider ng solusyon, na responsable para sa pagruruta at pamamahala ng trapiko.
Ang pangalawang eroplano ay ang data plane. Ito, tulad ng control plane, ay may sariling mga gawain. Nagbibigay ang control plane ng mga API para sa pamamahala ng mga function (CreateFunction, UpdateFunctionCode) at kinokontrol kung paano nakikipag-ugnayan ang Lambda sa ibang mga serbisyo ng AWS. Kinokontrol ng data plane ang Invoke API, na nagpapatakbo ng mga function ng Lambda. Pagkatapos tawagin ang isang function, ang control plane ay naglalaan o pumipili ng isang umiiral na runtime environment na paunang inihanda para sa function na iyon, at pagkatapos ay ipapatupad ang code sa loob nito.
Sinusuportahan ng AWS Lambda ang iba't ibang programming language, kabilang ang Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2, at iba pa, sa pamamagitan ng kani-kanilang runtime environment. Regular na ina-update ng AWS ang mga ito, namamahagi ng mga patch ng seguridad, at nagsasagawa ng iba pang aktibidad sa pagpapanatili sa mga kapaligirang ito. Pinapayagan ka ng Lambda na gumamit din ng iba pang mga wika, kung ikaw mismo ang magpapatupad ng naaangkop na runtime. At pagkatapos ay kailangan mong pangalagaan ang pagpapanatili nito, kabilang ang pagsubaybay sa kaligtasan nito.
Paano gumagana ang lahat ng ito at paano gagawin ng serbisyo ang iyong mga function?
Gumagana ang bawat function sa isa o higit pang nakatuong kapaligiran, na umiiral lamang para sa buhay ng function na iyon at pagkatapos ay masisira. Ang bawat kapaligiran ay gumagawa lamang ng isang tawag sa isang pagkakataon, ngunit ito ay muling ginagamit kung mayroong maraming mga serial na tawag sa parehong function. Ang lahat ng runtime environment ay tumatakbo sa mga virtual machine na may hardware virtualization - tinatawag na microVMs. Ang bawat microVM ay itinalaga sa isang partikular na AWS account at maaaring magamit muli ng mga kapaligiran upang magsagawa ng iba't ibang mga function sa loob ng account na iyon. Ang mga MicroVM ay naka-package sa mga building block ng Lambda Worker hardware platform, na pagmamay-ari at pinapatakbo ng AWS. Ang parehong runtime ay hindi maaaring gamitin ng iba't ibang function, at hindi rin natatangi ang mga microVM sa iba't ibang AWS account.
AWS Lambda Isolation Model
Ang paghihiwalay ng mga runtime na kapaligiran ay ipinatupad gamit ang ilang mga mekanismo. Sa pinakamataas na antas ng bawat kapaligiran ay may hiwalay na mga kopya ng mga sumusunod na bahagi:
- Code ng pag-andar
- Anumang Lambda layer na pinili para sa function
- Kapaligiran ng pagpapatupad ng function
- Minimal na espasyo ng user batay sa Amazon Linux
Ang mga sumusunod na mekanismo ay ginagamit upang ihiwalay ang iba't ibang mga kapaligiran ng pagpapatupad:
- cgroups - limitahan ang access sa CPU, memorya, storage at network resources para sa bawat runtime environment;
- namespaces - pagpapangkat ng mga process ID, user ID, network interface at iba pang mapagkukunan na pinamamahalaan ng Linux kernel. Ang bawat runtime ay tumatakbo sa sarili nitong namespace;
- seccomp-bpf - nililimitahan ang mga tawag sa system na maaaring magamit sa runtime;
- iptables at routing tables - paghihiwalay ng execution environment sa isa't isa;
- chroot - nagbibigay ng limitadong access sa pinagbabatayan na file system.
Kasama ng AWS proprietary isolation technologies, tinitiyak ng mga mekanismong ito ang maaasahang runtime separation. Ang mga kapaligirang nakahiwalay sa ganitong paraan ay hindi makaka-access o makakapagbago ng data mula sa ibang mga kapaligiran.
Bagama't maraming runtime ng parehong AWS account ang maaaring tumakbo sa isang microVM, sa ilalim ng anumang pagkakataon ay maaaring ibahagi ang mga microVM sa pagitan ng iba't ibang AWS account. Gumagamit lang ang AWS Lambda ng dalawang mekanismo para ihiwalay ang mga microVM: EC2 instance at Firecracker. Ang paghihiwalay ng bisita sa Lambda batay sa mga instance ng EC2 ay umiikot na mula noong 2015. Ang Firecracker ay isang bagong open source hypervisor na partikular na idinisenyo ng AWS para sa mga walang server na workload at ipinakilala noong 2018. Ang pisikal na hardware na tumatakbo sa mga microVM ay ibinabahagi sa pagitan ng mga workload sa iba't ibang account.
Nagse-save ng mga kapaligiran at estado ng proseso
Bagama't natatangi ang mga runtime ng Lambda sa iba't ibang function, maaari nilang tawagan ang parehong function nang paulit-ulit, ibig sabihin, ang runtime ay maaaring mabuhay nang ilang oras bago masira.
Ang bawat runtime ng Lambda ay mayroon ding naisusulat na file system na maa-access sa pamamagitan ng /tmp directory. Ang mga nilalaman nito ay hindi ma-access mula sa iba pang mga runtime. Sa abot ng proseso ng estado ng pagtitiyaga ay nababahala, ang mga file na nakasulat sa /tmp ay umiiral para sa buong ikot ng buhay ng runtime na kapaligiran. Nagbibigay-daan ito sa mga resulta ng maraming tawag na maipon, na partikular na kapaki-pakinabang para sa mga mamahaling operasyon gaya ng paglo-load ng mga modelo ng machine learning.
Paglipat ng data ng tawag
Maaaring gamitin ang Invoke API sa dalawang mode: event mode at request-response mode. Sa event mode, ang tawag ay idinaragdag sa isang queue para sa susunod na pagpapatupad. Sa mode na kahilingan-tugon, ang function ay agad na tinatawag na may ibinigay na kargamento, pagkatapos ay ibinalik ang tugon. Sa parehong mga kaso, ang function ay tumatakbo sa isang Lambda na kapaligiran, ngunit may iba't ibang mga path ng payload.
Sa panahon ng mga tawag sa pagtugon sa kahilingan, dumadaloy ang payload mula sa isang request processing API (API Caller), gaya ng AWS API Gateway o AWS SDK, patungo sa load balancer, at pagkatapos ay sa serbisyo ng tawag sa Lambda (Invoke Service). Tinutukoy ng huli ang naaangkop na kapaligiran para sa pagpapatupad ng function at ipinapasa ang payload doon upang makumpleto ang tawag. Ang load balancer ay tumatanggap ng trapikong protektado ng TLS sa Internet. Ang trapiko sa loob ng serbisyo ng Lambda—pagkatapos ng load balancer—ay dumadaan sa isang panloob na VPC sa isang partikular na rehiyon ng AWS.
Modelo sa Pagproseso ng Tawag ng AWS Lambda: Request-Response Mode
Ang mga tawag sa kaganapan ay maaaring gawin kaagad o idagdag sa isang pila. Sa ilang mga kaso, ipinapatupad ang queue gamit ang Amazon SQS (Amazon Simple Queue Service), na nagpapasa ng mga tawag sa serbisyo sa pagtupad ng tawag sa Lambda sa pamamagitan ng internal na proseso ng poller. Ang ipinadalang trapiko ay protektado ng TLS, at walang karagdagang pag-encrypt ng data na nakaimbak sa Amazon SQS.
Ang mga tawag sa kaganapan ay hindi nagbabalik ng mga tugon—ang Lambda Worker ay binabalewala lang ang anumang impormasyon sa pagtugon. Ang mga tawag na nakabatay sa kaganapan mula sa Amazon S3, Amazon SNS, CloudWatch, at iba pang source ay pinoproseso ng Lambda sa event mode. Ang mga tawag mula sa mga stream ng Amazon Kinesis at DynamoDB, mga SQS queue, Application Load Balancer, at mga tawag sa API Gateway ay pinoproseso sa paraan ng pagtugon sa kahilingan.
Pagsubaybay
Maaari mong subaybayan at i-audit ang mga function ng Lambda gamit ang iba't ibang mekanismo at serbisyo ng AWS, kabilang ang mga sumusunod.
Amazon CloudWatch
Nangongolekta ng iba't ibang istatistika tulad ng bilang ng mga kahilingan, ang tagal ng mga kahilingan, at ang bilang ng mga kahilingang nabigo.
Amazon CloudTrail
Binibigyang-daan kang mag-log, patuloy na subaybayan, at panatilihin ang impormasyon ng aktibidad ng account na nauugnay sa iyong imprastraktura ng AWS. Magkakaroon ka ng kumpletong kasaysayan ng mga pagkilos na isinagawa gamit ang AWS Management Console, AWS SDK, command line tool, at iba pang serbisyo ng AWS.
AWS X-Ray
Nagbibigay ng kumpletong kakayahang makita sa lahat ng mga yugto ng pagpoproseso ng kahilingan sa iyong aplikasyon batay sa isang mapa ng mga panloob na bahagi nito. Binibigyang-daan kang suriin ang mga application sa panahon ng pag-develop at sa mga kapaligiran ng produksyon.
AWS Config
Magagawa mong subaybayan ang mga pagbabago sa configuration ng Lambda function (kabilang ang pagtanggal) at mga runtime, mga tag, pangalan ng handler, laki ng code, paglalaan ng memory, mga setting ng timeout at mga setting ng concurrency, pati na rin ang Lambda IAM execution role, subnetting, at security group bindings .
Konklusyon
Nag-aalok ang AWS Lambda ng makapangyarihang hanay ng mga tool para sa pagbuo ng mga secure at scalable na application. Marami sa mga kasanayan sa seguridad at pagsunod sa AWS Lambda ay kapareho ng sa iba pang mga serbisyo ng AWS, bagama't may mga pagbubukod. Simula Marso 2019, ang Lambda ay sumusunod sa SOC 1, SOC 2, SOC 3, PCI DSS, Health Insurance Portability and Accountability Act (HIPAA) compliance, at iba pang mga regulasyon. Kaya, kapag nag-iisip ka tungkol sa pagpapatupad ng iyong susunod na aplikasyon, isaalang-alang ang serbisyo ng AWS Lambda - maaaring ito ang pinakaangkop para sa iyong gawain.
Pinagmulan: www.habr.com