Digitalt kundevent med hängslen och livrem

Digitalisering i många former har tagit ordentlig fart under Corona-pandemin. Många av oss på C.A.G sitter mitt i epicentrum för detta. Här följer en war-story från ett av våra team.

Digitalt kundevent med hängslen och livrem

Digitalt kundevent med hängslen och livrem 1949 1016 C.A.G

I våras ställdes vi inför en situation där vi tillsammans med vår kund skulle skapa ett IT-system för att kunna köra årets stora kundevent helt digitalt. Eventet brukar dra beslutsfattare hos många av företagets kunder över hela världen och har aldrig körts helt digitalt förut. Vi hade några månader på oss.

Vi har alltså ett nyutvecklat mjukvarusystem, vars hela värde ligger i att det ska köras en enda gång, under ett par timmar. Det måste fungera just då och just bara denna gång, annars är det helt värdelöst – och tyvärr inte bara helt värdelöst utan mycket sämre än det, eftersom ett misslyckande skulle slösa bort många upptagna människors tid och få vår kund att stå i sämre dager gentemot såväl kunder som marknad.

Detta är tvärtemot mjukvaruutvecklingens – och människans – natur, med iteration, tid för observation, reflektion och planering, tester med vänligt sinnade användare, stegvist införande och korrigeringar.

Allt sådant måste alltså ske innan.

“En sak till, pengar och resurser är ingen begränsning. Bara det funkar.”

Inte blir man väldigt mycket lugnare av det.

Eftersom vi till vardags utvecklar och driftar applikationer på Kubernetes i Google Cloud och Azure, så föll valet på att inte stöka till det, och därför köra något vi känner väl, en webbapp på Kubernetes i Google Cloud, där kan vi av erfarenhet garantera riktigt bra driftsäkerhet.

 

Ökad driftsäkerhet

Vi utforskade våra möjligheter att ytterligare öka driftsäkerheten.

Google Cloud är uppdelat i regioner, till exempel ligger regionen europe-west2 i London, och europe-west3 i Frankfurt, och varje region är uppdelad i typiskt tre zoner.

Ett sätt att öka driftsäkerheten är att lägga det i flera zoner samtidigt, och konstruera det så att det klarar av att fortsätta köra så länge minst en zon är uppe.

 

Flera zoner

Om vi sätter upp ett så kallat multi-zonal kluster och placerar det i minst två olika zoner så kommer våra applikationer alltså inte att gå ned om en zon går ned.

Ett kluster kontrolleras emellertid från en av zonerna (via klustrets så kallade control plane), vilket innebär att om man måste göra ändringar i systemet, till exempel ändra någon parameter i systemet eller i infrastrukturen, så skulle dessa möjligheter bli spärrade om just den zonen skulle gå ned där klustrets control plane ligger. Vi är beroende av detta control plane för alla sorters ändringar i såväl applikation som infrastruktur – vi kör allt inklusive kod, infrastruktur och parametrar versionshanterat och med central standardiserad deployment.

Vår deployment pipeline

Att riskera att tappa kontrollen på sitt kluster är inte bra så bra, så vi kollade vidare.

Om vi ska säkra upp klustrets så kallade control plane kräver det att vi sätter upp ett regional kluster. Ett sådant skulle kunna täcka upp för situationen att en eller flera zoner tappas. Det har aldrig hänt under alla år för något av våra system i Google Cloud så vitt vi känner till. Men tänk om det händer för första gången just där och just då och vi hade kunnat undvika det genom att sätta upp ett sånt?

Vi kollade hur det skulle gå till men bedömde att det var så många rörliga delar involverade, att bara det skulle innebära en markant ökad risk för strul. Det är två universella krafter som balanserar varandra här, den ena kraften är lösningar för redundans, där mer eller mindre komplexa lösningar täcker upp för alla möjliga sorters felfall i alla möjliga delsystem. Den andra kraften är komplexitet. Högre komplexitet innebär i större risk att något går sönder, och det blir svårare och tar längre tid att laga när det väl går sönder. Högre redundans innebär också högre komplexitet.

Vi hade i minnet att en av Googles centrala tjänster (IAM) tidigare i år gick sönder under ett par timmar, vilket hade påverkan i hela världen. Så även om vi tar oss tiden och besväret med att sätta upp ett regional kluster så är vi fortfarande oskyddade om denna situation, som faktiskt hände oss nyss, händer igen.

 

Flera moln

Vi valde istället att sätta upp ett backupsystem i Azure, alltså helt skilt från Google Cloud. Vi satte Cloudflare framför alltsammans, som normalt styr trafiken till Google Cloud, men om det slutar svara slår det över helt automatiskt till systemet i Azure.

Och vad händer om lastbalanseringen i Cloudflare krånglar då? Då når vi varken systemet i Google Cloud eller i Azure.

För att skydda oss från detta satte vi dessutom upp en statisk version av systemet direkt i Cloudflare som vi kan slå över till om allt annat är trasigt. Det har inte all funktionalitet, men det är i alla fall något där som möter kunderna.

Det enda som nu skulle kunna slå ut oss helt vore om vår DNS-tjänst gick ned, men då kan vi å andra sidan ingenting göra.

Vi landade alltså i en lösning som utgjorde både livrem och hängslen, med ett par extra kortbyxor i reserv.

Hur gick det då? Fungerade det?

Ja, applikationen fungerade klockrent, Google Cloud tickade på som en klocka hela den förmiddagen och backuplösningarna behövde aldrig aktiveras.

Vi var många som kunde andas ut.

 

Epilog

En fredagseftermiddag en tid efter kundeventet, närmare bestämt den 18:e juli, hände precis det som var nästan det enda som skulle kunna ha slagit ut oss helt, när Cloudflares DNS gick ned och var nere i 25 minuter. En router i Atlanta slutade fungera och tog med sig stora delar av internet ned. Endast en fysisk sammankomst och en gammal overheadprojektor skulle kunna ha räddat oss.

Kontaktperson

Daniel Marell

+46 70 563 10 52

daniel.marell@cag.se

Kontaktperson

Annika Rogneby

+46 70 687 33 08

annika.rogneby@cag.se

    X
    X