Az AWS Lambda részletes elemzése

A cikk fordítása kifejezetten a kurzus hallgatói számára készült "Felhőszolgáltatások". Érdekel ebbe az irányba fejlődni? Nézze meg Egor Zuev mesterkurzusát (TeamLead az InBitnél) "AWS EC2 szolgáltatás" és csatlakozz a következő tanfolyami csoporthoz: szeptember 26-án indul.

Az AWS Lambda részletes elemzése

Egyre többen költöznek át az AWS Lambdára a méretezhetőség, a teljesítmény, a megtakarítások és a havi több millió vagy akár billió kérés kezelésére. Ehhez nem kell felügyelnie azt az infrastruktúrát, amelyen a szolgáltatás fut. Az automatikus skálázás pedig lehetővé teszi másodpercenként több ezer egyidejű kérés kiszolgálását. Szerintem az AWS Lambda joggal nevezhető az egyik legnépszerűbb AWS szolgáltatásnak.

AWS Lambda

Az AWS Lambda egy eseményvezérelt kiszolgáló nélküli számítástechnikai szolgáltatás, amely lehetővé teszi a kód futtatását a kiszolgálók kiépítése vagy kezelése nélkül, valamint más AWS-szolgáltatások kiterjesztését egyéni logika segítségével. A Lambda automatikusan reagál a különféle eseményekre (úgynevezett triggerekre), például az Amazon API Gateway-n keresztüli HTTP-kérésekre, az Amazon S3 gyűjtőcsoportjaiban vagy az Amazon DynamoDB tábláiban lévő adatok változásaira; vagy futtathatja a kódot API-hívásokon keresztül az AWS SDK és állapotátmenetek segítségével az AWS Step Functions szolgáltatásban.

A Lambda egy magas rendelkezésre állású számítási infrastruktúrán futtatja a kódot, és teljes mértékben felelős a mögöttes platform adminisztrálásáért, beleértve a szerver- és operációsrendszer-karbantartást, az erőforrás-kiépítést, az automatikus skálázást, a kódfigyelést és a naplózást. Vagyis csak fel kell töltenie a kódot, és be kell állítania, hogyan és mikor kell végrehajtani. A szolgáltatás viszont gondoskodik annak elindításáról, és biztosítja az alkalmazás magas szintű elérhetőségét.

Mikor váltsunk lambdára?

Az AWS Lambda egy kényelmes számítási platform, amely számos felhasználási esetre alkalmas, amennyiben a szolgáltatás támogatja a kód nyelvét és futási idejét. Ha a kódjára és az üzleti logikára szeretne összpontosítani, miközben ésszerű költségek mellett kiszervezi a kiszolgáló karbantartását, kiépítését és méretezését, akkor az AWS Lambda a megfelelő út.

A Lambda ideális programozási interfészek létrehozásához, és az API Gateway-vel együtt használva jelentősen csökkentheti a költségeket és gyorsabban kerülhet piacra. A Lambda funkcióinak és a szerver nélküli architektúra szervezésének különböző módjai vannak – mindenki választhat a céljainak megfelelőt.

A lambda lehetővé teszi a feladatok széles skálájának elvégzését. Így a CloudWatch támogatásának köszönhetően halasztott feladatokat hozhat létre, és automatizálhatja az egyes folyamatokat. A szolgáltatás használatának jellegét és intenzitását illetően nincs korlátozás (a memóriafogyasztást és az időt figyelembe veszik), és semmi sem akadályozza meg, hogy szisztematikusan dolgozzon egy teljes értékű, Lambda alapú mikroszolgáltatáson.

Itt szolgáltatásorientált műveleteket hozhat létre, amelyek nem futnak folyamatosan. Tipikus példa a képméretezés. Még az elosztott rendszerek esetében is relevánsak maradnak a Lambda funkciók.

Tehát, ha nem szeretne számítási erőforrások kiosztásával és kezelésével foglalkozni, próbálja ki az AWS Lambdát; ha nincs szüksége nehéz, erőforrás-igényes számításokra, próbálja ki az AWS Lambdát is; ha a kód rendszeresen fut, ez így van, akkor próbálja ki az AWS Lambdát.

