Katsaus Oikotie-palvelun tekniseen toteutukseen
Noin kaksi vuotta sitten Codemate ja Idean aloittivat Sanoma Digital Finlandin kanssa kehitysprojektin, jossa alkuperäiset Oikotie-palvelut yhdistettiin yhtenäiseksi kokonaisuudeksi. Oikotie-ekosysteemi koostuu useista kuluttajille suunnatuista palvelukokonaisuuksista eli vertikaaleista, kuten
- Oikotie Asunnot (kiinteistöjen osto, myynti ja vuokraus)
- Oikotie Työpaikat (työilmoitukset)
- Huuto.net (verkkohuutokauppa)
- Autotie (autojen osto ja myynti)
Oikotie-palvelussa vierailee viikoittain yli miljoona käyttäjää. Finnish Internet Audience Measurementin (FIAMin) mukaan Oikotie on Suomen suosituimpia verkkopalveluita, ja sen kuukausittainen kävijämäärä on noin kaksi miljoonaa.
Kehitysprojektin tavoitteena oli tarjota käyttäjille yksilöllinen ja kaikki Oikotie-vertikaalit yhdistävä näkymä yhdessä sovelluksessa. UX- ja UI-suunnittelusta vastasi Idean, ja Codematen tehtävänä oli järjestelmän tekninen suunnittelu ja toteutus.
Henkilökohtaisesta näkökulmasta projekti tarjosi loistavan mahdollisuuden päästä toimimaan laajamittaisen projektin vastaavana ohjelmistokehittäjänä. Tässä blogijulkaisussa kerron projektin osakokonaisuuksien taustoista sekä uuden palvelun perustana toimivasta teknisestä ratkaisusta ja ohjelmistoarkkitehtuurista.
Kokonaisuuden rakentaminen…
Vertikaaleja yhdistävän palvelun toteuttaminen vaati uuden palvelun liittämistä osaksi alkuperäisten Oikotie-tuotteiden ekosysteemiä. Olemassa olevat Oikotie-palvelut toimivat itsenäisinä kokonaisuuksinaan omissa Oikotie-palveluissaan, ja niiden dataa säilytetään ja hallitaan vertikaalien omissa järjestelmissä, joista uusi palvelu voi hakea dataa vertikaalikohtaisten ohjelmointirajapintojen (API) kautta.
Järjestelmän toteutukseen liittyi lukuisia teknisiä haasteita. Alkuperäisten palveluiden itsenäisen luonteen takia integraatio jokaiseen vertikaaliin oli toteutettava erikseen. Uuden palvelun tehtävänä on näitä integraatioita hyödyntäen etsiä eri vertikaaleista käyttäjälle olennaista ja kiinnostavaa sisältöä. Vaikka sisältö kerätään useista eri lähteistä, on palvelun kyettävä tarjoamaan käyttäjäkokemus yhdestä yhtenäisestä Oikotie-palvelusta. Tätä varten kaikki sisältö on muunnettava yhtenäiseen muotoon ennen sen esittämistä käyttäjälle. Lisäksi palvelussa on suhteellisen paljon mediasisältöä, joten palvelun on kyettävä tehokkaasti hyödyntämään erilaisia välimuistiratkaisuja sekä sisällönjakeluverkkoja (CDN) osana teknistä toteutusta.
Lukuisista integraatioista ja niihin liittyvästä suuresta työmäärästä johtuen teknisessä ratkaisussa pyrittiin löytämään keinoja, joilla toteutusta voitiin yksinkertaistaa ja integraatioihin liittyvää työmäärää pienentää. Tätä varten vertikaalien ohjelmointirajapintojen päällä käytettiin erillistä abstraktiokerrosta, joka tarjosi yhtenäisen tavan yhdistää ja autentikoitua yksittäisiin vertikaaleihin. Ratkaisu yksinkertaisti ja yhtenäisti integraatioprosessia huomattavasti.
Kuva 1: Uudessa Oikotie-palvelussa näytetään sisältöä eri vertikaaleista. Käyttäjälle personoidulla etusivulla voi näkyä esimerkiksi nostettuja blogijulkaisuja, asuntoilmoituksia Asunnot-vertikaalista sekä työpaikkailmoituksia Työpaikat-vertikaalista.
…ja purkaminen osiin
Kun palvelun kuukausittainen kävijämäärä on kahden miljoonan luokkaa, tarvitaan käyttäjämäärän mukaan skaalautuva järjestelmä. Järjestelmän toteutuksessa noudatettiin yleisesti käytettyä microservice-arkkitehtuuria, jossa järjestelmä jaetaan yksittäisiin, itsenäisesti toimiviin palveluihin. Kutakin palvelua ajetaan omassa Docker-kontissaan, joten palvelut skaalautuvat erikseen. Sovelluksen ydintoiminnoista vastaa erillinen palvelu, ja kullekin tehtävälle, kuten push-ilmoitusten toimittamiselle sekä tulevien tapahtumien ja ilmoitusten käsittelylle, on oma mikropalvelunsa.
Palvelu toteutettiin Amazon Web Services -pilvialustan (AWS) päälle. Konttien orkestrointityökaluna käytettiin Elastic Container Service -ratkaisua (ECS).
Teknisestä näkökulmasta ajateltuna microservice-arkkitehtuurissa komponentit irrotetaan toisistaan, jolloin kukin komponenteista voidaan toteuttaa parhaiten tarkoitukseen soveltuvalla teknologialla. Järjestelmäkehitykseen vaikuttavat kuitenkin myös muut kuin tekniset vaatimukset. Palvelun luovuttaminen asiakkaalle sekä sen ylläpito aktiivisen kehitysjakson päätyttyä haluttiin tehdä mahdollisimman vaivattomaksi, joten uusi palvelu haluttiin toteuttaa mahdollisimman pitkälle alkuperäisissä vertikaaleissa käytössä olevia teknologioita hyödyntäen.
Muiden monimutkaisten järjestelmien tapaan myös uusi Oikotie-palvelu koostuu lopulta pienistä, yksinkertaisista ja varsin tutuista osakokonaisuuksista. Pinnan alta paljastuvat tavanomainen LAMP stack sekä integrointiin sopivat sovelluskehykset ja tarvittavat SDK:t. Palvelun koodikannan ymmärtäminen tai muokkaaminen ei vaadi vuosien kokemusta. Oikotien kaltaisissa valtavissa järjestelmissä on aina tilaa eritasoisille kehittäjille.
Mutta skaalautuuko palvelu?
AWS:n parhaiden käytäntöjen (AWS Best Practices) mukaisesti arkkitehtuurin suunnittelun perusperiaatteiksi valittiin skaalautuvuus ja korkean tason saavutettavuus (high availability). Sovellustasolla skaalautuvuus mahdollistettiin tekemällä kaikista API-kutsuista tilattomia, irrottamalla dataa tuottavat ja käyttävät komponentit toisistaan hyödyntäen ulkoisia viestijonoja (message queue), säilyttämällä käyttäjäistuntoja jaetussa in-memory -tietokannassa ja käyttämällä pysyvänä tallennusratkaisuna (persistent storage) jaettua relaatiotietokantaa. Tietokantapalveluna käytettiin AWS Relational Database Serviceä (RDS), joka tukee Multi-AZ deployment:ia ja vain luku -replikaatiota (read replicas). Vastaavasti in memory -tietokantana käytettiin Amazon ElastiCache for Redis -palvelua, joka mahdollistaa Multi-AZ -klusteroinnin ja -replikoinnin. Viestijonopalveluksi valittiin Amazon Simple Queue Service (SQS).
Infrastruktuuritasolla palveluun konfiguroitiin autoscaling sekä kontti- (ECS) että palvelintasolla (EC2). Myöhemmin kun AWS Fargate -palvelu tuli saataville EU-alueella vuoden 2018 toisella vuosineljänneksellä, soveltuvia osia palvelusta alettiin vaiheittain siirtää Fargate-palvelun piiriin. Järjestelmän skaalautuvuus todennettiin alkuperäisten Oikotie-tuotteiden analytiikasta saatuja liikennehuippuja vastaavalla kuormitustestauksella. Resurssien varaaminen joustavasti todellisen resurssitarpeen perusteella, tehokas välimuistinkäyttö järjestelmän eri tasoilla sekä valittu arkkitehtuuri, jossa varattuja resursseja voidaan hyödyntää tehokkaasti, ovat mahdollistaneet palvelun infrastruktuurikustannusten pitämisen suhteellisen alhaisina muihin vastaavanlaajuisiin palveluihin verrattuna.
Uuden Oikotie-palvelun ensiaskeleet
Uusi Oikotie-palvelu otettiin yleiseen käyttöön vuoden 2018 toukokuussa. Nyt kun palvelu on ollut jonkin aikaa käytössä, on hyvä katsoa taaksepäin ja arvioida valitun teknisen ratkaisun suunnitteluperiaatteita ja toteutusta.
Lanseerauksen jälkeen palveluun on rekisteröitynyt jatkuvasti uusia käyttäjiä, jonka seurauksena kasvavan käyttäjäkannan palvelemiseen on tarvittu koko ajan laajempaa infrastruktuuria. Lyhyellä aikavälillä autoscaling on vastannut lisäresurssitarpeeseen. Pitkän aikavälin tarpeeseen taas on vastattu nostamalla aika ajoin varattavien resurssien vähimmäistaso kasvaneen liikennemäärän ja järjestelmäkuorman vaatimalle tasolle. Palvelun lanseerauksen jälkeen järjestelmän eri komponentteja on pitänyt skaalata useilla sadoilla prosenteilla sekä vertikaalisesti että horisontaalisesti. Valitun arkkitehtuurin ansiosta skaalaaminen on onnistunut joustavasti ja ongelmitta.
Mikään järjestelmä ei kuitenkaan ole täydellinen. Järjestelmän kehittyessä ja sen käyttäjien tarpeiden ja vaatimusten täsmentyessä erilaisia parannuksia, jatkokehitystä ja ylläpitoa tullaan tarvitsemaan myös tulevaisuudessa. Valittu arkkitehtuuri ja palvelussa käytetyt tekniset ratkaisut mahdollistavat järjestelmän laajennettavuuden ja takaavat sen, että palvelua on myös jatkossa helppo päivittää, skaalata ja laajentaa tulevien tarpeiden mukaan.
Autoscaling
Autoscaling eli automaattinen skaalautuvuus on menetelmä, jossa resursseja varataan ja vapautetaan tarpeen mukaan ennalta määrätyissä rajoissa. Järjestelmän skaalautumista ohjaa skaalauskäytäntö (scaling policy), jossa määritetään, milloin ja kuinka paljon resursseja tulee varata ja vapauttaa. Järjestelmä voidaan esimerkiksi määrittää skaalautumaan aikatauluperusteisesti viikonpäivän ja kellonajan mukaan tai tietyn mitattavan arvon, kuten suoritinkäytön tai muistinkäytön, perusteella.
Automaattisesti skaalautuvalle järjestelmälle määritetään tietty varattavien resurssien vähimmäismäärä, jolla katetaan järjestelmän normaalikuormitus. Kun resurssitarve kasvaa esimerkiksi vuorokauden ruuhkahuippuina, autoscaling laajentaa järjestelmää automaattisesti varaamalla lisäresursseja. Kun kuormitus palautuu takaisin normaalitasolle, tarpeettomat resurssit vapautetaan automaattisesti. Automaattinen skaalautuvuus auttaa järjestelmää mukautumaan lyhyen aikavälin resurssitarvevaihteluihin ja pienentää infrastruktuurikustannuksia, koska käyttämättömiä resursseja ei pidetä varattuna tarpeettomasti. Kun järjestelmän resurssitarve kasvaa pysyvästi esimerkiksi palvelun käyttäjäkunnan kasvaessa, varattujen resurssien vähimmäistasoa on kasvatettava.
Johtopäätökset
Uudessa Oikotie-palvelussa käyttäjille voidaan näyttää samassa sovelluksessa yksilöllistä sisältöä kaikista olemassa olevista Oikotie-vertikaaleista. Järjestelmä perustuu microservice-arkkitehtuuriin, ja se on toteutettu AWS-pilvipalvelualustan päälle siten, että palvelu on skaalautuva, vikasietoinen ja sillä on korkea saavutettavuus (high availability).
Integraatioiden suuri lukumäärä lisää järjestelmän monimutkaisuutta, mutta valittu tekninen ratkaisu jakaa palvelun itsenäisiin ja erikseen hallittaviin komponentteihin, ja tekee siten koko järjestelmästä huomattavasti helpomman kehittää ja ylläpitää. Henkilökohtaisesta näkökulmasta projekti on ollut sekä haastava että palkitseva, ja voin olla ylpeä sen teknisestä toteutuksesta.
Haluatko kuulla lisää?
Jukka voi kertoa lisää tästä projektista ja siitä miten voisimme olla sinulle avuksi.
