xAPI & Valamis LRS – wat we hebben geleerd in vijf jaar

Experience API (of xAPI) is ontstaan in 2010, met het door ADL geïnitieerde Tin Can onderzoeksproject. Dit project werd uitgevoerd door Rustici Software. Het resulteerde in de Tin Can API-specificatie, de latere xAPI-specificatie. Versie 1.0.0 van xAPI werd op 27 april 2013 gereleased.

In de markt was er veel belangstelling en opwinding rond deze nieuwe technologieën, ook bij ons. Het product development team van Valamis volgde de ontwikkeling van xAPI op de voet en in 2014 hebben wij onze eigen Learning Record Store (LRS) geïmplementeerd. We begonnen ook onze eerste xAPI statements te genereren om de voortgang van leerders binnen ons Learning Experience Platform (LXP) vast te leggen.

Van duizenden naar miljoenen vastgelegde statements
Ik zal eerst de belangrijkste termen in deze blog toelichten. xAPI is een standaard (of specificatie) waarmee we de leerervaring die een gebruiker opdoet op verschillende platforms en in verscheidene contexten, kunnen volgen, bewaren en delen. Een Learning Record Store (LRS) is een systeem voor dataopslag dat dient als bewaarplaats voor learning records die zijn verzameld door aangesloten systemen.

In de herfst van 2014 gingen we van start met het gebruik van Valamis LRS in productie. Er is sindsdien veel veranderd en we hebben ook veel geleerd. Het aantal gebeurtenissen dat met xAPI wordt vastgelegd in Valamis LXP is meer dan vertienvoudigd, van aanvankelijk slechts 4 tot 50 in de laatste versie – en het worden er met elke nieuwe release meer. Binnen de omgevingen van sommige van onze klanten (zie onderstaande afbeelding) worden dagelijks tienduizenden statements gegenereerd, met recentelijk een peak performance van meer dan 2 miljoen in slechts twee dagen. Deze substantieel toenemende aantallen zijn positief, maar er zitten veel zweet en tranen, lange dagen en een enorme inspanning van het team achter.

Data – heel veel data

Onze eerste en belangrijkste les was dat onze LRS niet zomaar wat data bevatte, maar dat we beschikten over er een enorme, onbegrijpelijke berg gegevens. Vanaf het allereerste begin werden we geconfronteerd met het probleem van het duiden van de verzamelde data. Al snel ontdekten we dat xAPI niet geschikt was voor rapportage en dat onze naïeve manier van rapporten opstellen door de LRS direct te doorzoeken niet de verstandigste keuze was.

We hebben de afgelopen jaren veel iteratieve verbeteringen doorgevoerd, die erop gericht waren om xAPI statements direct te kunnen verwerken en om op basis van de verzamelde data real-time analyses te kunnen presenteren, maar we zijn verre van tevreden met de huidige stand van zaken. Daarom werken we aan een NoSQL-oplossing waarmee we real-time analyses kunnen verkrijgen met behulp van Spark.

Uitdagingen bij migratie

De grote hoeveelheid data had niet alleen implicaties voor de prestaties op het gebied van analytics. We kregen ook te maken met het probleem van iteratieve evolutie: migratie. Bij elke verbetering die we doorvoerden in het datamodel en in de opslag moesten we de bestaande gegevens migreren naar het nieuwe model. Onze simpele aanpak van deze database-migraties veroorzaakte direct lange (en meestal onverwachte) onderbrekingen voor onderhoud.

We waren genoodzaakt om onze hele benadering van migratie te heroverwegen, en we zijn uiteindelijk tot een eenvoudige oplossing gekomen. We voeren de migratie niet uit op de live-LRS, maar we bouwen een nieuwe instantie van de LRS (de doel-LRS). Vervolgens sturen we de statements een voor een door, waarbij we de timestamp inzetten als query parameter. Kort samengevat komt dit neer op lezen van de bron-LRS en schrijven naar de doel-LRS, op basis van de standaard-API die is gedefinieerd in de specificatie. Ondertussen is de live-LRS (die dus ook de bron-LRS is) gewoon in bedrijf voor klanten – gedurende de complete migratie. Na een succesvolle migratie hoeven we alleen maar de load balancer om te schakelen naar de nieuwe LRS, en dan zijn we klaar om verder te gaan.

Dit kost iets meer tijd in vergelijking met de directe aanpak van migratie, maar het zorgt voor minder onderbrekingen voor onderhoud en het verkleint het risico dat er iets misgaat voor klanten en eindgebruikers. Zou de migratie nu mislukken, dan heeft dat geen invloed op het live-systeem. We kunnen het probleem gewoon oplossen en opnieuw beginnen.

Omvang van de LRS-omgeving

Een ander aspect van een actieve LRS is dat deze binnen korte tijd een behoorlijke hoeveelheid statements moet kunnen vastleggen. Ik geef een voorbeeld van hoe we de LRS-omgeving onlangs hebben aangepast voor een van onze klanten.

