Bez servera po stalcima

Bez servera po stalcima
Bez servera se ne radi o fizičkom odsustvu servera. Ovo nije ubica kontejnera ili prolazni trend. Ovo je novi pristup izgradnji sistema u oblaku. U današnjem članku ćemo se dotaknuti arhitekture aplikacija bez servera, da vidimo kakvu ulogu imaju pružatelj usluga bez servera i projekti otvorenog koda. Na kraju, hajde da razgovaramo o problemima korišćenja bez servera.

Želim da napišem serverski deo aplikacije (ili čak online prodavnicu). Ovo može biti chat, usluga objavljivanja sadržaja ili balansiranje opterećenja. U svakom slučaju, biće mnogo glavobolja: moraćete da pripremite infrastrukturu, odredite zavisnosti aplikacije i razmislite o operativnom sistemu domaćina. Tada ćete morati ažurirati male komponente koje ne utječu na rad ostatka monolita. Pa, ne zaboravimo na skaliranje pod opterećenjem.

Šta ako uzmemo efemerne kontejnere, u kojima su potrebne zavisnosti već unapred instalirane, a sami kontejneri su izolovani jedan od drugog i od OS hosta? Podijelit ćemo monolit na mikroservise, od kojih se svaki može ažurirati i skalirati nezavisno od ostalih. Postavljanjem koda u takav kontejner, mogu ga pokrenuti na bilo kojoj infrastrukturi. Već bolje.

Što ako ne želite konfigurirati kontejnere? Ne želim razmišljati o skaliranju aplikacije. Ne želim da plaćam kontejnere koji rade u praznom hodu kada je opterećenje usluge minimalno. Želim napisati kod. Fokusirajte se na poslovnu logiku i iznesite proizvode na tržište brzinom svjetlosti.

Takve misli su me dovele do računarstva bez servera. Serverless u ovom slučaju znači ne fizičko odsustvo servera, već odsustvo glavobolje upravljanja infrastrukturom.

Ideja je da se logika aplikacije razbije na nezavisne funkcije. Imaju strukturu događaja. Svaka funkcija obavlja jedan „mikrozadatak“. Sve što je potrebno od programera je da učita funkcije u konzolu koju pruža cloud provajder i poveže ih sa izvorima događaja. Kod će se izvršiti na zahtjev u automatski pripremljenom kontejneru, a ja ću platiti samo vrijeme izvršenja.

Pogledajmo kako će sada izgledati proces razvoja aplikacije.

Sa strane programera

Ranije smo počeli da pričamo o aplikaciji za internet prodavnicu. U tradicionalnom pristupu, glavnu logiku sistema izvodi monolitna aplikacija. A server sa aplikacijom stalno radi, čak i ako nema opterećenja.

Da bismo prešli na bez servera, razbijamo aplikaciju na mikrozadatke. Za svaku od njih pišemo vlastitu funkciju. Funkcije su nezavisne jedna od druge i ne pohranjuju informacije o stanju (bez stanja). Čak mogu biti napisane na različitim jezicima. Ako jedan od njih “padne”, cijela aplikacija neće stati. Arhitektura aplikacije će izgledati ovako:

Bez servera po stalcima
Podjela na funkcije u Serverless je slična radu s mikroservisima. Ali mikroservis može obavljati nekoliko zadataka, a funkcija bi u idealnom slučaju trebala obavljati jedan. Zamislimo da je zadatak prikupiti statistiku i prikazati je na zahtjev korisnika. U mikroservisnom pristupu, zadatak obavlja jedan servis sa dvije ulazne tačke: pisanje i čitanje. U računarstvu bez servera, to će biti dvije različite funkcije koje nisu povezane jedna s drugom. Programer štedi računarske resurse ako se, na primjer, statistika ažurira češće nego što se preuzima.

Funkcije bez servera moraju se izvršiti u kratkom vremenskom periodu (timeout), koji određuje provajder servisa. Na primjer, za AWS vremensko ograničenje je 15 minuta. To znači da će dugotrajne funkcije morati da se menjaju kako bi odgovarale zahtevima - to je ono što razlikuje Serverless od ostalih popularnih tehnologija danas (kontejneri i Platforma kao usluga).

Svakoj funkciji dodjeljujemo događaj. Događaj je okidač za akciju:

Događaj
Radnja koju funkcija obavlja

Slika proizvoda je učitana u spremište.
Komprimirajte sliku i prenesite u direktorij

Adresa fizičke prodavnice je ažurirana u bazi podataka
Učitajte novu lokaciju u mape

Klijent plaća robu
Započnite obradu plaćanja

Događaji mogu biti HTTP zahtjevi, streaming podataka, redovi poruka itd. Izvori događaja su promjene ili pojave podataka. Osim toga, funkcije se mogu pokrenuti pomoću tajmera.

Arhitektura je razrađena, a aplikacija je skoro postala bez servera. Zatim idemo do dobavljača usluga.

Sa strane provajdera

