Server-flytning tvang en af Danmarks mest læste nyhedssider i knæ

Illustration: Bold.dk
En flytning fra et fysisk server-setup i Tyskland til en cloud-løsning hos Amazon gav sved på panden hos udviklerne på Danmarks største fodboldsite, bold.dk. Det tog 12 dage at få sitet tilbage på ret kurs.

Hver måned har fodboldsiden bold.dk omkring 13 millioner besøgende. Her tjekker fodboldinteresserede tabeller, kampresultater og læser de seneste nyheder fra den danske 2. division over Superligaen til Premier League og La Liga.

Det placerer bold.dk i toppen over danske nyhedsmedier sammen med f.eks. Jyllands-Posten og Politiken.

Men da bold.dk overgik fra et fysisk server-setup til en AWS cloud-løsning i starten af august, begyndte problemerne at vælte ind.

Brugerne kunne i perioder slet ikke tilgå sitet, mange havnede på forkerte landingssider, ligatabellerne var ikke opdaterede, og en lørdag i august gik der helt ged i målene, så forkerte hold fik tildelt mål, de aldrig havde lavet.

Læs også: Alt fra Apples App Store over universiteter til Slack er ramt af AWS-nedbrud

Tredobling af trafik i halvlegen

Nu fortæller produktchef Lars Riemann Andersen, produktchef på bold.dk, om overgangen og et par hektiske uger i august hos fodboldmediet.

»Vi har et højt grundniveau fordelt over hele dagen, men når der er store fodboldkampe i tv, så kan vi pludselig se en tredobling af trafikken, eksempelvis når der er halvleg i en kamp mellem Brøndby og FCK, hvor brugerne tjekker nyheder og andre resultater på vores site. Det stiller store krav til vores server-hardware, og vi har balanceret på grænsen af kapaciteten på de fysiske servere, vi har anvendt frem til august,« siger Lars Riemann Andersen.

Derfor valgte bold.dk at begynde migreringen til en cloud-løsning sidste december, hvor opgaven blev sendt i udbud.

»Vi har valgt en cloud-løsning for at opnå en mere skalerbar og fleksibel løsning. Kapaciteten bliver automatisk opskaleret, hvis trafikken stiger, ligesom vi manuelt kan planlægge kapaciteten efter store fodboldkampe,« fortæller Lars Riemann Andersen.

Læs også: Case study: Fejlfinding på en ustabil forbindelse

Fra Alibaba til AWS

Faktisk var det slet ikke Amazon Web Services, der var udset til at hoste de danske fodboldresultater i første omgang.

»Vi havde oprindeligt valgt Alibaba Cloud, som vi forsøgte at konvertere til i marts, men her kunne vi hurtigt se, at det ikke var muligt at overføre vores applikationer til den kinesiske cloud-løsning. Derfor afbrød vi samarbejdet og valgte i stedet Amazon Web Services (AWS) og en løsning, hvor vi omlagde en del funktioner til den nye arkitektur inden lancering,« siger Lars Riemann Andersen.

Flytningen blev gennemført tirsdag den 7. august i år. Det var dagen, hvor stikket endeligt skulle trækkes på de tre servere, der stod i Tyskland hos hostingselskabet Hertzner. Det skete efter flere måneders planlægning.

»Vi havde gennemført en lang række test før migreringen, og vi vidste godt, at der kunne være en vis risiko for, at der ville opstå problemer, men uden at vi kunne forudsige præcist, hvad der ville ske,« siger Lars Riemann Andersen.

Bekymringerne blev meget hurtigt konverteret til virkelighed, da flytningen blev sat i gang.

»Nogle databaser opførte sig anderledes. Det tog længere tid end forventet at loade sider, og vi oplevede udfordringer med load balancing, hvor serveren havde en forkert opfattelse af, hvornår et site var i luften. Vores livescore-funktion kan være svære at cache, og her oplevede vi også, at den nye cache fungerede væsentligt anderledes end tidligere.«

Læs også: Microsoft vil presse hostingfirmaer over i selskabets sky

Monolitisk kode

