Serverless hittide kärg

Serverless ei tähenda füüsiliste serverite puudumist. See ei ole konteinerite «tapja» ega ajutine trend. See on uus lähenemine süsteemide ehitamisele pilves. Täna vaatame Serverless-rakenduste arhitektuuri, uurime, millist rolli mängib Serverless-teenuste pakkuja ja open-source projektid. Lõpuks arutame, kuidas Serverless'i rakendusi kasutada.

Ma tahan kirjutada rakenduse serveripoolset osa (isegi kui see on internetipood). See võib olla vestlus, sisu avaldamise teenus või koormuse tasakaalustaja. Igatahes tuleb tegeleda paljude muredega: tuleb ette valmistada infrastruktuur, määrata rakenduse sõltuvused, mõelda hosti operatsioonisüsteemile. Siis tuleb uuendada väikseid komponente, mis ei mõjuta ülejäänud monoliiti. Ja ärgem unustagem koormuse järgi skaleerimist.

Aga mis siis, kui võtta efemeerseid konteinereid, milles vajalikud sõltuvused on juba eelnevalt installitud, ning need konteinerid on üksteisest ja hosti opsüsteemist eraldatud? Jagame monoliidi mikroteenusteks, millest igaüht saab uuendada ja skaleerida sõltumatult teistest. Paigutades koodi sellisesse konteinerisse, saan seda käivitada igasuguses infrastruktuuris. See on juba parem.

Aga kui ei taha konteinereid seadistada? Ei taha mõelda rakenduse skaleerimisele. Ei taha maksta käivitatud konteinerite ootamise eest, kui teenusele on minimaalne koormus. Tahan lihtsalt koodi kirjutada. Keskenduda äri loogikale ja tuua tooted turule tuulekiirusel.

Sellised mõtted viisid mind serverivabade arvutuste juurde. Serverless tähenduses tähendab see mitte füüsiliste serverite puudumist, vaid muret infrastruktuuri haldamise puudumisest.

Idee seisneb selles, et rakenduse loogika jaguneb sõltumatuteks funktsioonideks. Need on sündmustepõhised. Iga funktsioon täidab ühte «mikrotegevust». Kõik, mida arendajalt nõutakse, on laadida funktsioonid pilveteenuse pakkuja konsooli ja seostada need sündmuste allikatega. Kood käivitatakse nõudmisel automaatselt ette valmistatud konteineris ning maksan ainult käivitamise aja eest.

Vaatame nüüd, kuidas arenduse protsess välja näeb.

Arendaja vaatepunktist

Varem rääkisime e-poe rakendusest. Traditsioonilises lähenemisviisis täidab süsteemi põhiloogika monoliitne rakendus. Ja server, kus rakendus on pidevalt käivitatud, töötab pidevalt, isegi kui koormust pole.

Serverless lahendusele ülemineku jaoks jagame rakenduse mikrotegevusteks. Igaühe jaoks kirjutame oma funktsiooni. Funktsioonid on üksteisest sõltumatud ja ei salvesta olekut (stateless). Need võivad olla kirjutatud isegi erinevates keeltes. Kui üks neist „kukub”, ei peatu kogu rakendus. Rakenduse arhitektuur näeb välja selline:

Funktsioonide jaotamine Serverless'is sarnaneb mikroteenustega töötamisega. Kuid mikroteenus võib täita mitmeid ülesandeid, samas kui funktsioon peaks ideaalis täitma vaid üht. Kujutage ette, et ülesanne on koguda statistikat ja esitada see kasutaja päringu järgi. Mikroteenuse lähenemisviisis täidab ülesande üks teenus, millel on kaks sisendpunkti: kirjutamiseks ja lugemiseks. Besserveritaseme arvutustes on need kaks eraldi funktsiooni, mis ei ole omavahel seotud. Arendaja säästab arvutusressursse, kui näiteks statistikat uuendatakse sagedamini kui seda laaditakse.

