Brez strežnika na stojalih

Brez strežnika na stojalih
Brez strežnikov ne gre za fizično odsotnost strežnikov. To ni uničevalec kontejnerjev ali prehodni trend. To je nov pristop k izgradnji sistemov v oblaku. V današnjem članku se bomo dotaknili arhitekture aplikacij brez strežnikov, poglejmo, kakšno vlogo igrajo ponudnik storitev brez strežnikov in odprtokodni projekti. Nazadnje se pogovorimo o težavah pri uporabi brez strežnika.

Želim napisati strežniški del aplikacije (ali celo spletne trgovine). To je lahko klepet, storitev za objavljanje vsebine ali izravnavalec obremenitve. V vsakem primeru bo preglavic veliko: pripraviti bo treba infrastrukturo, določiti odvisnosti aplikacij in razmisliti o gostiteljskem operacijskem sistemu. Nato boste morali posodobiti majhne komponente, ki ne vplivajo na delovanje preostalega monolita. No, ne pozabimo na skaliranje pod obremenitvijo.

Kaj pa, če vzamemo efemerne kontejnerje, v katerih so zahtevane odvisnosti že vnaprej nameščene, sami kontejnerji pa so izolirani drug od drugega in od gostiteljskega OS? Monolit bomo razdelili na mikrostoritve, od katerih bo vsako mogoče posodobiti in skalirati neodvisno od drugih. Če kodo postavim v tak vsebnik, jo lahko izvajam na kateri koli infrastrukturi. Že bolje.

Kaj pa, če ne želite konfigurirati vsebnikov? Nočem razmišljati o povečanju aplikacije. Ne želim plačati za zabojnike v prostem teku, ko je obremenitev storitve minimalna. Želim napisati kodo. Osredotočite se na poslovno logiko in prinesite izdelke na trg s svetlobno hitrostjo.

Takšne misli so me pripeljale do brezstrežniškega računalništva. Brez strežnika v tem primeru pomeni ne fizična odsotnost strežnikov, ampak odsotnost upravljanja infrastrukture.

Ideja je, da je logika aplikacije razdeljena na neodvisne funkcije. Imajo prireditveno strukturo. Vsaka funkcija opravlja eno »mikroopravilo«. Vse, kar se zahteva od razvijalca, je naložiti funkcije v konzolo, ki jo ponuja ponudnik oblaka, in jih povezati z viri dogodkov. Koda se bo na zahtevo izvajala v avtomatsko pripravljenem vsebniku, plačal pa bom le čas izvedbe.

Poglejmo, kako bo zdaj izgledal proces razvoja aplikacije.

S strani razvijalca

Prej smo začeli govoriti o aplikaciji za spletno trgovino. Pri tradicionalnem pristopu glavno logiko sistema izvaja monolitna aplikacija. In strežnik z aplikacijo nenehno deluje, tudi če ni obremenitve.

Za prehod na brezstrežniško aplikacijo razdelimo na mikroopravila. Za vsakega od njih napišemo svojo funkcijo. Funkcije so neodvisne druga od druge in ne shranjujejo informacij o stanju (brez stanja). Lahko so celo napisani v različnih jezikih. Če eden od njih "pade", se celotna aplikacija ne bo ustavila. Arhitektura aplikacije bo videti takole:

Brez strežnika na stojalih
Delitev na funkcije v Serverless je podobna delu z mikrostoritvami. Toda mikrostoritev lahko izvaja več nalog, funkcija pa bi morala v idealnem primeru opravljati eno. Predstavljajmo si, da je naloga zbrati statistiko in jo prikazati na zahtevo uporabnika. Pri mikrostoritvenem pristopu nalogo izvaja ena storitev z dvema vstopnima točkama: pisanje in branje. Pri brezstrežniškem računalništvu bosta to dve različni funkciji, ki med seboj nista povezani. Razvijalec prihrani računalniške vire, če se na primer statistika posodablja pogosteje kot se prenaša.

Brezstrežniške funkcije morajo biti izvedene v kratkem času (timeout), ki ga določi ponudnik storitve. Na primer, za AWS je časovna omejitev 15 minut. To pomeni, da bo treba dolgožive funkcije spremeniti, da bodo ustrezale zahtevam - to je tisto, kar razlikuje Serverless od drugih danes priljubljenih tehnologij (vsebniki in platforma kot storitev).

Vsaki funkciji dodelimo dogodek. Dogodek je sprožilec dejanja:

Dogodek
Dejanje, ki ga funkcija izvaja

Slika izdelka je bila naložena v repozitorij.
Stisnite sliko in jo naložite v imenik

Naslov fizične trgovine je posodobljen v bazi podatkov
Naložite novo lokacijo v zemljevide

Naročnik plača blago
Začni obdelavo plačila

Dogodki so lahko zahteve HTTP, pretočni podatki, čakalne vrste sporočil itd. Viri dogodkov so spremembe ali pojavitve podatkov. Poleg tega lahko funkcije sproži časovnik.

Arhitektura je bila izdelana in aplikacija je skoraj postala brezstrežniška. Nato gremo do ponudnika storitev.