biztonság

A biztonságra egyelőre nem lehet panasz. Másrészt, mivel a modell számos belső folyamata és megvalósítási funkciója rejtve van az AWS Lambda felügyelt futási környezet felhasználója előtt, a felhőbiztonság néhány általánosan elfogadott szabálya irrelevánssá válik.

A legtöbb AWS-szolgáltatáshoz hasonlóan a Lambdát is megosztott biztonsági és megfelelőségi alapon biztosítják az AWS és az ügyfél között. Ez az elv csökkenti a kliens működési terheit, mivel az AWS átveszi a szolgáltatás-összetevők karbantartásának, adminisztrálásának és felügyeletének feladatait - a gazdagép operációs rendszertől és a virtualizációs rétegtől az infrastrukturális eszközök fizikai biztonságáig.

Ami az AWS Lambdát illeti, az AWS felelős az alapul szolgáló infrastruktúra, a kapcsolódó mögöttes szolgáltatások, az operációs rendszer és az alkalmazásplatform kezeléséért. Míg az ügyfél felelős kódja biztonságáért, a bizalmas adatok tárolásáért, az azokhoz való hozzáférés szabályozásáért, valamint a Lambda szolgáltatáshoz és erőforrásokhoz (Identity and Access Management, IAM), beleértve a felhasznált funkciók korlátait is.

Az alábbi diagram az AWS Lambdára vonatkozó megosztott felelősségi modellt mutatja be. Az AWS Responsibility narancssárga, az Ügyfél felelőssége pedig kék színű. Amint látható, az AWS nagyobb felelősséget vállal a szolgáltatásban telepített alkalmazásokért.

Az AWS Lambda részletes elemzése

A megosztott felelősségi modell az AWS Lambdára vonatkozik

Lambda futási idő

A Lambda fő előnye, hogy egy funkciót az Ön nevében végrehajtva maga a szolgáltatás osztja ki a szükséges erőforrásokat. Elkerülheti, hogy időt és erőfeszítést pazaroljon a rendszeradminisztrációra, és az üzleti logikára és kódolásra összpontosítson.

A Lambda szolgáltatás két síkra oszlik. Az első a vezérlősík. A Wikipédia szerint a vezérlősík a hálózat azon része, amely a jelzőforgalom továbbításáért és az útválasztásért felelős. Ez az elsődleges összetevő, amely globális döntéseket hoz a munkaterhelések kiépítésével, kiszolgálásával és elosztásával kapcsolatban. Ezenkívül a vezérlősík a megoldásszolgáltató hálózati topológiájaként működik, felelős a forgalom útválasztásáért és kezeléséért.

A második sík az adatsík. Ennek, akárcsak a vezérlősíknak, megvannak a maga feladatai. A vezérlősík API-kat biztosít a funkciók kezeléséhez (CreateFunction, UpdateFunctionCode), és szabályozza, hogy a Lambda hogyan kommunikál más AWS-szolgáltatásokkal. Az adatsík vezérli az Invoke API-t, amely Lambda függvényeket futtat. Egy függvény meghívása után a vezérlősík lefoglal vagy kiválaszt egy meglévő futási környezetet, amely előre fel van készítve az adott függvényhez, majd végrehajtja a kódot abban.

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ő futási környezetükön keresztül. Az AWS rendszeresen frissíti őket, biztonsági javításokat terjeszt, és egyéb karbantartási tevékenységeket végez ezeken a környezeteken. A Lambda lehetővé teszi más nyelvek használatát is, feltéve, hogy saját maga implementálja a megfelelő futtatókörnyezetet. És akkor gondoskodnia kell a karbantartásáról, beleértve a biztonságának ellenőrzését.

Hogyan működik mindez, és hogyan látja el a szolgáltatás az Ön feladatait?