Serverless-funktsioonid peavad töötama lühikese aja jooksul (timeout), mille määrab teenuse pakkuja. Näiteks AWS puhul on timeout 15 minutit. See tähendab, et pikaajalised funktsioonid (long-lived) tuleb kohandada nõuete järgi — sellega erineb Serverless teistest praegu populaarsetest tehnoloogiatest (nagu konteinerid ja Platform as a Service).

Iga funktsioonile määrame sündmuse. Sündmus on tegevuse väljakutsuja:

Sündmus
Tegevus, mida funktsioon täidab

Toote pilt on salvestatud salvestusruumi
Pildistada pilt ja laadida see kataloogi

Andmebaasis on uuendatud füüsilise poe aadress
Uue asukoha laadimine kaartidele

Klient maksab toote eest
Käivitada makse töötlemine

Sündmusteks võivad olla HTTP-päringud, voogedastuse andmed, sõnumijärjed jne. Sündmuste allikad on andmete muutumine või ilmumine. Samuti saab funktsioone käivitada ajastatult.

Arhitektuur on läbi töötatud ja rakendus on peaaegu serverless. Edasi liikume teenuse pakkuja poole.

Teenuse pakkuja poolt

Tavaliselt pakuvad serverless arvutusi pilveteenuse pakkujad. Neid nimetatakse erinevalt: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.

Teenust kasutame läbi teenusepakkuja konsooli või isikliku konto. Funktsioonide koodi saab laadida ühe järgmistest viisidest:

• koodi kirjutada sisseehitatud redaktorites läbi veebikonsooli,
• laadida koodi arhivina,
• töötada avalike või privaatsed git-repositooretega.

Siin seadistame sündmused, mis kutsuvad funktsiooni esile. Erinevate teenusepakkujate sündmuste kogumid võivad erineda.

Teenusepakkuja on oma infrastruktuuri üles ehitanud ja automatiseerinud Function as a Service (FaaS) süsteemi:

1. Funktsioonide kood jõuab teenusepakkuja salvestusruumi.
2. Kui sündmus tekib, käivitatakse serveris automaatselt konteinerid, millel on ettevalmistatud keskkond. Iga funktsiooni eksemplarile on oma isoleeritud konteiner.
3. Salvestusruumist saadetakse funktsioon konteinerisse, arvutatakse ja antakse tulemus.
4. Paralleelsete sündmuste arv kasvab — kasvab ka konteinerite arv. Süsteem skaleerib automaatselt. Kui kasutajad ei kasuta funktsiooni, jääb see mitteaktiivseks.
5. Teenusepakkuja määrab konteinerite ooteaja — kui selle aja jooksul funktsioonid konteineris ei ilmu, hävitatakse see.

Nii saame Serverless'i "karbist välja". Teenuse eest maksame pay-as-you-go mudeli järgi ja ainult nende funktsioonide eest, mida kasutame, ja ainult selle aja eest, kui neid kasutati.

Kuna arendajad teenusega tutvuda, pakuvad teenusepakkujad kuni 12 kuud tasuta katsetamist, kuid piiravad arvutusaega, kuude päringute arvu, rahasummat või tarbitavat võimsust.

Peamine eelis koostöös teenusepakkujaga on see, et ei pea muretsema infrastruktuuri (serverite, virtuaalmasinate, konteinerite) pärast. Teenusepakkuja võib omalt poolt rakendada FaaS-i nii oma arenduste kaudu kui ka open-source tööriistade abil. Räägime neist lähemalt.

Open source'i poolelt

Viimase paarikümne aasta jooksul on open-source kogukond aktiivselt töötanud Serverless-tööriistade kallal. Suured turu mängijad panustavad ka besservetete platvormide arendamisse:

• Google pakub arendajatele oma open-source tööriista — Knative. Selle väljatöötamisel osalesid IBM, RedHat, Pivotal ja SAP;
• IBM töötas Serverless platvormi kallal OpenWhisk, mis sai hiljem Apache Foundation'i projektiks;
• Microsoft osaliselt avasid nad platvormi koodi Azure Functions.

