Serverless ― ei tähenda füüsiliste serverite puudumist. See pole «nupp, mis tapab» konteinerid ega hetkeline trend. See on uus lähenemine pilvesüsteemide ehitamisele. Täna käsitleme Serverless-rakenduste arhitektuuri, vaatame, millist rolli mängib Serverless-teenuse pakkuja ja avatud lähtekoodiga projektid. Lõpus arutame Serverless'i rakendamise küsimusi.
Ma tahan kirjutada rakenduse serveripoolset osa (ükskõik, olgu see isegi veebipood). See võib olla ka vestlus ning sisu avaldamise teenus või koormuse tasakaalustaja. Igal juhul tuleb palju peavalu: tuleb ette valmistada infrastruktuur, määrata rakenduse sõltuvused, mõelda hosti operatsioonisüsteemile. Seejärel tuleb värskendada väikeseid komponente, mis ei mõjuta ülejäänud monoliiti. Ja koormuse all kõrvutamise kohta ei tohi unustada.
Kuidas oleks, kui võtta efemeersed konteinerid, milles vajalikud sõltuvused on juba ette paigutatud, ja need konteinerid on üksteisest ning host-OS-ist isoleeritud? Monoliit jagatakse mikroteenusteks, millest igaüht saab vahetada ja skaleerida sõltumatult teistest. Kui paigaldada kood sellisesse konteinerisse, saan seda käivitada igasugusel infrastruktuuril. See on juba parem.
Ent mis siis, kui ei soovi konteinerite seadistamisega tegeleda? Ei soovi mõelda rakenduse skaleerimisele. Ei soovi maksta käivitatud konteinerite seisakute eest, kui teenusele on minimaalne koormus. Tahan kirjutada koodi. Keskenduda äriloogikale ja tuua tooted turule valguskiirusel.
Sellised mõtted viisid mind serverivabade arvutusteni. Serverless tähendab sel juhul mitte füüsilise serverite puudumist, vaid muretsemise puudumist infrastruktuuri juhtimise üle.
Idee on see, et rakenduse loogika jaguneb sõltumatuteks funktsioonideks. Neil on ürituste struktuur. Iga funktsioon täidab ühte "mikrotehtavat". Kõik, mis arendajalt nõutakse, on funktsioonide üleslaadimine pilveteenuse pakkuja pakutavasse konsolisse ja nende sidumine üritusallikatega. Kood täidetakse nõudmisel automaatselt ettevalmistatud konteineris ning maksma pean ainult täitmise aja eest.
Vaatame, kuidas näeb nüüd välja rakenduse arendamise protsess.
Arendaja seisukohalt
Varasemalt rääkisime e-kaubanduse rakendusest. Traditsioonilises lähenemises täidab süsteemi peamist loogikat monoliitne rakendus. Ja server, kus rakendus on pidevalt käivitatud, töötab isegi siis, kui koormust ei ole.
Serverless'ile üleminekuks jagame rakenduse mikrotehtavateks. Igaühe jaoks kirjutame oma funktsiooni. Funktsioonid on üksteisest sõltumatud ja ei salvestata oleku (stateless) informatsiooni. Need võivad olla isegi kirjutatud erinevates keeltes. Kui üks neist "kukub", ei peatu kogu rakendus. Rakenduse arhitektuur näeb välja nii:
Serverless-funktsioonide jaotus sarnaneb mikroteenuste tööle. Kuid mikroteenus võib täita mitmeid ülesandeid, samas kui funktsioon peaks ideaaljuhul täitma ainult ühte. Kujutame ette, et ülesanne on koguda statistikat ja esitada see kasutaja päringu järgi. Mikroteenuste lähenemisviisis täidab ülesannet üks teenus, millel on kaks sisendpunkti: kirjutamiseks ja lugemiseks. Besserverite arvutustes on need kaks erinevat funktsiooni, mis ei ole omavahel seotud. Arendaja säästab arvutusressursse, kui näiteks statistikat uuendatakse sagedamini, kui seda väljastatakse.
Serverless-funktsioonid peavad töötama lühikese ajavahemiku jooksul (timeout), mille määrab teenusepakkuja. Näiteks AWS jaoks on ajavahemik 15 minutit. See tähendab, et pikaajalisi funktsioone tuleb kohandada nõuete järgi - sellega erineb Serverless teistest täna populaarsetest tehnoloogiatest (konteineritest ja Platform as a Service'ist).
Iga funktsioonile määrame sündmuse. Sündmus on tegevuse käivitaja:
Sündmus
Tegevus, mida funktsioon täidab
Hoidlasse on üles laaditud toote pilt
Pildi kokkusurumine ja katalooge väljastamine
Andmebaasis on füüsilise poe aadress uuendatud
Laadige kaardile uus asukoht
Klient maksab toote eest
Käivitage makse töötlemine
Sündmusteks võivad olla HTTP-päringud, voogandmed, sõnumijärjekorrad jne. Sündmuste allikad on andmete muutumine või ilmumine. Samuti saab funktsioone käivitada ajastatud põhjal.
Arhitektuur on välja töötatud ja rakendus on peaaegu serverivaba. Liikume nüüd teenusepakkuja poole.
Teenusepakkuja poolt
Tavaliselt pakuvad serverivabad arvutused pilveteenuse pakkujad. Neid nimetatakse erinevalt: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Kasutame teenust konsooli või teenusepakkuja isikliku konto kaudu. Funktsioonide koodi saab üles laadida järgmistel viisidel:
- kirjutada kood sisseehitatud toimetajates veebikonsoolis,
- üles laadida koodiarhiiv,
- töötada avalike või privaatsete git-repositega.
Siin seadistame ka sündmused, mis käivitavad funktsiooni. Erinevatel teenusepakkujatel võivad sündmuste komplektid erineda.
Teenusepakkuja on oma infrastruktuuri peal üles ehitanud ja automatiseerinud Function as a Service (FaaS) süsteemi:
- Funktsioonide kood saadetakse teenusepakkuja poolel asuvasse salvekohte.
- Kui toimub sündmus, käivitab server automaatselt konteinerid, kus on ettevalmistatud keskkond. Iga funktsiooni eksemplarile omistatakse oma isoleeritud konteiner.
- Ladustamisest saadetakse funktsioon konteinerisse, arvutatakse ja antakse tulemus.
- Samal ajal, kui paralleelsete sündmuste arv kasvab, suureneb ka konteinerite arv. Süsteem skaleerib automaati. Kui kasutajad ei pöördu funktsiooni poole, jääb see passiivseks.
- Teenusepakkuja määrab konteinerite ootamisaja — kui selle aja jooksul funktsioone konteineris ei esine, hävitatakse see.
Nii saame Serverless „karbist välja”. Teenuse eest maksame mudeli alusel pay-as-you-go ning ainult nende funktsioonide eest, mida kasutatakse, ja ainult selle aja eest, kui need olid aktiivsed.
Kehitajatega teenuse tutvustamiseks pakuvad teenusepakkujad kuni 12-kuulist tasuta testimist, kuid piiravad kokku arvutusaega, kuupõhiste päringute arvu, rahalisi vahendeid või tarbitavaid ressursse.
Peamine eelis töötamisel teenusepakkujaga on võimalus mitte muretseda infrastruktuuri (serverite, virtuaalmasinate, konteinerite) pärast. Teenusepakkujana saab realiseerida FaaS nii oma arenduste kaudu kui ka open-source tööriistade abil. Sellest räägime nüüd edasi.
Open source'i küljest
Viimased paar aastat on open-source kogukond aktiivselt töötanud Serverless tööriistade kallal. Suuri mängijaid turul, kes panustavad serverless platvormide arengusse, on sealhulgas:
- Google pakub arendajatele oma open-source tööriista ― . Selle arenduses osalesid IBM, RedHat, Pivotal ja SAP;
- IBM töötasid Serverless platvormi , mis muutus hiljem Apache Foundationi projektiks;
- Microsoft osaliselt avasid platvormi koodi .
Arendused käivad ka serverless raamistikude suunas. ja paigaldatakse eelnevalt ettevalmistatud Kubernetes klastritesse, töötleb nii Kubernetesega kui ka Docker Swarmiga. Raamistik toimib spetsiifilise kontrollina ― soovi korral valmistab ta klastris töö keskkonna ette ja käivitab seal funktsiooni.
Raamistikke jätavad ruumi tööriista kohandamiseks vastavalt vajadustele. Näiteks Kubelessis saab arendaja seadistada funktsiooni täitmisaja (vaikesätete väärtus on 180 sekundit). Fission proovib lahendada külma käivitamise probleemi, hoides mõned konteinerid kogu aeg käimas (kuigi see toob kaasa ressursside raiskamise kulud). OpenFaaS pakub erinevate maitse ja värviga trikke: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs ja teised.
Alustamise juhised leiate raamistike ametlikest dokumentatsioonidest. Nende kasutamine eeldab veidi rohkem oskusi kui teenusepakkujaga töötamine - minimaalne oskus on käivitada Kubernetes'i klaster CLI kaudu. Maksimaalne oskus on kaasata teisi avatud lähtekoodiga tööriistu (näiteks Kafka järjekorra haldur).
Olgem sõltumata sellest, kuidas me Serverless'iga töötame - kas teenusepakkuja kaudu või avatud lähtekoodiga, saame Serverless-lähenemise mitmeid eeliseid ja puudusi.
Eeliste ja puuduste seisukohalt
Serverless arendab konteinerite infrastruktuuri ja mikroteenuste lähenemist, mille raames saavad meeskonnad töötada mitmekeelselt, seotuna ainult ühe platvormiga. Süsteemi ülesehitamine muutub lihtsamaks ning vigade parandamine on kergem. Mikroteenuste arhitektuur võimaldab süsteemi lisada uut funktsionaalsust märksa kiiremini kui monoliitse rakenduse puhul.
Serverless vähendab arendusprojekti aega veelgi, lubades arendajal keskenduda ainult rakenduse äriloogikale ja koodi kirjutamisele. Selle tulemusena lüheneb arenduse turuletoomise aeg.
Boonusena saame automaatse skaleerimise koormuse järgi, ja maksame ainult kasutatud ressursside eest ning ainult selle ajal, kui neid kasutatakse.
Nagu iga tehnoloogia, on Serverless'il ka puudused.
Näiteks võib selliseks puuduseks olla külma käivitamise aeg (keskmiselt kuni 1 sekund selliste keelte nagu JavaScript, Python, Go, Java, Ruby puhul).
Ühelt poolt sõltub külma käivitamise aeg paljuski mitmest muust tegurist: keel, milles funktsioon on kirjutatud, raamatukogude arv, koodi maht, suhtlemine lisare sumberitega (näiteks andmebaasid või autentimiserverid). Kuna arendaja haldab neid tegureid, saab ta käivitamisaega lühendada. Teiselt poolt ei saa arendaja konteineri käivitamise aega juhtida – see sõltub täielikult teenusepakkujast.
Külm käivitus võib muutuda soojaks, kui funktsioon kasutab eelmisel sündmusel käivitatud konteinerit uuesti. Selline olukord tekib kolmes olukorras:
- kui kliendid kasutavad teenust tihti ja funktsiooni pöördumiste arv kasvab;
- kui teenusepakkuja, platvorm või raamistik võimaldavad hoida osa konteineritest pidevalt käimas;
- kui arendaja käivitab funktsioone ajastatud intervallidega (ütleme, igad 3 minuti tagant).
Paljude rakenduste jaoks ei ole külm käivitus probleem. Siin tuleb lähtuda teenuse tüübist ja ülesannetest. Startimine, mis viibib sekundi, ei ole alati kriitiline ärirakendusele, kuid see võib olla kriitiline meditsiiniteenustele. Tõenäoliselt ei sobi sellisel juhul serverita lähenemine enam.
Järgmise puudusena nimetatakse Serverless'i lühikest funktsiooni eluiga (timeout, mille jooksul funktsioon peab täituma).
Kuid kui on plaanis töötada pikaajaliste ülesannetega, ei pea kartma kasutada hübriidset arhitektuuri – kombineerida Serverless teise tehnoloogiaga.
Kuid mitte kõik süsteemid ei saa töötada Serverless skeemi järgi.
Mõned rakendused salvestavad endiselt andmeid ja olekuid töö ajal. Mõned arhitektuurid jäävad monoliitseteks, samas kui mõned funktsioonid ei ole lühiajalised. Siiski (nagu kunagi pilvetehnoloogiad ja hiljem konteinerid), Serverless on tehnoloogia, millel on suur tulevik.
Selles valguses soovin sujuvalt liikuda Serverless lähenemise rakendamise küsimusele.
Rakendamise poolest
2018. aastal kasvas Serverless'i kasutamise osakaal . Sa ettevõtted, kes on juba tehnoloogiat oma teenustes rakendanud, on turu hiiglased nagu Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Samas on oluline mõista, et Serverless ei ole imerohi, vaid tööriist teatud ülesannete lahendamiseks:
- Vähendada ressursside ooteaega. Ei ole vaja pidevalt hoida virtuaalmasinat teenuste jaoks, mida harva kasutatakse.
- Töötleda andmeid „lennult”. Kujundada pilte, eemaldada taust, muuta video kodeeringut, töötada IoT sensoritega, teostada matemaatilisi operatsioone.
- Siduda kokku teised teenused. Git-repositsioon sisemiste programmide jaoks, Slacki bot Jira ja kalendriga.
- Tasakaalustada koormust. Siin peatume lähemalt.
Kujutage ette teenust, kuhu tuleb 50 inimest. Selle jaoks on olemas nõrkade ressurssidega virtuaalmasin. Aeg-ajalt tõuseb teenusele koormus mitmekordseks. Sellisel juhul ei suuda nõrgad ressursid hakkama saada.
Saame süsteemi lisada koormuse tasakaalustaja, mis jaotab koormuse näiteks kolme virtuaalmasina vahel. Praegu ei saa me täpselt prognoosida koormust, seega hoidame mõned ressursid „varuks“, mis tähendab, et maksame mitteaktiivsete ressursside eest üle.
Sellises olukorras saame süsteemi optimeerida hübriidse lähenemise kaudu: koormustasakaalustaja tagab ühe virtuaalmasina ja seob selle Serverless Endpointiga funktsioonide jaoks. Kui koormus ületab piiri, käivitab tasakaalustaja funktsioonide instantsid, mis võtavad enda peale osa päringute töötlemisest.
Seega saab Serverless lahendust kasutada seal, kus tuleb harva, kuid intensiivselt töödelda suurt hulka päringuid. Sellisel juhul on kasulikum käivitada mitu funktsiooni 15 minutiks kui hoida kogu aeg virtuaalmasinat või serverit.
Hoolimata kõigist serverivabade arvutuste eelised, tuleb enne rakendamise alustamist kõigepealt hinnata rakenduse loogikat ja mõista, milliseid ülesandeid suudab Serverless konkreetsel juhul lahendada.
Serverless ja Selectel
Selectelis oleme juba meie juhtpaneeli kaudu. Oleme nüüd ehitamas oma FaaS platvormi. Soovime, et arendajad saaksid oma ülesandeid Serverless'i abil mugavas ja paindlikus liideses lahendada.
Kui teil on ideid, milline peaks olema ideaalne FaaS platvorm ja kuidas soovite Serverless'it oma projektides kasutada, jagage neid kommentaarides. Arvesse võtame teie soove platvormi arendamisel.
Artiklis kasutatud materjalid:
Allikas: habr.com
