Serverless nav par fizisku serveru neesamību. Tas nav 'nāves iznīcinātājs' konteineriem un ne mirkļa modes tendence. Tas ir jauns pieejas veids sistēmu veidošanai mākoņos. Šajā rakstā apskatīsim Serverless lietojumprogrammu arhitektūru, noskaidrosim, kāda loma ir Serverless pakalpojumu sniedzējam un open-source projektiem. Beigās runāsim par Serverless pielietošanas jautājumiem.
Es gribu uzrakstīt lietojumprogrammas servera pusi (pat interneta veikalam). Tas var būt gan čats, gan saturu publicēšanas pakalpojums, gan slodzes līdzsvarotājs. Katrā ziņā būs daudz galvassāpju: būs jāpreparē infrastruktūra, jānosaka lietojuma atkarības, jāspriež par hosta operētājsistēmu. Pēc tam būs nepieciešams atjaunināt nelielus komponentus, kas neietekmē pārējo monolītu. Un par slodzes mērogošanu arī nedrīkstam aizmirst.
Bet ko darīt, ja paņem efemērus konteinerus, kuros nepieciešamās atkarības jau ir iepriekš instalētas, un paši konteineri ir izolēti viens no otra un no OS hosta? Monolītu sadalām mikroservisos, katrs no kuriem var tikt atjaunināts un mērogots neatkarīgi no citiem. Ievietojot kodu šādā konteinerā, es varēšu to palaist uz jebkuras infrastruktūras. Jau labāk.
Bet, ja negribas konfigurēt konteinerus? Negribas domāt par lietojumprogrammas mērogošanu. Negribas maksāt par palaistiem konteineriem, kad slodze uz pakalpojumu ir minimāla. Gribas rakstīt kodu. Koncentrēties uz biznesa loģiku un laist tirgū produktus ar gaismas ātrumu.
Tādas domas noveda mani pie bezserveru skaitļošanas. Serverless šajā gadījumā nozīmē ne fizisku serveru neesamību, bet galvassāpju neesamību par infrastruktūras pārvaldīšanu.
Ideja ir tāda, ka lietojumprogrammas loģika tiek sadalīta neatkarīgās funkcijās. Tām ir notikumu struktūra. Katras funkcijas izpilda vienu "mikrodarbu". Viss, kas ir nepieciešams izstrādātājam, ir augšupielādēt funkcijas piegādātāja nodrošinātajā mākoņa konsolē un sasaistīt tās ar notikumu avotiem. Kods tiks izpildīts pieprasījuma laikā automātiski sagatavotā konteinerā, un es maksāšu tikai par izpildes laiku.
Paskatīsimies, kā tagad izskatīsies lietojumprogrammas izstrādes process.
No izstrādātāja puses
Iepriekš mēs sākām runāt par interneta veikala lietojumprogrammu. Tradicionālajā pieejā sistēmas pamatloģiku veic monolīta lietojumprogramma. Un serveris ar lietojumprogrammu darbojas pastāvīgi, pat ja nav slodzes.
Lai pārietu uz serverless, mēs sadalām lietojumprogrammu mikrodaļās. Katram no tiem mēs rakstām savu funkciju. Funkcijas ir neatkarīgas viena no otras un neuzglabā stāvokļa informāciju (stateless). Tās pat var būt uzrakstītas dažādās valodās. Ja viena no tām „nokritīs”, lietojumprogramma kopumā netiks apturēta. Lietojumprogrammas arhitektūra izskatīsies šādi:
Dalīšana funkcijās Serverless atgādina darbu ar mikroservisiem. Tomēr mikroserviss var izpildīt vairākas uzdevumus, bet funkcijai ideāli jāveic viens. Iedomāsimies, ka uzdevums ir vākšanas statistika un izsniegšana pēc lietotāja pieprasījuma. Mikroservisa pieejā šo uzdevumu veic viens serviss ar diviem ieejas punktiem: ierakstīšanai un lasīšanai. Bezservera aprēķinos tie būs divi atsevišķi funkcijas, kuri nav savstarpēji saistīti. Izstrādātājs ietaupa aprēķinu resursus, ja, piemēram, statistika tiek atjaunota biežāk, nekā tā tiek izvadīta.
Serverless funkcijām jāizpildās īsā laika posmā (timeout), ko nosaka pakalpojumu sniedzējs. Piemēram, AWS izpildes laiks ir 15 minūtes. Tas nozīmē, ka ilgstošas funkcijas (long-lived) būs jāpārveido atbilstoši prasībām — šis serverless atšķiras no citām šodien populārām tehnoloģijām (konteineriem un Platform as a Service).
Katrā funkcijā piešķiram notikumu. Notikums ir darbības trigeris:
Notikums
Darbība, ko veic funkcija
Krātuvē augšupielādēja produkta attēlu
Saspiežam attēlu un augšupielādējam katalogā
Datu bāzē tika atjaunota fiziskā veikala adrese
Ielādējam kartēs jauno atrašanās vietu
Klients apmaksā preci
Sākam maksājuma apstrādi
Notikumi var būt HTTP pieprasījumi, straumējoši dati, ziņojumu rindas un tā tālāk. Notikumu avoti ir datu izmaiņas vai parādīšanās. Turklāt funkcijas var palaist pēc taimeriem.
Arhitektūru esam izstrādājuši, un lietojumprogramma gandrīz ir kļuvusi par serverless. Pārējais ved uz pakalpojumu sniedzēju.
No pakalpojumu sniedzēja puses
Parasti bezservera aprēķinus piedāvā mākoņu pakalpojumu sniedzēji. Tos sauc dažādi: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Izmantosim pakalpojumu caur konsoli vai pakalpojumu sniedzēja lietotāja kontu. Funkciju kodu var augšupielādēt vienā no veidiem:
- uzrakstīt kodu iebūvētos redaktoros caur tīmekļa konsoli,
- augšupielādēt arhīvu ar kodu,
- strādāt ar publiskiem vai privātiem git-repozitorijiem.
Šeit mēs konfigurējam notikumus, kas aktivizē funkciju. Atšķirīgiem pakalpojumu sniedzējiem notikumu kopas var atšķirties.
Pakalpojumu sniedzējs ir izveidojis un automatizējis funkcijas kā pakalpojuma (FaaS) sistēmu savā infrastruktūrā:
- Funkciju kods tiek glabāts pakalpojumu sniedzēja krātuvē.
- Kad notikums notiek, uz servera automātiski tiek palaisti konteineri ar sagatavotu vidējo. Katram funkcijas piemēram ir sava izolēta konteineru.
- No krātuves funkcija tiek nosūtīta uz konteineru, tiek aprēķināta un sniedz rezultātu.
- Vienlaicīgo notikumu skaits pieaug, līdz ar to pieaug arī konteineru skaits. Sistēma automātiski pielāgojas. Ja lietotāji neizmanto funkciju, tā paliks neaktīva.
- Pakalpojumu sniedzējs nosaka konteineru bezdarbības laiku — ja šajā laikā funkcijas neparādās konteinerā, tas tiek iznīcināts.
Tādējādi mēs iegūstam serverless risinājumu „no kastes”. Par pakalpojumu maksāsim pēc pay-as-you-go modeļa tikai par tām funkcijām, kuras tiek izmantotas, un tikai par to laiku, kad tās tika izmantotas.
Lai iepazīstinātu izstrādātājus ar pakalpojumu, pakalpojumu sniedzēji piedāvā līdz 12 mēnešu bezmaksas izmēģinājuma periodu, taču ierobežo kopējo aprēķinu laiku, pieprasījumu skaitu mēnesī, naudas līdzekļus vai patērētās jaudas.
Galvenā priekšrocība sadarbojoties ar pakalpojumu sniedzēju ir tas, ka nav jāuztraucas par infrastruktūru (serveriem, virtuālajām mašīnām, konteineriem). No savas puses pakalpojumu sniedzējs var īstenot FaaS gan ar saviem izstrādājumiem, gan ar open-source rīkiem. Par to mēs runāsim tālāk.
No open source puses
Pēdējos pāris gados open-source kopiena aktīvi strādā pie serverless rīkiem. Tajā skaitā ieguldījumu bezservertisko platformu attīstībā sniedz lielākie tirgus spēlētāji:
- Google piedāvā izstrādātājiem savu open-source rīku — . Tās izstrādē piedalījušies IBM, RedHat, Pivotal un SAP;
- IBM strādāja pie serverless platformas , kas vēlāk kļuva par Apache Foundation projektu;
- Microsoft daļēji atklāja platformas kodu .
Izstrādes tiek veiktas arī virzienā uz serverless ietvariem. un tiek uzstādīti iepriekš sagatavotos Kubernetes klasteros, darbojas gan ar Kubernetes, gan ar Docker Swarm. Rāmju darbs kalpo kā savdabīgs kontrolieris – pēc pieprasījuma sagatavo izpildes vidi iekšpusē klastera un pēc tam uzsāk funkciju tur.
Rāmji atstāj iespēju konfigurēt rīku savām vajadzībām. Piemēram, Kubeless izstrādātājs var iestatīt funkcijas izpildes laika ierobežojumu (noklusējuma vērtība – 180 sekundes). Fission, cenšoties risināt aukstā starta problēmu, piedāvā daļu konteineru turēt vienmēr aizsāktus (lai gan tas rada resursu neizmantotību). OpenFaaS piedāvā virkni trigeru, kas piemēroti jebkurai gaumei: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs un citi.
Norādījumus, kā sākt strādāt, var atrast rāmju oficiālajā dokumentācijā. Darbs ar tiem prasa nedaudz vairāk prasmju nekā, strādājot ar pakalpojumu sniedzēju – vismaz iespēju palaist Kubernetes klasteri caur CLI. Maksimums – iekļaut darbā citus open-source rīkus (piemēram, Kafka rindas pārvaldnieku).
Neatkarīgi no tā, kādu veidu mēs izmantosim Serverless – caur pakalpojumu sniedzēju vai izmantojot open-source, mēs iegūstam virkni priekšrocību un trūkumu Serverless pieejā.
No priekšrocību un trūkumu pozīcijas
Serverless attīsta idejas par konteineru infrastruktūru un mikroservisu pieeju, kur komandām ir iespējams strādāt daudzvalodu režīmā, nepiesaistoties vienai platformai. Sistēmas veidošana kļūst vienkāršāka, un kļūdu labošana top vieglāka. Mikroservisu arhitektūra ļauj pievienot sistēmai jaunu funkcionalitāti daudz ātrāk nekā monolītajā lietojumprogrammā.
Serverless vēl vairāk samazina izstrādes laiku, ļaujot izstrādātājam koncentrēties tikai uz lietojumprogrammas biznesa loģiku un koda rakstīšanu. Rezultātā izstrādājumu iznākšanas laiks uz tirgu saīsinās.
Mums arī ir automātiska lieluma pielāgošana slodzei, bet mēs maksājam tikai par izmantotajiem resursiem un tikai tajā laikā, kad tie tiek izmantoti.
Kā jebkurai tehnoloģijai, Serverless ir trūkumi.
Piemēram, viens no šiem trūkumiem var būt aukstā starta laiks (vidēji līdz 1 sekundei tādiem valodām kā JavaScript, Python, Go, Java, Ruby).
No vienas puses, reālajā dzīvē aukstā starta laiks ir atkarīgs no daudziem mainīgajiem faktoriem: valoda, kurā ir uzrakstīta funkcija, bibliotēku skaits, koda apjoms, mijiedarbība ar papildu resursiem (tādām kā datu bāzēm vai autentifikācijas serveriem). Tā kā izstrādātājs kontrolē šos mainīgos, viņš var samazināt starta laiku. Bet no otras puses, izstrādātājs nevar kontrolēt konteineru palaišanas laiku - šeit viss ir atkarīgs no pakalpojumu sniedzēja.
Aukstā starta situācija var pārvērsties siltā, kad funkcija izmanto jau iepriekš palaistu konteineru no iepriekšējas notikumu. Šāda situācija var rasties trijos gadījumos:
- ja klienti bieži izmanto pakalpojumu un palielinās pieprasījumu skaits pēc funkcijas;
- ja pakalpojumu sniedzējs, platforma vai ietvars ļauj turēt daļu konteineru palaist visu laiku;
- ja izstrādātājs iedarbina funkcijas pēc taimera (piemēram, ik pēc 3 minūtēm).
Daudzām lietojumprogrammām aukstā starta jautājums nav problēma. Šeit jākoncentrējas uz servisa veidu un uzdevumiem. Startup aizkave uz sekundi ne vienmēr ir kritiska biznesa lietojumprogrammas gadījumā, bet var būt kritiska medicīnas pakalpojumos. Visticamāk, šajā gadījumā serverless pieeja vairs nebūs piemērota.
Nākamais trūkums, ko min Serverless, ir īss funkcijas mūža laiks (timeout, kurā funkcijai jāizpildās).
Taču, ja paredzēts strādāt ar ilgstošām uzdevumiem, var izmantot hibrīdu arhitektūru - kombinējot Serverless ar citu tehnoloģiju.
Ne visas sistēmas spēs darboties saskaņā ar Serverless shēmu.
Dažas lietojumprogrammas joprojām glabās datus un stāvokli izpildes laikā. Dažas arhitektūras paliks monolītiskas, savukārt dažas funkcijas būs ilgstošas. Tomēr (kā kādreiz mākoņu tehnoloģijas, tad konteineri), Serverless - tehnoloģija ar lielu nākotni.
Šajā kontekstā es vēlētos pakāpeniski pāriet uz Serverless pieejas izmantošanas jautājumu.
Pielietojuma pusē
2018. gadā Serverless lietošanas procentuālais īpatsvars . Starp uzņēmumiem, kas jau ir integrējuši tehnoloģiju savos pakalpojumos, ir tādi tirgus giganti kā Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Tajā pašā laikā ir jāapzinās, ka Serverless nav panaceja, bet instruments noteiktu uzdevumu risināšanai:
- Samazināt resursu dīkstāvi. Nav nepieciešams nepārtraukti uzturēt virtuālo mašīnu pakalpojumiem, kuriem ir maz atsauču.
- Apstrādāt datus "uz vietas". Saspiežot attēlus, izgriežot fonu, mainot video kodēšanu, strādājot ar IoT sensoriem, veicot matemātiskas operācijas.
- "Savienot" kopā citus pakalpojumus. Git repozitorijs ar iekšējiem programmām, čata bots Slack ar Jira un kalendāru.
- Balansēt slodzi. Šeit apstāsies detalizētāk.
Pieņemsim, ka ir pakalpojums, uz kuru nāk 50 cilvēki. Tam tiek piešķirta virtuālā mašīna ar vāju aparatūru. Periodiski slodze uz pakalpojumu pieaug vairākkārtīgi. Tad vāja aparatūra nespēj tikt galā.
Var iekļaut sistēmā balansētāju, kurš sadalīs slodzi, teiksim, uz trim virtuālajām mašīnām. Šajā posmā mēs nevaram precīzi prognozēt slodzi, tāpēc kādu resursu daudzumu turpinām darbināt "rezervē". Un pārmaksājam par dīkstāvi.
Šādā situācijā mēs varam optimizēt sistēmu, izmantojot hibrīda pieeju: aiz slodzes balansētāja atstājam vienu virtuālo mašīnu un iestatām saiti uz Serverless Endpoint ar funkcijām. Ja slodze pārsniedz robežu, balansētājs aktivizē funkciju instancē, kas uzņem daļu pieprasījumu apstrādes.
Tādējādi Serverless var izmantot tur, kur ir nepieciešams ne pārāk bieži, bet intensīvi apstrādāt lielu pieprasījumu skaitu. Šajā gadījumā ir izdevīgāk palaist vairākas funkcijas uz 15 minūtēm, nekā visu laiku uzturēt virtuālo mašīnu vai serveri.
Neskatoties uz visām bezserveru skaitļošanas priekšrocībām, pirms ieviešanas vispirms ir jānovērtē lietojumprogrammas loģika un jāizprot, kādas problēmas Serverless var atrisināt konkrētajā gadījumā.
Serverless un Selectel
Selectel mēs jau esam caur mūsu vadības paneli. Tagad mēs veidojam savu FaaS platformu. Mēs vēlamies, lai izstrādātāji varētu risināt savus uzdevumus, izmantojot Serverless caur ērtu, elastīgu interfeisu.
Ja jums ir idejas, kādai jābūt ideālai FaaS platformai un kā jūs vēlaties izmantot Serverless savos projektos, dalieties ar tām komentāros. Mēs ņemsim vērā jūsu vēlmes platformas izstrādē.
Materiāli, kas izmantoti rakstā:
Avots: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish