Az írás fordítása kifejezetten a kurzus hallgatói számára készült Érdekes fejlődni ezen a területen? Nézze meg Eгор Зуев mesterkurzusát (a InBit csapatvezetője) és csatlakozzon a legközelebbi tanfolyami csoporthoz: kezdés szeptember 26-án.
Egyre többen váltanak az AWS Lambda-ra a skálázhatóság, teljesítmény, költséghatékonyság és a havi milliók, sőt trilliók lekérdezésének kezelésének lehetősége érdekében. Ehhez nincs szükség a szolgáltatás működéséhez szükséges infrastruktúra kezelésére. Az automatikus skálázás lehetővé teszi ezer egyidejű lekérdezés kiszolgálását másodpercenként. Gondolom, az AWS Lambda joggal nevezhető az AWS egyik legkeresettebb szolgáltatásának.
AWS Lambda
Az AWS Lambda egy eseményalapú szerver nélküli számítási szolgáltatás, amely lehetővé teszi a kód futtatását anélkül, hogy szervereket kellene kiemelni és adminisztrálni, valamint más AWS szolgáltatásokat kiegészít felhasználói logika alapján. A Lambda automatikusan reagál különböző eseményekre (úgynevezett aktivátorokra), például HTTP-kérésekre az Amazon API Gateway-en, az Amazon S3 kosarakban vagy az Amazon DynamoDB táblákban történt adatmódosításokra; vagy saját kódját API-hívások révén indíthatja el, AWS SDK-t és állapotváltásokat használva az AWS Step Functions keretein belül.
A Lambda magas rendelkezésre állású számítási infrastruktúrán futtatja a kódot, és teljes mértékben felelős az alacsonyabb réteg platform adminisztrációjáért, beleértve a szerverek és az operációs rendszer karbantartását, az erőforrások kiemelését, az automatikus skálázást, a kód figyelését és a naplózást. Tehát Önnek csak a kódját kell feltöltenie, és beállítania, hogyan és mikor kell futnia. A szolgáltatás gondoskodik arról, hogy az működjön, és biztosítja az alkalmazása magas rendelkezésre állását.
Mikor érdemes áttérni a Lambda-ra?
Az AWS Lambda egy kényelmes számítási platform, amely számos alkalmazási forgatókönyvhöz megfelel, természetesen, ha a kódja nyelve és futtatási környezete támogatott a szolgáltatás által. Ha szeretne a kódra és az üzleti logikára összpontosítani, és a szerverek karbantartását, az erőforrások kiemelését és a skálázást egy harmadik fél szolgáltatóra bízni ésszerű áron, akkor mindenképp érdemes áttérni az AWS Lambda-ra.
A Lambda tökéletesen alkalmas API-k létrehozására, és ha a szolgáltatást az API Gateway-jel együtt használják, jelentősen csökkenthetők a költségek, és gyorsabban léphetnek piacra. Számos módja van a Lambda funkciók használatának és a serverless architektúra megszervezésének — mindenki választhat valamit a kitűzött célok figyelembevételével.
A Lambda széles spektrumú feladatok végrehajtására képes. A CloudWatch támogatásának köszönhetően ütemezett feladatokat hozhatunk létre és automatizálhatunk egyes folyamatokat. Nincsenek korlátozások a szolgáltatás használatának jellegére vagy intenzitására vonatkozóan (a memóriafogyasztást és az időt veszik figyelembe), és semmi sem akadályozza meg, hogy fokozatosan dolgozzon egy teljes értékű mikroszolgáltatáson a Lambda alapjain.
Itt szolgáltatásorientált műveleteket hozhatunk létre, amelyek nem folyamatosan futnak. A tipikus példa a képek méretezése. Még elosztott rendszerek esetén is a Lambda funkciók nem veszítenek relevanciájukból.
Tehát, ha nem akar a számítási erőforrások kiemelésével és adminisztrálásával foglalkozni — próbálja ki az AWS Lambdát; ha nem szükségesek nehéz, erőforrás-igényes számítások — szintén próbálja ki az AWS Lambdát; ha a kódja időszakosan fut — helyes, érdemes kipróbálnia az AWS Lambdát.
Biztonság
Eddig a biztonsággal nincs panasz. Másrészt, mivel az AWS Lambda által kezelt környezet felhasználója számára sok belső folyamat és a modell megvalósításának részletetei rejtve vannak, bizonyos általánosan elfogadott felhőbiztonsági szabályok elveszítik relevanciájukat.
Mint a legtöbb AWS szolgáltatás, a Lambda a AWS és az ügyfél közötti közös felelősség elve alapján kerül biztosításra a biztonság és a szabályozási követelmények betartásában. Ez az elv csökkenti az ügyfél működési terhét, mivel az AWS vállalja a szolgáltatás komponenseinek karbantartásának, adminisztrálásának és ellenőrzésének feladatait — a gazdagép operációs rendszerétől és a virtualizálási szinttől kezdve a fizikai infrastruktúra biztonságáig.
Ha az AWS Lambda-ról van szó, az AWS felel az alatta lévő infrastruktúra, a kapcsolódó alapvető szolgáltatások, az operációs rendszer és az alkalmazásplatform kezeléséért. Míg az ügyfél felelőssége a saját kódjának biztonsága, a bizalmas adatok tárolása, ezekhez való hozzáférés ellenőrzése, valamint a Lambda szolgáltatáshoz és erőforrásokhoz (Identity and Access Management, IAM) való hozzáférlés, beleértve a használt funkciók kereteit.
Az alábbi ábrán látható a közös felelősségi modell, amely az AWS Lambda-ra vonatkozik. Az AWS felelősségi köre narancssárga, míg az ügyfél felelőssége világoskék. Amint látható, az AWS több felelősséget vállal az alkalmazásokért, amelyek a szolgáltatáson futnak.
Közös felelősségi modell, amely az AWS Lambda-ra vonatkozik
Lambda környezet
A Lambda legfőbb előnye, hogy azáltal, hogy a funkciót az Ön nevében hajtja végre, a szolgáltatás maga osztja ki a szükséges erőforrásokat. Nem kell időt és energiát pazarolnia a rendszerek adminisztrálására, hanem a üzleti logikára és a kód megírására koncentrálhat.
A Lambda szolgáltatás két síkra oszlik. Az első a vezérlési sík. A Wikipédia szerint a vezérlési sík (control plane) a hálózat azon része, amely a jelzési forgalom szállításáért és irányításáért felelős. Ez a legfontosabb összetevő, amely globális döntéseket hoz az erőforrások kiosztásával, fenntartásával és a terhelések elosztásával kapcsolatban. Ezen kívül a vezérlési sík a szolgáltató megoldásának hálózati topológiájaként funkcionál, amely a forgalom irányításáért és kezeléséért felel.
A második sík az adatsík. Ennek saját feladatai vannak, akárcsak a vezérlési síknak. A vezérlési sík API-t biztosít a funkciók kezelésére (CreateFunction, UpdateFunctionCode) és felügyeli a Lambda más AWS szolgáltatásokkal való interakcióját. Az adatsík kezeli az API hívásokat (Invoke API), amelyek elindítják a Lambda funkciókat. A funkció hívása után a vezérlési sík vagy kioszt egy meglévő, előre elkészített környezetet az adott funkció számára, majd végrehajtja a kódot benne.
Az AWS Lambda számos programozási nyelvet támogat, beleértve a Java 8-at, a Python 3.7-et, a Go-t, a NodeJS 8-at, a .NET Core 2-t és másokat, a megfelelő futtatási környezeteken keresztül. Az AWS rendszeresen frissíti őket, biztonsági javításokat terjeszt, és egyéb karbantartási műveleteket végez ezekkel a környezetekkel. A Lambda lehetővé teszi más nyelvek használatát is, feltéve, hogy ön megvalósítja a megfelelő futtatási környezetet. Ebben az esetben a karbantartásért is önnek kell gondoskodnia, beleértve a biztonság figyelemmel kísérését.
Hogyan működik mindez, és hogyan fogja a szolgáltatás végrehajtani a funkcióit?
Minden funkció egy vagy több elkülönített környezetben működik, amelyek csak a funkció életciklusa alatt léteznek, majd eltűnnek. Minden környezetben egyszerre csak egy hívás zajlik, de az újra felhasználható, ha ugyanazon funkció sorozatos hívásai merülnek fel. Minden futtatási környezet virtuális gépeken fut hardveres virtualizációval — az úgynevezett microVM-eken. Minden microVM egy adott AWS fióknak van hozzárendelve és többször is felhasználható különböző funkciók végrehajtására ugyanazon a fiókon belül. A microVM-eket az AWS által birtokolt és kezelt Lambda Worker hardverplatformban csomagolják. Ugyanaz a futtatási környezet nem használható különböző funkciók által, ahogyan a microVM-ek is egyediek a különböző AWS fiókok számára.
Az izoláció modell az AWS Lambda-ban
A futtatási környezetek izolációját több mechanizmus révén valósítják meg. A legmagasabb szinten minden környezetben külön másolatok találhatók a következő összetevőkből:
- A funkciókód
- Bármely Lambda réteg, amelyet a funkcióhoz választottak
- A funkció futtatási közege
- Minimális felhasználói tér az Amazon Linux alapjain
A különböző futtatási környezetek izolálásához a következő mechanizmusokat alkalmazzák:
- cgroups — a CPU, memória, tárolási sávszélesség és hálózati erőforrások hozzáférésének korlátozása minden futtatási környezet számára;
- namespaces — a folyamatok, felhasználói ID-k, hálózati interfészek és más, a Linux kernel által kezelt erőforrások csoportosítása. Minden futtatási környezet a saját névterében működik;
- seccomp-bpf — a futtatási környezetben felhasználható rendszerv calls korlátozása;
- iptables és routing tables — a futtatási környezetek egymástól való izolációja;
- A chroot — korlátozott hozzáférés biztosítása a mélyebben fekvő fájlrendszerekhez.
A fent említett mechanizmusok, a proprietáris AWS szigetelési technológiákkal kombinálva, megbízható határokat garantálnak a végrehajtási környezetek között. Az így izolált környezetek nem férhetnek hozzá más környezetek adataihoz és nem módosíthatják azokat.
Bár egy AWS fiók több végrehajtási környezete egy microVM-en futhat, semmilyen körülmények között nem oszthatják meg a microVM-et különböző AWS fiókok. Az AWS Lambda izolálásához a microVM-ekben csupán két mechanizmust használnak: EC2 példányokat és Firecracker-t. Az EC2 példányok alapú vendégizoláció a Lambda számára 2015 óta alkalmazott. A Firecracker egy új, nyílt forráskódú hipervizor, amelyet kifejezetten az AWS tervezett a kiszolgáló nélküli terhelésekhez, és 2018-ban mutatták be. Az a fizikai hardver, amelyen a microVM-ek futnak, különböző fiókok terhelése által megosztott.
Környezetek és folyamatállapotok megőrzése
Bár a Lambda futási környezetek egyedi funkciókhoz kapcsolódnak, ugyanaz a funkció többször is meghívható, azaz a futási környezet több órán át fennmaradhat, mielőtt megszűnne.
Minden Lambda futási környezetben van egy írási engedéllyel rendelkező fájlrendszer, amely az /tmp könyvtáron keresztül érhető el. A többi futási környezetből nem lehet elérni a tartalmát. A folyamatállapotok megőrzésére vonatkozóan az /tmp könyvtárba írt fájlok a futási környezet életciklusa alatt léteznek. Ennek köszönhetően több hívás eredményei is felhalmozódhatnak, amely különösen hasznos a gépi tanulási modellek betöltéséhez hasonló költséges műveleteknél.
Hívások adatainak átadása
Az Invoke API interfész két üzemmódban használható: esemény módban és kérés-válasz módban. Esemény módban a hívás be van sorolva későbbi végrehajtásra. Kérés-válasz módban a funkció azonnal meghívásra kerül a megadott terheléssel, majd visszatér a válasz. Mindkét esetben a funkció a Lambda környezetében fut, de különböző terhelési útvonalakon.
A 'request-response' call type processes payloads from an API request handler (API Caller), such as AWS API Gateway or AWS SDK, into a load balancer and then into the Lambda invocation service. The latter determines the suitable environment for function execution and sends the payload there to complete the call. The load balancer receives traffic with TLS protection over the Internet. Traffic within the Lambda service, after the load balancer, travels through an internal VPC in a specific AWS region.
AWS Lambda call processing model: 'request-response' mode
Event-driven calls can be executed immediately or queued. In some cases, the queue is implemented using the Amazon SQS (Amazon Simple Queue Service), which forwards calls to the Lambda invocation service via an internal polling process. The transmitted traffic is protected by TLS, with no additional encryption of data stored in Amazon SQS.
Event-driven calls do not return responses — any response information is simply ignored by the Lambda Worker. Calls based on Amazon S3 events, Amazon SNS, CloudWatch, and other sources are processed by the Lambda service in event mode. Calls from Amazon Kinesis streams and DynamoDB, SQS queue calls, application load balancer calls, and API Gateway are processed in 'request-response' mode.
Monitorozás
You can monitor and audit Lambda functions using various AWS mechanisms and services, including the following.
Amazon CloudWatch
Collects various statistics such as the number of requests, duration of request execution, and the number of requests that resulted in an error.
Amazon CloudTrail
Enables logging, continuous monitoring, and preserving information about activities in your account related to your AWS infrastructure. You will have a complete history of actions taken through the AWS Management Console, AWS SDK, command-line tools, and other AWS services.
AWS X-Ray
Provides complete visibility into all stages of request processing in your application based on a mapping of its internal components. It allows you to analyze applications during development and in a production environment.
AWS Config
Nyomon követheti a Lambda-funkciók konfigurációs változásait (beleértve azok törlését) és futtatási környezetét, címkéit, kezelőneveit, kódméretét, memóriaelosztását, időtúllépési beállításait és párhuzamossági paramétereit, valamint a Lambda IAM végrehajtási szerepkörét, az alhálózatokat és a biztonsági csoportokhoz való kötődést.
Zárás
Az AWS Lambda hatékony eszközkészletet kínál biztonságos és skálázható alkalmazások létrehozásához. Számos biztonsági és megfelelőségi módszer az AWS Lambdán nem különbözik az AWS többi szolgáltatásának alkalmazottaktól, bár vannak kivételek. 2019 márciusáig a Lambda megfelel a SOC 1, SOC 2, SOC 3, PCI DSS, az amerikai egészségbiztosítási törvény (HIPAA) és egyéb normák követelményeinek. Ezért, amikor a következő alkalmazás megvalósításán gondolkodik, érdemes megfontolnia az AWS Lambda szolgáltatást — lehet, hogy ez a legjobb megoldás az Ön feladata számára.
Forrás: habr.com
