Serverless Days Helsinki 2019

Allekirjoittanut tapahtumapaikalla

Yleistä Serverlessistä

Eilen Helsingissä järjestettiin ensimmäinen Serverless Days -tapahtuma jonne itsekin menin kuuntelemaan ja katselemaan minkälaisesta tapahtumasta on kyse.

Koska kyseessä oli omaan alaani (eli aateekoo ja intternet) liittyvä tapahtuma on mahdollista että termi Serverless ei soita monelle tämän blogin lukijalle kelloja mistä on kyse. Lyhyesti ilmaisten termillä siis viitataan verkkopalveluiden tuottamiseen siten että itse tai muut välikädet eivät joudu hoitamaan palvelinten ylläpitoa vaan varsinainen palvelimen olemassaolokin pyritään poistamaan kuvioista ja sovelluksia ajetaan suoraan pilvipalveluissa siten että tarpeen mukaan pilvipalvelun tuottaja (esim. AWS, Azure tai Google Cloud) hoitaa koodareille näkymättömästi tämänkaltaiset prosessit.

Edellinen kappale ei varmasti sytyttänyt idean lamppua päässä palamaan epäselvän ilmaisunsa vuoksi, mutta otetaan esimerkki josko se selventäisi yhtään sen enempää.

Kun normaalisti vaikkapa jonkin verkkokaupan käyttäjä tulee nettisivulle ja saa näkyviin myynnissä olevat tuotteet on tämä perinteisesti hoidettu siten, että taustalla on koko ajan käynnissä palvelin josta nettisivun “frontend” (eli se käyttäjälle näkyvä osa) pyytää listaa tuotteista. Tällöin frontend lähettää kyselyn taustalla pyörivälle ns. backendille joka pyörii jossain palvelimella (joka karkeasti yleistäen ja tiivistäen ihmisten ymmärrettävästi on vain jokin tietokone jossain) ja se sitten saatuaan pyynnön etsii tietokannasta että mitäs tuotteita tuohon kategoriaan käyttäjälle pitäisi näyttää. Sen jälkeen se lähettää frontendille vastauksena listan näytettävistä tuotteista jonka jälkeen sitten frontend osaa tehdä käyttäjälle näkyviin oikeanlaiset tuotteet.

Serverless-ajattelun ideana on saada poistettua tuo “backend” nykyisessä muodossaan kuvioista pois kokonaan että ei olisi olemassa enää perinteistä palvelinta jossain pyörimässä turhaan. Käytännön tasolla tämä tapahtuu ns. event driven -ajattelumallilla toteuttamalla. Eli äskeisessä esimerkissä se tarkoittaisi sitä, että vasta siinä vaiheessa kun frontend lähettää pyynnön backendille pitäisi joku saada sinne vastaamaankin jotain jotta pyynnön esittäjä saa haluamansa tulokset että tietää mitä sivulle pitää näyttää.

Isot pilvipalvelut – ainakin AWS sekä Azure – tarjoavat tähän ns. Lambda-funktioita joita triggeröidään vasta kun jotakin tapahtuu. Eli koko aikaa ei ole palvelin taustalla pyörimässä turhan päiten, vaan vasta siinä vaiheessa kun käyttäjältä tulee pyyntö saada lista noista verkkokaupan tuotteista herättää nämä pilvipalvelut koodareiden tekemät funktiot jotka tekevät halutut asiat.

Jos tämän miettisi reaalimaailman asiana vastaisi se samaa kuin talossa ei olisi lainkaan puhelinasiakaspalvelua, mutta heti kun puhelin soi olisi maagisesti oikeita ihmisiä heti vastaamassa puhelimeen ja kun puhelu on ohi katoaisi hän samantien eikä olisi koko aikaa paikan päällä päivystämässä josko sinne sattuisi puhelu tulemaan.

Tapahtuma

Varsinainen tapahtumapäivä oli mielenkiintoinen ja puhujia oli useita erilaisia. Ensimmäisenä puheena kuulimme Lego-kaupan uudelleen toteuttamisesta serverless-arkkitehtuuria hyödyntäen. Seuraavana puheena kuulimme chaos engineeringistä ja kuinka toteuttaa tällaisia serverless -arkkitehtuurilla tehdyissä sovelluksissa. Seuraava puhe käsitteli erilaisten palveluiden integraatioista ja kuinka tämänkaltaisia haasteita on taklattu serverless-sovelluksilla ja ennen lounasta kuulimme vielä puheen kuinka Google Cloud -palvelun koneoppimisen rajapintoja hyödyntäen voi tehdä erilaisia tutkimuksia esimerkiksi fake news -sivustoista verrattuna ns. vakavammin otettaviin uutissivuihin.

Lounaan jälkeen sitten oli puheita virheenkäsittelystä, suunnittelun patterneista ja anti-pattereista sekä todellisen elämän esimerkki kuinka chatbot oli toteutettu Azuren funktioilla.

