Röviden: A Lambda-skálázás megöli a klasszikus connection poolt: minden példány új kapcsolatot nyit, és az adatbázis kifogy. Az RDS Proxy vagy a data API a megoldás.
A serverless és a relációs adatbázis párosítása gyakran egy csúnya meglepetéssel jár, amit senki nem lát előre a fejlesztés során: a kapcsolatszám-probléma. A rendszer szépen fut fejlesztésben és kis terhelésen, aztán jön a forgalmi csúcs, és az adatbázis egyszerre elkezdi visszautasítani a kapcsolatokat. A gyökér a serverless és a klasszikus adatbázis-kapcsolatkezelés alapvető feszültsége.
Miért ütközik a két világ?
A hagyományos alkalmazásszerver néhány hosszú életű kapcsolatot tart fenn az adatbázishoz, és ezeket újrahasználja egy connection poolból. Ez hatékony, mert a kapcsolat felépítése drága, és így ritkán kell megtenni. A serverless viszont másképp működik: sok, egymástól független végrehajtási példány jön létre a terheléshez, és mindegyik saját kapcsolatot nyitna. Csúcson ez a kapcsolatok robbanását okozza.
A robbanás mechanizmusa
Képzeld el, hogy a forgalom megugrik, és a platform sok párhuzamos függvénypéldányt indít. Ha mindegyik nyit egy-egy adatbázis-kapcsolatot, akkor a kapcsolatok száma a párhuzamosság mértékével nő. A relációs adatbázisoknak viszont véges a kapcsolatszám-korlátjuk, és azt gyorsan elérheted — onnantól az új kérések elutasításra kerülnek, és az egész rendszer elhasal, pont a legrosszabb pillanatban.
A megoldás 1: kapcsolat-proxy
A legelterjedtebb válasz egy kapcsolat-proxy (mint az RDS Proxy) beiktatása a függvények és az adatbázis közé. A proxy egy közös kapcsolatkészletet tart fenn az adatbázis felé, és a sok függvénypéldányt ehhez a megosztott készlethez multiplexeli. Így a függvények számától függetlenül az adatbázis felé a kapcsolatok száma kordában marad. Ez a legkevésbé invazív megoldás — jellemzően nem kell átírni az alkalmazáslogikát.
A megoldás 2: HTTP-alapú adathozzáférés
Egy másik megközelítés, amikor a relációs adatbázist nem közvetlen kapcsolaton, hanem egy HTTP-alapú adat-API-n keresztül éred el. Itt nincs hagyományos, tartós kapcsolat, tehát a kapcsolatszám-probléma fel sem merül. Ennek megvannak a maga korlátai és kompromisszumai (nem minden mintához ideális), de bizonyos serverless workloadokhoz kiváló illeszkedés.
| Megoldás | Előny | Megfontolás |
|---|---|---|
| Kapcsolat-proxy | Kevés kódváltozás, kezeli a poolt | Egy plusz komponens |
| HTTP adat-API | Nincs kapcsolatprobléma | Más hozzáférési modell, korlátok |
| Kapcsolat-limit a függvényen | Egyszerű mérséklés | Nem oldja meg teljesen |
A tervezés az elején
A legjobb, ha ezzel a problémával nem éles incidensben találkozol először. Amikor serverless és relációs adatbázis párosítását tervezed, már az elején számolj a kapcsolatkezeléssel: tervezz be proxyt vagy adat-API-t, és terheléses teszttel ellenőrizd, hogy a kapcsolatszám csúcson is kordában marad. A skálázhatóság ígérete csak akkor tartható, ha az adatbázis-kapcsolat nem lesz a rejtett plafon.
A kapcsolatrobbanás mechanizmusa
A probléma gyökere a serverless és a klasszikus kapcsolatkezelés feszültsége. A hagyományos alkalmazásszerver néhány hosszú életű kapcsolatot tart fenn és újrahasznál egy poolból. A serverless viszont sok, egymástól független végrehajtási példányt indít a terheléshez, és mindegyik saját kapcsolatot nyitna. Csúcson, amikor a platform sok párhuzamos példányt indít, a kapcsolatok száma a párhuzamossággal nő — és a relációs adatbázis véges kapcsolatkorlátját gyorsan eléri.
Onnantól az új kérések elutasításra kerülnek, és a rendszer elhasal, pont a legrosszabb pillanatban. A klasszikus, függvényen belüli pool itt nem segít — sőt árt, mert minden hideg példány új poolt nyitna.
A megoldások
Két fő válasz van. Az egyik egy kapcsolat-proxy (mint az RDS Proxy) a függvények és az adatbázis közé: egy közös kapcsolatkészletet tart fenn, és a sok függvénypéldányt ehhez multiplexeli, így az adatbázis felé a kapcsolatok száma kordában marad. A másik egy HTTP-alapú adat-API, ahol nincs tartós kapcsolat, tehát a probléma fel sem merül.
- Kapcsolat-proxy: kevés kódváltozás, kezeli a poolt.
- HTTP adat-API: nincs kapcsolatprobléma, más hozzáférési modell.
Mit jelent ez neked?
A serverless és a relációs adatbázis között alapvető feszültség van: a sok párhuzamos függvénypéldány kimerítheti az adatbázis kapcsolatkorlátját, és a rendszer pont csúcson hasal el. A klasszikus, függvényen belüli connection pool itt nem segít. Iktass be egy kapcsolat-proxyt, ami megosztott kapcsolatkészletet tart fenn, vagy használj HTTP-alapú adat-API-t, ahol a probléma fel sem merül. Tervezd ezt be az elején, és teszteld terheléssel — így a skálázhatóság valós marad, nem csak ígéret.