Hoe blijft je website altijd bereikbaar?
Op zich is het vreemd. Bij grootschalige ticketverkoop à la Tomorrowland of Pukkelpop blijft een site doorgaans in de lucht. Terwijl bij de eerste de beste online-inschrijving voor een jeugdkamp de server plat gaat. Waar zit het verschil?
Webwinkels niet bereikbaar tijdens bezoekerspieken
Eén week was de opgetelde periode, gemeten tussen midden november en midden januari, dat veertig Belgische webwinkels in totaliteit onbereikbaar waren. Zo blijkt uit onderzoek van Internetvista.
Enkele van de gecontroleerde sites faalden door het sterk gestegen bezoekersverkeer tijdens het internetshoppen. Dat was het geval bij Nespresso (14 uur storing in totaal gedurende deze twee maanden), bij NewPharma (17 uur) en Mediamarkt (10 uur). "Omdat zij geen server hadden die de massieve verkeerspieken aankon, hebben deze bedrijven wellicht tal van klanten gemist die op dat moment hun aankopen deden", zegt Cédric Braem van Internetvista.
Internetvista legt met zijn onderzoek de vinger op de wond, maar vertelt slechts één deel van het verhaal. Want constante online beschikbaarheid, dus ook bij piekverkeer, gaat verder dan het aanbieden van een extra server. We vroegen enkele hostingspecialisten naar hun antwoord op bezoekerspieken.
1. Werkverdeling
Een eerste antwoord bij piekverkeer is natuurlijk te verwachten: de cloud. Je valt terug op en beschikt over een pool van computersystemen die de toename in bezoekers kunnen opvangen. “Cloud is een belangrijke sleutel”, geeft David Geens van hostingbedrijf Nucleus toe. “In die zin dat je de cloud ziet als een verzameling van hardware waarin snel geschaald kan worden.”
Naast de beschikbare hardware, komt het erop aan om het werk ertussen goed te verdelen. Een van de termen die in deze context het meest vallen, is loadbalancing. Vrij vertaald: ervoor zorgen dat het verkeer netjes wordt verdeeld over meerdere beschikbare systemen.
“Een van de beste manieren om grote bezoekerspieken op te vangen, is via een clusteromgeving”, haalt Bart Stoffels, technical accountmanager bij Priorweb aan. “Daarbij verdeelt een zogenaamde loadbalancer het verkeer over verschillende zogenaamde webnodes. Hoe meer webnodes je voorziet, hoe groter de pieken die je kunt opvangen”, stelt hij.
Bij efficiënte werkverdeling hoort ook een optimaal gebruik van de beschikbare systemen. Of om het met een cliché te zeggen: niet alleen de kwantiteit (hoeveelheid hardware), maar ook de kwaliteit (hoe je ermee omspringt).
Je gaat bijvoorbeeld data af en toe in het geheugen bewaren. “Je kiest dan voor zogenaamde caching waar mogelijk. Ook al moet dat in een shopomgeving met tickets wel goed afgescheiden zijn en onderzocht worden”, stelt Jimmy Cappaert van Combell, die er nog enkele andere tips aan toevoegt. “Je moet ook een schaalbare oplossing bouwen, met zogenaamde cold standby.” Hierbij wordt infrastructuur ter beschikking gesteld die kan ingeschakeld worden bij het falen van de zogenaamde ‘primaire’ systemen. En hij vervolgt: “Serverfuncties, zoals dus via caching of de databank, kan je ook het best zo veel mogelijk splitsen. Op die manier kan je hier ook weer optimaliseren.”
2. Architectuur
Het aantal servers is één verhaal, de achterliggende architectuur een andere. “Grootschalige systemen zijn alleen maar goed te hosten als je als systeembeheerder betrokken bent vanaf het begin. Liefst zelfs al bij het uittekenen van de architectuur. Zo kan je de ontwikkelaars helpen bij bepaalde keuzes en kan je systemen en code op elkaar afstemmen”, stelt David Geens.
Doordat er moet kunnen worden omgegaan met onverwachte groei, is het van belang dat het systeem schaalbaar is. “Als je gewoon een site of applicatie schrijft zonder oog te hebben voor schaalbaarheid, loop je als site-aanbieder altijd vast”, weet Geens.
Er zijn twee verschillende vormen van schaalbaarheid, die bekendstaan als scale-up en scale-out. Scale-up is het uitbreiden van de hardware, zoals het plaatsen van extra capaciteit. Dit vormt meestal niet veel extra implicatie voor de software-implementatie. Scale-out is daarentegen het distribueren van de serverload over meerdere machines. “Hoeveel middelen je er ook tegenaan gooit in de cloud. Je kan niet blijven upscalen, je moet ook op een gegeven moment gaan outscalen, en een goeie outscaling kan alleen als de code daarop voorzien is.”
Efficiënte code en een doordachte dataflow kunnen het gebruik van de serverresources flink inperken, zodat minder snel het plafond bereikt wordt. “Vaak is het ook een kwestie van waar een bedrijf in kan of wil investeren: in ontwikkelaars en tools om de code te optimaliseren, of in zwaardere servers?” oppert Bart Stoffels van Priorweb. “In het ideale geval doe je natuurlijk beide.”
3. Testen
De derde remedie is het constant testen. Dat kan op diverse vlakken. “Denk maar aan een geschikte monitoring en logging”, aldus Jimmy Cappaert van Combell. Het testen gebeurt eigenlijk gedurende het hele parcours, en dus niet alleen als je systeem al live staat. “Tijdens de ontwikkeling al regelmatig loadtesten doen, leert heel veel en zorgt voor tijdige bijsturing”, oppert Geens.
4. Budget
De vierde factor zijn de financiële middelen. Want de drie remedies hierboven hebben budgettaire implicaties. Ook al is het verhaal in de cloud dat je alleen betaalt voor het verbruik. Maar als het aantal bezoekers gigantisch toeneemt zal de prijs, ook voor je voorbereidingen, dat ook doen.
Voor een klein bedrijf is het moeilijk af te stappen van één server die het totale webverkeer moet zien te trotseren. “Als het budget niet groot is, dan is één server vaak het maximum haalbare”, stelt Bart Stoffels vast. “Die server kun je natuurlijk zo zwaar als mogelijk maken, maar als de beschikbare middelen eenmaal vollopen is het definitief afgelopen en gaat de site down.”
Op zich is het vreemd. Bij grootschalige ticketverkoop à la Tomorrowland of Pukkelpop blijft een site doorgaans in de lucht. Terwijl bij de eerste de beste online-inschrijving voor een jeugdkamp de server plat gaat. Waar zit het verschil?
Webwinkels niet bereikbaar tijdens bezoekerspieken
Eén week was de opgetelde periode, gemeten tussen midden november en midden januari, dat veertig Belgische webwinkels in totaliteit onbereikbaar waren. Zo blijkt uit onderzoek van Internetvista.
Enkele van de gecontroleerde sites faalden door het sterk gestegen bezoekersverkeer tijdens het internetshoppen. Dat was het geval bij Nespresso (14 uur storing in totaal gedurende deze twee maanden), bij NewPharma (17 uur) en Mediamarkt (10 uur). "Omdat zij geen server hadden die de massieve verkeerspieken aankon, hebben deze bedrijven wellicht tal van klanten gemist die op dat moment hun aankopen deden", zegt Cédric Braem van Internetvista.
Internetvista legt met zijn onderzoek de vinger op de wond, maar vertelt slechts één deel van het verhaal. Want constante online beschikbaarheid, dus ook bij piekverkeer, gaat verder dan het aanbieden van een extra server. We vroegen enkele hostingspecialisten naar hun antwoord op bezoekerspieken.
1. Werkverdeling
Een eerste antwoord bij piekverkeer is natuurlijk te verwachten: de cloud. Je valt terug op en beschikt over een pool van computersystemen die de toename in bezoekers kunnen opvangen. “Cloud is een belangrijke sleutel”, geeft David Geens van hostingbedrijf Nucleus toe. “In die zin dat je de cloud ziet als een verzameling van hardware waarin snel geschaald kan worden.”
Naast de beschikbare hardware, komt het erop aan om het werk ertussen goed te verdelen. Een van de termen die in deze context het meest vallen, is loadbalancing. Vrij vertaald: ervoor zorgen dat het verkeer netjes wordt verdeeld over meerdere beschikbare systemen.
“Een van de beste manieren om grote bezoekerspieken op te vangen, is via een clusteromgeving”, haalt Bart Stoffels, technical accountmanager bij Priorweb aan. “Daarbij verdeelt een zogenaamde loadbalancer het verkeer over verschillende zogenaamde webnodes. Hoe meer webnodes je voorziet, hoe groter de pieken die je kunt opvangen”, stelt hij.
Bij efficiënte werkverdeling hoort ook een optimaal gebruik van de beschikbare systemen. Of om het met een cliché te zeggen: niet alleen de kwantiteit (hoeveelheid hardware), maar ook de kwaliteit (hoe je ermee omspringt).
Je gaat bijvoorbeeld data af en toe in het geheugen bewaren. “Je kiest dan voor zogenaamde caching waar mogelijk. Ook al moet dat in een shopomgeving met tickets wel goed afgescheiden zijn en onderzocht worden”, stelt Jimmy Cappaert van Combell, die er nog enkele andere tips aan toevoegt. “Je moet ook een schaalbare oplossing bouwen, met zogenaamde cold standby.” Hierbij wordt infrastructuur ter beschikking gesteld die kan ingeschakeld worden bij het falen van de zogenaamde ‘primaire’ systemen. En hij vervolgt: “Serverfuncties, zoals dus via caching of de databank, kan je ook het best zo veel mogelijk splitsen. Op die manier kan je hier ook weer optimaliseren.”
2. Architectuur
Het aantal servers is één verhaal, de achterliggende architectuur een andere. “Grootschalige systemen zijn alleen maar goed te hosten als je als systeembeheerder betrokken bent vanaf het begin. Liefst zelfs al bij het uittekenen van de architectuur. Zo kan je de ontwikkelaars helpen bij bepaalde keuzes en kan je systemen en code op elkaar afstemmen”, stelt David Geens.
Doordat er moet kunnen worden omgegaan met onverwachte groei, is het van belang dat het systeem schaalbaar is. “Als je gewoon een site of applicatie schrijft zonder oog te hebben voor schaalbaarheid, loop je als site-aanbieder altijd vast”, weet Geens.
Er zijn twee verschillende vormen van schaalbaarheid, die bekendstaan als scale-up en scale-out. Scale-up is het uitbreiden van de hardware, zoals het plaatsen van extra capaciteit. Dit vormt meestal niet veel extra implicatie voor de software-implementatie. Scale-out is daarentegen het distribueren van de serverload over meerdere machines. “Hoeveel middelen je er ook tegenaan gooit in de cloud. Je kan niet blijven upscalen, je moet ook op een gegeven moment gaan outscalen, en een goeie outscaling kan alleen als de code daarop voorzien is.”
Efficiënte code en een doordachte dataflow kunnen het gebruik van de serverresources flink inperken, zodat minder snel het plafond bereikt wordt. “Vaak is het ook een kwestie van waar een bedrijf in kan of wil investeren: in ontwikkelaars en tools om de code te optimaliseren, of in zwaardere servers?” oppert Bart Stoffels van Priorweb. “In het ideale geval doe je natuurlijk beide.”
3. Testen
De derde remedie is het constant testen. Dat kan op diverse vlakken. “Denk maar aan een geschikte monitoring en logging”, aldus Jimmy Cappaert van Combell. Het testen gebeurt eigenlijk gedurende het hele parcours, en dus niet alleen als je systeem al live staat. “Tijdens de ontwikkeling al regelmatig loadtesten doen, leert heel veel en zorgt voor tijdige bijsturing”, oppert Geens.
4. Budget
De vierde factor zijn de financiële middelen. Want de drie remedies hierboven hebben budgettaire implicaties. Ook al is het verhaal in de cloud dat je alleen betaalt voor het verbruik. Maar als het aantal bezoekers gigantisch toeneemt zal de prijs, ook voor je voorbereidingen, dat ook doen.
Voor een klein bedrijf is het moeilijk af te stappen van één server die het totale webverkeer moet zien te trotseren. “Als het budget niet groot is, dan is één server vaak het maximum haalbare”, stelt Bart Stoffels vast. “Die server kun je natuurlijk zo zwaar als mogelijk maken, maar als de beschikbare middelen eenmaal vollopen is het definitief afgelopen en gaat de site down.”