Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter
50 gange mere load på en dag.
Det var vores realitet, da kampen om Gamestop-aktien var på sit højeste. Vi har haft sved på panden, og vi har løbet stærkt.
Men selv midt i kampens hede, stod vi fast - med et system der ikke fik det hele til at briste.
Efterfølgende står nu særligt én læring helt klart for mig: Byg systemet til skalerbarhed
Public.com blev grundlagt for tre år siden, og vi har hele tiden haft høje vækstrater.
Alligevel kan man bogstavelig talt sige, at brugerne væltede ind i forbindelse med stormløbet på Gamestop-aktien.
Se bare grafen her over antal request, og stort set alle metrics ser sådan ud.
Vi har heldigvis altid været meget ambitiøse og har nu har rundet en million brugere på vores sociale investeringsplatform.
Så vi har fra begyndelsen bygget cloud native med teknologier, der skalerer horisontalt.
Vi kører SpringBoot microservices docker på Amazons ECS Fargate platform. Hvis du ikke kender ECS, så tænk på det som en Kubernetes, der blot er managed af skyen.
På en normal dag ligger vi på 30 docker-instanser, og da vi fornemmede, at aktiviteten ville stige lodret, skalerede vi ud til 275 kørende docker-containere for at være sikker på, at vi ikke ville gå ned på ressourcer.
Vores database er en blanding af SQL, NoSQL og graph databaser.
Til endpoints med massivt load anvvender vi Amazons DynamoDB NoSQL, der skalerer ekstremt godt og som på intet tidspunkt var presset under den voldsomme stigning i trafikken.
Vi har faktisk en DynamoDb NoSQL database med 1,5 milliarder rækker, som performede perfekt under load.
Skalerer godt
Til vores sociale algoritme anvender vi en Neo4J graph database, der er super god til at svare på spørgsmålet om, “hvilket feed er mest interessent for hver enkelt bruger på platformen”.
Neo4J skalerer godt, men den blev ustabil i løbet af dagen.
Heldigvis havde vi forudset, at Neo4J kunne være en flaskehals, og vi havde circuit breakers på plads.
Så nogle af brugerne så et lidt mindre optimalt feed på den sociale del af platformen. Men det er trods alt bedre end at vise en fejl skærm.
En anden vigtig ting i en platform er at have god indsigt i produktionsmiljøet.
Da alarmen for Neo4J database circuit breakeren gik, fik vi ret hurtigt tilført flere ressourcer, så alle igen kunne få et optional feed skræddersyet til dem.
Vi er også for et par måneder skiftet fra Datadog til overvågning, og jeg må sige, at jeg er glad for det valg.
Noget nær perfekt indsigt
Vi havde nær perfekt indsigt i produktionsmiljøet i de dage med mest vækst.
Nogle af de problemer, vi havde set med den tidligere platform, oplevede vi ikke. Vi kunne hurtigt få svar på de spørgsmål, vi havde og blev gjort opmærksom på de ting, der trodsalt gik galt.
Men der dukkede flere problemer op i løbet af dagen.
Vi har kun kunder på det amerikanske marked, og i USA har man ikke Nemid.
Så fordi håndterer brugernes penge, er det første skridt i vores onboarding af brugere, at vi sender en SMS med en kode, som bruges til two-factor-authentication.
Og med 10.000 nye brugere hver time begyndte fik vi at få en alarm på, at en stor procentdel ikke modtog SMS-koden.
Teleudbyderen var begyndt at blokere
Efter noget fejlsøgning fandt vi ud af, at teleudbyderen var begyndt at blokere vores SMS’er, som vi sender gennem en ekstern service.
Det er den slags ting, der er meget svære at teste i en loadtest. For vi har ikke lige 10.000 telefonnumre, vi kan sende en SMS til. Det var ikke alle SMS’er, der blev blokeret - kun 10-15 procent.
Vi fandt en løsning, men det krævede, at vi skulle ændre koden og pushe et nyt build til produktion.
Heldigvis har vi en fuldt automatiseret build og deployment pipeline, og vi deployer kode til produktion hver dag.
Pipelinen er bygget på en blanding af GitLab, AWS Codebuild, Terraform og en masse docker containers.
I løbet af halvanden time fik vi ændret koden, så vi anvendte den nye løsning, fik testet det i vores staging-miljø og skubbet det til produktion.
Deployment til produktion i prime hours er et non-event for os.
Gennemtestet pipeline
Vi deployer ofte til produktion, når der er mange brugere på platformen. Det er simpelt hen et krav, når vi bygger software.
Og siden vi deployer til produktion hver dag, har vi en gennemtestet pipeline, og jeg rystede ikke på hånden over at skulle deploye med massivt load.
Havde vi haft en mere traditionel deployment, hvor der kun kan skubbes ting i produktion lørdag nat, så havde vi haft et massivt problem.
En ting er, at nye kunder ikke kan komme ind i butikken. Noget helt andet er, hvis en eksisterende kunde ikke kan logge på, fordi kunden anvender two-faktor-authentication til at logge in og sælge aktier i et meget volatilt market.
Det kan føre til, at vi får et problem med banktilsynet.
Så derfor var vi tvunget til enten at fikse problemet eller lukke for inflow af nye kunder. Derfor var jeg utrolig glad for, at vi kunne fikse problemet hurtigt.
Vi har lært en masse af dette load og kan nu bygge vores system endnu bedre, så vi er klar til næste runde.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.
