Når redundans ikke rækker: Jernbaneudfaldet og afhængigheden af control plane

Multi-cloud: Mere spredning er ikke nok

Mange tror, at multi-cloud automatisk giver høj tilgængelighed. Fordeler du dine workloads over flere udbydere, skulle du være sikret mod udfald hos én enkelt leverandør. Logikken er fornuftig – indtil den ikke er det.

Railway er et eksempel på netop det. De havde kørt applikationer på både AWS, Google Cloud og deres egen hardware. Alligevel gik det galt. Ikke på grund af en reel infrastrukturfejl hos Google, men fordi en automatiseret sikkerhedsproces fejlagtigt suspenderede deres konto. Resultatet: Otte timers nedetid.

Det mest overraskende var, at selve applikationerne faktisk kørte videre. Problemet lå et andet sted.

Hvorfor kontrolplanet er afgørende

Når trafik rammer en Railway-applikation, går den først gennem edge proxies. Disse proxies skal vide, hvor hver enkelt app befinder sig. Den viden kommer fra et kontrolplan – en slags database over, hvor workloads er placeret.

Hos Railway lå dette kontrolplan udelukkende på Google Cloud. Som GCP’s automatiserede systemer lukkede kontoen, forsvandt den centrale styring. Proxiesne havde godt nok cachet routing-information i cirka 35 minutter, men når den udløb, kunne de ikke længere finde vej. Alle requests endte i 404.

Sekundære fejl fører til yderligere nedetid

Da fejlen først var indtruffet, udløste den en kædereaktion. Den høje mængde mislykkede requests førte til rate limiting hos GitHub på Railway’s OAuth-endpoints. Det var ikke en fejl hos GitHub – det var sikkerhedsforanstaltninger, der fungerede korrekt. Men effekten var at brugere ikke længere kunne logge ind eller udløse deployments.

Distributed workloads vs. distributed control

Railway havde spredt deres applikationer godt nok. Men den logik, der styrer, dirigerer og finder dem, var samlet ét sted. Det er her, forskellen ligger mellem spredt belastning og spredt styring.

Det er ikke nok, at workloads kører på tværs af flere clouds. Hvis routing og service discovery stadig afhængige af en single point of failure, er multi-cloud mesteparten af tiden kun delvist effektivt.

Hvad betyder det praktisk?

• Kontrolplan og data plane er forskellige. Spredning af workloads alene er ikke tilstrækkeligt. Du skal også spredtænke routing og orchestration.
• Caching køber dig tid, ikke sikkerhed. 35 minutters cache er bedre end nul tid, men når den udløber, er du stadig stuck.
• Kædereaktioner er svære at bryde. Når én fejl udløser rate limiting eller andre sekundære mekanismer, kan det forlænge nedetiden betydeligt.
• Forstå dine udbyderes automatiserede systemer. Du kan ikke altid forhinder en suspension, but you can have backup plans og escalationskonti, med fastlagt kontaktpersoner hos provideren.

Næste step for Railway – og dig

Railway har allerede offentligt annonceret, at de vil fjerne Google Cloud fra den kritiske del af deres data plane og udbrede deres kontrolplan på både AWS og deres egen hardware. Det er en dyr, men nødvendig, reparatur.

For dig som bygger eller vedligeholder ikke mindre infrastrukturer, er incident’en en reminder, at multi-cloud er ikke kun en konfigurati