Obično, računarstvo bez servera nude pružaoci usluga u oblaku. Zovu se drugačije: Azure funkcije, AWS Lambda, Google Cloud funkcije, IBM Cloud funkcije.

Uslugu ćemo koristiti putem konzole ili ličnog računa provajdera. Kod funkcije se može preuzeti na jedan od sljedećih načina:

  • pisati kod u ugrađenim uređivačima putem web konzole,
  • preuzmite arhivu sa kodom,
  • rad sa javnim ili privatnim git repozitorijumima.

Ovdje postavljamo događaje koji pozivaju funkciju. Skupovi događaja mogu se razlikovati za različite provajdere.

Bez servera po stalcima

Provajder je izgradio i automatizovao sistem funkcije kao usluge (FaaS) na svojoj infrastrukturi:

  1. Kôd funkcije završava u skladištu na strani dobavljača.
  2. Kada dođe do događaja, kontejneri sa pripremljenim okruženjem se automatski postavljaju na server. Svaka instanca funkcije ima svoj izolirani spremnik.
  3. Iz skladišta se funkcija šalje u kontejner, izračunava i vraća rezultat.
  4. Raste broj paralelnih događaja - raste broj kontejnera. Sistem automatski skalira. Ako korisnici ne pristupe funkciji, ona će biti neaktivna.
  5. Provajder postavlja vrijeme mirovanja za kontejnere - ako se za to vrijeme funkcije ne pojave u kontejneru, on se uništava.

Na ovaj način dobijamo Serverless iz kutije. Uslugu ćemo platiti po modelu pay-as-you-go i to samo za one funkcije koje se koriste i samo za vrijeme kada su korištene.

Kako bi programere upoznali sa uslugom, provajderi nude do 12 mjeseci besplatnog testiranja, ali ograničavaju ukupno vrijeme računanja, broj zahtjeva mjesečno, sredstva ili potrošnju energije.

Glavna prednost rada sa provajderom je mogućnost da ne brinete o infrastrukturi (serveri, virtuelne mašine, kontejneri). Sa svoje strane, provajder može implementirati FaaS i korištenjem vlastitih razvoja i korištenjem alata otvorenog koda. Hajde da pričamo o njima dalje.

Sa strane otvorenog koda

Zajednica otvorenog koda je aktivno radila na alatima bez servera posljednjih nekoliko godina. Najveći tržišni igrači također doprinose razvoju platformi bez servera:

  • Google nudi programerima svoj alat otvorenog koda - knativ. U njegovom razvoju su učestvovali IBM, RedHat, Pivotal i SAP;
  • IBM radio na platformi bez servera OpenWhisk, koji je tada postao projekat Apache fondacije;
  • Microsoft djelomično otvorio kod platforme Azure funkcije.

Razvoj je takođe u toku u pravcu bezserverskih okvira. Kubeless и Fisija raspoređeni unutar unaprijed pripremljenih Kubernetes klastera, OpenFaaS radi i sa Kubernetesom i sa Docker Swarmom. Framework djeluje kao neka vrsta kontrolera - na zahtjev, priprema okruženje za izvršavanje unutar klastera, a zatim tamo pokreće funkciju.

Okviri ostavljaju prostor za konfigurisanje alata prema vašim potrebama. Dakle, u Kubeless-u, programer može konfigurirati vremensko ograničenje izvršavanja funkcije (podrazumevana vrijednost je 180 sekundi). Fission, u pokušaju da riješi problem hladnog starta, predlaže da se neki kontejneri stalno rade (iako to podrazumijeva troškove zastoja resursa). A OpenFaaS nudi skup okidača za svaki ukus i boju: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NAT i drugi.

Uputstva za početak možete pronaći u službenoj dokumentaciji okvira. Rad s njima zahtijeva malo više vještina nego kada radite s provajderom - ovo je barem sposobnost pokretanja Kubernetes klastera putem CLI-a. Najviše, uključite druge alate otvorenog koda (na primjer, Kafka upravitelj redova).

Bez obzira na to kako radimo sa serverless-om - preko provajdera ili koristeći open-source, dobićemo brojne prednosti i nedostatke pristupa bez servera.

Sa stanovišta prednosti i mana

Serverless razvija ideje o kontejnerskoj infrastrukturi i mikroservisnom pristupu, u kojem timovi mogu raditi u višejezičnom načinu bez vezanja za jednu platformu. Izgradnja sistema je pojednostavljena, a greške se lakše ispravljaju. Mikroservisna arhitektura vam omogućava da dodate nove funkcionalnosti sistemu mnogo brže nego u slučaju monolitne aplikacije.

Bez servera još više smanjuje vrijeme razvoja, omogućavajući programeru da se fokusira isključivo na poslovnu logiku i kodiranje aplikacije. Kao rezultat toga, vrijeme za razvoj tržišta se smanjuje.

Kao bonus, dobijamo automatsko skaliranje za opterećenje, a mi plaćamo samo za utrošena sredstva i samo u vrijeme kada se koriste.

Kao i svaka tehnologija, Serverless ima nedostatke.

