Scorito is al jaren de grootste aanbieder van sportspellen in Nederland. Het aantal spelers stijgt gestaag over de jaren heen en heeft met het WK 2022 een nieuwe piek bereikt. Liefst 650.000 deelnemers speelden mee met het WK-spel. Dat brengt natuurlijk behoorlijke technische uitdagingen met zich mee. In dit artikel geven wij inzage over onze scaling-uitdagingen en hoe wij ervoor zorgen dat onze app niet bezwijkt onder de enorm hoge bezoekersaantallen.
Hockeysticks
Het verkeer op Scorito is sterk evenementgebonden. Zo zien wij voorafgaand aan een wedstrijd pieken van deelnemers die nog snel even een voorspelling voor de deadline invullen. Gedurende een wedstrijd checken spelers graag de app bij belangrijke gebeurtenissen zoals een doelpunt. De grootste piek is echter vlak na afloop van een wedstrijd: iedereen is benieuwd naar de hoeveelheid behaalde punten én of zij een sprong(etje) hebben gemaakt op de ranglijst. De enorme pieken in bezoekersaantallen zien er op een grafiek uit als, je raadt het al, een hockeystick. Aan onze infrastructuur de taak om alle gebruikers op deze piekmomenten een snelle en fijne gebruikerservaring te bieden.
HPA's
De data van Scorito wordt in de app gevoed door een microservices architectuur die wordt gehost op Kubernetes. Het scalen van microservices op resourcegebruik van CPU of geheugen wordt prima ondersteund binnen Kubernetes op het moment dat resourcegebruik gestaag toe- of afneemt. Dat is helaas niet het geval bij Scorito, waar de hoeveelheid requests op een microservice zomaar kan vertienvoudigen binnen een minuut. Een HPA met een reactietijd van één minuut is dan gewoonweg te langzaam.
Headroom
Dit betekent dat wij voorafgaand een inschatting dienen te maken van de te verwachten drukte en daar een veiligheidsmarge bovenop moeten aanhouden. Dit is essentieel, want een gebrek aan CPU of geheugenresources en dus een te trage app leidt tot een hoge bounce rate. Oftewel, bezoeker die de app té traag vinden en het opgeven. Extra gevaarlijk hieraan is dat wij deze gebruikers niet opvangen en de potentiële hoeveelheid klandizie niet volledig kunnen inzien. Zie het als een zichtbare wachtrij voor de supermarkt, waarin potentiële klanten reeds zijn doorgelopen naar de concurrent. Kortom, een veiligheidsmarge is benodigd!
Om te ondervangen of onze infrastructuur een verwachte piek aan zou kunnen maken wij gebruik van een load testing tool. Hiermee kunnen we de HTTP requests nabootsen die klanten op onze infrastructuur doen en de load simuleren.
De tool laat ons complexe loadtest scenario's schrijven. Op deze manier kunnen wij met gesimuleerde gebruikersaccounts en gebruikersdata, kansberekening en willekeurige pauzes bepaalde piekmomenten nabootsen en testen op een identieke kopie van onze productieomgeving.
Bij deze tests houden we de monitoring en prestaties van onze loadtest omgeving nauwlettend in de gaten, en wordt de belasting, aantal gesimuleerde klanten, en HTTP requests per seconde opgeschroefd. Dit blijven we opschroeven totdat er a) een workload crash plaatsvindt of b) onacceptabele traagheid optreedt.
Workload crashes
Bij Scorito zien we meestal maar 3 verschillende workload crashes:
Codefouten lossen we zelf handmatig zo snel mogelijk op en Out-of-Memory problemen worden veroorzaakt door Kubernetes geheugenlimieten of het onvermogen van de workload om intelligent met zijn geheugen om te springen. Het geheugengebruik terugdringen is vaak een kwestie van een lange adem en wat voorzichtigheid bij het programmeren. Sommige vaak gebruikte programmeerconcepten zijn inefficiënt als ze zwaar belast worden en vereisen een complete nieuw ontwerp om op de limiet nog goed te functioneren. Op dat moment maken we een kosten-baten afweging of het de moeite is om tijdelijk meer resources uit te delen. We hebben hoe dan ook een semi-automatisch systeem die specifieke workloads ruim voor een verwachte piek voorziet van genoeg resources.
Onacceptabele traagheid
Er zijn workloads die prima kunnen functioneren met een beperking van CPU of geheugenbronnen. Deze workloads blijven doorgaan met het verwerken en beantwoorden van HTTP requests binnen de afgebakende resources die het Kubernetes cluster biedt. Echter verwachten wij een bepaalde snelheid.
Het is hier zaak om te waken dat de workloads onder een hoge belasting de gebruikerservaring niet vertragen. Dit kan door horizontaal uit te schalen (meer replica's van dezelfde dienst neer te zetten die samen de load verdelen), of meer CPU uit te delen.
In sommige gevallen worden workloads vertraagd door de diensten die ze gebruiken, zoals caches of databases. Dan kijken we nog een laag dieper om aanpassingen te verrichten.
Na wat aanpassingen, code iteraties en hertesten van het systeem onder load hebben we de potentiële pijnpunten omzeild of opgelost. Er is echter één bottleneck die we zelf niet kunnen aanpassen: een enorme hoeveelheid spelers die de app op hetzelfde moment willen bezoeken. Gelukkig hebben we nog meer gereedschap in huis om dit aan te kunnen.
Caching
Scorito maakt gebruik van 3 lagen aan cache om veelgebruikte data snel te kunnen leveren. Het gebruik van meerdere lagen zorgt voor uitdagingen met cache invalidation, locking en thundering herds, maar zorgt er tevens voor dat we een snelle app kunnen aanbieden met een minimum aan berekeningen.
Scaling
Goede developers, degelijke code, onze cloud provider en Kubernetes zorgen gezamenlijk voor een systeem waarin de afzonderlijke microservices alsmede de monolithische backend systemen intelligent kunnen schalen. Dit zorgt ervoor dat we een systeem hebben dat voorbereid is op pieken, maar ook kan worden afgeschaald op momenten van relatieve rust. Tijdens het WK is het systeem dat de app aanbiedt aan klanten enkele tientallen keren zo groot als normaal!
Draaiboeken
Om eventuele problemen tijdens piekmomenten snel de baas te kunnen zijn hebben we draaiboeken voor het verder opschalen van diverse componenten en het verminderen van load door het progressief uitschakelen van 'dure' functies. We hebben tijdens grote evenementen ook technisch personeel klaar staan om eventuele problemen snel te kunnen signaleren en op te lossen.