At serverflytningen gav fejl, skyldtes ikke kun cloud-løsningen. Koden bag bold.dk var ikke helt ligetil.

Bold.dk gik første gang online for 19 år siden i 1999. Med årene er koden bag sitet bare vokset og vokset.

»Vores site er bygget op over mange år, og vores kode er monolitisk og ikke splittet op i naturlige grænseflader. Historisk har bold.dk været gode til at agere hurtigt og lancere nye tiltag, men den hastighed har også haft betydning for skalerbarheden. Det er vi i gang med at rydde op i nu, så vi får en mere fleksibel virtuel hardware-arkitektur med mere afgrænsede tjenester. På den måde vil en spidsbelastning på vores livescore ikke nødvendigvis påvirke resten af siden i fremtiden, « siger Lars Riemann Andersen.

Serverflytningen betød, at sitet oplevede flere større udfald på serverne, især i weekender, hvor de fleste fodboldkampe afvikles, ligesom en lang række tjenester på sitet blev sat ud af funktion. Først efter 10-12 dage var de fleste fejl rettet.

»Vi er to udviklere og mig der står for driften, og så havde vi en hostingvirksomhed til at stå for selve migreringen og en ekstern rådgiver med AWS-erfaring til at sparre med. Vi havde brug for at få hentet noget søvn, efter vi havde fået løst de fleste problemer på 10-12 dage efter overgangen til cloud.«

Det var ikke kun udviklerne bag bold.dk, der har bidraget til at løse server-problemerne.

»Vores stab af journalister viste sig at være en stor hjælp. Vi har journalister på arbejde mellem kl. 6 om morgenen til midnat, og de var faktisk hurtigere til at opdage fejl end vores overvågningssystemer, så vi hurtigt kunne sætte ekstra servere på, når der opstod en overbelastning.«

Læs også: AWS lancerer ‘hemmelig’ sky-region til efterretningstjenester

Fleksibel arkitektur på ønskelisten

Når man står med en uoverskuelig bunke fejl, handler det om at prioritere.

»Vi stod med den klassiske udfordring: Hvordan spiser man en elefant? Vi valgte at gøre det til en benhård prioritering, hvor brugerne var udgangspunktet. Så måtte vi midlertidigt acceptere kluntede løsninger for eksempelvis vores journalister.«

I dag er serverproblemerne ryddet af vejen, men bold.dk er stadig i gang med at opdatere websitet og de mange tjenester til en mere fleksibel arkitektur.

»Vi har en masse tjenester i den samme kodebase. Vi arbejder med at finde ud af, hvor de rigtige snitflader er, og hvor opdelingen skal laves i naturlige tjenester. Det er den kerneopgave, vi arbejder med netop nu, og som vi er i gang med at ansætte nye medarbejdere til at bidrage til,« siger Lars Riemann Andersen.

Selvom serverflytningen har givet anledning til mange frustrationer hos brugerne, er trafikken ikke dalet markant hos bold.dk.

Undervejs har bold.dk løbende opdateret sine læsere med status på de mange serverproblemer, både på bold.dk og sociale medier.

»Når man er et stort site som vores, er det langtfra gratis at have tidspunkter, hvor tjenesten er helt eller delvist nede. Heldigvis er vores brugere loyale. De er gode til at brokke sig, når noget går galt, men de forsvinder ikke, så længe man er åben omkring, hvad der sker, og hvordan vi prioriterede at løse problemerne.«

Status på bold.dk's tekniske problemer

Han har tre gode råd til andre, der måtte komme til at stå i en lignende situation.

»Prioriter opgaverne, så de vigtigste problemer kommer først, giv dine udviklere ro til at løse kerneopgaverne, så de ikke skal bruge tid på at kommunikere til omverdenen, og få en uafhængig sparringspartner til at hjælpe dig. Man kan ikke læse korrektur på sine egne tekster.«

Læs også: Amazons sky gør klar til at indtage Danmark: Jeg forstår godt, hvis I er nervøse

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (18)
Jari Wiklund