S strani ponudnika

Običajno brezstrežniško računalništvo ponujajo ponudniki storitev v oblaku. Imenujejo se različno: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.

Storitev bomo uporabljali prek ponudnikove konzole ali osebnega računa. Funkcijsko kodo lahko prenesete na enega od naslednjih načinov:

  • pisanje kode v vgrajenih urejevalnikih prek spletne konzole,
  • prenesite arhiv s kodo,
  • delo z javnimi ali zasebnimi repozitoriji git.

Tukaj nastavimo dogodke, ki kličejo funkcijo. Nabori dogodkov se lahko pri različnih ponudnikih razlikujejo.

Brez strežnika na stojalih

Ponudnik je zgradil in avtomatiziral sistem Function as a Service (FaaS) na svoji infrastrukturi:

  1. Funkcijska koda konča v shrambi na strani ponudnika.
  2. Ko pride do dogodka, se vsebniki s pripravljenim okoljem samodejno namestijo na strežnik. Vsak primerek funkcije ima svoj izoliran vsebnik.
  3. Iz pomnilnika se funkcija pošlje v vsebnik, izračuna in vrne rezultat.
  4. Število vzporednih dogodkov narašča - število zabojnikov raste. Sistem samodejno skalira. Če uporabniki ne dostopajo do funkcije, bo ta neaktivna.
  5. Ponudnik določi čas mirovanja kontejnerjev – če se v tem času funkcije v kontejnerju ne pojavijo, se ta uniči.

Na ta način dobimo Serverless takoj. Storitev bomo plačevali po dohodnem modelu in samo za tiste funkcije, ki so v uporabi in le za čas, ko so bile v uporabi.

Da bi razvijalcem predstavili storitev, ponudniki ponujajo do 12 mesecev brezplačnega testiranja, vendar omejujejo skupni čas izračuna, število zahtev na mesec, sredstva ali porabo energije.

Glavna prednost sodelovanja s ponudnikom je možnost, da ne skrbite za infrastrukturo (strežniki, virtualni stroji, kontejnerji). Ponudnik lahko izvaja FaaS tako z lastnim razvojem kot z uporabo odprtokodnih orodij. Pogovorimo se o njih naprej.

S strani odprte kode

Odprtokodna skupnost je zadnjih nekaj let aktivno delala na brezstrežniških orodjih. K razvoju brezstrežniških platform prispevajo tudi največji akterji na trgu:

  • google razvijalcem ponuja svoje odprtokodno orodje – knativ. Pri njegovem razvoju so sodelovali IBM, RedHat, Pivotal in SAP;
  • IBM delal na platformi brez strežnika OpenWhisk, ki je nato postal projekt Fundacije Apache;
  • Microsoft delno odprl kodo platforme Azure funkcije.

Razvoj poteka tudi v smeri brezstrežniških ogrodij. Kubeless и Fisija nameščeni znotraj vnaprej pripravljenih gruč Kubernetes, OpenFaaS deluje s Kubernetes in Docker Swarm. Ogrodje deluje kot nekakšen krmilnik - na zahtevo pripravi izvajalno okolje znotraj gruče, nato pa tam zažene funkcijo.

Ogrodja puščajo prostor za konfiguracijo orodja tako, da ustreza vašim potrebam. Tako lahko v Kubelessu razvijalec konfigurira časovno omejitev izvajanja funkcije (privzeta vrednost je 180 sekund). Fission, da bi rešil problem hladnega zagona, predlaga, da nekateri vsebniki delujejo ves čas (čeprav to pomeni stroške izpadov virov). In OpenFaaS ponuja nabor sprožilcev za vsak okus in barvo: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NAT in drugi.

Navodila za začetek najdete v uradni dokumentaciji ogrodij. Delo z njimi zahteva nekaj več spretnosti kot pri delu s ponudnikom – to je vsaj možnost zagona gruče Kubernetes preko CLI. Vključite kvečjemu druga odprtokodna orodja (na primer upravljalnik čakalnih vrst Kafka).

Ne glede na to, kako delamo s Serverless – prek ponudnika ali z uporabo odprte kode, bomo deležni številnih prednosti in slabosti brezstrežniškega pristopa.

Z vidika prednosti in slabosti

Serverless razvija ideje vsebniške infrastrukture in mikrostoritvenega pristopa, v katerem lahko ekipe delajo v večjezičnem načinu, ne da bi bile vezane na eno platformo. Gradnja sistema je poenostavljena in napake je lažje popraviti. Mikrostoritvena arhitektura vam omogoča dodajanje novih funkcionalnosti sistemu veliko hitreje kot v primeru monolitne aplikacije.

Brez strežnika še bolj skrajša razvojni čas, omogoča razvijalcu, da se osredotoči izključno na poslovno logiko in kodiranje aplikacije. Posledično se skrajša čas do trženja razvoja.

Kot bonus dobimo samodejno skaliranje za obremenitev, in plačamo samo za uporabljene vire in samo v času, ko so uporabljeni.

Kot vsaka druga tehnologija ima tudi brezstrežniška tehnologija slabosti.

Takšna pomanjkljivost je lahko na primer čas hladnega zagona (povprečno do 1 sekunde za jezike, kot so JavaScript, Python, Go, Java, Ruby).

Po eni strani je v resnici čas hladnega zagona odvisen od številnih spremenljivk: jezika, v katerem je funkcija napisana, števila knjižnic, količine kode, komunikacije z dodatnimi viri (iste baze podatkov ali strežniki za preverjanje pristnosti). Ker razvijalec nadzoruje te spremenljivke, lahko skrajša čas zagona. Po drugi strani pa razvijalec ne more nadzorovati časa zagona vsebnika - vse je odvisno od ponudnika.

Hladen zagon se lahko spremeni v topel zagon, ko funkcija ponovno uporabi vsebnik, ki ga je zagnal prejšnji dogodek. Ta situacija se bo pojavila v treh primerih:

  • če stranke pogosto uporabljajo storitev in se število klicev na funkcijo poveča;
  • če vam ponudnik, platforma ali ogrodje omogoča, da nekateri vsebniki delujejo ves čas;
  • če razvijalec izvaja funkcije na časovniku (recimo vsake 3 minute).

Za mnoge aplikacije hladen zagon ni problem. Tukaj morate graditi na vrsti in nalogah storitve. Zakasnitev začetka sekunde ni vedno kritična za poslovno aplikacijo, lahko pa postane kritična za zdravstvene storitve. V tem primeru brezstrežniški pristop verjetno ne bo več primeren.

Naslednja pomanjkljivost Serverless je kratka življenjska doba funkcije (časovna omejitev, med katero je treba funkcijo izvesti).

Če pa morate delati z dolgotrajnimi nalogami, lahko uporabite hibridno arhitekturo – združite Serverless z drugo tehnologijo.

Vsi sistemi ne bodo mogli delovati s shemo brez strežnika.

Nekatere aplikacije bodo še vedno shranjevale podatke in stanje med izvajanjem. Nekatere arhitekture bodo ostale monolitne, nekatere funkcije pa dolgožive. Vendar (tako kot tehnologije v oblaku in nato kontejnerji) je Serverless tehnologija z veliko prihodnostjo.

V tem smislu bi rad gladko prešel na vprašanje uporabe pristopa brez strežnika.

S strani aplikacije

Za leto 2018 odstotek uporabe brez strežnika zrasel enkrat in pol. Med podjetji, ki so tehnologijo že implementirala v svoje storitve, so takšni tržni velikani, kot so Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Hkrati morate razumeti, da Serverless ni zdravilo, ampak orodje za reševanje določenega obsega težav:

  • Zmanjšajte čas izpadov virov. Za storitve, ki imajo malo klicev, ni treba nenehno vzdrževati virtualnega stroja.
  • Obdelujte podatke sproti. Stisnite slike, izrežite ozadja, spremenite video kodiranje, delajte s senzorji IoT, izvajajte matematične operacije.
  • »Zlepite« druge storitve skupaj. Repozitorij Git z internimi programi, klepetalnica v Slacku z Jiro in koledar.
  • Uravnotežite obremenitev. Oglejmo si tukaj podrobneje.

Recimo, da obstaja storitev, ki pritegne 50 ljudi. Pod njim je virtualni stroj s šibko strojno opremo. Od časa do časa se obremenitev storitve znatno poveča. Potem šibka strojna oprema ne more kos.

V sistem lahko vključite balanser, ki bo obremenitev razdelil recimo na tri virtualne stroje. Na tej stopnji ne moremo natančno predvideti obremenitve, zato imamo določeno količino virov, ki tečejo »v rezervi«. In preplačamo za izpade.

V takšni situaciji lahko optimiziramo sistem s hibridnim pristopom: pustimo en navidezni stroj za izenačevalnikom obremenitve in postavimo povezavo do končne točke brez strežnika s funkcijami. Če obremenitev preseže prag, izravnalnik zažene primerke funkcij, ki prevzamejo del obdelave zahteve.

Brez strežnika na stojalih
Tako se lahko Serverless uporablja tam, kjer je potrebno obdelati veliko število zahtev ne prepogosto, ampak intenzivno. V tem primeru je izvajanje več funkcij 15 minut bolj donosno kot vzdrževanje virtualnega stroja ali strežnika ves čas.

Ob vseh prednostih brezstrežniškega računalništva je treba pred implementacijo najprej oceniti logiko aplikacije in razumeti, katere težave lahko brezstrežniško reši v posameznem primeru.

Brez strežnika in Selectel

Pri Selectel smo že poenostavljeno delo s Kubernetesom prek naše nadzorne plošče. Zdaj gradimo lastno platformo FaaS. Želimo, da lahko razvijalci svoje težave rešijo z uporabo brezstrežniškega vmesnika prek priročnega in prilagodljivega vmesnika.

Če imate ideje o tem, kakšna bi morala biti idealna platforma FaaS in kako želite uporabiti brezstrežniško platformo v svojih projektih, jih delite v komentarjih. Pri razvoju platforme bomo upoštevali vaše želje.
 
Materiali, uporabljeni v članku:

Vir: www.habr.com

Dodaj komentar