Abstrakt Bezserverové databáze představují odklon od dlouholetého modelu, ve kterém organizace platily za databázovou kapacitu připravenou na špičku, ač ji většinu času nevyužily. Oddělení výpočetní a úložné vrstvy umožňuje měnit přidělené prostředky v řádu sekund a v některých případech klesnout až k nule. Článek mapuje hlavní zástupce této kategorie, zejména Amazon Aurora Serverless v2, Azure SQL Database Serverless, MongoDB Atlas Serverless a PlanetScale, srovnává jejich modely cenotvorby, ukazuje typické úspory u proměnlivého zatížení a věnuje se i provozním rizikům, jako jsou studené starty a omezení funkcí.
Od pevné kapacity k platbě za skutečnou spotřebu
Po dvě desetiletí byl provoz databází postaven na předpokladu, že server musí být vždy zapnutý a dimenzovaný na špičkové zatížení. Tento přístup přinášel předvídatelnost, ale i výrazné plýtvání. Studie vytíženosti běžných databázových instancí dlouhodobě ukazují, že průměrné využití procesoru zřídka překračuje třicet procent, přičemž zákazník platí stoprocentní cenu.
Bezserverové databáze tento model mění. Výpočetní vrstva se pružně přizpůsobuje aktuálnímu zatížení, úložiště je samostatné a roste průběžně. Cena se odvíjí od skutečné spotřeby, ať už měřené v jednotkách kapacity (Aurora Capacity Unit), virtuálních jádrech, požadavkových jednotkách nebo konkrétním počtu čtení a zápisů. Vývojová a testovací prostředí se tak stávají téměř zdarma, protože v noci a o víkendech databáze klesá na minimální spotřebu.
Oddělení výpočtu a úložiště jako základ
Klasická databáze sdružuje procesor, paměť a disk v jedné instanci. Změna kapacity znamená přesun na větší stroj a obvykle krátký výpadek. Bezserverové databáze tuto vazbu rozbíjejí. Výpočetní uzly jsou bezstavové, sdílené napříč zákazníky a dokážou se vytvořit či ukončit během sekund. Úložná vrstva je distribuovaná, replikovaná napříč zónami a roste podle potřeby bez zásahu administrátora.
Tato architektura přináší tři hlavní praktické důsledky. Škálování se měří v sekundách, ne v minutách nebo hodinách. Zálohování a obnovení do bodu v čase nevyžadují přerušení provozu. A konečně, idle náklady mohou být velmi nízké, protože platba se vztahuje k aktuální výpočetní spotřebě, nikoli k vyhrazenému stroji.
Aurora Serverless v2
Druhá generace Aurora Serverless přinesla zásadní zlepšení oproti původní verzi. Kapacita se mění v krocích po půl jednotce ACU, škálování proběhne pod patnáct sekund a databáze podporuje běžné MySQL i PostgreSQL ovladače bez nutnosti používat HTTP Data API. Zachovává se vysoká dostupnost přes více zón a integrace s ekosystémem AWS, včetně RDS Proxy pro správu spojení.
Cena se odvíjí od průměrné spotřeby ACU za hodinu. Na typickém workloadu elektronického obchodu, který má dvacet hodin denně lehký provoz a čtyři hodiny špičky, vychází měsíční náklad přibližně o sedmdesát procent nižší než u rezervované instance dimenzované na špičku. Aurora Serverless v2 už, na rozdíl od první verze, nepauzuje na nulu, takže studené starty v kritickém významu zmizely; pro skutečné nulování slouží jiné nástroje.
Azure SQL Database Serverless
Microsoft nabízí v rámci Azure SQL Database režim spotřeby měřený v jednotkách vCore za sekundu. Databáze se dokáže pozastavit po nastavené době neaktivity (typicky hodiny až dny) a po novém připojení během desítek sekund obnovit. Tento model je ideální pro vývojová a testovací prostředí, méně už pro produkční API s nízkou tolerancí latence.
Cena zahrnuje výpočetní část účtovanou po sekundách aktivity, datové úložiště a transakční logy. Pro aplikaci s aktivním používáním osm hodin denně může výsledná částka klesnout na čtvrtinu rezervované instance srovnatelného výkonu.
MongoDB Atlas Serverless
MongoDB Atlas Serverless přechází od kapacitního modelu k modelu jednotek operací. Účtuje samostatně za čtení, zápisy a uložená data v gigabajtech. Pro aplikace s nepravidelným provozem se tak často podaří dosáhnout úspory v řádu desítek procent oproti vyhrazenému clusteru.
Bezserverový režim však s sebou nese omezení. Není dostupné globální nasazení napříč regiony, vyhledávací index Atlas Search a některé pokročilé funkce. Před migrací je proto třeba ověřit, zda aplikace tyto možnosti nepotřebuje, případně zvážit hybridní nasazení.
PlanetScale a větvení schémat
PlanetScale staví na distribuovaném MySQL projektu Vitess a do databázového světa přináší koncept větvení známý z verzování zdrojového kódu. Vývojář vytvoří větev schématu, provede na ní změny, otestuje je proti reálným datům a následně otevře žádost o nasazení. Sloučení do hlavní větve probíhá bez výpadku.
Tento přístup výrazně mění způsob práce s migracemi. Odpadá obava z dlouhého zámku tabulky při přidání sloupce nebo indexu, riziko ztráty dat se snižuje a možnost otestovat změnu na produkčních datech bez kopírování dramaticky zkracuje vývojový cyklus. Cenou za to je absence cizích klíčů, kterou je nutné kompenzovat na úrovni aplikace, a vázanost na MySQL.
Studené starty a jak je zmírnit
Bezserverové databáze, které dokážou klesnout na nulu, čelí problému studeného startu. První dotaz po dlouhé pauze čeká na probuzení výpočetní vrstvy, navázání spojení k úložišti a zahřátí cache. Časy se pohybují od stovek milisekund u Cosmos DB až po desítky sekund u Azure SQL Serverless v hlubokém režimu pauzy.
V produkčním nasazení proto patří mezi standardní opatření plánované pingování databáze v kratších intervalech, využití fondu spojení (RDS Proxy, PgBouncer) a aplikační logika s opakováním požadavků a krátkým exponenciálním odstupem. Pro uživatelská API s nízkou latencí je vhodnější vybrat databázi, která pauzu nepodporuje, případně nastavit minimální kapacitu nad nulou.
Ekonomika a kdy se vyplatí
Modelové výpočty na reálných workloadech ukazují tři typické scénáře, kde bezserverové databáze přinášejí největší úsporu. První jsou vývojová a testovací prostředí, kde lze realisticky čekat snížení nákladů o osmdesát až devadesát procent. Druhým jsou aplikace se sezónními špičkami, například elektronické obchody nebo systémy pro sportovní sázky, kde rozdíl mezi špičkou a klidovým provozem dosahuje řádu. Třetím jsou nové aplikace s neznámým profilem zatížení, u kterých vyhrazená kapacita představuje sázku do neznáma.
Naopak pro stabilní workloady se stálým vysokým využitím vychází rezervovaná kapacita levněji. Hraniční bod, nad kterým přestává mít smysl bezserverový režim, se obvykle uvádí kolem čtyřiceti procent průměrného využití. Při rozhodování je proto třeba sledovat skutečný profil zatížení v čase, nikoliv jen průměry.
Volba a migrace
Při výběru konkrétního řešení je vhodné zvážit pět kritérií: cenovou strukturu vůči očekávanému profilu zatížení, výkonnostní požadavky včetně tolerance studených startů, povahu vývojového procesu a požadavek na větvení, provozní složitost a uzamčení k poskytovateli. Žádný produkt nevítězí ve všech kategoriích, rozhodnutí by proto mělo vycházet z konkrétních priorit dané aplikace.
Migrace ze stávající instance probíhá nejlépe ve fázích. V první se vyhodnotí kompatibilita aplikace, využité funkce databáze a způsob, jakým aplikace pracuje se spojeními. Druhou fází je pilotní nasazení v nevýrobním prostředí, ve kterém se ladí parametry škálování, zálohování a alarmy. Třetí fází je vlastní přechod, ideálně s metodou modré a zelené větve nebo postupným přesměrováváním provozu, doplněný o automatické vrácení v případě regrese výkonu.
Závěr
Bezserverové databáze nepředstavují stříbrnou kulku. Pro stabilní workload se stálým zatížením stále vítězí klasické instance s rezervovanou kapacitou. Pro proměnlivé, nepravidelné nebo nově startující aplikace však mění ekonomiku i způsob práce. Hodnota není pouze v úspoře nákladů, ale v možnosti soustředit se na aplikační logiku místo plánování kapacity. Kombinace pružného výpočtu, oddělené úložné vrstvy a inteligentního řízení spotřeby tvoří základ, na němž bude stát příští generace cloudových datových služeb.
