Serverless ei tarkoita yhtä suurta Lambda-funktiota

Serverless-arkkitehtuurissa pilvipalveluntarjoaja vastaa palvelinten käyttöjärjestelmistä, kapasiteetin perusskaalauksesta ja suuren osan saatavuusrakenteesta. Sovellus rakennetaan pienistä laskenta-, tallennus-, viesti- ja tunnistuspalveluista, joiden käyttöä voidaan hinnoitella toteutuneen kulutuksen mukaan. AWS:llä kokonaisuus voi sisältää esimerkiksi Lambdan, DynamoDB:n, S3:n, Cogniton, API Gatewayn ja tapahtumapalveluita.

Tämä ei poista operointia. Lokit, hälytykset, käyttöoikeudet, varmistukset, kustannusrajat ja virhetilanteet pitää edelleen suunnitella. Hyvin tehtynä vastuu siirtyy palvelinten paikkaamisesta ja kapasiteetin varaamisesta järjestelmän toiminnan valvontaan. Huonosti tehtynä tuloksena on vaikeasti hahmotettava joukko palveluita ilman yhteistä rakennetta.

Poggers Oy:n omissa Kierto Commerce- ja Vainuri-tuotteissa serverless-malli yhdistää Lambda-taustapalvelut hallittuihin AWS-palveluihin. Valinta sopii niihin, koska käyttö vaihtelee, tuotteet tarvitsevat monta valmista pilvitoimintoa ja ympäristön pitää skaalautua ilman erillistä palvelintiimiä.

Aloita kuorman muodosta, älä kuukausihinnan arvauksesta

Ensimmäinen kysymys ei ole käyttäjämäärä vaan kuorman muoto. Kymmenentuhatta pyyntöä yhden kampanjapäivän aikana on eri ongelma kuin sama määrä tasaisesti kuukaudessa. Lambda-funktioissa laskutus perustuu pyyntöihin ja suoritusaikaan. Fargate-kontissa laskenta perustuu varattuun prosessoriin, muistiin ja tehtävän käyntiaikaan. Jatkuvasti käyvän palvelun kustannus alkaa siis jo ennen ensimmäistä käyttäjäpyyntöä, kun taas tapahtumapohjainen laskenta seuraa käyttöä tarkemmin.

Pelkkä laskentahinta ei ratkaise. Arvioon kuuluvat myös tietokanta, lokien määrä, datansiirto, verkon kiinteät osat, varmistukset, valvonta ja ihmisen käyttämä ylläpitoaika. Halpa funktio ei tee kokonaisuudesta halpaa, jos jokainen pyyntö kirjoittaa tarpeettomasti suuren lokin tai arkkitehtuuri tarvitsee kalliita jatkuvasti käyviä tukipalveluita.

Tee vertailu vähintään kolmella tilanteella: normaali kuukausi, lähes käyttämätön kuukausi ja odotettu ruuhkahuippu. Lisää kustannukseen myös häiriöiden selvitys ja muutosten julkaisu. Vasta sen jälkeen vaihtoehdot ovat vertailukelpoisia.

Milloin serverless on vahva lähtökohta?

Serverless on usein perusteltu oletus uudelle web-tuotteelle, API:lle, sisäiselle työkalulle tai automaatiolle, kun käyttö on vielä epävarmaa. Pieni tiimi saa valmiina esimerkiksi skaalautuvan laskennan, tiedostojen tallennuksen, viestijonot ja tunnistautumisen eikä joudu rakentamaan ympärivuorokautista palvelinten ylläpitomallia ensimmäistä asiakasta varten.

  • Kuorma vaihtelee paljon tai palvelulla on pitkiä hiljaisia jaksoja.
  • Työ käynnistyy HTTP-pyynnöstä, ajastuksesta, jonosta, tiedostosta tai muusta selkeästä tapahtumasta.
  • Yksittäinen työ voidaan rajata lyhyeksi ja tila tallentaa kestävään tietokantaan tai tallennuspalveluun.
  • Nopea julkaiseminen ja pieni operointitaakka ovat tärkeämpiä kuin täydellinen ajoympäristön hallinta.
  • Järjestelmän pitää kestää hetkellinen kuormapiikki ilman etukäteen varattua huippukapasiteettia.