Door de aard van het leerproces doet zich bij deze klant elke week een piek in gebruikersactiviteit voor, met een wekelijks hoogtepunt binnen één bepaald uur. De hoeveelheid statements die gedurende dat uur wordt gegenereerd ligt rond de 35.000. Dat betekent zo’n 10 statements per seconde.

Om te anticiperen op toekomstige groei, hebben we onze testen uitgevoerd met als doel 100 statements per seconde. Als gevolg daarvan hebben we onze omgeving zodanig moeten aanpassen dat er drie instanties van de LRS achter de load balancer zitten. Daarbij is één instantie redundant voor high availability en draait elke node op 2 CPU en 3 GB RAM.

We realiseerden 100% beschikbaarheid op de 24-uursloadtest, met de LRS steeds in de normale bedrijfsmodus en zonder dat de servers op hol sloegen. Met een eenvoudige rekensom kom je uit op 8,6 miljoen statements per dag voor onze testopstelling. En zoals ik al eerder zei, we hebben bij een ander voorbeeld van LRS-performance in productie (‘slechts’) 2 miljoen statements vastgelegd (inderdaad, er waren in dit geval veel krachtiger servers in bedrijf, dus het was voor onze LRS een no-brainer 🙂 ).

Wij werken nu aan de capaciteit om 100.000 gelijktijdige gebruikers te verwerken, wat neerkomt op ongeveer 10.000 statements per seconde – 500 GB aan JSON-data die worden vastgelegd in één dag. Om een dergelijke belasting aan te kunnen, ontwikkelen we de opslag voor onze LRS met behulp van Cassandra NoSQL.

Flexibiliteit is zowel een voordeel als een nadeel

Naast de performance is er nog een ander belangrijk aspect van werken met xAPI. De essentie van de xAPI-specificatie is immers de behoefte om betekenis te geven aan activiteiten die op veel verschillende plekken plaatsvinden. Je moet weten wat je zoekt, en je moet gegevens in de vorm van xAPI statements kunnen interpreteren.

De xAPI-specificatie is ontwikkeld vanuit de gedachte van flexibiliteit. Op detailniveau biedt de specificatie veel vrijheid wat betreft de structuur van de statements. Dat is tegelijkertijd een voordeel èn een nadeel.

We hebben de flexibiliteit als een nadeel ervaren, zodra we materiaal gingen gebruiken van externe content-authoring tools die xAPI statements genereerden, zoals Articulate Storyline.

Storyline is een zeer krachtige tool om interactief leermateriaal te bouwen, maar de eerste pogingen van Storyline om met xAPI te werken, waren eerlijk gezegd verre van perfect. Valamis was toen al afhankelijk van xAPI voor het volgen van de voortgang van leerders.

Met oudere versies van Storyline hadden we vaker wel dan niet issues waarbij de voortgang van de leerders niet goed werd bijgehouden in Valamis. Het systeem gaf soms niet eens aan dat lessen waren voltooid, zelfs al had de leerder hard gewerkt en alle toetsen gemaakt.

U hebt waarschijnlijk wel gehoord van xAPI Profiles, een methode om verschillende systemen op elkaar af te stemmen voor wat betreft het gebruik van de flexibiliteit van xAPI en de betekenis van de statements. Maar die aanpassingen zijn in werkelijkheid nog niet doorgevoerd. We hebben de weg van trail-and-error moeten volgen om de betekenisvolle delen te vinden in de reeksen statements die worden gegenereerd door externe leerpakketten.

Gelukkig is er ook een algemene ‘bron van waarheid’ waarop we kunnen vertrouwen: SCORM Cloud van Rustici Software is een goede lakmoesproef voor het leerpakket wanneer je twijfelt of een probleem in je systeem zit, of in het leerpakket.

Hoe nu verder?

Wat hebben we geleerd tijdens onze vijf jaar durende ontdekkingsreis? Allereerst dat de toepassing van xAPI en het bouwen van een nieuwe LRS vragen om aanzienlijke inspanningen en om tal van niet-triviale technische beslissingen, willen we in de pas blijven lopen met de voortdurend toenemende hoeveelheid gegevens. En het begrijpen van al die data en het bieden van analyses daarvan vergt nog meer moeite en nog minder triviale oplossingen.

Als u bezig bent om een LRS te ontwikkelen, houdt u er dan vanaf het begin rekening mee dat u moet migreren. Bepaal uw migratiestrategie en veranker deze in de kern van uw LRS. Let ook meteen op de schaalbaarheid van uw LRS. Vergeet niet dat de LRS straks HEEL VEEL gegevens bevat, en dat die hoeveelheid sneller gaat groeien dan uw gebruikersgroep.

En bedenkt u als laatste, maar niet minder belangrijke punt, hoe u uw gegevens kunt begrijpen vanaf het moment waarop u xAPI toevoegt aan uw product of uw integraties. xAPI is flexibel als het gaat om de inhoud van de gegevens die u naar de LRS stuurt. Maar wat eenmaal is opgeslagen, blijft daar. U hebt geen invloed meer op datgene wat er wordt bewaard versus de betekenis van het xAPI statement op het moment dat het werd toegevoegd.