Na primjer, takav nedostatak može biti hladno vrijeme početka (u prosjeku do 1 sekunde za jezike kao što su JavaScript, Python, Go, Java, Ruby).

S jedne strane, u stvarnosti, vrijeme hladnog starta ovisi o mnogim varijablama: jeziku na kojem je funkcija napisana, broju biblioteka, količini koda, komunikaciji s dodatnim resursima (iste baze podataka ili serveri za autentifikaciju). Budući da programer kontrolira ove varijable, može smanjiti vrijeme pokretanja. Ali s druge strane, programer ne može kontrolirati vrijeme pokretanja kontejnera - sve ovisi o provajderu.

Hladni početak može se pretvoriti u topli početak kada funkcija ponovo koristi kontejner pokrenut prethodnim događajem. Ova situacija će se pojaviti u tri slučaja:

  • ako klijenti često koriste uslugu i broj poziva funkciji se povećava;
  • ako vam dobavljač, platforma ili okvir dozvoljavaju da neki kontejneri rade cijelo vrijeme;
  • ako programer pokreće funkcije na tajmeru (recimo svaka 3 minute).

Za mnoge aplikacije, hladan start nije problem. Ovdje morate graditi na vrsti i zadacima usluge. Kašnjenje početka od jedne sekunde nije uvijek kritično za poslovnu aplikaciju, ali može postati kritično za medicinske usluge. U ovom slučaju, pristup bez servera vjerovatno više neće biti prikladan.

Sljedeći nedostatak bez servera je kratak vijek trajanja funkcije (vremensko ograničenje tokom kojeg funkcija mora biti izvršena).

Ali, ako morate da radite sa dugotrajnim zadacima, možete koristiti hibridnu arhitekturu - kombinovati Serverless sa drugom tehnologijom.

Neće svi sistemi moći da rade koristeći šemu bez servera.

Neke aplikacije će i dalje pohranjivati ​​podatke i stanje tokom izvršavanja. Neke arhitekture će ostati monolitne, a neke karakteristike će dugo trajati. Međutim (kao i cloud tehnologije, a zatim i kontejneri), bez servera je tehnologija sa velikom budućnošću.

U tom smislu, želio bih glatko preći na pitanje korištenja pristupa bez servera.

Sa strane aplikacije

Za 2018., postotak korištenja bez servera porastao jedan i po put. Među kompanijama koje su već implementirale tehnologiju u svoje usluge su tržišni divovi kao što su Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Istovremeno, morate shvatiti da Serverless nije lijek, već alat za rješavanje određenog niza problema:

  • Smanjite vrijeme zastoja resursa. Nema potrebe stalno držati virtuelnu mašinu za usluge koje imaju malo poziva.
  • Obradite podatke u hodu. Komprimirajte slike, izrežite pozadinu, promijenite video kodiranje, radite sa IoT senzorima, izvodite matematičke operacije.
  • “Zalijepite” druge usluge zajedno. Git repozitorij sa internim programima, chat bot u Slack-u sa Jira i kalendarom.
  • Uravnotežite opterećenje. Pogledajmo pobliže ovdje.

Recimo da postoji usluga koja privlači 50 ljudi. Ispod njega se nalazi virtuelna mašina sa slabim hardverom. S vremena na vrijeme, opterećenje usluge se značajno povećava. Tada se slab hardver ne može nositi.

Možete uključiti balanser u sistem koji će rasporediti opterećenje, recimo, na tri virtuelne mašine. U ovoj fazi ne možemo precizno predvidjeti opterećenje, tako da određenu količinu resursa držimo „u rezervi“. I preplaćujemo zastoje.

U takvoj situaciji možemo optimizirati sistem kroz hibridni pristup: ostavljamo jednu virtuelnu mašinu iza balansera opterećenja i stavljamo vezu na krajnju tačku bez servera sa funkcijama. Ako opterećenje premašuje prag, balanser pokreće instance funkcije koje preuzimaju dio obrade zahtjeva.

Bez servera po stalcima
Dakle, Serverless se može koristiti tamo gdje je potrebno obraditi veliki broj zahtjeva ne prečesto, već intenzivno. U ovom slučaju, pokretanje nekoliko funkcija u trajanju od 15 minuta je isplativije od stalnog održavanja virtuelne mašine ili servera.

Uz sve prednosti računarstva bez servera, prije implementacije, prvo biste trebali procijeniti logiku aplikacije i razumjeti koje probleme može riješiti bez servera u određenom slučaju.

Serverless i Selectel

U Selectelu već jesmo pojednostavljen rad sa Kubernetesom preko naše kontrolne table. Sada gradimo vlastitu FaaS platformu. Želimo da programeri budu u mogućnosti da riješe svoje probleme koristeći Serverless kroz pogodan, fleksibilan interfejs.

Ako imate ideje o tome koja bi idealna FaaS platforma trebala biti i kako želite koristiti bez servera u svojim projektima, podijelite ih u komentarima. Vaše želje ćemo uzeti u obzir prilikom razvoja platforme.
 
Materijali korišteni u članku:

izvor: www.habr.com

Dodajte komentar