Arendused toimuvad ka serverless-raamistike suunas. Kubeless ja Fission paigaldatakse eelnevalt ettevalmistatud Kubernetes-klastritesse, OpenFaaS töötab nii Kubernetesega kui ka Docker Swarmiga. Raamistik toimib omamoodi kontrollerina – ta valmistab nõudmisel klastris tööaja keskkonna ja käivitab seal funktsiooni.

Raamistikud jätavad ruumi tööriista konfigureerimiseks vastavalt oma vajadustele. Nii võib Kubeless arendaja seadistada funktsiooni täitmise ajapiiri (vaikeväärtus on 180 sekundit). Fission püüab lahendada külma käivituse probleemi hoides osa konteineritest alati töös (kuigi see toob kaasa ressursikasutuse kulud). OpenFaaS pakub aga hulgaliselt trigeerijaid igale maitsele: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs ja teised.

Käivitamise juhised leiate raamistikute ametlikust dokumentatsioonist. Nende kasutamine eeldab veidi rohkem oskusi kui teenusepakkujaga töötamine - see tähendab vähemalt oskust käivitada Kubernetes-klaster CLI kaudu. Maksimaalselt võib kaasata ka teisi avatud lähtekoodiga tööriistu (näiteks Kafka järjekorrakasutaja).

Olenemata sellest, kuidas me Serverlessiga töötame – kas teenusepakkuja kaudu või avatud lähtekoodiga lahendusega, saame serverless-lähenemise mitmeid eeliseid ja puudusi.

Eeliste ja puuduste seisukohalt

Serverless arendab konteineritest ja mikroteenuste lähenemisest tulenevaid ideid, kus meeskonnad saavad töötada mitmem keeles ilma ühe platvormiga sidumata. Süsteemi ülesehitamine muutub lihtsamaks ja vigade parandamine kergemaks. Mikroteenuste arhitektuur võimaldab süsteemi uue funktsionaalsuse lisamist oluliselt kiiremini kui monoliitsete rakenduste puhul.

Serverless vähendab veelgi arendusaega, lubades arendajal keskenduda ainult rakenduse äriloogikale ja koodi kirjutamisele. Selle tulemusena lüheneb arenduste turule jõudmise aeg.

Boonuseks on automaatne skaleerimine koormuse järgi, ja maksame ainult kasutatud ressursside eest ja vaid siis, kui neid kasutatakse.

Kuna iga tehnoloogia, on Serverlessel ka puudused.

Näiteks võib selliseks puuduseks olla külma käivituse aeg (keskmiselt kuni 1 sekund selliste keelte jaoks nagu JavaScript, Python, Go, Java, Ruby).

Ühelt poolt sõltub külma käivitamise aeg tegelikult paljusid muutujatest: keel, milles funktsioon on kirjutatud, raamatukogude hulk, koodi maht, suhtlemine lisavahenditega (näiteks andmebaasid või autentimisserverid). Kuna arendaja haldab neid muutujad, võib ta käivitamisaega lühendada. Teiselt poolt ei saa arendaja konteineri käivitamise aega mõjutada - see sõltub täielikult teenusepakkujast.

Külm käivitamine võib muutuda soojaks, kui funktsioon kasutab eelnevalt sama sündmuse käivitatud konteinerit. Selline olukord tekib kolmes olukorras:

• kui kliendid kasutavad teenust sageli ja funktsiooni kõnetuste arv suureneb;
• kui teenusepakkuja, platvorm või raamistik võimaldab osa konteineritest pidevalt käivitamata hoida;
• kui arendaja käivitab funktsioone ajastuse järgi (ütleme, iga kolme minuti tagant).

Paljude rakenduste jaoks ei ole külm käivitamine probleem. Siin tuleks lähtuda teenuse tüübist ja ülesannetest. Käivitamise viivitus sekundiks ei pruugi olla ärirakenduse jaoks kriitiline, kuid võib olla kriitiline meditsiiniteenuste jaoks. Tõenäoliselt ei sobi sellisel juhul serverita lähenemine.

Serverless'i järgmise puudusena peetakse funktsiooni lühikest eluaega (timeout, mille jooksul funktsioon peab soorituma).

