Palvelimeton ei tarkoita palvelimien fyysistä puuttumista. Tämä ei ole konttimurhaaja tai ohimenevä trendi. Tämä on uusi lähestymistapa järjestelmien rakentamiseen pilvessä. Tämän päivän artikkelissa käsittelemme Palvelimettomien sovellusten arkkitehtuuria, katsotaanpa, mikä rooli Serverless-palveluntarjoajalla ja avoimen lähdekoodin projekteilla on. Lopuksi puhutaan Serverlessin käytön ongelmista.
Haluan kirjoittaa palvelimen osan sovelluksesta (tai jopa verkkokaupasta). Tämä voi olla chat, sisällön julkaisupalvelu tai kuormituksen tasapainottaja. Joka tapauksessa tulee paljon päänsärkyä: sinun on valmisteltava infrastruktuuri, määritettävä sovellusriippuvuudet ja mietittävä isäntäkäyttöjärjestelmää. Sitten sinun on päivitettävä pienet komponentit, jotka eivät vaikuta muun monoliitin toimintaan. No, älkäämme unohtako skaalausta kuormituksen alla.
Entä jos otamme lyhytaikaiset säiliöt, joihin tarvittavat riippuvuudet on jo esiasennettu, ja itse säilöt on eristetty toisistaan ja isäntäkäyttöjärjestelmästä? Jaamme monoliitin mikropalveluihin, joista jokainen voidaan päivittää ja skaalata muista riippumatta. Sijoittamalla koodin tällaiseen säiliöön, voin käyttää sitä missä tahansa infrastruktuurissa. Jo paremmin.
Entä jos et halua määrittää säilöjä? En halua ajatella sovelluksen skaalausta. En halua maksaa tyhjäkäynnillä käyvistä konteista, kun palvelun kuormitus on minimaalinen. Haluan kirjoittaa koodin. Keskity liiketoimintalogiikkaan ja tuo tuotteita markkinoille valonnopeudella.
Tällaiset ajatukset johtivat minut palvelimettomaan tietokoneeseen. Palvelimeton tarkoittaa tässä tapauksessa ei palvelimien fyysinen puute, vaan infrastruktuurin hallinnan päänvaivojen puuttuminen.
Ajatuksena on, että sovelluslogiikka on jaettu itsenäisiin toimintoihin. Niillä on tapahtumarakenne. Jokainen toiminto suorittaa yhden "mikrotehtävän". Kehittäjältä vaaditaan vain toimintojen lataaminen pilvipalvelun tarjoajan tarjoamaan konsoliin ja niiden korreloiminen tapahtumalähteiden kanssa. Koodi suoritetaan pyynnöstä automaattisesti valmistetussa säiliössä, ja maksan vain suoritusajasta.
Katsotaan miltä sovelluskehitysprosessi näyttää nyt.
Kehittäjän puolelta
Aiemmin aloimme puhua verkkokaupan hakemuksesta. Perinteisessä lähestymistavassa järjestelmän päälogiikka suorittaa monoliittinen sovellus. Ja palvelin sovelluksen kanssa on jatkuvasti käynnissä, vaikka kuormaa ei olisikaan.
Siirtyäksemme palvelimettomaan sovellukseen jaamme sovelluksen mikrotehtäviin. Kirjoitamme jokaiselle niistä oman funktiomme. Toiminnot ovat toisistaan riippumattomia eivätkä tallenna tilatietoa (tilattomat). Ne voidaan jopa kirjoittaa eri kielillä. Jos yksi niistä "putoaa", koko sovellus ei pysähdy. Sovellusarkkitehtuuri näyttää tältä:
Toimintojen jako Serverlessissä on samanlainen kuin mikropalveluiden kanssa työskentely. Mutta mikropalvelu voi suorittaa useita tehtäviä, ja toiminnon tulisi ihanteellisesti suorittaa yksi. Kuvitellaan, että tehtävänä on kerätä tilastoja ja näyttää ne käyttäjän pyynnöstä. Mikropalvelulähestymistavassa tehtävän suorittaa yksi palvelu, jossa on kaksi sisääntulokohtaa: kirjoittaminen ja lukeminen. Palvelimettomassa laskennassa nämä ovat kaksi eri toimintoa, jotka eivät liity toisiinsa. Kehittäjä säästää laskentaresursseja, jos esimerkiksi tilastot päivitetään useammin kuin ne ladataan.
Palvelimettomat toiminnot tulee suorittaa lyhyessä ajassa (aikakatkaisu), jonka palveluntarjoaja määrittelee. Esimerkiksi AWS:n aikakatkaisu on 15 minuuttia. Tämä tarkoittaa, että pitkäikäisiä toimintoja on muutettava vastaamaan vaatimuksia - tämä erottaa Serverlessin muista nykyään suosituista teknologioista (säilöt ja alusta palveluna).
Määritämme jokaiselle toiminnolle tapahtuman. Tapahtuma laukaisee toiminnon:
Tapahtuma
Toiminto, jonka toiminto suorittaa
Tuotekuva on ladattu arkistoon.
Pakkaa kuva ja lataa se hakemistoon
Fyysisen kaupan osoite on päivitetty tietokantaan
Lataa uusi sijainti karttoihin
Asiakas maksaa tavarat
Aloita maksun käsittely
Tapahtumat voivat olla HTTP-pyyntöjä, suoratoistodataa, viestijonoja ja niin edelleen. Tapahtumalähteet ovat tietojen muutoksia tai esiintymiä. Lisäksi toimintoja voidaan laukaista ajastimella.
Arkkitehtuuri oli kehitetty ja sovellus melkein muuttui palvelimettomaksi. Seuraavaksi mennään palveluntarjoajan puoleen.
Palveluntarjoajan puolelta
Tyypillisesti palvelimetonta tietojenkäsittelyä tarjoavat pilvipalveluntarjoajat. Niitä kutsutaan eri tavalla: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Käytämme palvelua palveluntarjoajan konsolin tai henkilökohtaisen tilin kautta. Toimintokoodi voidaan ladata jollakin seuraavista tavoista:
- kirjoittaa koodia sisäänrakennetuissa muokkausohjelmissa verkkokonsolin kautta,
- lataa arkisto koodilla,
- työskentele julkisten tai yksityisten git-tietovarastojen kanssa.
Tässä asetetaan tapahtumat, jotka kutsuvat funktiota. Tapahtumasarjat voivat vaihdella eri palveluntarjoajien välillä.
Palveluntarjoaja rakensi ja automatisoi Function as a Service (FaaS) -järjestelmän infrastruktuuriinsa:
- Toimintokoodi päätyy palveluntarjoajan puolelle.
- Kun tapahtuma tapahtuu, palvelimelle otetaan automaattisesti käyttöön säilöjä, joissa on valmis ympäristö. Jokaisella funktioinstanssilla on oma eristetty säilönsä.
- Tallennustilasta funktio lähetetään säiliöön, lasketaan ja palauttaa tuloksen.
- Rinnakkaisten tapahtumien määrä kasvaa - konttien määrä kasvaa. Järjestelmä skaalautuu automaattisesti. Jos käyttäjät eivät käytä toimintoa, se ei ole aktiivinen.
- Palveluntarjoaja asettaa säilöille lepotilan - jos toimintoja ei tänä aikana näy säilössä, se tuhoutuu.
Näin saamme Serverless pois laatikosta. Maksamme palvelusta pay-as-you-go -mallilla ja vain niistä toiminnoista, joita käytetään, ja vain siltä ajalta, jolloin niitä käytettiin.
Esitelläkseen kehittäjät palvelun tarjoajat tarjoavat jopa 12 kuukauden ilmaisen testauksen, mutta rajoittavat kokonaislaskenta-aikaa, pyyntöjen määrää kuukaudessa, varoja tai virrankulutusta.
Palveluntarjoajan kanssa työskentelyn tärkein etu on kyky olla huolehtimatta infrastruktuurista (palvelimet, virtuaalikoneet, kontit). Palveluntarjoaja voi puolestaan toteuttaa FaaS:n sekä omalla kehitystyöllään että avoimen lähdekoodin työkaluilla. Puhutaanpa niistä lisää.
Avoimen lähdekoodin puolelta
Avoimen lähdekoodin yhteisö on työskennellyt aktiivisesti palvelimettomien työkalujen parissa parin viime vuoden ajan. Suurimmat markkinatoimijat osallistuvat myös palvelimettomien alustojen kehittämiseen:
- Google tarjoaa kehittäjille avoimen lähdekoodin työkalunsa - . IBM, RedHat, Pivotal ja SAP osallistuivat sen kehittämiseen;
- IBM työskenteli palvelimettomalla alustalla , josta tuli sitten Apache Foundationin projekti;
- Microsoft avasi alustakoodin osittain .
Kehitystä on meneillään myös palvelimettomien puitteiden suuntaan. и käyttöön valmiiksi valmisteltujen Kubernetes-klustereiden sisällä, toimii sekä Kubernetesin että Docker Swarmin kanssa. Viitekehys toimii eräänlaisena ohjaimena - se valmistelee pyynnöstä ajonaikaisen ympäristön klusterin sisällä ja käynnistää sitten toiminnon siellä.
Kehykset jättävät tilaa työkalun määrittämiselle tarpeidesi mukaan. Joten Kubelessissa kehittäjä voi määrittää funktion suorittamisen aikakatkaisun (oletusarvo on 180 sekuntia). Fission, joka yrittää ratkaista kylmäkäynnistysongelman, ehdottaa joidenkin säiliöiden pitämistä käynnissä koko ajan (vaikka tämä aiheuttaa resurssien seisokkikustannuksia). Ja OpenFaaS tarjoaa joukon laukaisimia jokaiseen makuun ja väriin: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NAT ja muut.
Aloitusohjeet löytyvät viitekehysten virallisesta dokumentaatiosta. Niiden kanssa työskentely vaatii hieman enemmän taitoja kuin palveluntarjoajan kanssa työskentely - tämä on ainakin kyky käynnistää Kubernetes-klusteri CLI:n kautta. Sisällytä korkeintaan muita avoimen lähdekoodin työkaluja (esimerkiksi Kafka-jononhallinta).
Riippumatta siitä, kuinka työskentelemme Serverlessin kanssa - palveluntarjoajan kautta tai avoimen lähdekoodin avulla, saamme palvelimettoman lähestymistavan useita etuja ja haittoja.
Edut ja haitat näkökulmasta
Serverless kehittää ideoita konttiinfrastruktuurista ja mikropalvelulähestymistavasta, jossa tiimit voivat työskennellä monikielisessä tilassa olematta sidottu yhteen alustaan. Järjestelmän rakentaminen yksinkertaistuu ja virheet on helpompi korjata. Mikropalveluarkkitehtuuri mahdollistaa uusien toimintojen lisäämisen järjestelmään paljon nopeammin kuin monoliittisessa sovelluksessa.
Palvelimeton vähentää kehitysaikaa entisestään, jolloin kehittäjä voi keskittyä yksinomaan sovelluksen liiketoimintalogiikkaan ja koodaukseen. Tämän seurauksena kehitystyön markkinoilletuloaika lyhenee.
Bonuksena saamme automaattisen kuorman skaalauksen, ja maksamme vain käytetyistä resursseista ja vain silloin, kun niitä käytetään.
Kuten kaikilla tekniikoilla, Serverlessillä on haittoja.
Tällainen haitta voi olla esimerkiksi kylmäkäynnistysaika (keskimäärin jopa 1 sekunti kielillä, kuten JavaScript, Python, Go, Java, Ruby).
Toisaalta todellisuudessa kylmäkäynnistysaika riippuu monista muuttujista: kielestä, jolla funktio kirjoitetaan, kirjastojen määrästä, koodin määrästä, kommunikaatiosta lisäresurssien kanssa (samat tietokannat tai todennuspalvelimet). Koska kehittäjä hallitsee näitä muuttujia, hän voi lyhentää käynnistysaikaa. Mutta toisaalta, kehittäjä ei voi hallita säilön käynnistysaikaa - kaikki riippuu palveluntarjoajasta.
Kylmäkäynnistys voi muuttua lämpimäksi käynnistykseksi, kun toiminto käyttää uudelleen aikaisemman tapahtuman laukaisemaa konttia. Tämä tilanne syntyy kolmessa tapauksessa:
- jos asiakkaat käyttävät palvelua usein ja puhelujen määrä toimintoon kasvaa;
- jos palveluntarjoaja, alusta tai kehys sallii joidenkin säilöjen pitämisen käynnissä koko ajan;
- jos kehittäjä suorittaa toimintoja ajastimella (sanotaan 3 minuutin välein).
Useissa sovelluksissa kylmäkäynnistys ei ole ongelma. Tässä sinun on rakennettava palvelun tyyppi ja tehtävät. Sekuntien käynnistysviive ei ole aina kriittinen yrityssovellukselle, mutta siitä voi tulla kriittinen lääketieteellisille palveluille. Tässä tapauksessa palvelimeton lähestymistapa ei todennäköisesti enää sovellu.
Seuraava Serverlessin haittapuoli on toiminnon lyhyt käyttöikä (aikakatkaisu, jonka aikana toiminto on suoritettava).
Mutta jos sinun on työskenneltävä pitkäikäisten tehtävien kanssa, voit käyttää hybridiarkkitehtuuria - yhdistä Serverless toiseen tekniikkaan.
Kaikki järjestelmät eivät pysty toimimaan palvelimettoman järjestelmän avulla.
Jotkut sovellukset tallentavat edelleen dataa ja tilaa suorituksen aikana. Jotkut arkkitehtuurit säilyvät monoliittisina ja jotkut ominaisuudet ovat pitkäikäisiä. Kuitenkin (kuten pilviteknologiat ja sitten kontit) Serverless on teknologia, jolla on suuri tulevaisuus.
Tässä mielessä haluaisin siirtyä sujuvasti palvelimettoman lähestymistavan käyttöön.
Sovelluksen puolelta
Vuonna 2018 palvelimettoman käytön prosenttiosuus . Teknologian palveluihinsa jo ottaneiden yritysten joukossa ovat markkinajätit kuten Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Samanaikaisesti sinun on ymmärrettävä, että Serverless ei ole ihmelääke, vaan työkalu tiettyjen ongelmien ratkaisemiseen:
- Vähennä resurssien käyttökatkoksia. Ei ole tarvetta pitää jatkuvasti virtuaalikonetta palveluille, joilla on vähän puheluita.
- Käsittele tietoja lennossa. Pakkaa kuvia, leikkaa taustoja, muuta videon koodausta, työskentele IoT-anturien kanssa, suorita matemaattisia operaatioita.
- "Liimaa" muut palvelut yhteen. Git arkisto sisäisillä ohjelmilla, chat-botti Slackissa Jiran kanssa ja kalenteri.
- Tasapainota kuormitusta. Katsotaanpa tätä tarkemmin.
Oletetaan, että on palvelu, joka houkuttelee 50 ihmistä. Sen alla on virtuaalikone, jossa on heikko laitteisto. Ajoittain palvelun kuormitus kasvaa merkittävästi. Silloin heikko laitteisto ei kestä.
Voit sisällyttää järjestelmään tasapainottimen, joka jakaa kuorman esimerkiksi kolmelle virtuaalikoneelle. Tässä vaiheessa emme voi tarkasti ennustaa kuormitusta, joten pidämme tietyn määrän resursseja käynnissä "varassa". Ja me maksamme liikaa seisokeista.
Tällaisessa tilanteessa voimme optimoida järjestelmän hybridilähestymistavan avulla: jätämme yhden virtuaalikoneen kuormituksen tasaajan taakse ja laitamme linkin palvelimettomaan päätepisteeseen funktioineen. Jos kuormitus ylittää kynnyksen, tasapainotin käynnistää toimintoesiintymiä, jotka ottavat haltuunsa osan pyynnön käsittelystä.
Siten palvelintonta voidaan käyttää silloin, kun on tarpeen käsitellä suuri määrä pyyntöjä ei liian usein, mutta intensiivisesti. Tässä tapauksessa useiden toimintojen ajaminen 15 minuutin ajan on kannattavampaa kuin virtuaalikoneen tai palvelimen jatkuva ylläpito.
Kaikilla palvelimettoman laskennan eduilla, sinun tulee ennen käyttöönottoa arvioida sovelluslogiikka ja ymmärtää, mitä ongelmia Serverless voi ratkaista tietyssä tapauksessa.
Palvelimeton ja Selectel
Olemme jo Selectelissä ohjauspaneelimme kautta. Nyt rakennamme omaa FaaS-alustaa. Haluamme kehittäjien pystyvän ratkaisemaan ongelmansa käyttämällä Serverlessiä kätevän ja joustavan käyttöliittymän kautta.
Jos sinulla on ideoita siitä, millainen ihanteellinen FaaS-alusta pitäisi olla ja miten haluat käyttää Serverlessia projekteissasi, jaa ne kommenteissa. Otamme toiveesi huomioon alustaa kehitettäessä.
Artikkelissa käytetyt materiaalit:
Lähde: will.com