I 520 dagar hade Liseberg varit stängt på grund av pandemin. Inför den efterlängtade öppningen slog man i sina sociala medier på den stora trumman inför biljettsläppet den 25 maj för sommaren 2021. Man hade tydligen t.om. en nedräkningstimer på sidan. Det hela slutade dock med att sajten kraschade redan några minuter före biljettsläppet klockan 10 och man fick stänga ner bokningen under flera dagar.
Runt 20 000 besökare försökte komma in på sajten samtidigt vilket gjorde den instabil under hela dagen. Framförallt under betalningsprocessen då många blev utkastade, kunde inte betala eller fick biljetter med felaktiga datum.
Några artiklar om kraschen:
- Sveriges Radio: 20 000 besökare jagade biljett till Liseberg – allt kraschade
- SVT: Lisebergs hemsida kraschade – minuten innan biljettsläpp
- Göteborgs-Posten: Lisebergs bokningssida kraschade minuter efter öppnandet
- GT: Lisebergs sajt kraschade – nu pausas biljettförsäljningen
Tekniken bakom
Som teknikintresserad blir jag genast nyfiken var man hade hamnat snett när man inte lyckades med att hålla tillräckligt hög kapacitet. Jag började därför att gräva lite för att se om jag kunde se vad för system de kör med.
Cloudflare ligger framför liseberg.se
Genast kunde man konstatera att Liseberg använder Cloudflare, felmeddelandet nedan var det många som möttes av under dagen. Att använda Cloudflare är smart tänkt och mer eller mindre strandad för större sajter för att sprida ut belastningen och kunna stå emot överbelastningsattacker som DDOS.
Cloudflare är en CDN (Content Distribution Network). Istället för att ha allt på en enda webbserver så kan man med en CDN sprida ut trafiken över flera platser runt hela världen. Besökaren ansluter sig mot den plats som är närmast geografiskt och får därmed snabbare upplevelse. Grundnivån är att statiska filer såsom bilder ligger på CDN medans webbsidorna fortfarande genereras från webbservern. En CDN löser därmed inte magiskt alla kapacitetsproblem, men det är helt klart ett bra verktyg på vägen mot att skapa en webbplats som klarar hög belastning.
Att som extern kunna lista ut vad man har för system bakom Cloudflare är inte trivialt att ta reda på. Möjligtvis kan man se några spår som tyder på att de använder Episerver för hemsidan.
Men det stora problemet var inte hemsidan i sig, jag kunde själv surfa runt på liseberg.se under dagen. Deras främsta problem var att folk inte kunde köpa biljetter. Man hade problem med sin e-handelsdel som sköts av Jetshop.
Bokningen hanteras av Jetshop
Själva bokningen av biljetter har man i ett separat system, Jetshop. Lisebergs VD Andreas Andersen har i en intervju uppgett att man förberett sig i den mån att man lagt detta på en separat server. Så långt är allt väl. Jepshop har sitt system i Azure. Att ha systemet i molnet är en bra tanke i grunden, då har man möjlighet att skala upp systemet betydligt enklare.
Men frågan är hur Jetshop har byggt sitt system och hur väl det skalar. Tar man en titt på deras kundreferenser så verkar det inte finnas några riktigt tunga e-handelsplatser som använder Jetshop.
Några referenser är Norrgavel, Hööks och Scorett. De två största jag kunde hitta är Lagerhaus och 24.se.
Liseberg säger själva att i vanliga fall har de bara några hundra besökare inne och bokar samtidigt.
En fråga som jag sett ställas är om verkligen IT-avdelningen var med på noterna till 100% eller om marknadsavdelningen fått fria tyglar.
Jag får säga att det krävs en hel del självförtroende som IT-chef att kunna lova att – javisst vår sajt kommer klara samma tryck som ett biljettsläpp på Ullevi. Tyvärr så visade det sig tämligen omgående att lösningen inte höll måttet.
Man kanske inte ville hålla på och lasttesta sina system när man kunde få ett fint lasttest helt gratis? Använde själv ett system för lasttest för många år sedan som kunde simulera många användare. Minns inte vad det hette, finns kanske inte kvar längre men jag vill minnas att det var mer fokuserat för applikationer och inte webbsidor. Men naturligtvis finns det verktyg för detta idag. Lokala Göteborgsföretaget 3Bits hade säkert gärna hjälpt till, de verkar ha erfarenhet av lasttester.
Eller var alltihop en slug medveten plan för att skapa en snackis och buzz? Är man konspiratoriskt lagd och ser bristen på kösystem är det ingen helt orimlig tanke.
Hade man inte slagit på stora trumman med nedräkning å allt så hade man förmodligen kommit lindrigare undan och klarat sig med sitt befintliga system. Som jämförelse så använder även Gröna Lund Jetshop och där har jag inte hört något om att de skulle haft samma typ av problem, jag har inte heller sett att de slog på stort med deras biljettsläpp. Å andra sidan har de förmodligen mycket mindre trafik till sin sajt.
Hur man löste problemet
Jag började själv fundera på hur jag hade löst detta problem. Ett sätt som man genast tänker på är att införa ett kösystem. Alla som har försökt boka en biljett på Live Nation har nog varit med om att hamna i en kö. En telefonkö på nätet om man så vill.
Ett kösystem är ett enkelt sätt att begränsa belastningen utan att massivt behöva skala upp bakomliggande system. Det verkar även vara så Liseberg ha löst sitt problem. Man har infört ett kösystem från Queue-it. En rätt basal funktion i dessa sammanhang. Att man inte hade det redan från start tror jag helt enkelt beror på att man inte har haft erfarenhet av att jobba med stora tunga sajter på den här nivån tidigare.
Bokningen är igång igen
Två dagar senare, torsdagen den 27 maj började man släppa på bokningen igen. Vis av tidigare erfarenheter gick man denna gången inte ut med ett specifikt klockslag.
Jag kunde själv enkelt boka min biljett och det fungerade som man kunde förvänta sig. Kösystemet såg jag endast en gång, så antingen har man färre besökare nu eller så har man biffat upp även bakomliggande system ytterligare för att klara av högre trafik.
Vad finns det att lära?
På det hela taget tycker jag att man löste det hela rätt snyggt trots allt. Men här finns det lärdomar att dra nytta av. Spontant tänker jag på alla bokningssiter för Coronavaccinet som kommer få känna av hög belastning när det når den stora massan. Till viss del har man indirekt redan gjort en lastbalansering i och med att bokningen inte sker på en enda sida utan är utspridd hos flera aktörer. Störst börda kommer förmodligen 1177.se få med de borde å andra sidan vara varma i kläderna nu och väl förberedda för hög belastning. Bankid är en annan flaskhals som skulle kunna stöta på problem.
