Det er Black Week. Og selv om trenden de siste årene viser at nordmenn stort sett er på jakt etter gode tilbud hele novembermåned – ligger det fremdeles spenning knyttet til selveste Black Friday.
Har nettbutikkene gjort nødvendige tiltak for at systemene skal tåle lasten? Eller har de lukket øynene samtidig som de biter negler på kryssede fingre? Det spør Forte Digitals kvalitetsdirektør, Roger Hoem-Martinsen, som også lover ut gode råd for en smertefri Black Friday uten svarte skjermer.
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, forteller Hoem-Martinsen.
Fremst i minnet til undertegnede ligger Elkjøps Black Friday-krasj i 2019. Trafikken ble for stor, og kundene måtte gjennom dagen vente i opptil en time før de fikk gjennomført kjøpene sine. Dette skapte naturligvis frustrasjon blant kundene, men også et reelt tap på 50 millioner kroner i tapte inntekter.
Spredning av trafikken, som naturlig skjer når man introduserer ikke bare Black Friday, men også Singles Day, Black Week og Cyber Monday, er et grep for å hindre trafikkork på Black Friday. Men er det tilstrekkelig?
Synliggjør problemene
Hoem-Martinsen deler konkrete råd for å holde nettbutikkene i levende live under fredagen. Det første handler om å utbedre observerbarheten og å 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, forteller Hoem-Martinsen.
Han forteller videre at grafiske fremstillinger av ting som feil-frekvens, svartider og ressursbruk gjør at man er bedre rustet for å forstå hvordan det står til med systemet. Målet er å gjøre veien fra symptom til rotårsak betraktelig kortere.
Triple fjorårets trafikk i testingen
Neste råd på lista handler om å legge press på systemet for å observere responsen. Helst bør testene være realistiske og følge en troverdig brukerreise. Da møter du eventuelle problemer i samme rekkefølge som kunden din vil møte dem.
Det finnes masse spesialiserte verktøy for å lage og gjennomføre testene. 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, forklarer Hoem-Martinsen.
Men hvor mye last kan du forvente? Et godt utgangspunkt kan være tallene fra fjorårets Black Friday, ganget med tre.
Å 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.
Hva gikk galt, og hvordan?
Når ytelsestesten er over gjelder det å hente informasjon om hva som gikk galt, men også hvordan. Hentet systemet seg inn av seg selv, eller trenger det hjelp for å 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, sier Hoem-Martinsen.
Er det fremdeles et behov for å øke kapasiteten, råder kvalitetsdirektøren at man ser 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.
"Stort potensial for forbedring"
Råd nummer tre handler om Content Delivery Network (CDN), sikkerhet og HTTP Caching.
Hoem-Martinsen forklarer at CDN er et distribuert nettverk av noder plassert i datasentre rundt om i verden, som tilbyr caching nær brukeren. Dermed kan tiden det tar å laste ned en nettside eller få svar på en HTTP-forespørsel tas ned.
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, sier kvalitetsdirektøren, før han legger til:
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.
Dessuten kan man sette opp regler for å begrense trafikken, rate limiting, samt implementere en brannmur, web application firewall, for å hindre uønsket trafikk.
Siste runde før det braker løs
Helt på tampen er det en ny runde med testing som gjenstår.
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, sier Hoem-Martinsen, før han runder av:
Det er viktig å investere tid i å sørge for at systemet er robust. Det siste man ønsker er at kundene strømmer til uten at netthandelsløsningen fungerer. Da er tapet er størst. Jeg håper dere tar med dere noen av rådene over, så slipper dere å frykte, paradoksalt nok, at det blir for mange kunder på Black Friday.