Milloin jatkuvasti käyvä palvelu on selkeämpi?

Kontti tai virtuaalipalvelin on usein luontevampi, kun sovellus tekee tasaista työtä ympäri vuorokauden ja käytettävä kapasiteetti voidaan ennustaa. Sama koskee prosessia, jonka pitää pitää pitkä yhteys auki, ylläpitää muistissa suurta tilaa, käyttää erityisiä järjestelmäkirjastoja tai hallita omaa prosessiaan tarkasti.

Tavallisen Lambda-funktion yksittäinen suoritus voi kestää enintään 15 minuuttia. Pitkä liiketoimintaprosessi voidaan pilkkoa tapahtumiksi tai orkestroida tilakoneella, mutta kaikkea ei kannata väkisin muuttaa tällaiseksi. Jos tehtävä on aidosti yksi tuntikausia käyvä laskenta tai valmis sovellus toimii jo hyvin Docker-kontissa, jatkuva tai työkohtaisesti käynnistyvä kontti voi olla helpompi ymmärtää ja testata.

  • Kuorma on jatkuvasti korkea ja tasainen.
  • Prosessi kestää pitkään tai tarvitsee pysyvän yhteyden asiakkaaseen tai ulkoiseen järjestelmään.
  • Sovellus tarvitsee erityisen käyttöjärjestelmän, laitteistokiihdytyksen tai tarkan prosessitason hallinnan.
  • Valmis konttisovellus pitäisi kirjoittaa merkittävästi uusiksi vain serverless-mallia varten.
  • Tiimillä on jo toimiva konttiympäristö, valvonta ja kapasiteetin hallinta.

Kylmäkäynnistys, tietokanta ja tapahtumien toistuminen

Kylmäkäynnistys ei ole automaattinen syy hylätä serverless. Sen merkitys riippuu sallitusta vasteajasta, ohjelmointikielestä, paketin koosta, alustuksesta ja siitä, kuinka usein funktiota käytetään. Tavallisen hallintanäkymän taustapyyntö ja reaaliaikaisen ohjauksen kriittinen polku tarvitsevat eri ratkaisun. Provisioned Concurrency voi pienentää viivettä, mutta samalla osa kapasiteetista muuttuu jatkuvasti maksettavaksi.

Perinteinen SQL-tietokanta tarvitsee yhteyksien hallintaa, koska nopeasti kasvava funktioiden rinnakkaisuus voi avata enemmän yhteyksiä kuin tietokanta kestää. Ratkaisu voi olla yhteyspooli, välityspalvelu, rinnakkaisuuden rajoitus tai kuormaan paremmin sopiva tietomalli. Tietokantaa ei pidä valita vain siksi, että se kuuluu samaan arkkitehtuurimuotiin.

Tapahtumapohjainen järjestelmä pitää suunnitella virheille ja uudelleenyrityksille. Sama viesti voidaan käsitellä useammin kuin kerran, joten maksun, tilauksen tai muun muutoksen on oltava idempotentti: toisto ei saa tehdä samaa liiketoimintavaikutusta kahdesti. Jonot, virhejonot ja hälytykset ovat osa tuotetta, eivät myöhemmin lisättävä ylläpitolisä.

Hybridi on usein käytännöllisin arkkitehtuuri

Valintaa ei tarvitse tehdä koko järjestelmälle yhdellä kertaa. Staattinen käyttöliittymä voi tulla CDN:n kautta, tavalliset API-pyynnöt ja tapahtumat voidaan käsitellä funktioilla, pitkä taustatyö ajaa kontissa ja liiketoimintadata säilyttää hallitussa SQL-tietokannassa. Palveluiden rajat kannattaa piirtää työkuormien eikä organisaatiokaavion perusteella.

