Mi az a szerver nélküli (serverless) működés? Egyszerűen elmagyarázva

A serverless egy kódfuttatási mód, amelynél nem állítasz be és nem kezelsz semmilyen szervert. A kódodat egy felhőszolgáltatónak adod, az pedig csak akkor futtatja, ha valami elindítja – egy webes kérés, egy feltöltött fájl, egy fizetési értesítés –, majd leáll. Általában azt az időt fizeted, amíg a kódod ténylegesen fut, nem egy tétlenül álló gépet.

Miért fontos a serverless, ha AI-val építkezel

Ha AI-val építesz alkalmazást, és tárhelyopciókat vagy kódot nézel, összefutsz a „serverless függvények”, „edge függvények” vagy „felhőfüggvények” kifejezésekkel. Sok tárhelyplatform kínálja őket, és néhány AI-építő így telepíti a backendet. A modell megértése három gyakorlati kérdésben segít:

• Költség. Fizetni fogsz az alkalmazásért, amikor senki sem használja?
• Sebesség. Miért lassabb az első kérés egy csendes időszak után?
• Korlátok. Miért járt le a időkorlát egy hosszú feladatnál – egy nagy jelentés generálásánál vagy egy videó feldolgozásánál?

Az is segít tudni, mit nem jelent a serverless: nem azt jelenti, hogy nincs backend. Továbbra is van szerveroldali kódod; csak más futtatja a gépeket. Az alapokért lásd: mi az a szerver.

Hétköznapi hasonlat

A hagyományos szerver olyan, mint egy autó tulajdonlása. Mindig ott van, azonnal indulásra kész, de fizetsz érte – biztosításért, parkolásért, karbantartásért –, akár használod, akár nem.

A serverless olyan, mint taxit hívni. Csak az utak után fizetsz, és ha száz embernek kell egyszerre fuvar, száz taxi jön. Viszont rövid várakozás lehet, amíg az autó megérkezik (ez a hideg indítás), minden út maximális hosszúságú, és a sofőr nem emlékszik rád az előző fuvar után (a függvények állapotmentesek).

Hogyan működnek a serverless függvények

A legelterjedtebb formában, amelyet functions as a service-nek (FaaS) hívnak:

1. Írsz egy függvényt – egy kis kódrészletet, amely egyfajta eseményt kezel, például „kezeld a POST kérést a /api/bookings útvonalon”.
2. Telepíted. A szolgáltató tárolja, és egy eseményindítóhoz köti: egy URL-hez, egy ütemezéshez, egy új fájlhoz a tárolóban, vagy egy üzenethez a sorban.
3. Esemény érkezik. A szolgáltató elindít egy példányt a függvényedből (vagy újrahasznosít egy meleg példányt), lefuttatja, és visszaadja az eredményt.
4. Magától skálázódik. Ha egyszerre ezer kérés érkezik, a szolgáltató párhuzamosan sok példányt futtat, a fiókod korlátaiig.
5. Tétlenné válik. Ha leáll a forgalom, a példányok leállnak. Ha nincs semmi futva, a számítási költség nulla.

Egy apró serverless függvény JavaScriptben nagyjából így nézhet ki:

export default async function handler(request) {
  const { name } = await request.json();
  return Response.json({ message: `Hello, ${name}` });
}

Nincs szükség kódra szerver indításához, portok nyitásához vagy folyamat életben tartásához. Ezt mind a platform intézi.

A „serverless” kifejezést lazábban más, automatikusan skálázódó, használat szerint számlázott menedzselt szolgáltatásokra is használják – például a serverless adatbázisokra, amelyek tétlenség esetén szüneteltetnek.

Kulcsfogalmak

Munkapélda: egy kis foglalási oldal

Egy jógastúdió foglalási oldalára minden vasárnap este rohamszerűen érkeznek a látogatók, amikor kikerül az új órarend, a hét többi részében pedig alig.

• Állandóan futó szerveren a stúdió non-stop fizet egy gépért, amelyet a vasárnap esti csúcsra méreteztek, és a többi időben nagyrészt tétlen.
• Serverless függvényekkel a GET /api/classes és a POST /api/bookings függvények. A vasárnapi rohamot automatikusan sok példány követi; egy csendes keddi reggelen szinte semmi nem fut, és a számla közel nulla.

A kompromisszumok is megjelennek. Az első ember, aki kedd reggel megnyitja az oldalt, egy kicsit többet várhat a hideg indításra. Az adatbázisnak sok rövid életű kapcsolatot kell kezelnie sok függvénypéldánytól, ami kapcsolatkezelő (connection pooler) használatát indokolhatja. Ha a stúdió később egy „generáld mindenki éves részvételi PDF-jét” feladatot szeretne, az túllépheti a függvény időkorlátját, és máshol kell futnia.

Mikor jó a serverless – és mikor nem

Gyakori tévhitek

• „A serverless azt jelenti, hogy nincs backend.” Azt jelenti, hogy nincsenek kezelendő szerverek. A backend kódot továbbra is meg kell írnod és biztosítanod.
• „A serverless mindig olcsóbb.” Kis volumen mellett az, de kérésenkénti árazásnál nagy, állandó volumen mellett a költségek összeadódhatnak.
• „A serverless végtelenül skálázódik.” A platformoknak van párhuzamossági korlátjuk, és az adatbázisod sokkal előbb szűk keresztmetszet lehet, mint a függvények.
• „A függvényben mentett fájlok legközelebb is ott lesznek.” A helyi tárolás ideiglenes. Használj adatbázist vagy fájltárhelyet.
• „A nullára skálázás ugyanaz, mint a serverless.” Rokon, de nem azonos. Egyes platformok az alkalmazásodat hagyományos szerverként futtatják, amely tétlenül elalszik, és a következő kérésre felébred – hasonló megtakarítással és hasonló első kérés-késleltetéssel, de függvényszerű kérésenkénti időkorlát nélkül.

Mit kérj az AI-építődtől

• „Ez a backend serverless függvényként fut, vagy állandóan futó, illetve elalvó szerverként? Mit jelent ez a költség szempontjából?”
• „Van olyan feladat, amely valószínűleg hosszabb lesz a platform időkorlátjánál? Ha igen, hogyan kezeljük?”
• „Minden maradandó adatot az adatbázisban vagy fájltárhelyen tárolj, ne memóriában vagy helyi fájlokban.”
• „Hogyan kezeljük az adatbázis-kapcsolatokat, ha sok példány fut egyszerre?”
• „Mennyi a késleltetés az első kérésnél, miután az alkalmazás tétlen volt?”

Hogyan szolgálja ki a Mythex az alkalmazásokat

A Mythex nem serverless függvényekként írja le a tárhelyét. Közzétételkor az alkalmazásod normál webalkalmazásként vagy konténerként fut, amelyet a Mythex kezel helyetted – nincs beállítanivaló tárhely. Ez nullára skálázás: a közzétett alkalmazások és adatbázisaik tétlenül elalszanak, és a következő látogatásra felébrednek; az elalvó alkalmazás nem fizet számítási költséget, a plusz gépek pedig csak nagy forgalomnál indulnak (Pro csomagban szolgáltatásonként legfeljebb 3). A csatolt Postgres adatbázis is 5 perc tétlenség után elalszik, és a felébren töltött időért számláz. Így a „fizess azt, amit használsz” előny nagy részét megkapod, csendes időszak utáni első kérés-késleltetéssel együtt. Lásd a dokumentációban a tárhelykorlátokat, illetve az útmutatóinkat a webhostingról és a tárhelyköltségek csökkentéséről.

Kérdések