Minden függvény egy vagy több dedikált környezetben fut, amelyek csak az adott függvény élettartama alatt léteznek, majd megsemmisülnek. Minden környezet egyszerre csak egy hívást kezdeményez, de a rendszer újrafelhasználja, ha több soros hívás is van ugyanahhoz a funkcióhoz. Minden futási környezet hardveres virtualizációval ellátott virtuális gépeken fut – úgynevezett microVM-eken. Minden microVM egy adott AWS-fiókhoz van hozzárendelve, és a környezetek újra felhasználhatják az adott fiókon belüli különböző funkciók végrehajtására. A MicroVM-ek az AWS tulajdonában lévő és üzemeltetett Lambda Worker hardverplatform építőelemeibe vannak csomagolva. Ugyanazt a futási környezetet nem használhatják különböző funkciók, és a microVM-ek sem egyediek a különböző AWS-fiókokhoz.

Az AWS Lambda részletes elemzése

AWS lambda izolációs modell

A futási környezetek elkülönítése többféle mechanizmus segítségével valósul meg. Az egyes környezetek legfelső szintjén a következő összetevők külön másolatai találhatók:

  • Funkciókód
  • A funkcióhoz kiválasztott bármely lambda réteg
  • Funkcióvégrehajtási környezet
  • Minimális felhasználói hely Amazon Linux alapján

A következő mechanizmusokat használják a különböző végrehajtási környezetek elkülönítésére:

  • cgroups - korlátozza a hozzáférést a CPU-hoz, a memóriához, a tárolóhoz és a hálózati erőforrásokhoz az egyes futási környezetekben;
  • névterek – folyamatazonosítók, felhasználói azonosítók, hálózati interfészek és egyéb, a Linux kernel által kezelt erőforrások csoportosítása. Minden futási környezet a saját névterében fut;
  • seccomp-bpf - korlátozza a futásidőben használható rendszerhívásokat;
  • iptables és routing tables - a végrehajtási környezetek elkülönítése egymástól;
  • chroot – korlátozott hozzáférést biztosít az alapul szolgáló fájlrendszerhez.

Az AWS szabadalmaztatott leválasztási technológiáival kombinálva ezek a mechanizmusok megbízható futásidejű szétválasztást biztosítanak. Az ilyen módon elkülönített környezetek nem férhetnek hozzá más környezetekből származó adatokhoz és nem módosíthatják azokat.

Bár ugyanazon AWS-fiók több futtatókörnyezete futhat egyetlen microVM-en, a microVM-ek semmilyen körülmények között nem oszthatók meg különböző AWS-fiókok között. Az AWS Lambda csak két mechanizmust használ a microVM-ek elkülönítésére: az EC2 példányokat és a Firecrackert. A Lambdában az EC2-példányokon alapuló vendégizoláció 2015 óta létezik. A Firecracker egy új, nyílt forráskódú hipervizor, amelyet az AWS kifejezetten szerver nélküli munkaterhelésekhez tervezett, és 2018-ban vezették be. A microVM-eket futtató fizikai hardver meg van osztva a különböző fiókok munkaterhelései között.

Környezetek és folyamatállapotok mentése

Bár a Lambda futási környezetek egyediek a különböző funkciókhoz, ugyanazt a függvényt többször is meghívhatják, ami azt jelenti, hogy a futási idő több órán keresztül fennmaradhat, mielőtt megsemmisülne.

Minden Lambda futtatókörnyezet rendelkezik egy írható fájlrendszerrel is, amely a /tmp könyvtáron keresztül érhető el. Tartalma más futási környezetből nem érhető el. Ami a folyamatállapot fennmaradását illeti, a /tmp fájlba írt fájlok a futási környezet teljes életciklusa alatt léteznek. Ez lehetővé teszi több hívás eredményeinek összegyűjtését, ami különösen hasznos olyan drága műveleteknél, mint például a gépi tanulási modellek betöltése.

Hívás adatátvitel