Aga kui tuleb töötada pikaajaliste ülesannetega, võib kasutada hübriidset arhitektuuri - kombineerida Serverless'i muu tehnoloogiaga.

Kuid mitte kõik süsteemid ei saa töötada Serverless'i skeemi alusel.

Mõned rakendused jätkavad andmete ja oleku hoidmist töötamise ajal. Mõned arhitektuurid jäävad monoliitseteks, samas kui mõned funktsioonid on pikaealised. Siiski on Serverless (nagu kunagi pilvetehnoloogiad ja seejärel konteinerid) tehnoloogia, millel on suur tulevik.

Sellega seoses sooviksin sujuvalt liikuda Serverless'i lähenemise rakendamise küsimuse juurde.

Rakendamise poolelt

Aastal 2018 suurenes Serverless'i kasutamine ühe ja poole korra võrra. Ettevõtete seas, kes on juba tehnoloogiat oma teenustes rakendanud, on sellised turujuhtivad ettevõtted nagu Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Samuti tuleb mõista, et Serverless ei ole universaalne lahendus, vaid vahend spetsiifiliste probleemide lahendamiseks:

• Ressursside seisaku vähendamine. Ei ole vaja pidevalt hoida virtuaalmasinat teenuste jaoks, mida harva kasutatakse.
• Töödelda andmeid "reaalajas". Pildifailide tihendamine, tausta eemaldamine, video kodeeringu muutmine, IoT-anduritega töötamine, matemaatiliste operatsioonide tegemine.
• "Kleebitakse" kokku teiste teenustega. Git-repositoorium siseprogrammidest, Slacki chatbot Jira ja kalendri integreerimisega.
• Koormuse tasakaalustamine. Siin peatume lähemalt.

Oletame, et on teenus, kuhu tuleb 50 inimest. Selle jaoks on seadistatud nõrkade komponentidega virtuaalmasin. Aeg-ajalt koormus teenusele kasvab mitu korda. Sel juhul ei suuda nõrgad komponendid hakkama saada.

Süsteemi saab lisada koormuse tasakaalustaja, mis jaotab koormust, ütleme, kolmele virtuaalmasinale. Sel etapil ei saa me täpselt prognoosida koormust, seetõttu hoidame mõned ressursid "varuks". Ja maksame liiga palju tühikäigu eest.

Sellises olukorras saame süsteemi optimeerida hübriidlahenduse kaudu: koormuse tasakaalustaja taha jätame ühe virtuaalmasina ja seome selle Serverless Endpointiga funktsioonide jaoks. Kui koormus ületab piiri, käivitab tasakaalustaja funktsioonide eksemplarid, mis võtavad osa päringute töötlemisest.

Nii saab Serverlessi kasutada seal, kus tuleb harva, kuid intensiivselt töödelda suurt hulka päringuid. Sellisel juhul on mitme funktsiooni käivitamine 15 minutiks kasulikum kui pidevalt virtuaalmasina või serveri hoidmine.

Kõikide serverivabade arvutuste eeliste juures on enne rakenduse rakendamist kõigepealt vajalik hinnata rakenduse loogikat ja mõista, milliseid ülesandeid suudab Serverless konkreetses olukorras lahendada.

Serverless ja Selectel

Selectelis oleme juba lihtsustanud Kubernetesega töötamist meie juhtpaneeli kaudu. Nüüd ehitame oma FaaS-plaatvormi. Soovime, et arendajad saaksid oma ülesandeid lahendada Serverlessi abil mugava ja paindliku liidese kaudu.

Kui teil on ideid selle kohta, milline peaks olema ideaalne FaaS-plaatvorm ja kuidas soovite Serverlessi oma projektides kasutada, jagage neid kommentaarides. Arvestame teie soove platvormi arendamisel.
 
Artiklis kasutatud materjalid:

• Serverlessi kasutamise protsent on tõusnud 1,5 korda (täisraport RightScale)
• Kuidas sõltub külma käivitamise aeg rakenduse keelest

Allikas: habr.com