Serverless ei tähenda serverite füüsilist puudumist. See ei ole konteinerite tapja ega mööduv trend. See on uus lähenemisviis pilves süsteemide ehitamisele. Tänases artiklis käsitleme serverita rakenduste arhitektuuri, vaatame, millist rolli mängivad serverita teenusepakkuja ja avatud lähtekoodiga projektid. Lõpuks räägime Serverlessi kasutamise probleemidest.
Ma tahan kirjutada rakenduse (või isegi veebipoe) serveriosa. See võib olla vestlus, sisu avaldamise teenus või koormuse tasakaalustaja. Igal juhul tuleb palju peavalu: peate ette valmistama infrastruktuuri, määrama rakenduste sõltuvused ja mõtlema hosti operatsioonisüsteemile. Seejärel peate värskendama väikseid komponente, mis ei mõjuta ülejäänud monoliidi tööd. Noh, ärgem unustagem skaleerimist koormuse all.
Mis siis, kui võtame lühiajalised konteinerid, millesse vajalikud sõltuvused on juba eelinstallitud, ja konteinerid ise on üksteisest ja host OS-ist isoleeritud? Jagame monoliidi mikroteenusteks, millest igaüks saab teistest sõltumatult uuendada ja skaleerida. Pannes koodi sellisesse konteinerisse, saan seda käivitada mis tahes infrastruktuuris. Juba parem.
Mis siis, kui te ei soovi konteinereid konfigureerida? Ma ei taha mõelda rakenduse skaleerimisele. Ma ei taha maksta tühikäigul töötavate konteinerite eest, kui teenuse koormus on minimaalne. Ma tahan koodi kirjutada. Keskenduge äriloogikale ja tooge tooted turule valguse kiirusel.
Sellised mõtted viisid mind serverita andmetöötluse juurde. Serverita tähendab antud juhul mitte serverite füüsiline puudumine, vaid infrastruktuuri haldamise peavalude puudumine.
Idee seisneb selles, et rakendusloogika on jaotatud sõltumatuteks funktsioonideks. Neil on sündmuste struktuur. Iga funktsioon täidab ühte "mikroülesannet". Kõik, mida arendajalt nõutakse, on funktsioonid pilvepakkuja pakutavasse konsooli laadida ja sündmuste allikatega seostada. Kood täidetakse nõudmisel automaatselt ettevalmistatud konteineris ja maksan ainult täitmisaja eest.
Vaatame, kuidas rakenduste arendusprotsess nüüd välja näeb.
Arendaja poolelt
Varem hakkasime rääkima veebipoe rakendusest. Traditsioonilise lähenemise korral teostab süsteemi põhiloogikat monoliitne rakendus. Ja rakendusega server töötab pidevalt, isegi kui koormust pole.
Serverivabale üleminekuks jagame rakenduse mikrotegumiteks. Kirjutame igaühe jaoks oma funktsiooni. Funktsioonid on üksteisest sõltumatud ega salvesta olekuteavet (olekuta). Need võivad olla isegi kirjutatud erinevates keeltes. Kui üks neist "kukkub", ei peatu kogu rakendus. Rakenduse arhitektuur näeb välja selline:
Serverlessi funktsioonideks jaotus sarnaneb mikroteenustega töötamisele. Kuid mikroteenus võib täita mitut ülesannet ja funktsioon peaks ideaalis täitma ühte. Kujutagem ette, et ülesandeks on koguda statistikat ja seda kasutaja soovil kuvada. Mikroteenuse lähenemisviisis täidab ülesannet üks teenus, millel on kaks sisenemispunkti: kirjutamine ja lugemine. Serverita andmetöötluses on need kaks erinevat funktsiooni, mis ei ole üksteisega seotud. Arendaja säästab arvutusressursse, kui näiteks statistikat uuendatakse sagedamini kui alla laaditakse.
Serverita funktsioonid peavad täitma lühikese aja jooksul (timeout), mille määrab teenusepakkuja. Näiteks AWS-i ajalõpp on 15 minutit. See tähendab, et pikaealisi funktsioone tuleb muuta vastavalt nõuetele – see eristab Serverlessi teistest tänapäeval populaarsetest tehnoloogiatest (konteinerid ja platvorm kui teenus).
Määrame igale funktsioonile sündmuse. Sündmus on toimingu käivitaja:
Sündmus
Toiming, mida funktsioon täidab
Tootepilt on hoidlasse üles laaditud.
Tihendage pilt ja laadige see kataloogi
Füüsilise poe aadressi on andmebaasis uuendatud
Laadige kaartidele uus asukoht
Kauba eest tasub klient
Alustage maksete töötlemist
Sündmused võivad olla HTTP-päringud, voogesituse andmed, sõnumijärjekorrad ja nii edasi. Sündmuste allikad on andmete muudatused või esinemised. Lisaks saab funktsioone käivitada taimer.
Arhitektuur oli läbi töötatud ja rakendus muutus peaaegu serverivabaks. Järgmisena läheme teenusepakkuja juurde.
Pakkuja poolelt
Tavaliselt pakuvad serverita andmetöötlust pilveteenuse pakkujad. Neid nimetatakse erinevalt: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Kasutame teenust teenusepakkuja konsooli või isikliku konto kaudu. Funktsioonikoodi saab alla laadida ühel järgmistest viisidest:
- kirjutage veebikonsooli kaudu koodi sisseehitatud redaktoritesse,
- laadige alla arhiiv koos koodiga,
- töötada avalike või privaatsete git-hoidlatega.
Siin seadistame funktsiooni kutsuvad sündmused. Sündmuste komplektid võivad erinevate pakkujate puhul erineda.
Pakkuja ehitas ja automatiseeris funktsiooni Function as a Service (FaaS) oma infrastruktuuris:
- Funktsioonikood jõuab teenusepakkuja poolel asuvasse salvestusruumi.
- Sündmuse ilmnemisel juurutatakse serverisse automaatselt ettevalmistatud keskkonnaga konteinerid. Igal funktsiooni eksemplaril on oma isoleeritud konteiner.
- Salvest saadetakse funktsioon konteinerisse, arvutatakse ja tagastatakse tulemus.
- Paralleelsete ürituste arv kasvab – konteinerite arv kasvab. Süsteem skaleerib automaatselt. Kui kasutajad funktsioonile juurde ei pääse, on see passiivne.
- Pakkuja määrab konteineritele jõudeaja – kui selle aja jooksul funktsioone konteinerisse ei ilmu, siis see hävitatakse.
Nii saame serverita karbist välja. Teenuse eest tasume jaotusmudelit kasutades ja ainult nende funktsioonide eest, mida kasutatakse ja ainult nende kasutamise aja eest.
Arendajatele teenuse tutvustamiseks pakuvad pakkujad kuni 12 kuud tasuta testimist, kuid piiravad kogu arvutamise aega, päringute arvu kuus, rahalisi vahendeid või energiatarbimist.
Pakkujaga töötamise peamine eelis on võimalus mitte muretseda infrastruktuuri (serverid, virtuaalsed masinad, konteinerid) pärast. Pakkuja saab omalt poolt FaaS-i juurutada nii enda arendusi kasutades kui ka avatud lähtekoodiga tööriistu kasutades. Räägime neist lähemalt.
Avatud lähtekoodiga poolelt
Avatud lähtekoodiga kogukond on viimase paari aasta jooksul aktiivselt töötanud serverita tööriistade kallal. Serverita platvormide arendamisse panustavad ka suurimad turuosalised:
- Google pakub arendajatele oma avatud lähtekoodiga tööriista - . Selle arendamisel osalesid IBM, RedHat, Pivotal ja SAP;
- IBM töötas serverita platvormil , millest sai siis Apache Foundationi projekt;
- Microsoft avas osaliselt platvormi koodi .
Arendused käivad ka serverita raamistike suunas. и kasutatakse eelnevalt ettevalmistatud Kubernetese klastrites, töötab nii Kubernetese kui ka Docker Swarmiga. Raamistik toimib omamoodi kontrollerina – nõudmisel valmistab see ette klastri sees käituskeskkonna, seejärel käivitab seal mingi funktsiooni.
Raamistikud jätavad ruumi tööriista teie vajadustele vastavaks konfigureerimiseks. Seega saab arendaja Kubelessis konfigureerida funktsiooni täitmise ajalõpu (vaikeväärtus on 180 sekundit). Fission, püüdes lahendada külmkäivituse probleemi, soovitab mõnda konteinerit kogu aeg töös hoida (kuigi sellega kaasnevad ressursside seisakukulud). Ja OpenFaaS pakub iga maitse ja värvi jaoks käivitajate komplekti: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NAT ja teised.
Juhised alustamiseks leiate raamistike ametlikust dokumentatsioonist. Nendega töötamine nõuab veidi rohkem oskusi kui teenusepakkujaga töötades – see on vähemalt võimalus käivitada Kubernetese klaster CLI kaudu. Kaasake maksimaalselt muid avatud lähtekoodiga tööriistu (nt Kafka järjekorrahaldur).
Sõltumata sellest, kuidas me Serverlessiga töötame – teenusepakkuja kaudu või avatud lähtekoodiga – saame serverivaba lähenemisviisi eeliseid ja puudusi.
Eeliste ja miinuste seisukohalt
Serverless arendab ideid konteinerite infrastruktuurist ja mikroteenuste lähenemisviisist, milles meeskonnad saavad töötada mitmekeelses režiimis, ilma et nad oleksid seotud ühe platvormiga. Süsteemi ülesehitamine on lihtsam ja vigu on lihtsam parandada. Mikroteenuste arhitektuur võimaldab lisada süsteemi uut funktsionaalsust palju kiiremini kui monoliitse rakenduse puhul.
Serverita vähendab arendusaega veelgi, võimaldades arendajal keskenduda ainult rakenduse äriloogikale ja kodeerimisele. Selle tulemusena väheneb arenduste turule jõudmiseks kuluv aeg.
Boonusena saame koormuse automaatse skaleerimise, ja maksame ainult kasutatud ressursside eest ja ainult nende kasutamise ajal.
Nagu igal tehnoloogial, on serverita ka puudusi.
Näiteks võib selliseks puuduseks olla külmkäivitusaeg (keskmiselt kuni 1 sekund selliste keelte puhul nagu JavaScript, Python, Go, Java, Ruby).
Ühest küljest sõltub tegelikkuses külmkäivitusaeg paljudest muutujatest: keelest, milles funktsioon on kirjutatud, teekide arvust, koodi hulgast, suhtlusest lisaressurssidega (sama andmebaasid või autentimisserverid). Kuna arendaja kontrollib neid muutujaid, saab ta lühendada käivitusaega. Kuid teisest küljest ei saa arendaja konteineri käivitusaega kontrollida - kõik sõltub pakkujast.
Külmkäivitus võib muutuda soojakäivituseks, kui funktsioon kasutab uuesti eelmise sündmuse poolt käivitatud konteinerit. See olukord tekib kolmel juhul:
- kui kliendid kasutavad teenust sageli ja funktsiooni kõnede arv suureneb;
- kui pakkuja, platvorm või raamistik võimaldab teil mõnda konteinerit kogu aeg töös hoida;
- kui arendaja käivitab funktsioone taimeriga (näiteks iga 3 minuti järel).
Paljude rakenduste puhul pole külmkäivitus probleem. Siin peate lähtuma teenuse tüübist ja ülesannetest. Sekundine käivitusviivitus ei ole alati ärirakenduse jaoks kriitiline, kuid see võib muutuda kriitiliseks meditsiiniteenuste jaoks. Sel juhul serverita lähenemine tõenäoliselt enam ei sobi.
Serverlessi järgmine puudus on funktsiooni lühike eluiga (ajalõpp, mille jooksul funktsiooni tuleb käivitada).
Kuid kui peate töötama pikaajaliste ülesannetega, võite kasutada hübriidarhitektuuri – ühendage serverita mõne muu tehnoloogiaga.
Kõik süsteemid ei saa serverita skeemi kasutades töötada.
Mõned rakendused salvestavad täitmise ajal endiselt andmeid ja olekut. Mõned arhitektuurid jäävad monoliitseks ja mõned funktsioonid on pikaealised. Kuid (nagu pilvetehnoloogiad ja seejärel konteinerid) on Serverless tehnoloogia, millel on suur tulevik.
Sellega seoses tahaksin sujuvalt liikuda serverita lähenemisviisi kasutamise küsimuse juurde.
Rakenduse poolelt
2018. aasta serveriteta kasutamise protsent . Ettevõtete hulgas, kes on tehnoloogiat oma teenustes juba kasutusele võtnud, on sellised turuhiiglased nagu Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Samal ajal peate mõistma, et Serverless pole imerohi, vaid tööriist teatud probleemide lahendamiseks:
- Vähendage ressursside seisakuaega. Väheste kõnedega teenuste jaoks pole vaja pidevalt virtuaalmasinat hoida.
- Töötle andmeid lennult. Tihendage pilte, lõigake välja taustad, muutke video kodeeringut, töötage IoT anduritega, tehke matemaatilisi toiminguid.
- "Liimi" muud teenused kokku. Git-hoidla koos sisemiste programmidega, vestlusbot Slackis koos Jiraga ja kalender.
- Tasakaalustage koormus. Vaatame siin lähemalt.
Oletame, et on teenus, mis tõmbab ligi 50 inimest. Selle all on nõrga riistvaraga virtuaalmasin. Aeg-ajalt suureneb teenuse koormus oluliselt. Siis ei saa nõrk riistvara hakkama.
Saate süsteemi lisada tasakaalustaja, mis jaotab koormuse näiteks kolme virtuaalse masina vahel. Praeguses etapis ei saa me koormust täpselt ennustada, seega hoiame teatud hulga ressursse "varus". Ja seisakute eest maksame üle.
Sellises olukorras saame süsteemi optimeerida läbi hübriidse lähenemise: jätame ühe virtuaalmasina koormuse tasakaalustaja taha ja paneme funktsioonidega lingi Serverless Endpointi. Kui koormus ületab läve, käivitab tasakaalustaja funktsioonieksemplarid, mis võtavad osa päringu töötlemisest üle.
Seega saab Serverlessi kasutada seal, kus on vaja töödelda suurt hulka päringuid mitte liiga sageli, vaid intensiivselt. Sel juhul on 15 minuti jooksul mitme funktsiooni käivitamine tulusam kui virtuaalmasina või serveri pidev ülalpidamine.
Arvestades kõiki serverita andmetöötluse eeliseid, peaksite enne juurutamist esmalt hindama rakenduse loogikat ja mõistma, milliseid probleeme saab Serverless konkreetsel juhul lahendada.
Serverita ja Selectel
Selectelis oleme juba meie juhtpaneeli kaudu. Nüüd ehitame oma FaaS-i platvormi. Soovime, et arendajad saaksid oma probleeme lahendada serverita kasutades mugava ja paindliku liidese kaudu.
Kui teil on ideid, milline peaks olema ideaalne FaaS-i platvorm ja kuidas soovite oma projektides Serverlessi kasutada, jagage neid kommentaarides. Platvormi arendamisel arvestame teie soovidega.
Artiklis kasutatud materjalid:
Allikas: www.habr.com