Az Invoke API két módban használható: esemény módban és kérés-válasz módban. Esemény módban a hívás egy sorba kerül későbbi végrehajtás céljából. Kérelem-válasz módban a függvény azonnal meghívásra kerül a megadott hasznos adattartalommal, majd a válasz visszaadásra kerül. A függvény mindkét esetben Lambda környezetben fut, de eltérő hasznos terhelési útvonalakkal.

A kérés-válasz hívások során a hasznos teher a kérésfeldolgozási API-tól (API-hívó), például az AWS API-átjárótól vagy az AWS SDK-tól a terheléselosztóhoz, majd a Lambda-hívásszolgáltatáshoz (Invoke Service) áramlik. Ez utóbbi meghatározza a megfelelő környezetet a funkció végrehajtásához, és a hívás befejezéséhez átadja a hasznos terhet. A terheléselosztó TLS-védett forgalmat fogad az interneten keresztül. A Lambda szolgáltatáson belüli forgalom – a terheléselosztó után – egy belső VPC-n halad át egy adott AWS régióban.

Az AWS Lambda részletes elemzése

AWS Lambda hívásfeldolgozási modell: Kérelem-válasz mód

Eseményhívások azonnal kezdeményezhetők, vagy sorba helyezhetők. Egyes esetekben a sor az Amazon SQS (Amazon Simple Queue Service) segítségével valósul meg, amely belső lekérdezési folyamaton keresztül továbbítja a hívásokat a Lambda hívásteljesítési szolgáltatásnak. A továbbított forgalmat TLS védi, és nincs további titkosítás az Amazon SQS-ben tárolt adatokhoz.

Az eseményhívások nem adnak vissza választ – a Lambda Worker egyszerűen figyelmen kívül hagy minden válaszinformációt. Az Amazon S3, Amazon SNS, CloudWatch és más forrásokból érkező eseményalapú hívásokat a Lambda esemény módban dolgozza fel. Az Amazon Kinesis és DynamoDB adatfolyamokból, SQS-sorokból, Application Load Balancer és API Gateway hívások feldolgozása kérés-válasz módban történik.

megfigyelés

A Lambda funkcióit különféle AWS-mechanizmusok és szolgáltatások segítségével figyelheti és auditálhatja, beleértve a következőket.

amazonfelhőóra
Különféle statisztikákat gyűjt, például a kérelmek számát, a kérések időtartamát és a sikertelen kérések számát.

Amazon CloudTrail
Lehetővé teszi az AWS-infrastruktúrához kapcsolódó fióktevékenység-információk naplózását, folyamatos figyelését és karbantartását. Az AWS Management Console, az AWS SDK, a parancssori eszközök és más AWS-szolgáltatások használatával végrehajtott műveletek teljes előzménye lesz.

AWS röntgen
A belső összetevők térképe alapján teljes áttekintést biztosít az alkalmazás kérésfeldolgozásának minden szakaszában. Lehetővé teszi alkalmazások elemzését fejlesztés közben és éles környezetben.

AWS konfig
Nyomon követheti a Lambda-funkciók konfigurációjában (beleértve a törlést) és a futási időkben, a címkékben, a kezelőnevekben, a kódméretben, a memóriafoglalásban, az időtúllépési beállításokban és a párhuzamossági beállításokban, valamint a Lambda IAM végrehajtási szerepkörében, az alhálózatokban és a biztonsági csoport-összerendelésekben bekövetkezett változásokat. .

Következtetés

Az AWS Lambda hatékony eszközkészletet kínál biztonságos és méretezhető alkalmazások létrehozásához. Az AWS Lambda számos biztonsági és megfelelőségi gyakorlata ugyanaz, mint más AWS-szolgáltatásokban, bár vannak kivételek. 2019 márciusától a Lambda megfelel az SOC 1, SOC 2, SOC 3, PCI DSS, az egészségbiztosítási hordozhatóságról és elszámoltathatóságról szóló törvénynek (HIPAA) és egyéb előírásoknak. Tehát, amikor a következő alkalmazás megvalósításán gondolkodik, fontolja meg az AWS Lambda szolgáltatást – lehet, hogy ez a legjobban megfelel a feladatának.

Forrás: will.com

Hozzászólás