Abstrakt Serverless přístup v Amazon Web Services se za poslední dekádu posunul z experimentální technologie do hlavního proudu. Pro řadu workloadů dnes představuje rychlejší a levnější alternativu ke klasickým virtuálním strojům i kontejnerům. Není však univerzální. Článek shrnuje, kdy serverless v AWS dává smysl, jaké architektonické vzory se v produkci osvědčují, jak řešit studené starty, databázová spojení a sledovatelnost, a jak realisticky odhadnout náklady. Cílem je poskytnout architektům a vedoucím vývoje rámec pro rozhodnutí, kde bezserverový přístup nasadit a kde se mu raději vyhnout.
Co serverless skutečně je a není
Pod pojmem serverless se v AWS skrývá především model funkcí jako služby (Lambda), automatické škálování od nuly do tisíců souběžných instancí, platba za skutečnou spotřebu a událostmi řízené propojení s ostatními službami. Za serverless se ovšem dnes označují i kontejnerové služby Fargate a App Runner, datová úložiště typu DynamoDB nebo Aurora Serverless a integrační komponenty jako EventBridge, SQS a Step Functions.
Co serverless nenabízí, je úplná absence provozních povinností. Sledování, ladění výkonu, řízení přístupů a správa nasazení nezmizí, jen se přesunou na jinou úroveň. Stejně tak neplatí, že je vždy levnější. Pro stabilní workload s predikovatelným zatížením vychází kontejnery nebo rezervované instance výhodněji. Konečně serverless nepředstavuje neutrální volbu z hlediska závislosti na poskytovateli; provozní model i nástroje jsou specifické pro AWS.
Architektonické vzory v produkci
Základem většiny řešení je událostmi řízený model. Klient zavolá API Gateway, ta předá požadavek do funkce Lambda, která buď vrátí odpověď synchronně, nebo publikuje událost do EventBridge či SQS, kterou dále zpracovávají specializované funkce. Tento přístup zlepšuje odolnost: selhání jedné komponenty neznamená výpadek celého toku a každou část lze nezávisle škálovat i nasazovat.
Při návrhu se vyplatí promyslet granularitu. Příliš jemné funkce typu „getUserName" generují zbytečnou síťovou komunikaci a obtížně se ladí. Příliš hrubé funkce, které řeší celou doménu, zase ztrácejí výhody nezávislého škálování a delšího nasazení. Praktický kompromis je rozdělení podle obchodních úkonů – zpracování platby, odeslání notifikace, validace uživatele.
Pro koordinaci delších procesů se nabízejí dvě cesty. Choreografie pomocí událostí poskytuje volné vazby a snadné rozšiřování o další konzumenty, ale ztěžuje sledování celkového toku. Orchestrace v Step Functions naopak přináší vizuální mapu workflow a centralizované ošetření chyb za cenu vyšší vazby na konkrétní službu. V praxi se obě techniky kombinují podle povahy procesu.
Vzor backendu pro frontend (BFF) se v serverless prostředí osvědčuje pro mobilní a webové klienty. Jediná funkce agreguje data z několika interních služeb, vrací je v podobě uzpůsobené konkrétnímu klientovi a šetří síťové cesty.
Studený start a jak ho zkrotit
Studený start vzniká, když AWS musí pro novou žádost připravit běhové prostředí. Doba inicializace se pohybuje od desítek milisekund pro Go a Rust přes stovky milisekund pro Node.js a Python až po jednotky sekund pro Javu a .NET. Pro pozadí běžící úlohy je tato režie obvykle nepodstatná, pro uživatelská API však může být citelná.
Účinnou obranou je volba běhového prostředí, redukce velikosti balíku, oddělení inicializačního kódu mimo handler a opětovné využití klientů AWS SDK. Pro kritická API nabízí AWS rezervovanou souběžnost, která drží určený počet připravených instancí, případně lze využít plánované „zahřívání" pomocí EventBridge. Provoz funkce ve VPC studený start prodlužuje, protože je nutné přidělit síťové rozhraní; pro funkce volané z internetu je proto vhodné se VPC vyhnout, pokud k vnitřním zdrojům nepřistupují.
Databáze v bezserverovém světě
Klasické relační databáze počítají s dlouhožijícími aplikačními procesy a omezeným počtem trvalých spojení. Lambda však může v okamžiku špičky vytvořit tisíce paralelních instancí, což rychle vyčerpá konexní limit databáze. Standardním řešením je RDS Proxy, který udržuje fond spojení a Lambdám předkládá rychlou připojovací vrstvu.
Pro nové aplikace stojí za úvahu DynamoDB. Komunikuje přes HTTP, takže problém s navazováním spojení odpadá, škáluje se podle skutečného zatížení a nabízí latence pod deset milisekund. Vyžaduje však jiný způsob datového modelování. Návrh jedné tabulky s pečlivě zvolenými klíči a sekundárními indexy umožňuje pokrýt většinu přístupových vzorů aplikace, ale klade vyšší nároky na předem promyšlený model.
Integrace, monitoring a sledování chování
API Gateway nabízí tři základní způsoby integrace s Lambdou: proxy integrace s plnou kontrolou nad odpovědí, ne-proxy integrace s mapováním požadavků a odpovědí pro starší klienty a přímá integrace na další služby AWS bez Lambdy v cestě. Posledně jmenovaný přístup minimalizuje latenci i náklady tam, kde stačí jednoduchá transformace, například zápis do SQS nebo dotaz do DynamoDB.
Pro nahrávání souborů je vhodnější vyhnout se Lambdě v hlavní cestě. Klient si vyžádá podepsanou URL adresu, soubor nahraje přímo do S3 a navazující zpracování se spustí jako reakce na S3 událost. Tím se obejdou limity Lambdy na velikost požadavku i dobu běhu.
Sledování chování distribuovaného serverless systému vyžaduje strukturované logy v CloudWatch, distribuované trasování v X-Ray a metriky reflektující obchodní význam, nejen technické ukazatele. Strukturované logy s identifikátorem transakce umožní dohledat veškeré kroky napříč funkcemi pomocí dotazů v CloudWatch Insights. X-Ray pak poskytne mapu závislostí a identifikuje úzká místa.
Náklady a kdy serverless nevolit
Cena Lambdy se skládá z platby za počet vyvolání, dobu běhu váženou přidělenou pamětí a případně rezervovanou souběžnost. Paměť přitom přímo úměrně škáluje i přidělený výkon, takže vyšší alokace často zkrátí běh natolik, že celkové náklady klesnou. Vyplatí se proto provádět měření a hledat optimum, nikoliv volit nejmenší možnou hodnotu paměti.
U stabilního provozu s desítkami milionů žádostí měsíčně může klasický kontejnerový provoz vycházet levněji než Lambda. Hraniční bod závisí na konkrétním profilu zatížení a délce běhu funkcí, ale při průměrném vytížení nad zhruba čtyřicet procent kapacity se obvykle nevyplatí. Pro nepravidelné nebo výrazně sezónní zatížení naopak serverless dramaticky šetří.
Serverless se nehodí pro dlouhotrvající procesy přesahující limity běhu Lambdy, pro výpočetně náročné stavové úlohy, pro aplikace vyžadující předvídatelnou velmi nízkou latenci a pro situace, kdy je strategickým požadavkem nezávislost na konkrétním poskytovateli cloudu.
Bezpečnost, testování a nasazení
Serverless prostředí klade důraz na princip minimálních oprávnění. Každá funkce by měla mít vlastní roli IAM s úzce vymezenými právy ke konkrétním zdrojům. Tajemství patří do AWS Secrets Manager nebo Parameter Store a do funkce vstupují přes proměnné prostředí nebo runtime volání. Validace vstupů by měla probíhat již na úrovni API Gateway, aby se zamezilo zbytečnému spouštění funkcí na neplatných požadavcích.
Pro testování se osvědčuje kombinace jednotkových testů aplikační logiky, integračních testů proti reálným službám v izolovaném účtu a kontraktních testů ověřujících formát událostí. Nástroje SAM a CDK umožňují popsat infrastrukturu jako kód a automatizovat nasazení v CI/CD pipeline. Pro produkci je vhodné využívat strategii postupného vystavování (canary nebo lineární deployment) ve spojení s alarmy nad metrikami, které v případě regrese automaticky vrátí provoz na předchozí verzi.
Závěr
Serverless v AWS změnil ekonomiku i způsob návrhu cloudových aplikací. Pro událostmi řízené workloady, nepravidelné zatížení a malé týmy bez vlastního provozního oddělení představuje dnes výchozí volbu. Úspěšné nasazení však vyžaduje pochopení architektonických vzorů, vědomé řešení studených startů a databázových spojení, důsledný monitoring a střízlivý odhad nákladů. Serverless není o odstranění serverů, je o odstranění starostí o jejich provoz, a tato hranice rozhoduje, zda se daný workload pro tento model hodí.
