Op 18 november had Cloudflare een incident dat duizenden klanten trof, waaronder klanten die gebruikmaken van onze dienst. Onze proxyservice draait op AWS in een ultra high availability-architectuur, die niet werd getroffen (ook niet door de recente AWS-storing). We hebben ons systeem ook zo ontworpen dat het bestand is tegen gecentraliseerde storingen en dat de impact op klanten beperkt blijft als er toch iets uitvalt.
Het incident duurde ongeveer 5 uur en 34 minuten, van het moment van uitval tot volledige oplossing (we zagen herstel al na ongeveer 3 uur). Onze incidenttijdlijn is hier te bekijken.
We willen een aantal interessante observaties tijdens de storing bespreken en enkele details over onze architectuur toelichten die de impact op onze klanten hebben beperkt.
Interne observaties + hoe we de impact voor klanten beperkten
Omdat onze proxy en interne verwerkingspipeline op AWS draaien, ondervonden onze kritieke processen geen enkele hinder. Ons dashboard is echter gehost op Cloudflare, waardoor dat wel werd getroffen — net als de meeste websites op het internet. Omdat we Cloudflare gebruiken voor hosting (Cloudflare Workers/Pages/etc.) en niet alleen voor proxying, konden we de storing niet eenvoudig omzeilen door DNS om te leiden. Bovendien zijn veel upstream-diensten op de een of andere manier afhankelijk van Cloudflare. Als je op zoek bent naar goedkope assetdistributie via een CDN, kom je al snel bij Cloudflare uit.
Upstream-storingen
Vanuit ons perspectief konden we de storing waarnemen via upstream-servers. We zagen een groot aantal 5XX-fouten van servers die door de Cloudflare-storing werden getroffen, via onze proxy. We ontvingen hier ook meldingen over, en je kunt zien dat het tijdstip van de toename in fouten vrijwel exact overeenkomt met het moment waarop de Cloudflare-storing begon om 11:48 UTC.
Omdat onze proxy via AWS load balancers loopt en we dezelfde HTTP-respons teruggeven als de upstream scriptbronnen, beschikken we over alle meetgegevens wanneer dit soort storingen zich voordoen. Dit is een voordeel van het routeren van verkeer via ons systeem: we kunnen storingen als deze direct waarnemen en onze klanten informeren over de impact.
Hoe we scripts bleven serveren tijdens de storing
We cachen verzoeken voor identieke scripts wanneer het cachingbeleid (Cache-Control) dit toestaat. In dit geval waren scripts die op Cloudflare werden gehost nog steeds beschikbaar en zouden dat blijven totdat de cache werd ongeldig gemaakt. Dit is een voordeel van het gebruik van de cside-proxy.
Hieronder een screenshot van ons interne Grafana-dashboard met onze scriptmetrieken tijdens de storingsperiode.
Tijdens de storing: het dashboard toont een cache-hitrate van 70,8%, wat betekent dat veel scripts nog steeds werden geserveerd die anders mogelijk onbereikbaar waren geweest.
Normale basislijn: dit percentage ligt dicht bij ons gebruikelijke niveau. Op 17 november was de gemiddelde cache-hitrate bijvoorbeeld 74%, wat betekent dat we nog steeds het gebruikelijke aantal gecachede scripts serveerden.
Het totale aantal verzoeken nam echter wel af.**
cside is ontworpen om grootschalige storingen op te vangen
Dit soort grootschalige storingen is onvermijdelijk vanwege de gecentraliseerde aard van cloudproviders, maar we doen er alles aan om de impact te beperken door onze proxy in meerdere regio's te deployen en een "Fail Open"-architectuur te hanteren, zodat verzoeken blijven doorlopen zelfs als alles uitvalt.
Het is ook belangrijk te vermelden dat onze edge-services zijn ontworpen om in een "geïsoleerde" modus te werken als onze gecentraliseerde pipeline uitvalt. Dit betekent dat onze proxy operationeel blijft en verzoeken voor scripts kan blijven ontvangen en beantwoorden, ook als we geen verbinding kunnen maken met dat systeem. Het uitvallen van een gecentraliseerd systeem kan dus by design niet alle edge-nodes tegelijk platleggen.
Een uitleg van hoe onze architectuur voorkomt dat sites uitvallen, is hier te lezen.
De Cloudflare-blogpost hier gaat ook uitgebreid in op de details en is zeker de moeite waard om te lezen.
Een kanttekening over foutafhandeling:
- De oorzaak van de Cloudflare-storing bleek te maken te hebben met een specifieke foutmodus in Rust-programma's die gebruikmaken van
.unwrap()-aanroepen, wat de 500-fouten veroorzaakte die we zagen. Wij gebruiken deze functie helemaal niet in onze proxycodebase, die ook in Rust is geschreven.
cside bestaat uit een team van ervaren distributed web-engineers. Van kernbijdragers aan browsers zoals Servo, voormalige Cloudflare-engineers tot vroege open source-bijdragers aan Tailwind en Bootstrap. We geven om het web; we behandelen onze infrastructuur en architectuur als een kunstwerk. We waarderen bedrijven zoals Cloudflare die diepgaande details over incidenten delen, en we hebben daar gedurende onze carrières van geleerd om ze waar mogelijk te voorkomen.
