xAPI ja Valamis LRS viisi vuotta tuotannossa: Mitä olemme oppineet?

xAPI-nimellä tunnetun Experience APIn juuret juontavat vuoteen 2010. ADL käynnisti silloin Tin Can Project -tutkimushankkeen, jota veti Rustici Software. Projektin lopputuloksena syntyi Tin Can API -spesifikaatio, josta tuli myöhemmin xAPI. xAPIn versio 1.0.0. julkaistiin 27. huhtikuuta 2013.

Me – kuten koko toimialamme – innostuimme ja kiinnostuimme uutuudesta. Valamiksen tuotekehitystiimi seurasi tiiviisti xAPIn kehitystä. Vuonna 2014 otimme käyttöön oman Learning Record Storemme (LRS) ja tuotimme ensimmäiset xAPI-lausekkeemme oppijoiden kehityksen tallentamiseksi omassa Valamis-oppimisympäristössämme.

Tuhansista miljooniin tallennettuihin lausekkeisiin

Selvennän ensin keskeiset käsitteet joista blogissa puhutaan. xAPI on standardi (tai spesifikaatio) joka mahdollistaa erilaisissa konteksteissa olevien oppimistapahtumien seurannan, tallentamisen ja jakamisen. Learning Record Store (LRS) on tietovarastojärjestelmä, jonne eri konteksteista kerätyt oppimisaktiviteetit voidaan säilöä.

Valamis LRS:n tuotantokäyttö alkoi syksyllä 2014. Paljon on muuttunut sen jälkeen, ja paljon olemme myös oppineet. xAPI-lausekkeet pystyvät tallentamaan Valamis-oppimisympäristön uusimmassa versiossa jo 50 erilaista tapahtumaa. Määrä on yli kymmenkertaistunut alkuaikojen neljästä erilaisesta tapahtumasta, ja se kasvaa aina uuden version myötä. Päivittäinen tuotantomäärä (katso kuva alla) liikkuu joidenkin asiakkaidemme ympäristöissä jopa kymmenissä tuhansissa lausekkeissa. Tämänhetkinen ennätys on kaksi miljoonaa tallennusta vain kahdessa päivässä. Voimakkaasti kasvavat määrät ovat hyvä merkki. Mutta menestys ei ole tullut itsestään. Tiimimme on paiskonut lujasti töitä – pitkiä hien ja kyyneltenkin täyttämiä päiviä.

Dataa – ja paljon!

Ensimmäinen – ja tärkein – opetuksemme oli, että LRS:mme ei pelkästään sisältäisi dataa – se sisältäisi sitä aivan käsittämättömän paljon! Heti alussa törmäsimme haasteeseen, kuinka saada kerätystä datasta merkityksiä selville. Päädyimme pian siihen, että xAPIa ei oikeastaan ollut suunniteltu raportointiin. Naiivi käytäntömme koostaa raportteja suoraan LRS-kyselyillä ei ollut paras vaihtoehto.

Olemme tehneet vuosien mittaan useita iteratiivisia parannuksia, että voisimme käsitellä xAPI-lausekkeita lennossa ja esittää kerättyyn dataan perustuvaa analytiikkaa reaaliajassa. Emme ole kuitenkaan toistaiseksi tyytyväisiä hankkeen tilanteeseen. Niinpä työstämme NoSQL-ratkaisua, joka sallii reaaliaikaisen analytiikan Sparkin avustuksella.

Migraation haasteet

Datan määrä paitsi vaikuttaa analytiikan suorituskykyyn, myös vaikeuttaa iteratiivista evoluutiota eli migraatiota. Jokainen datamalliin ja tallennukseen tekemämme parannus vaatii olemassa olevan datan migratoimista uuteen malliin. Naiivi tapamme toteuttaa näitä tietokantamigraatioita johti pitkiin (ja yleensä ennakoimattomiin) huoltokatkoihin.

Meidän piti siten suunnitella migraation toteutustapa kokonaan uudelleen. Päädyimme lopulta yksinkertaiseen ratkaisuun. Sen sijaan, että tekisimme migraation käytössä olevaan LRS:ään, luomme LRS:stä uuden instanssin (kohde-LRS:n) ja käynnistämme sitten lausekkeiden edelleenlähetysprosessin (pähkinänkuoressa: luemme lähde-LRS:ää ja kirjoitamme kohde-LRS:ään käyttämällä määrittelyn mukaista standardia ohjelmointirajapintaa) alusta alkaen käyttämällä aikaleimaa hakuparametrina, samalla kun käytössä oleva LRS (joka on samalla lähde-LRS) palvelee asiakkaita tavalliseen tapaan koko migraation ajan. (Onnistuneen migraation jälkeen vaihdamme vain kuormantasaajan käyttämää LRS:ää, ja homma on siinä).

Uudessa mallissa migraatio vie hieman pidempään kuin aiemmassa mallissa, mutta siinä sekä huoltokatkojen tarve että asiakkaita ja loppukäyttäjiä kiusaavien virheiden mahdollisuus on huomattavasti pienempi kuin aiemmin. Jos migraatio menee nyt mönkään, se ei vaaranna tuotantokäytössä olevaa järjestelmää. Korjaamme vain ongelman ja aloitamme prosessin uudestaan ihan alusta.

LRS-ympäristön mitoittaminen

LRS:n pitäisi käytön aikana pystyä tallentamaan kohtuullisen suuri määrä lausekkeita lyhyessä ajassa. Seuraavassa esittelen esimerkin siitä, kuinka kasvatimme LRS-ympäristön kapasiteettia eräälle asiakkaallemme äskettäin.