Kahvitauon jälkeen puheina kuultiin SLA:sta ja kuinka sen mittaaminen serverless-aikakaudella on sinänsä hankalaa ja merkityksetöntä, seuraava puhe kertoi kuinka finanssiraporttejen käsittelyä oli toteutettu AWS:n lambdoissa ja viimeisenä puheena vielä kuulimme CI/CD aiheesta kuinka serverlessillä voi toteuttaa esimerkiksi erilaisia deploymettejä turvallisesti.

Lopussa vielä oli paneelikeskustelu jossa käsiteltiin mm. kannattaako serverless-maailmaan hypätä ja luoda sitä kautta vendor-lockia ja muita yleisiä kiintoisia aiheita.

Kokonaisuutena päivä oli varsin mielekiintoinen ja oli mukava päästä käymään. Toivon mukaan näitä tapahtumia tulisi useamminkin myös Helsinkiin ja toivottavasti myös serverlessiä pääseemme pian toteuttamaan laajamittaisemminkin. Uskon että suurimmat haasteet tällä hetkellä sen yleistymiselle on business-näkökulmat (totuttu vanhoihin toimiviin tapoihin) sekä tietenkin tekniset aspektit joka aiheuttaa oman mielentilan muutosta ohjelmoinnissa ja ilmenevien ongelmien ratkaisuissa.

AWS-koulutusta

Alkuviikko meni vaihteen vuoksi kouluttautumisen merkeissä kun olin maanantaista keskiviikkoon AWS-koulutuksessa. Mikäli AWS ei ole entuudestaan tuttu on kyseessä siis Amazonin pilvipalvelualusta jonka päällä moni internetissä pyörivistä suurista ja pienistäkin verkkopalveluista toimii.

Aiheina koulutuksessa oli mm. vikasietoisten ja tehokkaiden verkkoinfrastruktuurien rakentamista AWS:ään, Serverless arkkitehtuuri sekä tietoturva ja työkalut joita AWS tarjoaa tämänkaltaisten haasteiden ratkaisuun. Lisäksi myös oli puhetta kuinka infrastruktuuria rakennetaan koodilla ja sen eduista.

Koulutus oli mielenkiintoinen ja toki moni asia oli entuudestaan jo tuttua käytännön tasolta, mutta mielenkiintoista oli silti päästä käymään koulutuksessa ja saada kertausta sekä uuttakin tietoa. AWS:n ja muiden pilvipalvelualustoiden kehitys on todella nopeaa ja uusia palveluita niihin tulee kovalla tahdilla lisää joten jatkuva oman osaamisen kehittämisen tarve IT-alalla ei luultavasti tule jatkossakaan osoittamaan vähenemisen merkkejä.

Sivuston nopeuden optimointia

Viime viikolla aloitin hieman optimoimaan tämän blogin nopeutta havaittuani muutamia todella helposti toteutettavissa olevia optimointeja.

Muutoksen myötä sivuston uudempien postauksien pitäisi latautua nyt nopeammin, erityisesti niillä käyttäjillä jotka ovat hitaamman nettiyhteyden päässä. Vanhempia postauksia en ole käynyt läpi ja optimoinut niitä, mutta viime keskiviikon jälkeen julkaistuiden postauksien sekä tietenkin kaikkien jatkossa julkaistavien postauksien pitäisi ladata nopeammin merkittävästi pienennettyjen kuvien myötä.

Koetin kuvien pienentämisen lisäksi W3 Total Cache -lisäosaa mutta tällä sivulla nykyisillä kävijämäärillä ei hyötyä tullut lainkaan joten otin lisäosan pois käytöstä samantien. Pitänee jossain vaiheessa koettaa keksiä myös muita optimointeja kunhan aikaa on.

Sivusto siirretty uudelle palvelimelle

PHP-GD:n asennus Lissie-palvelimelle

Kuten aiemmin tästä blogista pystyi lukemaan, oli sivustolla hieman teknisiä ongelmia tietokannan leipoessa kiinni ja myöhemmin levytilan suhteen. Koska kuitenkin arvostan että asiat toimisivat mahdollisimman hyvin ilman tarpeetonta säätämistä, tein vielä tuona samana iltana tilauksen OVH-hostingille uuden virtuaalipalvelimen osalta.

Viime viikon maanantaina yöllä tuli jo laitettua palvelimelle tarvittavat softat, eli Apache, MariaDB ja PHP. Samoin kävin vaihtamassa Joker.comissa DNS-tiedot viittaamaan uudelle serverille. Seuraavana aamuna asentelin vielä PHP-GD:n jotta kuvien resizetys blogiin toimii.

Katselin hintoja hieman muuallakin, mutta ainoat vaihtoehdot joita jaksoin edes miettiä vaihtoehtona OVH-Hostingille olivat Digital Ocean ja WP-Palvelu.

Digital Oceanista on kokemusta monen vuoden ajalta – esim. Runosydan.net on siellä pyörinyt vuosia, mutta heidän tuoteperheessä ei ollut nykyiseen tarpeeseeni sopivaa palvelinta oikeassa hintasegementissä. 10 USD maksavassa virtuaalipalvelimessa olisi ollut vain 1 GB muistia, joten en halunnut lähteä sitä koettamaan. Palvelin jossa olisi ollut 2 GB muistia olisi maksanutkin jo 20 USD, joten se meni omiin tarpeisiin tarpeettoman kalliiksi.

