Multi-region failover-arkitektur i GCP för svenska e-handlare.
För en e-handlare är nertid inte ett tekniskt problem utan förlorad försäljning, i realtid. En kund som möts av en felsida köper hos någon annan. Därför är multi-region failover en av de tydligaste investeringarna en växande e-handel kan göra. Den här artikeln beskriver en praktisk arkitektur i Google Cloud för en svensk e-handlare som vill överleva ett regionavbrott utan att kunden märker det. Jag håller det konkret.
Börja med kraven, inte med tekniken
Innan något byggs behöver två tal sättas. Hur länge får butiken vara nere innan det måste vara tillbaka, och hur mycket data får förloras vid ett avbrott. För en e-handel är båda oftast korta - en order som tappas är en missnöjd kund. De här kraven styr hur långt du behöver gå, för full multi-region kostar och ska motiveras av vad ett avbrott faktiskt kostar i utebliven försäljning.
Global lastbalansering som fundament
Grunden i GCP är den globala lastbalanseraren. Den tar emot trafik på en enda adress och dirigerar den till närmaste friska region, med hälsokontroller som upptäcker när en region slutar svara. Det här är det som gör failover möjlig utan att kunden behöver göra något - trafiken styrs automatiskt om från en sjuk region till en frisk. För en svensk e-handlare med kunder främst i Norden ger det dessutom lägre latens i normalläget.
Det eleganta med den globala lastbalanseraren är att den döljer hela komplexiteten bakom en enda adress. Kunden, och er DNS, behöver aldrig veta hur många regioner ni kör i eller vilken som för tillfället tar emot trafiken. När en region blir sjuk slutar hälsokontrollerna att skicka trafik dit, och allt fortsätter mot de friska - utan att någon behöver agera och utan att kunden märker mer än möjligen en kort knyck. Det är den automatiken som skiljer en verklig failover från en plan som kräver att någon vaknar och trycker på en knapp mitt i natten.
Applikationslagret: kör aktivt i flera regioner
Själva applikationen vill jag köra aktivt i minst två regioner, inte som en kall reserv. Med tjänster körda i flera regioner och lastbalanseraren framför finns det alltid en frisk kopia att dirigera till. Statslösa tjänster gör det här enkelt - de kan köras var som helst. Det som kräver omsorg är tillståndet, alltså datan.
- Kör applikationen aktivt i flera regioner, inte som kall standby.
- Håll tjänsterna statslösa så de kan dirigeras fritt.
- Lägg ett CDN framför statiskt innehåll för fart och avlastning.
Skälet att köra aktivt-aktivt snarare än med en kall reserv är att en reserv du sällan använder sällan fungerar när den behövs. En region som står varm och tar emot trafik dagligen är bevisat frisk, medan en kall miljö som ska startas i panik mitt under ett avbrott är full av obehagliga överraskningar. Att fördela trafiken över båda regionerna i normalläget innebär dessutom att en bortfallen region bara halverar kapaciteten i stället för att slå ut allt, vilket ger marginal att hantera lasten medan ni återställer.
Datalagret är den svåra delen
Failover av applikationen är enkelt jämfört med datan. En order får inte tappas, och två regioner får inte hamna i osynk. Här använder jag GCP-tjänster med inbyggd replikering över regioner - exempelvis en databas som replikerar synkront eller med mycket kort fördröjning. Avvägningen mellan hur snabbt data replikeras och hur mycket prestanda det kostar är central, och den styrs direkt av ditt krav på hur mycket data som får förloras. Det här är där arkitekturen står och faller.
Det avgörande: testa failover på riktigt
En failover-arkitektur som aldrig testats är en förhoppning, inte en plan. Jag testar regelbundet att stänga av en region och verifierar att trafiken styrs om, att ingen data tappas och att tiden ligger inom kravet. Nästan varje första test avslöjar något - ett beroende ingen tänkte på, en cache som pekar fel, en process som tar längre tid än antaget. Bättre att hitta det under ett planerat test än under en skarp incident en Black Friday. Hur jag tänker bredare kring detta finns i min genomgång av disaster recovery.
Relaterat
- Terraform vs Pulumi vs OpenTofu: Migrationsguide efter HashiCorp-licensskiftet
- Sovereign cloud i Sverige: Bahnhof, Glesys och Elastx för NIS2-compliance
- Kubernetes på EKS vs GKE vs AKS: Driftkostnad och developer experience
Vill du ta det vidare?
Vill ni bygga en e-handel som överlever ett regionavbrott hjälper jag er med arkitekturen - och med att testa att den håller. Läs om min molninfrastruktur, se exempel i casebook, eller boka ett samtal.
“En failover-arkitektur som aldrig testats är en förhoppning, inte en plan.”
- Simon Axelsson
Vanliga frågor
- Behöver vår e-handel verkligen multi-region?
- Det beror på vad ett avbrott kostar. För en e-handel där nertid är direkt utebliven försäljning är multi-region ofta en tydlig investering. För mindre volymer kan en enklare nivå med snabb återställning räcka. Låt kostnaden av avbrott avgöra.
- Vad är svårast i en multi-region-arkitektur?
- Datalagret. Att dirigera om trafik är enkelt, men att se till att ingen order tappas och att regionerna inte hamnar i osynk kräver replikering med en medveten avvägning mellan hastighet och prestanda. Det är där arkitekturen står och faller.
- Hur ofta bör vi testa failover?
- Regelbundet, och alltid inför en högtrafikperiod som Black Friday. Ett planerat test avslöjar nästan alltid något oväntat - ett beroende, en felpekande cache, en process som tar för lång tid. Det är mycket bättre att hitta det då än under en skarp incident.
Simon Axelsson är senior IT-konsult och grundare av SIAX Technology AB. Han hjälper nordiska företag med molninfrastruktur, dataplattformar och AI-automation.
Fler artiklar