Tämä asiakas työstää oppimista niin, että sen oppimisympäristössä on viikoittain käyttäjäaktiivisuuden piikki, jossa suurin kuorma on aina yhden tietyn tunnin aikana. Tuon tunnin aikana generoidaan noin 35 0000 lauseketta – noin kymmenen lauseketta sekunnissa.

Varautuaksemme kuorman kasvuun aloitimme testauksen, jonka tavoitteena oli käsitellä sata lauseketta sekunnissa. Lopputuloksena ympäristössä on kuormantasaajan takana kolme LRS-instanssia (joista yksi on korkean käytettävyyden takaamiseksi varalla). Jokaisessa LRS-noodissa on kaksi keskusyksikköä ja kolme gigatavua muistia.

Palvelu oli 100-prosenttisesti saatavilla koko 24 tunnin testin ajan. LRS:t toimivat koko ajan normaalisti ilman, että palvelimet olisivat piiputtaneet. Testikokoonpano suoriutui siis 8,6 miljoonasta lausekkeesta vuorokaudessa. Ja kuten jo mainitsin, toinen LRS-tuotantoympäristö käsitteli taannoin ”vain” kaksi miljoonaa lauseketta kahdessa päivässä (nämä palvelimet olivat selvästi suorituskykyisempiä, joten tämä oli LRS:llemme lastenleikkiä ☺).

Työskentelemme nyt sen eteen, että 100 000 samanaikaisen käyttäjän käsittely olisi mahdollista. Tämä tarkoittaa noin 10 000 lauseketta sekunnissa – lähes 500 gigatavua JSON-dataa tallennettuna yhdessä päivässä. Kehitämme LRS:mme tallennusalustaa Cassandra NoSQL:llä niin, että se selviää moisesta kuormasta.

Joustavuus on etu ja haitta

Suorituskyvyn lisäksi xAPIin liittyy toinen oleellinen seikka. xAPIn määritelmän ytimessä on tarve saada useissa eri paikoissa suoritettavien toimenpiteiden merkitys selville. On tiedettävä, mitä on etsimässä, ja on osattava tulkita xAPI-lausekemuotoista dataa.

xAPI-määritelmä on kehitetty joustavuutta silmälläpitäen. Se antaa lausekkeiden rakenteiden yksityiskohdille suuria vapauksia. Mutta tämä joustavuus on samalla sekä etu että haitta.

Törmäsimme haittapuoleen, kun aloimme käyttää oppimateriaaleja, jotka oli tehty Articulate Storylinen kaltaisilla ulkoisilla sisällöntuotantotyökaluilla, jotka tuottivat xAPI-lausekkeita.

Storyline on hyvin tehokas työkalu vuorovaikutteisten oppimateriaalien tekemiseen. Mutta rehellisesti sanoen, sen ensimmäiset xAPI-toteutukset olivat kaukana täydellisestä. Ja samaan aikaan Valamiksen oppijoiden kehityksen seuraaminen oli jo täysin xAPIn varassa.

Meillä oli Valamiksessa hyvin usein ongelmia käyttäjien oppimiskehityksen seuraamisessa Storylinen vanhojen versioiden kanssa. Joskus järjestelmä ei merkinnyt oppitunteja lainkaan suoritetuksi, vaikka oppija olisi tehnyt hienoa työtä ja selvittänyt kaikki kyselyt.

Olet varmaankin kuullut xAPI-profiileista. Ne muodostavat metodin, jonka avulla eri järjestelmät päättävät, miten xAPIn joustavuutta hyödynnetään ja mitä merkityksiä lausekkeilla on. Mutta ne eivät vielä käytännössä toimi niin kuin pitäisi. Ulkopuolisten oppimisohjelmistojen tuottamien lausekesarjojen käyttökelpoiset osuudet löytyivät vain yrityksen ja erehdyksen kautta.

Onneksi on olemassa yhteinen ”totuuden lähde”, johon voi tässä tapauksessa luottaa. Rustici Softwaren SCORM Cloud on hyvä oppimisohjelmistojen lakmustesti, kun pitää selvittää, onko vika omassa järjestelmässä vai oppimisohjelmistossa.

Mitä seuraavaksi?

Mitä olemme siis tähän asti oppineet viiden vuoden matkastamme? Ensinnäkin, xAPIn käyttöönotto ja uuden LRS:n kehittäminen vaatii huomattavia ponnisteluja ja merkittävien teknisten päätösten tekemistä, että pysyttäisiin jatkuvasti kasvavan datamäärän tahdissa. Lisäksi, datan tulkitseminen ja siihen perustuvan analytiikan tarjoaminen vaatii vieläkin suurempia ponnisteluja ja merkittävämpiä ratkaisuja.

Jos aiot perustaa LRS:n, pidä mielessä alusta asti, että joudut tekemään migraatioita. Kehitä migraatiostrategia ja pidä se LRS:si ytimessä. Myös LRS:n skaalautuminen pitäisi huomioida jo alkuvaiheessa. Pidä mielessä, että LRS tulee sisältämään PALJON dataa, ja sen määrä kasvaa nopeammin kuin käyttäjien määrä.

Ja viimeisenä muttei vähäisimpänä: mieti, miten saat datastasi tolkkua myös silloin, kun otat tuotteeseesi tai integraatioihisi xAPI-ominaisuuksia. xAPI on joustava, kun kyseessä on LRS:ään lähetettävän datan sisältö. Mutta kun se on kerran tallennettu, se on siellä pysyvästi. Sen jälkeen ei voi enää vaikuttaa siihen, vastaako tallennettu data sitä, mikä xAPI-lausekkeen merkitys oli sen lähettämishetkellä.