WP-Palvelu taas vastaavasti tarjoaa erilaisen palvelun kokonaan. Mietin sitäkin vaihtoehtona, koska kuitenkin kyseessä suomalainen lafka ja kiinnostaisi ammatillisessa mielessä koettaa käyttää joskus kyseistä palvelua, jotta tietäisi voinko suositella sitä muille vaiko en. Omaan korvaan palvelusta on kuulunut vain hyvää, joten luultavasti ainakin kehottaisin vähemmän nörttejä koettamaan kyseistä palvelua mikäli WordPress-sivuston haluaa pystyyn eikä ole nörttejä lähipiirissä kuka jaksaa tunkata asioita toimimaan.

Vaikka hinta ei ole paha heilläkään (18 e/kk pienimmässä paketissaan), oli se omaan tarpeeseen liian kallis. Jos pyörittäisin tärkeämpää webbsivua jossa kävijöitä on paljon ja toimivuus on tärkeämpää niin hyvin voisin maksaa sen hinnan. Kuitenkin tämä blogi on vain harrastus ja olen sen verran nörtti että osaan itse ylläpitää palvelimia, joten hyvä on sinänsä ylläpitää omaa ammatillista osaamista vapaa-ajallaankin. Toisaalta palvelmia ei tarvitse jatkuvalla syötöllä säätää, helposti satoja päiviä ja enemmänkin menee ilman mitään tarvetta säätää mitään sen jälkeen kun kerran on laittanut tarvittavat perusasiat kuntoon.

OVH-hostingilta lopulta otin tämänkin palvelimen, sillä aiemminkin aleksinblogi.net on pyörinyt siellä, samoin siellä on pyörinyt irkkiclienttini jo viime talvesta saakka ja uptimet serverillä on yli 240 päivää. Käytännössä palvelu on ollut vakaa. Myös hinta palvelussa on hyvä – tämä serveri maksaa 9,90 eur/kk, eli ei ole palvelinta hinnalla pilattu. Ostin tälle blogille VPS Cloud 1 -palvelimen joka vaikuttaa ainakin hyvältä paperilla, eiköhän myös käytännössä.

Koska jokaisella palvelimella kannattaa olla itselle helposti muistettava nimi, tuli tällä kertaa nimeksi Lissie, eli tämäkin palvelin on nimetty naislaulajan mukaan. Aikaisemmat palvelimet ovat Elize joka on nimetty Amaranthen laulajan Elize Rydin mukaan, sekä Simone joka on nimetty Epican laulajan Simone Simonsin mukaan.

Loppuun vielä artistin Lissie biisi Further Away (Romance Police).

Tietokanta leipoi kiinni

MySQL leipoi kiinni ja swapin lisäämisen jälkeen levytila loppui serveriltä. Hieno juttu, Hermannit.

Jos satuitte käymään blogissani maanantaina ilta-aikaan, saatoitte havaita tyhjän valkoisen sivun ja mustan tekstin Error establishing a database connect normaalin blogin etusivun sijaan. Logeista päätellen ongelma ilmaantui siinä noin kolmen maissa, mutta huomasin itse ongelman vasta hieman ennen kahdeksaa.

Tietokantana palvelimella on käytössä MySQL ja sen virhelogeissa olevat virheet auttoivat paikantamaan ongelman muistin käyttöön. Katsoin serverin muistinkäyttöä ja havaitsin että swappiä ei ollut serverille tullut konffattua lainkaan. Toki tein sitten tähän swappitiedoston dd:llä jonka jälkeen mkswapilla & swaponilla sen otin käyttöön. Tämän jälkeen koetin käynnistellä mysql:n serviceä uudemman kerran, mutta edelleen huonolla menestyksellä.

Tarkemmin kun ongelmaa rupesin selvittämään, huomasin että äsken generoimani swappitiedosto oli niin suuri että se sai serverin levytilan loppumaan kesken. Facepalm. Eipä siinä sitten muu auttanut kuin generoida swappitiedosto uudemman kerran pienemmällä koolla.

Kun swappi oli generoitu pienemmäksi ja otettu käyttöön, myös MySQL lähti nätisti takaisin tulille.

Täytynee jatkoa varten katsella josko jostain löytyisi järkevän hintaista virtuaalipalvelinta jossa on merkittävästi enemmän levytilaa kuin nykyisessä. Mahdollisesti voisin tutkailla josko siirtäisin blogini johonkin WordPress-sivustoja hostaaviin palveluihin niin ei tarvitsisi itse ruveta tunkkaamaan tällaisia vapaa-ajallaan. Onneksi näiden tunkkaaminen ei ole vaikeaa, mutta aina ei tule istuttua koneen äärellä, joten on tympäisevää mikäli blogipostausta on tulossa kirjoittamaan ja ensimmäisenä pääsee tunkkaamaan palvelimella swappejä ja muuta. Saa nähdä mihin ratkaisuun päädyn, mutta ainakin jotain asialle täytyy tehdä ennen kuin ongelma ilmenee uudelleen.