Jeg hæfter mig især ved at bold.dk har haft tests af deres migrering. Men virkeligheden viste så at deres tests var ubruglige, eller var det på områder hvor der ikke var testdækning, at fejlene opstod efter AWS migreringen? Det virker i alle tilfælde underligt at de ikke har testet noget så elementært som at login fungerer. Eller måske mente de at de havde testdækning, men så kunne det være meget interessant at vide hvorfor deres test gav falsk positiv tilbagemelding.
Uden mere konkrete beskrivelser ift hvorfor bold.dks forholdsregler fejlede, står artiklen blot tilbage som en beskrivelse af et amatøragtigt migreringsforløb med en konklusion som ikke kræver meget erfaring for at kunne drage: “prioriter dine opgaver så de vigtigste kommer først”.
Det er desværre meget lidt læring man kan uddrage af bold.dks erfaringer med denne artikel.

Jørgen Kanters

Jeg er IT amatør, men jeg ville da aldrig lukke det gamle ned gør det andet virkede. Selvfølgelig har man migreret når testene ikke viste fejl, men så snart det ikke virkede hvorfor gik man så ikke tilbage til det gamle site indtil man havde løst fejlene?

Mogens Lysemose

Jeg har siddet i en webhosting og udviklings-virksomhed og disse beskrevne erfaringer kommer når de første par gange man forsøger den slags migreringer som et lille webfirma.

Jeg har selv prøvet at stå i den situation, og det er vildt stressende.

Derefter søger man naturligvis viden og teknikker til at undgå den slags i fremtiden, hvis man føler bare nogenlunde ansvar for sit job og kundeservice.

F.eks. var DNS var et stort problem, for du kunne rette records på navneserveren men ikke vide hvornår folks internetsudbyddere havde cachet dem; derfor sætter man selvfølgelig TTL meget langt ned (fra typisk en dags tid til f.eks. en time) så man hurtig kan rulle tilbage til den gamle server hvis go live svigter.

Så ja det efterlader et indtryk af at det første gang de udviklere prøver sådan en full scale migrering - og de falder i mange af de faldgruber der ligger og venter.

Men fuld sympati med den kamp de har været igennem - og modigt at stille det til skue! :)

Allan Ebdrup Blogger

Tak for at dele historien Lars Riemann Andersen! Jeg har fuld forståelse for hvor nærmest umulig en opgave det må have været at flytte 19 års kode og kun være to udviklere og en produktchef til det. Kudos for at dele det, i fortjener klapsalver, så vi ikke skræmmer andre fra også at dele deres dyrt købte erfaringer.

Jari Wiklund

Jeg sætter også stor pris på at folk deler “skyttegravshistorier”. Jeg ville dog ønske at den journalistiske vinkel var mere konstruktiv, i retningen “gør X for at undgå det vi oplevede”, i stedet for “vi oplevede at migrering til cloud er svært”.

Det eneste konstruktive jeg kan udlede, hvis jeg vel at mærke læser meget mellem linjerne, er at man skal migrere sin monolitiske kodebase, inden man migrerer sin infrastruktur.

Lars Andersen

Jeg kan godt uddybe lidt, jeg tror der er masser at lære - og en del områder hvor vores situation er unik til os.

Vi havde et hosting/migreringsfirma på til at rådgive og hjælpe os over på cloud. Jeg kom ind hos bold.dk efter at de var valgt og efter at man havde lavet første fejlslagne forsøg med et lift-n-shift til Alibaba som blev rullet tilbage.

Pga de to faktorer havde jeg spørgsmålstegn, og engagerede en enkeltmands-konsulent med AWS-erfaring som jeg havde en relation og historik med, og som kunne give mig en mulighed for at få syretestet min opfattelse af hvornår vores hosting/migreringskonsulenter var på bolden og hvornår de ikke var.

Da vi først var i "crunch-time" var den støtte uvurderlig at have, og der var et par områder hvor hans assistance var essentiel for at få løst udfordringerne - som for eksempel når vores loadbalancer havde forkert opfattelse af om en server var på vej op/ned som en del af vores CI/CD pipeline. Den oprindelige løsningsarkitekt var forvirret over hvorfor, mens vi udefra nemmere kunne se hullerne i osten og komme med en løsning.

