Der var Black Week i gang for alvor! Folk kommer stormende gjennom de digitale dørene, og mange handler mye på kort tid.
Publikum tar det for gitt at dette skal gå smertefritt, men hva med de som skal levere løsningen? Har nettbutikkene gjort de nødvendige tiltakene for at systemene skal tåle lasten? Eller har de lukket øynene og biter negler på kryssede fingre?
Black Friday har i mange år skapt trafikk-kork både fysisk og digitalt. Black Friday har blitt til Black Week og Cyber Monday. Dette har spredd trafikken utover en lengre tidsperiode, som også er vanlig for andre store begivenheter. For eksempel har det blitt innført forhåndsstemming vet Stortingsvalg for å unngå lange køer på valgdagen.
Utviklere overraska over Elkjøps black friday-kø
Men er spredning av trafikken et tilstrekkelig grep for å håndtere den årlige handle-bonanzaen?
Jeg har tidligere jobbet med systemer som skal ta imot stor last på kort tid, der konsekvensen av å være ett minutt forsinket er nyhetsoppslag og full krise. Mange møter nok tilsvarende utfordringer i forbindelse med Black Friday.
Her er mine tips for å unngå nyhetsoppslag eller andre ubehageligheter.
#1: Utbedre observerbarheten
Observerbarhet handler om å kunne forstå den interne tilstanden til et system. Dette muliggjør læring på et helt annet nivå enn man får ved å bare observere systemet fra utsiden.
Alle de store skyplattformene har god støtte for observerbarhet. Mange plattformleverandører tar seg imidlertid godt betalt for denne tjenesten, så det kan være lurt å vurdere gratis alternativer. Da er et oppsett basert på OpenTelemetry et godt valg.
Grafiske fremstillinger av ting som feilrater, svartider og ressursbruk gjør at dere er mye bedre rustet til å forstå hvordan det står til med systemet. Det å kunne peke på en graf og diskutere denne har en enorm kraft, og veien fra symptom til rotårsak blir med ett mye kortere.
BankID stenger ned i 9 timer – «for vedlikehold»
#2: Gjør lasttesting
Lasttesting er en type ytelsestester der fokus ligger på å legge last på systemet og observere hvordan det responderer.
Det finnes masse spesialiserte verktøy for å gjøre dette. Jeg bruker som regel k6. Grunnen til det er at testene kan kodes i javascript, at jeg har gode løsninger for å tegne grafer og at jeg har muligheten til å kjøre de samme testene i en skyløsning. Da kjøres testene på utsiden av egen infrastruktur.
- Det er lurt å lage tester som mest mulig realistisk følger brukerreisen. Da møter du flaskehalsene i samme rekkefølge som brukeren, slik at du løser det viktigste først. Det er for eksempel lite å hente på lynraske endepunkter når forsiden ikke laster.
- Det er lurt å ha en formening om hvor mye last man kan forvente. Å ta utgangspunkt i tall fra fjorårets Black Friday, og triple dette for å sette maksimal last, er et godt utgangspunkt. Det er også hensiktsmessig å kjøre knekkpunktstester. Dette er tester der lasten skrus opp over tid, for å finne det punktet der systemet ikke klarer å ta unna trafikken – systemet går i metning. I denne tilstanden vil mye slutte å fungere. Dette er en veldig god mulighet til læring.
«Husk at flaskehalsen kan ligge før dere i løypa.»
Det ligger mye informasjon i måten systemet feiler på. Henter systemet seg inn av seg selv, eller trenger det hjelp med å komme i gang? Under høy last vil typisk enkelte deler at systemet være overarbeidet og andre deler ha lite å gjøre. De delene som bruker lite ressurser, ligger bak flaskehalser.
For å flytte flaskehalsene bakover, kan ressursene skaleres ut eller opp. Etter å ha gjentatt tester og skalering flere ganger, kommer det til et punkt der ut- eller oppskaleringen ikke lenger påvirker resultatet.
Hvis det fremdeles er behov for økt kapasitet, må man se på andre løsninger for å komme videre. Kanskje trengs det en gjennomgang av arkitekturen eller kanskje skaper et eksternt endepunkt problemer? Husk at flaskehalsen kan ligge før dere i løypa. For eksempel, kan trafikkrutingen inn i Kubernetes-clusteret være skalert for lavt, slik at trafikken som treffer applikasjonene allerede er strupet.
Stenger i to uker, for oppdatering
#3: CDN – sikkerhet og HTTP-caching
Content Delivery Network (CDN) er et distribuert nettverk av noder plassert i datasentre rundt om i verden. Disse tilbyr caching nær brukeren, og kan derfor ta ned tiden det tar å laste nettsiden eller få svar på en HTTP-forespørsel.
Her ligger det et stort potensial for forbedring om man lærer å utnytte det. Det er aldri bortkastet å bruke tid på å lære seg HTTP skikkelig. Man bør gjøre en gjennomgang av hva man cacher, og forsikre seg om at CDN er satt opp til å respektere cache headere.
Hvis det er noen endepunkter som er spesielt trege eller som legger høy last på systemet, er dette gode kandidater for caching.
Alle de store CDN-leverandørene tilbyr brannmur («Web Application Firewall»). Dette skåner system ditt for masse uønsket trafikk. I tillegg bør dere å sette opp regler for å begrense trafikken («rate limiting»).
#4: En siste runde med lasttesting
Etter at cachingen er oppdatert, er det på tide med en ny runde med testing.
Disse testene bør bekrefte at personspesifikk data ikke blir tilgjengelig på tvers av kontekster. I tillegg vil cachingen kunne flytte på flaskehalser, som gjør at noen deler av systemet må skaleres ytterligere.
Jeg håper disse rådene er nyttige for å få full kontroll, slik at man slipper å frykte at Black Friday ikke blir en braksuksess!
