Serverless ez da zerbitzarien absentzia fisikoari buruz. Hau ez da edukiontzi hiltzailea edo joera iragankorra. Hodeian sistemak eraikitzeko ikuspegi berria da. Gaurko artikuluan Serverless aplikazioen arkitektura ukituko dugu, ikus dezagun zer rol betetzen duten Serverless zerbitzu hornitzaileak eta kode irekiko proiektuek. Azkenik, hitz egin dezagun Serverless erabiltzearen arazoei buruz.
Aplikazio baten zerbitzariaren zati bat idatzi nahi dut (edo baita lineako denda bat ere). Hau txat bat, edukia argitaratzeko zerbitzu bat edo karga-orekatzailea izan daiteke. Nolanahi ere, buruhauste asko izango dira: azpiegitura prestatu, aplikazioen menpekotasunak zehaztu eta ostalariaren sistema eragilean pentsatu beharko duzu. Ondoren, gainerako monolitoaren funtzionamenduan eragiten ez duten osagai txikiak eguneratu beharko dituzu. Beno, ez dezagun ahaztu kargapean eskalatzeaz.
Zer gertatzen da edukiontzi iragankorrak hartzen baditugu, zeinetan beharrezkoak diren mendekotasunak aurrez instalatuta dauden eta edukiontziak eurak elkarrengandik eta ostalari OStik isolatuta dauden? Monolitoa mikrozerbitzuetan banatuko dugu, eta horietako bakoitza eguneratu eta eskala daiteke besteetatik independentean. Kodea halako edukiontzi batean jarrita, edozein azpiegituratan exekutatu dezaket. Dagoeneko hobeto.
Zer gertatzen da edukiontziak konfiguratu nahi ez badituzu? Ez dut aplikazioa eskalatzean pentsatu nahi. Ez ditut ordaindu nahi inaktibo dauden edukiontziak zerbitzuaren karga txikia denean. Kodea idatzi nahi dut. Zentratu negozio-logikan eta ekarri produktuak merkatura argiaren abiaduran.
Horrelako pentsamenduek zerbitzaririk gabeko konputaziora eraman ninduten. Zerbitzaririk gabe kasu honetan esan nahi du ez zerbitzarien gabezia fisikoa, azpiegitura kudeatzeko buruhausterik eza baizik.
Ideia da aplikazio-logika funtzio independenteetan banatzen dela. Ekitaldiaren egitura dute. Funtzio bakoitzak "mikroataza" bat egiten du. Garatzaileari behar dena da funtzioak hodeiko hornitzaileak emandako kontsolan kargatzea eta gertaeren iturriekin erlazionatzea. Kodea automatikoki prestatutako edukiontzi batean eskatuko da eta exekuzio-denbora baino ez dut ordainduko.
Ikus dezagun nolakoa izango den aplikazioen garapen prozesua orain.
Garatzailearen aldetik
Lehenago online denda baterako aplikazio bati buruz hitz egiten hasi ginen. Ikuspegi tradizionalean, sistemaren logika nagusia aplikazio monolitiko baten bidez egiten da. Eta aplikazioa duen zerbitzaria etengabe exekutatzen ari da, kargarik ez badago ere.
Zerbitzaririk gabekora pasatzeko, aplikazioa mikrozereginetan zatitzen dugu. Horietako bakoitzarentzat gure funtzioa idazten dugu. Funtzioak elkarrengandik independenteak dira eta ez dute egoera-informazioa gordetzen (estaturik gabekoa). Baliteke hizkuntza ezberdinetan ere idatzita egotea. Horietako bat "erortzen" bada, aplikazio osoa ez da geldituko. Aplikazioaren arkitektura itxura hau izango du:
Zerbitzaririk gabeko funtzioen banaketa mikrozerbitzuekin lan egitearen antzekoa da. Baina mikrozerbitzu batek hainbat zeregin egin ditzake, eta funtzio batek hobeki egin beharko luke bat. Imajina dezagun zeregina estatistikak biltzea eta erabiltzaileak eskatuta bistaratzea dela. Mikrozerbitzuen ikuspegian, zeregin bat zerbitzu batek egiten du bi sarrera punturekin: idazketa eta irakurketa. Zerbitzaririk gabeko informatikan, elkarren artean erlazionatuta ez dauden bi funtzio ezberdin izango dira. Garatzaileak baliabide informatikoak gordetzen ditu, adibidez, estatistikak deskargatzen diren baino maizago eguneratzen badira.
Zerbitzaririk gabeko funtzioak epe laburrean (denbora-muga) exekutatu behar dira, zerbitzu-hornitzaileak zehazten duena. Adibidez, AWSrako denbora-muga 15 minutukoa da. Horrek esan nahi du iraupen luzeko funtzioak aldatu beharko direla eskakizunetara egokitzeko; hori da Serverless gaur egungo beste teknologia ezagunetatik (edukiontziak eta Platform as a Service) bereizten duena.
Funtzio bakoitzari gertaera bat esleitzen diogu. Gertaera bat ekintza baten abiarazlea da:
gertaera
Funtzioak egiten duen ekintza
Produktu-irudi bat kargatu da biltegira.
Konprimitu irudia eta igo direktorio batera
Denda fisikoaren helbidea eguneratu da datu-basean
Kargatu kokapen berri bat mapetan
Bezeroak salgaiak ordaintzen ditu
Hasi ordainketa prozesatzen
Gertaerak HTTP eskaerak, streaming datuak, mezu-ilarak eta abar izan daitezke. Gertaeren iturriak datuen aldaketak edo agerraldiak dira. Gainera, funtzioak tenporizadore batek abiarazi ditzake.
Arkitektura landu zen, eta aplikazioa ia zerbitzaririk gabe geratu zen. Jarraian, zerbitzu hornitzailera joango gara.
Hornitzailearen aldetik
Normalean, zerbitzaririk gabeko informatika hodeiko zerbitzu hornitzaileek eskaintzen dute. Modu ezberdinean deitzen zaie: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Zerbitzua hornitzailearen kontsolaren edo kontu pertsonalaren bidez erabiliko dugu. Funtzio-kodea modu hauetako batean deskargatu daiteke:
- idatzi kodea integratutako editoreetan web kontsolaren bidez,
- deskargatu artxiboa kodearekin,
- git biltegi publiko edo pribatuekin lan egin.
Hemen funtzioa deitzen duten gertaerak konfiguratzen ditugu. Gertaera multzoak desberdinak izan daitezke hornitzaile ezberdinen arabera.
Hornitzaileak Function as a Service (FaaS) sistema eraiki eta automatizatu zuen bere azpiegituran:
- Funtzio-kodea hornitzailearen aldean biltegian amaitzen da.
- Gertaera bat gertatzen denean, ingurune prestatua duten edukiontziak automatikoki zabaltzen dira zerbitzarian. Funtzio-instantzia bakoitzak bere edukiontzi isolatua du.
- Biltegiratzetik, funtzioa edukiontzira bidaltzen da, kalkulatzen da eta emaitza itzultzen du.
- Gertaera paraleloen kopurua hazten ari da - edukiontzi kopurua hazten ari da. Sistema automatikoki eskalatzen da. Erabiltzaileak funtziora sartzen ez badira, inaktibo egongo da.
- Hornitzaileak edukiontzien inaktibo-denbora ezartzen du; denbora horretan funtzioak edukiontzian agertzen ez badira, suntsitu egingo da.
Horrela Serverless aterako dugu kutxatik. Ordainketa eredua erabiliz ordainduko dugu zerbitzua eta erabiltzen diren funtzioengatik bakarrik, eta erabili zireneko denboragatik bakarrik.
Garatzaileei zerbitzua aurkezteko, hornitzaileek 12 hilabeteko doako proba eskaintzen dute, baina konputazio-denbora osoa, hilabeteko eskaera kopurua, funtsak edo energia-kontsumoa mugatzen dute.
Hornitzaile batekin lan egitearen abantaila nagusia azpiegituraz (zerbitzariak, makina birtualak, edukiontziak) ez kezkatzeko gaitasuna da. Bere aldetik, hornitzaileak FaaS inplementatu dezake bai garapen propioak erabiliz, bai kode irekiko tresnak erabiliz. Hitz egin dezagun gehiago haiei buruz.
Kode irekiaren aldetik
Kode irekiko komunitatea zerbitzaririk gabeko tresnetan aktiboki lanean aritu da azken bi urteetan. Merkatuko eragile handienek zerbitzaririk gabeko plataformen garapenean ere laguntzen dute:
- Google garatzaileei bere kode irekiko tresna eskaintzen die - . IBM, RedHat, Pivotal eta SAPek parte hartu zuten bere garapenean;
- IBM Serverless plataforma batean lan egin zuen , orduan Apache Fundazioaren proiektu bihurtu zena;
- Microsoft plataformaren kodea partzialki ireki zuen .
Zerbitzaririk gabeko esparruen norabidean ere garatzen ari dira. и Aurrez prestatutako Kubernetes klusterren barruan zabalduta, Kubernetes eta Docker Swarm-ekin funtzionatzen du. Esparruak kontrolagailu moduko bat bezala jokatzen du; hala eskatuz gero, kluster barruan exekuzio-ingurune bat prestatzen du, gero funtzio bat abiarazten du bertan.
Markoek lekua uzten dute tresna zure beharretara egokitzeko konfiguratzeko. Beraz, Kubeless-en, garatzaile batek funtzioaren exekuzio-denbora konfigura dezake (balio lehenetsia 180 segundokoa da). Fisioak, hotz abiaraztearen arazoa konpondu nahian, edukiontzi batzuk etengabe martxan mantentzea proposatzen du (nahiz eta horrek baliabideen geldialdi-kostuak dakarren). Eta OpenFaaS-ek abiarazle sorta bat eskaintzen du gustu eta kolore guztietarako: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs eta beste.
Hasteko jarraibideak esparruen dokumentazio ofizialean aurki daitezke. Haiekin lan egiteak hornitzaile batekin lan egitean baino trebetasun apur bat gehiago izatea eskatzen du - hau da, gutxienez, Kubernetes kluster bat CLI bidez abiarazteko gaitasuna. Gehienez, kode irekiko beste tresna batzuk sartu (adibidez, Kafka ilararen kudeatzailea).
Serverless-ekin nola lan egiten dugun - hornitzaile baten bidez edo kode irekia erabiliz, Serverless ikuspegiaren abantaila eta desabantaila ugari jasoko ditugu.
Abantailen eta desabantailen ikuspegitik
Serverless-ek edukiontzien azpiegitura eta mikrozerbitzuen ikuspegiaren ideiak garatzen ditu, zeinetan taldeek modu eleaniztunean lan egin dezaketen plataforma batera lotu gabe. Sistema bat eraikitzea errazagoa da eta akatsak zuzentzea errazagoa da. Mikrozerbitzuen arkitekturak sistemari funtzionalitate berriak gehitzeko aukera ematen dizu aplikazio monolitiko baten kasuan baino askoz azkarrago.
Zerbitzaririk gabeko garapen-denbora are gehiago murrizten du, garatzaileari aplikazioaren negozio-logikan eta kodifikazioan soilik zentratu ahal izateko. Ondorioz, garapenak merkaturatzeko denbora murrizten da.
Hobari gisa, kargarako eskalatze automatikoa lortzen dugu, eta erabilitako baliabideengatik eta erabiltzen diren unean bakarrik ordaintzen dugu.
Edozein teknologiak bezala, Serverlessek desabantailak ditu.
Esate baterako, desabantaila bat hasierako denbora hotza izan daiteke (batez beste segundo 1 arte JavaScript, Python, Go, Java, Ruby bezalako hizkuntzetarako).
Alde batetik, errealitatean, hotz abiarazteko denbora aldagai askoren araberakoa da: funtzioa zein hizkuntzatan idazten den, liburutegi kopurua, kode kopurua, baliabide gehigarriekiko komunikazioa (datu-base berdinak edo autentifikazio-zerbitzariak). Garatzaileak aldagai hauek kontrolatzen dituenez, abiarazte-denbora murriztu dezake. Baina, bestalde, garatzaileak ezin du edukiontziaren abiarazteko denbora kontrolatu - dena hornitzailearen araberakoa da.
Hasiera hotza abiarazte epel bihur daiteke funtzio batek aurreko gertaera batek abian jarritako edukiontzi bat berrerabiltzen duenean. Egoera hau hiru kasutan sortuko da:
- bezeroek zerbitzua maiz erabiltzen badute eta funtziorako dei kopurua handitzen bada;
- hornitzaileak, plataformak edo esparruak edukiontzi batzuk etengabe martxan mantentzea ahalbidetzen badu;
- garatzaileak funtzioak tenporizadore batean exekutatzen baditu (esan 3 minuturo).
Aplikazio askotan, hotz abiarazte bat ez da arazo bat. Hemen zerbitzu motaren eta zereginen gainean eraiki behar duzu. Segundo bateko abiarazte-atzerapena ez da beti funtsezkoa negozio-aplikazio baterako, baina ezinbestekoa izan daiteke mediku-zerbitzuetarako. Kasu honetan, zerbitzaririk gabeko ikuspegia seguruenik ez da egokia izango.
Serverless-en hurrengo desabantaila funtzio baten bizitza laburra da (funtzioa exekutatu behar den denbora-muga).
Baina, iraupen luzeko zereginekin lan egin behar baduzu, arkitektura hibrido bat erabil dezakezu: Serverless beste teknologia batekin konbinatu.
Sistema guztiek ez dute zerbitzaririk gabeko eskema erabiliz funtzionatu ahal izango.
Aplikazio batzuek datuak eta egoera gordeko dituzte exekuzioan zehar. Arkitektura batzuk monolitikoak mantenduko dira eta ezaugarri batzuk luze iraungo dute. Hala ere (hodeiko teknologiak eta gero edukiontziak bezala), Serverless etorkizun handiko teknologia da.
Ildo honetan, zerbitzaririk gabeko ikuspegia erabiltzearen gaiari leunki pasatu nahiko nuke.
Aplikazioaren aldetik
2018rako, Zerbitzaririk gabeko erabileraren ehunekoa . Dagoeneko beren zerbitzuetan teknologia ezarri duten enpresen artean Twitter, PayPal, Netflix, T-Mobile, Coca-Cola bezalako merkatu erraldoiak daude. Aldi berean, ulertu behar duzu Serverless ez dela panazea, arazo sorta jakin bat konpontzeko tresna bat baizik:
- Murriztu baliabideen geldialdia. Dei gutxi dituzten zerbitzuetarako ez dago makina birtual bat etengabe mantendu beharrik.
- Prozesatu datuak hegan. Konprimitu argazkiak, moztu atzeko planoak, aldatu bideoen kodeketa, lan egin IoT sentsoreekin, egin eragiketa matematikoak.
- "Kolatu" beste zerbitzu batzuk elkarrekin. Git biltegia barne programekin, txat bot-a Slack-en Jira-rekin eta egutegia.
- Karga orekatu. Ikus dezagun hemen hurbilagotik.
Demagun 50 pertsona erakartzen dituen zerbitzu bat dagoela. Haren azpian makina birtual bat dago hardware ahula duena. Noizean behin, zerbitzuaren karga nabarmen handitzen da. Orduan, hardware ahulak ezin du aurre egin.
Karga, esate baterako, hiru makina birtualetan banatuko duen orekatzaile bat sar dezakezu sisteman. Fase honetan, ezin dugu karga zehaztasunez aurreikusi, beraz, baliabide kopuru jakin bat "erreserbatan" mantentzen dugu martxan. Eta geldialdiengatik gehiegi ordaintzen dugu.
Horrelako egoera batean, sistema optimizatu dezakegu ikuspegi hibrido baten bidez: makina birtual bat utziko dugu karga-orekatzailearen atzean eta zerbitzaririk gabeko amaierako esteka bat jartzen dugu funtzioekin. Kargak atalasea gainditzen badu, balantzaileak eskaera prozesatzeko zati bat hartzen duten funtzio-instantziak abiarazten ditu.
Horrela, Serverless erabil daiteke eskaera ugari prozesatu behar den tokietan, ez askotan, baina intentsiboki. Kasu honetan, 15 minutuz hainbat funtzio exekutatzea errentagarriagoa da makina edo zerbitzari birtual bat denbora guztian mantentzea baino.
Zerbitzaririk gabeko konputazioaren abantaila guztiekin, inplementatu baino lehen, aplikazioaren logika ebaluatu beharko zenuke eta zer arazo Zerbitzaririk gabeko kasu jakin batean ebatzi dezakeen ulertu beharko zenuke.
Zerbitzaririk gabeko eta Selectel
Selectel-en gaude jada gure kontrol panelaren bidez. Orain gure FaaS plataforma eraikitzen ari gara. Garatzaileek Serverless erabiliz dituzten arazoak konpontzeko gai izatea nahi dugu, interfaze eroso eta malgu baten bidez.
FaaS plataforma idealak zein izan behar duen eta nola erabili nahi duzun Serverless zure proiektuetan ideiak badituzu, partekatu iruzkinetan. Zure nahiak kontuan hartuko ditugu plataforma garatzerakoan.
Artikuluan erabilitako materialak:
Iturria: www.habr.com