Hybridi toimii vain, jos sillä vähennetään monimutkaisuutta. Jos pieneen tuotteeseen tuodaan funktiot, kontit, Kubernetes, kaksi tietokantaa ja kolme viestipalvelua varmuuden vuoksi, operointitaakka kasvaa ilman käyttäjälle näkyvää hyötyä. Pienin riittävä kokonaisuus on yleensä paras ensimmäinen versio.

Seitsemän kysymyksen päätöstesti

Kirjaa vastaukset ennen palveluiden valintaa. Jos vastauksia ei tiedetä, tee pieni kuormitettava kokeilu tärkeimmästä epävarmuudesta sen sijaan, että lukitset koko arkkitehtuurin oletukseen.

  • Onko kuorma tasainen, piikikäs, kausittainen vai vielä täysin tuntematon?
  • Kuinka kauan yksi työ kestää ja voiko sen jakaa turvallisesti vaiheisiin?
  • Mikä on hyväksyttävä vasteaika tavallisessa tilanteessa ja kylmän käynnistyksen jälkeen?
  • Mihin pysyvä tila tallennetaan ja montako yhtäaikaista yhteyttä se kestää?
  • Mitä tiimi osaa ja haluaa operoida myös kahden vuoden kuluttua?
  • Miten normaali käyttö, hiljainen kuukausi ja ruuhkahuippu vaikuttavat kokonaiskustannukseen?
  • Voidaanko työkuorma myöhemmin siirtää tai vaihtaa ilman koko tuotteen uudelleenkirjoitusta?

Näin päätös kannattaa varmistaa ennen rakentamista

Valitse ensin yksi tärkeä käyttäjäpolku ja yksi raskas taustatyö. Arvioi kummallekin normaali ja suurin rinnakkaisuus, suoritusaika, muistitarve, datan määrä ja ulkoiset riippuvuudet. Tee kustannusarvio oikealle AWS-alueelle ja lisää mukaan kaikki tukipalvelut. Testaa epävarmin kohta tuotantoa muistuttavalla kuormalla.

Kirjaa päätökseen myös vaihtoraja. Esimerkiksi jatkuvasti kasvava tasainen kuorma, muuttunut vasteaikavaatimus tai uusi pitkäkestoinen prosessi voi olla sovittu syy siirtää yksi työkuorma konttiin. Hyvä arkkitehtuuri ei ennusta täydellisesti tulevaisuutta, vaan tekee seuraavasta muutoksesta hallittavan.

Aiheeseen liittyvät toteutukset ja palvelut

Usein kysytyt kysymykset

Onko serverless aina palvelinta halvempi?

Ei. Serverless on usein edullinen pienelle tai vaihtelevalle kuormalle, koska tyhjästä kapasiteetista ei makseta samalla tavalla. Jatkuvasti korkealla kuormalla kontti tai varattu kapasiteetti voi olla edullisempi. Vertaa koko järjestelmää ja ylläpitotyötä, älä vain laskentapalvelun listahintaa.

Sopiiko AWS Lambda tavallisen web-sovelluksen taustalle?

Usein sopii. Lyhyet HTTP-pyynnöt, integraatiot ja tapahtumankäsittely ovat luontevia käyttökohteita. Erityistä huomiota tarvitsevat vasteaika, rinnakkaisuus, tietokantayhteydet ja ulkoisten palveluiden virhetilanteet.

Pitääkö valmis Docker-sovellus kirjoittaa uusiksi serverlessiksi?

Ei yleensä. Jos sovellus toimii ja sen operointi on hallinnassa, uudelleenkirjoitus tarvitsee selkeän liiketoimintahyödyn. Kontti voidaan ajaa hallitussa palvelussa ja vain aidosti tapahtumapohjaiset osat erottaa funktioiksi.

Voiko serverless-ratkaisu käyttää SQL-tietokantaa?

Voi. Yhteyksien määrä ja rinnakkaisuus pitää kuitenkin suunnitella. Kuormasta riippuen tarvitaan yhteyspooli, RDS Proxy, rinnakkaisuuden rajoitus tai serverless-käyttöön paremmin sopiva tietokantaratkaisu.

Lähteet ja lisälukeminen