Hvis man ikke, som køber af eksterne ydelser, føler at man er skarp nok til at vurdere det, man får leveret, så kan jeg godt anbefale at man finder en uvildig rådgiver til at sidde ved siden af og 100% varetage dine interesser.

Lars Andersen

Det eneste konstruktive jeg kan udlede, hvis jeg vel at mærke læser meget mellem linjerne, er at man skal migrere sin monolitiske kodebase, inden man migrerer sin infrastruktur.

Den læring skriver jeg meget gerne direkte på linjen og med en tyk streg under - vi kunne have undgået meget kaos ved at have ladet alt ligge på det gamle jern og migreret gradvist til AWS over en længere periode.

Lars Andersen

derfor sætter man selvfølgelig TTL meget langt ned (fra typisk en dags tid til f.eks. en time) så man hurtig kan rulle tilbage til den gamle server hvis go live svigter.

Ah, hvis bare det var så simple udfordringer. TTL'en var på 5 minutter, og vi havde hele tiden muligheden for et rollback, men det var aldrig inde i overvejelserne.

På den ene side var de udfordringer vi mødte ikke uoverkommelige eller globale, og på den anden side var der også mange af dem hvor løsningen først rigtig kunne testes ved et uforudsigeligt trafikpres alligevel.

Poul-Henning Kamp Blogger

Det er meget svært at simulere mange tusind brugere der bruger websitet på hver deres måde når man tester.

De sites jeg kender i detaljer, og det er nogle stykker efterhånden, har bygget sig faciliteter så de kan optage live traffik og "afspille" den i deres test-miljø.

Alle som en har sagt at det var forbavsende nemt da de tog sig sammen til at gøre det.

Anders Petersen

Det er pudsigt, at der ikke bliver nævnt med ét ord, at der en overgang var problemer med brugerprofiler, der blev cached, således, at brugere fik adgang til forkerte profiler, når de loggede ind. Det betød, at man kunne poste på andres vegne, kunne se deres personlige data og meget andet.

Dét synes jeg er langt den mest alvorlige ting ved migreringen. Og så selvfølgelig, at der her snart 3 måneder senere stadig er problemer med visse tabeller, der ikke er korrekt opdateret.

Mogens Lysemose

faciliteter så de kan optage live traffik og "afspille" den i deres test-miljø.

Ja det lyder jo indlysende som en rigtig god måde at gøre det på.
Bruger de et standard-værktøj, eller har de selv bygget noget som bare udfører noget fra http-logfilen ift. de loggede tidsstempler?

Mogens Lysemose

man kunne poste på andres vegne, kunne se deres personlige data og meget andet.

Det lyder umiddelbart som om der er noget der kodet meget amatøragtigt. Sessioner bør ikke kunne hijackes på den måde ved en fejl, så er det jo alt for nemt at gøre det med vilje.

Anders Petersen

Det lyder sådan ja, Mogens. Det nævnes heller ikke, at der på et tidspunkt blev sendt hundredevis af enslydende mails afsted til brugere inden for meget kort tid.

Det er interessant læsning, denne artikel, men det kan undre at Lars Andersen ikke udtaler sig om de rigtigt kritiske problemer, der var.

Lars Knudsen

Spændende case, men udover det åbentlyst smarte i skaleringsmulighederne på AWS kunne det være interessant at høre om omkostningerne for AWS kontra det tyske setup. Evt. som en opfølgning efter et halvt eller helt år.

Log ind eller Opret konto for at kommentere
Pressemeddelelser

Welcome to the Cloud Integration Enablement Day (Bring your own laptop)

On this track, we will give you the chance to become a "Cloud First" data integration specialist.
15. nov 2017

Silicom i Søborg har fået stærk vind i sejlene…

Silicom Denmark arbejder med cutting-edge teknologier og er helt fremme hvad angår FPGA teknologien, som har eksisteret i over 20 år.
22. sep 2017

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 2017
Jobfinder Logo
Job fra Jobfinder