Překlad článku byl připraven speciálně pro studenty kurzu . Máte zájem se tímto směrem rozvíjet? Podívejte se na mistrovskou třídu Egora Zueva (TeamLead na InBit) a připojte se k další skupině kurzů: začíná 26. září.
Více lidí migruje na AWS Lambda kvůli škálovatelnosti, výkonu, úsporám a schopnosti zpracovávat miliony nebo dokonce biliony požadavků měsíčně. K tomu nemusíte spravovat infrastrukturu, na které služba běží. A automatické škálování vám umožňuje obsluhovat tisíce současných požadavků za sekundu. Myslím, že AWS Lambda lze právem nazvat jednou z nejoblíbenějších služeb AWS.
AWS Lambda
AWS Lambda je událostmi řízená výpočetní služba bez serveru, která vám umožňuje spouštět kód bez zajišťování nebo správy serverů a rozšiřovat další služby AWS pomocí vlastní logiky. Lambda automaticky reaguje na různé události (nazývané spouštěče), jako jsou požadavky HTTP prostřednictvím brány Amazon API Gateway, změny dat v bucketech Amazon S3 nebo tabulkách Amazon DynamoDB; nebo můžete svůj kód spustit prostřednictvím volání API pomocí sady AWS SDK a přechodů stavů ve funkcích AWS Step Functions.
Lambda spouští kód na vysoce dostupné výpočetní infrastruktuře a je plně zodpovědná za správu základní platformy, včetně údržby serveru a operačního systému, zajišťování zdrojů, automatického škálování, monitorování kódu a protokolování. To znamená, že stačí nahrát svůj kód a nakonfigurovat, jak a kdy se má spustit. Služba se zase postará o její spuštění a zajistí vysokou dostupnost vaší aplikace.
Kdy přejít na Lambdu?
AWS Lambda je pohodlná výpočetní platforma, která je vhodná pro různé případy použití, pokud služba podporuje jazyk a běh vašeho kódu. Pokud se chcete zaměřit na svůj kód a obchodní logiku a zároveň outsourcovat údržbu, zajišťování a škálování serverů za rozumnou cenu, AWS Lambda je rozhodně tou správnou cestou.
Lambda je ideální pro vytváření programovacích rozhraní a při použití ve spojení s API Gateway můžete výrazně snížit náklady a rychleji se dostat na trh. Existují různé způsoby, jak využít funkce Lambda a možnosti organizace architektury bez serveru – každý si může vybrat něco vhodného podle svého cíle.
Lambda umožňuje provádět širokou škálu úkolů. Díky podpoře CloudWatch tak můžete vytvářet odložené úkoly a automatizovat jednotlivé procesy. Neexistují žádná omezení na charakter a intenzitu využívání služby (počítá se spotřeba paměti a čas) a nic vám nebrání systematicky pracovat na plnohodnotné mikroslužbě založené na Lambdě.
Zde můžete vytvářet akce zaměřené na služby, které neběží nepřetržitě. Typickým příkladem je škálování obrazu. I v případě distribuovaných systémů zůstávají funkce Lambda relevantní.
Pokud se tedy nechcete zabývat alokací a správou výpočetních zdrojů, zkuste AWS Lambda; pokud nepotřebujete těžké výpočty náročné na zdroje, zkuste také AWS Lambda; pokud váš kód běží pravidelně, je to tak, měli byste zkusit AWS Lambda.
zabezpečení
Zatím nejsou žádné stížnosti na bezpečnost. Na druhou stranu, protože mnoho interních procesů a implementačních funkcí tohoto modelu je před uživatelem spravovaného runtime prostředí AWS Lambda skryto, některá obecně přijímaná pravidla cloudového zabezpečení se stávají irelevantními.
Jako většina služeb AWS je i Lambda poskytována na základě sdíleného zabezpečení a souladu mezi AWS a zákazníkem. Tento princip snižuje provozní zátěž klienta, protože AWS přebírá úkoly údržby, správy a monitorování komponent služeb – od hostitelského operačního systému a virtualizační vrstvy až po fyzické zabezpečení infrastrukturních aktiv.
Konkrétně, pokud jde o AWS Lambda, AWS je zodpovědná za správu základní infrastruktury, souvisejících základních služeb, operačního systému a aplikační platformy. Zatímco klient odpovídá za bezpečnost svého kódu, uchovává důvěrná data, řídí přístup k nim, jakož i ke službě a zdrojům Lambda (Identity and Access Management, IAM), a to i v rámci limitů používaných funkcí.
Níže uvedený diagram ukazuje model sdílené odpovědnosti, jak se vztahuje na AWS Lambda. AWS Responsibility je oranžová a Customer Responsibility je modrá. Jak vidíte, AWS přebírá větší odpovědnost za aplikace nasazené ve službě.
Model sdílené odpovědnosti platný pro AWS Lambda
Doba běhu lambda
Hlavní výhodou Lambda je, že vykonáváním funkce vaším jménem služba sama přiděluje potřebné zdroje. Můžete se vyhnout plýtvání časem a úsilím na správu systému a zaměřit se na obchodní logiku a kódování.
Služba Lambda je rozdělena do dvou rovin. První je řídicí rovina. Podle Wikipedie je řídicí rovina součástí sítě odpovědné za přenos signalizačního provozu a směrování. Je to primární komponenta, která činí globální rozhodnutí o zajišťování, údržbě a distribuci úloh. Řídicí rovina navíc funguje jako topologie sítě poskytovatele řešení, která je zodpovědná za směrování a řízení provozu.
Druhá rovina je datová rovina. Stejně jako řídicí rovina má své vlastní úkoly. Řídicí rovina poskytuje rozhraní API pro správu funkcí (CreateFunction, UpdateFunctionCode) a řídí, jak Lambda komunikuje s ostatními službami AWS. Datová rovina řídí Invoke API, které spouští funkce Lambda. Po zavolání funkce řídicí rovina alokuje nebo vybere existující běhové prostředí, které je pro danou funkci předem připraveno, a poté v něm spustí kód.
AWS Lambda podporuje řadu programovacích jazyků, včetně Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2 a dalších, prostřednictvím příslušných běhových prostředí. AWS je pravidelně aktualizuje, distribuuje bezpečnostní záplaty a provádí další činnosti údržby v těchto prostředích. Lambda vám umožňuje používat i jiné jazyky, za předpokladu, že si sami implementujete příslušný runtime. A pak se budete muset postarat o jeho údržbu, včetně sledování jeho bezpečnosti.
Jak to celé funguje a jak bude služba plnit vaše funkce?
Každá funkce běží v jednom nebo více vyhrazených prostředích, která existují pouze po dobu životnosti dané funkce a poté jsou zničena. Každé prostředí provádí vždy pouze jedno volání, ale je znovu použito, pokud existuje více sériových volání stejné funkce. Všechna runtime prostředí běží na virtuálních strojích s hardwarovou virtualizací – tzv. microVMs. Každý microVM je přiřazen ke konkrétnímu účtu AWS a může být prostředím znovu použit k provádění různých funkcí v rámci tohoto účtu. MicroVM jsou zabaleny do stavebních bloků hardwarové platformy Lambda Worker, kterou vlastní a provozuje AWS. Stejné runtime nemohou používat různé funkce, ani mikroVM nejsou jedinečné pro různé účty AWS.
Model izolace lambda AWS
Izolace runtime prostředí je realizována pomocí několika mechanismů. Na nejvyšší úrovni každého prostředí jsou samostatné kopie následujících komponent:
- Kód funkce
- Jakékoli Lambda vrstvy vybrané pro funkci
- Prostředí pro provádění funkcí
- Minimální uživatelský prostor založený na Amazon Linuxu
K izolaci různých prováděcích prostředí se používají následující mechanismy:
- cgroups - omezují přístup k CPU, paměti, úložišti a síťovým zdrojům pro každé běhové prostředí;
- jmenné prostory – seskupují ID procesů, ID uživatelů, síťová rozhraní a další prostředky spravované linuxovým jádrem. Každý runtime běží ve svém vlastním jmenném prostoru;
- seccomp-bpf - omezuje systémová volání, která lze použít za běhu;
- iptables a směrovací tabulky - izolace prováděcích prostředí od sebe;
- chroot - poskytuje omezený přístup k základnímu souborovému systému.
V kombinaci s proprietárními izolačními technologiemi AWS tyto mechanismy zajišťují spolehlivé oddělení doby běhu. Prostředí izolovaná tímto způsobem nemohou přistupovat k datům z jiných prostředí nebo je upravovat.
Přestože na jednom microVM může běžet více běhových prostředí stejného účtu AWS, za žádných okolností nelze microVM sdílet mezi různými účty AWS. AWS Lambda používá k izolaci mikroVM pouze dva mechanismy: instance EC2 a Firecracker. Izolace hostů v Lambda založená na instancích EC2 existuje od roku 2015. Firecracker je nový open source hypervizor speciálně navržený společností AWS pro bezserverové pracovní zátěže a představený v roce 2018. Fyzický hardware běžící na mikroVM je sdílen mezi pracovními zátěžemi napříč různými účty.
Ukládání prostředí a stavů procesů
Přestože jsou runtime Lambda jedinečné pro různé funkce, mohou volat stejnou funkci opakovaně, což znamená, že runtime může přežít několik hodin, než bude zničeno.
Každé běhové prostředí Lambda má také zapisovatelný souborový systém přístupný přes adresář /tmp. K jeho obsahu nelze přistupovat z jiných běhových prostředí. Pokud jde o persistenci stavu procesu, soubory zapsané do /tmp existují po celý životní cyklus běhového prostředí. To umožňuje shromažďovat výsledky více volání, což je užitečné zejména pro drahé operace, jako je načítání modelů strojového učení.
Přenos dat hovorů
Rozhraní Invoke API lze použít ve dvou režimech: v režimu události a režimu žádost-odpověď. V režimu události je volání přidáno do fronty pro pozdější provedení. V režimu požadavek-odpověď je funkce volána okamžitě s poskytnutým užitečným zatížením, načež je vrácena odpověď. V obou případech funkce běží v prostředí Lambda, ale s různými cestami užitečného zatížení.
Během volání žádost-odpověď proudí datová část z API pro zpracování požadavků (API Caller), jako je AWS API Gateway nebo AWS SDK, do nástroje pro vyrovnávání zátěže a poté do služby volání Lambda (Invoke Service). Ten určí vhodné prostředí pro provedení funkce a předá tam užitečné zatížení k dokončení volání. Nástroj pro vyrovnávání zatížení přijímá provoz chráněný TLS přes internet. Provoz v rámci služby Lambda – po nástroji pro vyrovnávání zatížení – prochází interním VPC v konkrétní oblasti AWS.
Model zpracování hovorů AWS Lambda: Režim žádost-odpověď
Volání událostí lze uskutečnit okamžitě nebo je přidat do fronty. V některých případech je fronta implementována pomocí služby Amazon SQS (Amazon Simple Queue Service), která předává volání službě plnění hovorů Lambda prostřednictvím interního procesu dotazování. Přenášený provoz je chráněn TLS a neexistuje žádné další šifrování dat uložených v Amazon SQS.
Volání událostí nevrací odpovědi – Lambda Worker jednoduše ignoruje jakoukoli informaci o odpovědi. Hovory založené na událostech z Amazon S3, Amazon SNS, CloudWatch a dalších zdrojů zpracovává Lambda v režimu události. Volání ze streamů Amazon Kinesis a DynamoDB, front SQS, Application Load Balancer a API Gateway se zpracovávají způsobem požadavek-odpověď.
Sledování
Funkce Lambda můžete monitorovat a auditovat pomocí různých mechanismů a služeb AWS, včetně následujících.
amazoncloudwatch
Shromažďuje různé statistiky, jako je počet požadavků, doba trvání požadavků a počet neúspěšných požadavků.
Amazon CloudTrail
Umožňuje vám protokolovat, průběžně sledovat a udržovat informace o aktivitě účtu spojené s vaší infrastrukturou AWS. Budete mít kompletní historii akcí prováděných pomocí konzoly AWS Management Console, AWS SDK, nástrojů příkazového řádku a dalších služeb AWS.
RTG AWS
Poskytuje úplný přehled o všech fázích zpracování požadavků ve vaší aplikaci na základě mapy jejích vnitřních součástí. Umožňuje analyzovat aplikace během vývoje a v produkčním prostředí.
Konfigurace AWS
Budete moci sledovat změny konfigurace funkce Lambda (včetně mazání) a běhových prostředí, značek, názvů obslužných rutin, velikosti kódu, alokace paměti, nastavení časového limitu a nastavení souběžnosti, stejně jako spouštěcí role Lambda IAM, podsítě a vazby bezpečnostních skupin. .
Závěr
AWS Lambda nabízí výkonnou sadu nástrojů pro vytváření bezpečných a škálovatelných aplikací. Mnoho postupů zabezpečení a dodržování předpisů v AWS Lambda je stejných jako v jiných službách AWS, i když existují výjimky. Od března 2019 je společnost Lambda v souladu se SOC 1, SOC 2, SOC 3, PCI DSS, zákonem o přenositelnosti a odpovědnosti zdravotního pojištění (HIPAA) a dalšími předpisy. Když tedy uvažujete o implementaci své další aplikace, zvažte službu AWS Lambda – může být pro váš úkol nejvhodnější.
Zdroj: www.habr.com