A szerver nélküliség nem a szerverek fizikai hiányáról szól. Ez nem konténergyilkos vagy múló trend. Ez egy új megközelítés a rendszerek felhőben történő felépítéséhez. Mai cikkünkben a Serverless alkalmazások architektúráját fogjuk érinteni, nézzük meg, milyen szerepet tölt be a Serverless szolgáltató és a nyílt forráskódú projektek. Végül beszéljünk a Serverless használatának problémáiról.
Szeretnék egy alkalmazás (vagy akár egy webáruház) szerver részét írni. Ez lehet egy csevegés, egy tartalom közzétételi szolgáltatás vagy egy terheléselosztó. Mindenesetre sok fejtörés lesz: elő kell készíteni az infrastruktúrát, meg kell határozni az alkalmazásfüggőségeket, és át kell gondolni a gazdagép operációs rendszerét. Ezután frissítenie kell a kis alkatrészeket, amelyek nem befolyásolják a monolit többi részének működését. Nos, ne feledkezzünk meg a terhelés alatti méretezésről.
Mi van, ha efemer konténereket veszünk, amelyekben a szükséges függőségek már előre telepítve vannak, és maguk a tárolók el vannak szigetelve egymástól és a gazdagép operációs rendszertől? A monolitot mikroszolgáltatásokra fogjuk felosztani, amelyek mindegyike a többitől függetlenül frissíthető és méretezhető. A kódot egy ilyen konténerbe helyezve bármilyen infrastruktúrán futtathatom. Már jobban.
Mi a teendő, ha nem akar konténereket konfigurálni? Nem akarok az alkalmazás méretezésére gondolni. Nem akarok üresen futó konténerekért fizetni, amikor a szolgáltatás terhelése minimális. Kódot akarok írni. Összpontosítson az üzleti logikára, és vigye piacra a termékeket fénysebességgel.
Az ilyen gondolatok a szerver nélküli számítástechnikához vezettek. Szerver nélküli ebben az esetben azt jelenti nem a szerverek fizikai hiánya, hanem az infrastruktúra-kezelési fejfájás hiánya.
Az ötlet az, hogy az alkalmazáslogikát független függvényekre bontják. Eseménystruktúrájuk van. Minden funkció egy „mikrofeladatot” hajt végre. A fejlesztőtől mindössze annyit kell tennie, hogy a funkciókat a felhőszolgáltató által biztosított konzolba töltse be, és az eseményforrásokkal korrelálja. A kód igény szerint automatikusan elkészített konténerben kerül végrehajtásra, és csak a végrehajtási időt fizetem.
Lássuk, hogyan fog most kinézni az alkalmazásfejlesztési folyamat.
A fejlesztő oldaláról
Korábban elkezdtünk beszélni egy online áruház alkalmazásáról. A hagyományos megközelítésben a rendszer fő logikáját egy monolitikus alkalmazás hajtja végre. Az alkalmazással rendelkező szerver pedig folyamatosan fut, még akkor is, ha nincs terhelés.
A szerver nélküli használathoz az alkalmazást mikrofeladatokra bontjuk. Mindegyikhez saját függvényt írunk. A függvények egymástól függetlenek, állapotinformációkat nem tárolnak (állammentes). Akár különböző nyelveken is megírhatók. Ha egyikük „leesik”, az egész alkalmazás nem áll le. Az alkalmazás architektúrája így fog kinézni:
A szerver nélküli funkciókra való felosztás hasonló a mikroszolgáltatások használatához. De egy mikroszolgáltatás több feladatot is elláthat, és ideális esetben egy funkciónak egyet kell végrehajtania. Képzeljük el, hogy a feladat statisztikai adatok gyűjtése és megjelenítése a felhasználó kérésére. A mikroszolgáltatásos megközelítésben egy feladatot egy szolgáltatás lát el két belépési ponttal: írással és olvasással. A szerver nélküli számítástechnikában ez két különböző függvény lesz, amelyek nem kapcsolódnak egymáshoz. A fejlesztő megtakarítja a számítási erőforrásokat, ha például a statisztikákat gyakrabban frissítik, mint amennyit letöltenek.
A szerver nélküli funkciókat a szolgáltató által meghatározott rövid időn belül (timeout) kell végrehajtani. Például az AWS esetében az időkorlát 15 perc. Ez azt jelenti, hogy a hosszú élettartamú funkciókat a követelményeknek megfelelően módosítani kell – ez különbözteti meg a Serverless-t a mai népszerű technológiáktól (konténerek és platform mint szolgáltatás).
Minden funkcióhoz eseményt rendelünk. Egy esemény kiváltója egy műveletnek:
esemény
A funkció által végrehajtott művelet
A termék képe feltöltve az adattárba.
Tömörítse a képet és töltse fel egy könyvtárba
A fizikai bolt címe frissítve lett az adatbázisban
Új hely betöltése a térképekbe
Az ügyfél fizeti az árut
Indítsa el a fizetés feldolgozását
Az események lehetnek HTTP kérések, adatfolyamok, üzenetsorok és így tovább. Az eseményforrások az adatok változásai vagy előfordulásai. Ezenkívül a funkciókat egy időzítő is kiválthatja.
Az architektúrát kidolgozták, és az alkalmazás szinte szerver nélkülivé vált. Ezután megyünk a szolgáltatóhoz.
A szolgáltató oldaláról
A szerver nélküli számítástechnikát jellemzően felhőszolgáltatók kínálják. Másképpen hívják őket: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
A szolgáltatást a szolgáltató konzolján vagy személyes fiókján keresztül fogjuk használni. A funkciókód az alábbi módok egyikén tölthető le:
- írjon kódot a beépített szerkesztőkbe a webkonzolon keresztül,
- töltse le az archívumot a kóddal,
- nyilvános vagy privát git-tárolókkal dolgozni.
Itt állítjuk be a függvényt meghívó eseményeket. Az események sorozata a különböző szolgáltatóknál eltérő lehet.
A szolgáltató kiépítette és automatizálta a Function as a Service (FaaS) rendszert infrastruktúráján:
- A funkciókód a szolgáltatói oldalon lévő tárhelyen végzi.
- Amikor egy esemény bekövetkezik, az előkészített környezettel rendelkező tárolók automatikusan telepítésre kerülnek a kiszolgálón. Minden függvénypéldánynak saját elkülönített tárolója van.
- A tárolóból a függvény a tárolóba kerül, kiszámítja, és visszaadja az eredményt.
- A párhuzamos rendezvények száma egyre nő - a konténerek száma nő. A rendszer automatikusan skálázódik. Ha a felhasználók nem érik el a funkciót, az inaktív lesz.
- A szolgáltató állítja be a tárolók üresjárati idejét - ha ezalatt a funkciók nem jelennek meg a tárolóban, az megsemmisül.
Így kihozzuk a kiszolgáló nélkülit a dobozból. A szolgáltatásért a felosztó-kirovó modellt használva fizetünk, és csak a használt funkciókért, és csak a használat idejéért.
A fejlesztőknek a szolgáltatás megismertetése érdekében a szolgáltatók akár 12 hónapig ingyenes tesztelést kínálnak, de korlátozzák a teljes számítási időt, a havi kérések számát, a forrásokat vagy az energiafogyasztást.
A szolgáltatóval való együttműködés fő előnye, hogy nem kell aggódni az infrastruktúra miatt (szerverek, virtuális gépek, konténerek). A szolgáltató a maga részéről saját fejlesztésekkel és nyílt forráskódú eszközökkel is megvalósíthatja a FaaS-t. Beszéljünk róluk tovább.
Nyílt forráskódú oldalról
A nyílt forráskódú közösség az elmúlt néhány évben aktívan dolgozik a szerver nélküli eszközökön. A legnagyobb piaci szereplők is hozzájárulnak a szerver nélküli platformok fejlesztéséhez:
- Google nyílt forráskódú eszközét kínálja a fejlesztőknek - . A fejlesztésben az IBM, a RedHat, a Pivotal és az SAP vett részt;
- IBM szerver nélküli platformon dolgozott , amely aztán az Apache Alapítvány projektje lett;
- microsoft részben megnyitotta a platformkódot .
A szerver nélküli keretrendszerek irányába is folynak fejlesztések. и előre elkészített Kubernetes-fürtökben telepítve, működik a Kubernetes és a Docker Swarm segítségével is. A keretrendszer egyfajta vezérlőként működik - kérésre futási környezetet készít a fürtön belül, majd ott elindít egy funkciót.
A keretrendszerek lehetőséget adnak az eszköz igényeinek megfelelő konfigurálására. Tehát a Kubeless-ben a fejlesztő beállíthatja a függvényvégrehajtási időtúllépést (az alapértelmezett érték 180 másodperc). A fission a hidegindítási probléma megoldására azt javasolja, hogy egyes konténereket folyamatosan üzemeltessenek (bár ez erőforrás-leállási költségekkel jár). Az OpenFaaS pedig egy sor triggert kínál minden ízléshez és színhez: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NAT és mások.
Az induláshoz a keretrendszerek hivatalos dokumentációjában talál útmutatást. A velük való munka egy kicsit több készségre van szükség, mint egy szolgáltatóval való munka során – ez legalább a Kubernetes-fürt elindításának képessége a CLI-n keresztül. Legfeljebb más nyílt forráskódú eszközöket (például a Kafka sorkezelőt) tartalmazhat.
Függetlenül attól, hogy hogyan dolgozunk a Serverless-szel – szolgáltatón keresztül vagy nyílt forráskód használatával, számos előnye és hátránya lesz a szerver nélküli megközelítésnek.
Előnyök és hátrányok szempontjából
A Serverless egy konténer-infrastruktúra és egy mikroszolgáltatási megközelítés ötleteit fejleszti ki, amelyben a csapatok többnyelvű módban dolgozhatnak anélkül, hogy egy platformhoz lennének kötve. A rendszer felépítése leegyszerűsödik, a hibák pedig könnyebben javíthatók. A mikroszolgáltatási architektúra lehetővé teszi, hogy sokkal gyorsabban adjon új funkciókat a rendszerhez, mint egy monolitikus alkalmazás esetében.
A szerver nélküli tovább csökkenti a fejlesztési időt, lehetővé teszi a fejlesztő számára, hogy kizárólag az alkalmazás üzleti logikájára és kódolására összpontosítson. Ennek eredményeként csökken a fejlesztések piacra kerülésének ideje.
Bónuszként automatikus méretezést kapunk a terheléshez, és csak a felhasznált erőforrásokért fizetünk, és csak akkor, amikor azokat felhasználják.
Mint minden technológiának, a Serverlessnek is vannak hátrányai.
Ilyen hátrány lehet például a hidegindítási idő (átlagosan legfeljebb 1 másodperc olyan nyelveknél, mint a JavaScript, Python, Go, Java, Ruby).
Egyrészt a valóságban a hidegindítási idő sok változótól függ: a függvény írásának nyelvétől, a könyvtárak számától, a kód mennyiségétől, a további erőforrásokkal (ugyanazokkal az adatbázisokkal vagy hitelesítő szerverekkel) való kommunikációtól. Mivel a fejlesztő vezérli ezeket a változókat, csökkentheti az indítási időt. Másrészt a fejlesztő nem tudja szabályozni a konténer indítási idejét - minden a szolgáltatótól függ.
A hidegindítás melegindítássá válhat, ha egy funkció újra felhasznál egy korábbi esemény által elindított tárolót. Ez a helyzet három esetben fordul elő:
- ha az ügyfelek gyakran veszik igénybe a szolgáltatást, és megnő a funkcióra irányuló hívások száma;
- ha a szolgáltató, a platform vagy a keretrendszer lehetővé teszi, hogy bizonyos konténereket folyamatosan futtasson;
- ha a fejlesztő időzítőn futtat funkciókat (mondjuk 3 percenként).
Sok alkalmazásnál a hidegindítás nem jelent problémát. Itt a szolgáltatás típusára és feladataira kell építeni. A másodperces indítási késleltetés nem mindig kritikus az üzleti alkalmazásoknál, de az egészségügyi szolgáltatásoknál kritikussá válhat. Ebben az esetben a szerver nélküli megközelítés valószínűleg már nem lesz megfelelő.
A Serverless következő hátránya a függvény rövid élettartama (időtúllépés, amely alatt a függvényt végre kell hajtani).
De ha hosszú élettartamú feladatokkal kell dolgoznia, használhat hibrid architektúrát – kombinálja a Serverless-t egy másik technológiával.
Nem minden rendszer fog tudni működni a kiszolgáló nélküli séma használatával.
Egyes alkalmazások továbbra is tárolnak adatokat és állapotokat a végrehajtás során. Egyes architektúrák monolitikusak maradnak, egyes funkciók pedig hosszú életűek lesznek. Azonban (a felhőtechnológiákhoz, majd a konténerekhez hasonlóan) a Serverless egy nagy jövő előtt álló technológia.
Ennek jegyében szeretnék simán áttérni a szerver nélküli megközelítés használatának kérdésére.
Az alkalmazás oldaláról
2018-ban a szerver nélküli használat százalékos aránya . A technológiát szolgáltatásaikban már bevezetett cégek között vannak olyan piaci óriások, mint a Twitter, a PayPal, a Netflix, a T-Mobile, a Coca-Cola. Ugyanakkor meg kell értenie, hogy a Serverless nem csodaszer, hanem egy bizonyos problémakör megoldásának eszköze:
- Csökkentse az erőforrás-leállást. Nincs szükség folyamatosan virtuális gépre a kevés hívással rendelkező szolgáltatásokhoz.
- Menet közben dolgozza fel az adatokat. Tömörítsen képeket, vágja ki a háttereket, módosítsa a videó kódolását, dolgozzon IoT-érzékelőkkel, végezzen matematikai műveleteket.
- Más szolgáltatásokat „összeragasztani”. Git repository belső programokkal, chat bot a Slackben Jira-val és naptár.
- Egyensúlyozza a terhelést. Nézzük meg itt közelebbről.
Tegyük fel, hogy van egy szolgáltatás, amely 50 embert vonz. Alatta van egy virtuális gép gyenge hardverrel. Időről időre jelentősen megnő a szolgáltatás terhelése. Ekkor a gyenge hardver nem tud megbirkózni.
A rendszerbe beépíthet egy egyensúlyozót, amely elosztja a terhelést, mondjuk, három virtuális gép között. Ebben a szakaszban nem tudjuk pontosan megjósolni a terhelést, ezért bizonyos mennyiségű erőforrást „tartalékban” tartunk. És túlfizetünk az állásidőért.
Ilyen helyzetben hibrid megközelítéssel optimalizálhatjuk a rendszert: egy virtuális gépet hagyunk a terheléselosztó mögött, és hivatkozást helyezünk el a szerver nélküli végpontra függvényekkel. Ha a terhelés meghaladja a küszöbértéket, a kiegyenlítő olyan függvénypéldányokat indít el, amelyek átveszik a kérésfeldolgozás egy részét.
Így a Serverless ott használható, ahol nagyszámú kérés feldolgozására van szükség nem túl gyakran, hanem intenzíven. Ebben az esetben több funkció 15 perces futtatása jövedelmezőbb, mint egy virtuális gép vagy szerver folyamatos karbantartása.
A kiszolgáló nélküli számítástechnika minden előnyével a megvalósítás előtt először értékelnie kell az alkalmazás logikáját, és meg kell értenie, hogy a Serverless milyen problémákat tud megoldani egy adott esetben.
Szerver nélküli és Selectel
A Selectelnél már ott vagyunk a vezérlőpultunkon keresztül. Most saját FaaS platformot építünk. Azt akarjuk, hogy a fejlesztők egy kényelmes, rugalmas felületen keresztül megoldhassák problémáikat a Serverless használatával.
Ha van ötleted arra vonatkozóan, hogy milyen legyen az ideális FaaS platform, és hogyan szeretnéd használni a Serverless-t a projektjeidben, oszd meg kommentben. A platform fejlesztése során figyelembe vesszük az Ön kívánságait.
A cikkben felhasznált anyagok:
Forrás: will.com