Robuste Architekturen für hohe Verfügbarkeit

Zu unserer freudigen Überraschung steht diese Woche die Einzigartigkeit und verteilte Architektur unserer zuverlässigen Kontrollebene im Fokus. Kein Cloud-Anbieter ist gegen Ausfälle immun, allerdings wirkt Fastly diesem Risiko gezielt entgegen, nämlich indem wir zusätzliche Ausfallsicherheit und Redundanz in unser Netzwerk, die Kontrollebene und die Datenebene integrieren. Auf diese Weise können wir uns vor katastrophalen Ausfällen schützen und proaktiv dafür sorgen, dass ein Notfall nur minimale Auswirkungen nach sich zieht. 

Getreu dem Motto #hugops fühlen wir mit unseren Kollegen in der Branche mit, die in letzter Zeit von Ausfällen betroffen waren. Für uns der schlimmste Albtraum. Wir werden oft von Kunden gefragt, wie wir an Netzwerkstabilität herangehen. In diesem Blogpost gehen wir nun genauer auf unsere Vorgehensweise ein.

Neben den erforderlichen Entscheidungen untersuchen wir auch die vor mehreren Jahren begonnene Arbeit, die Fastly so robust macht. Damit meinen wir die Ausfallsicherheit gegenüber einfach allem, von unerwarteten Ereignissen wie dem vollständigen Ausfall eines Rechenzentrums bis hin zu gängigeren Situationen wie Internetausfällen oder ausgeklügelten DDoS-Angriffen. Ausfallsicherheit bedeutet, sowohl die Kontroll- und Datenebene als auch das gesamte Netzwerk von Fastly und noch vieles mehr so zu gestalten, dass alle Aufgaben zu jeder Zeit zuverlässig ausgeführt werden können. Spätestens am Ende dieses Blogposts werden Sie verstehen, warum Netzwerkstabilität Fastlys zweiter Vorname ist. Und warum Redundanz für uns Alpha und Omega darstellt. 

Verteilte Lösungen beugen Single Points of Failure vor

Zwei wesentliche Prinzipien, die wir auf der gesamten Fastly Plattform berücksichtigen, sind die Entwicklung verteilter Systeme und die Beseitigung von Single Points of Failure. 

Vor etwa drei Jahren führte Fastly einen formellen Prozess zur kontinuierlichen Bewertung und Stärkung unserer Architektur ein, der von einem funktionsübergreifenden internen Team namens Fastly Reliability Task Force (RTF) geleitet wird. Die RTF trifft sich regelmäßig, um die für die Plattform existenziellen Risiken zu analysieren, zu bewerten, zu erörtern und nach Prioritäten zu ordnen. Dieses Gremium hat entscheidend dazu beigetragen, wichtige Verbesserungen voranzutreiben, und berät ständig über die nächsten Schritte. Der Anstoß für die Gründung der Task Force war unter anderem die Erkenntnis, dass ein Stromausfall im Rechenzentrum Fastly (in der Vergangenheit) möglicherweise schlimm getroffen hätte. Um die von uns identifizierten Risiken in Angriff zu nehmen, starteten wir eine (wahrlich) gigantische unternehmensweite Initiative, die wir aus zwei Gründen liebevoll „Cloudvolution“ tauften. Zum einen, weil wir die Art und Weise, wie wir unsere gesamte Plattform betreiben, revolutionieren und eine robustere Multi-Cloud- und Multi-Region-Architektur schaffen wollten. Und zum anderen, weil wir nie gedacht hätten, dass wir diesen Namen jemals öffentlich teilen würden, und alberne Namen manchmal einfach lustig finden. Nicht alles braucht immer ein Akronym.

Ausfallsicherheit auf Kontroll- und Datenebene

Im Rahmen von „Cloudvolution“ sollten sowohl unsere Kontroll- als auch unsere Datenebene gestärkt und die Verfügbarkeit von zentralen Plattformservices erhöht werden, um die Ausfallsicherheit der Plattform zu gewährleisten. Ein Hauptziel war die iterative Weiterentwicklung von Systemdesignabstraktionen, um die Netzwerkstabilität zu verbessern, Services klarer abgrenzen zu können und uns hinsichtlich Skalierung auf den nächsten (und weitere) Wachstumsschritte vorzubereiten. Im Wesentlichen strebten wir nach weniger Abhängigkeiten, geringerem Risiko, weniger Points of Failure und mehr Ausfallsicherheit. 

Wir wussten, dass unser Service infolge dieses Architektur-Upgrades künftig auch im Katastrophenfall zuverlässig ausgeführt würde. Und so sind unsere Kontroll- und Datenebene heute Multi-Cloud und Multi-Region. Wir haben viel dafür getan, dass Fastly nicht von einem einzigen Rechenzentrum, einer einzigen Verfügbarkeitszone oder einem einzigen Cloud-Anbieter abhängig ist. Unsere Kontrollebene wird in zwei unabhängigen und geografisch voneinander getrennten Regionen betrieben, wobei bei Bedarf ein Warm Failover zur zweiten Region ausgeführt wird. In ähnlicher Weise ist unsere Datenebene (die unsere Observability- und Analysefunktionen ermöglicht) ebenfalls auf zwei unabhängige Regionen aufgeteilt und verfügt über ein Warm Failover, wird jedoch von einem gesonderten Cloud-Anbieter gehostet. Dadurch wird der Streuungsgrad im Katastrophenfall effektiv begrenzt, was die Wahrscheinlichkeit, dass sowohl unsere Beobachtungs- (Datenebene) als auch unsere Handlungsfähigkeit (Kontrollebene) ausgeschaltet werden, erheblich verringert. 

Wir stellen außerdem sicher, dass unsere Rechenzentren über Failovers verfügen, und zwar von der Netzstromversorgung bis hin zur batteriegestützten unterbrechungsfreien Stromversorgung (USV) mit Notstromaggregaten. Allerdings reicht es nicht aus, diese Maßnahmen einfach nur umzusetzen. Im Zuge unserer betrieblichen Kontinuitätsplanung (Business Continuity Planning, BCP) führen wir auch Failovers zwischen der aktiven und der Standby-Region durch, um die Eignung kontinuierlich zu testen und im Falle eines regionalen Cloud-Ausfalls bestens gerüstet zu sein. 

Nachdem wir unsere Kontroll- und Datenebene auf diese erweiterte Architektur umgestellt hatten, war klar, dass unsere Entwicklerteams darauf möglichst einfach entwickeln können mussten, damit JEGLICHER Fastly Code so robust wie möglich sein würde. Deshalb haben wir unsere Kontroll- und Datenebene als Integrationsplattform nutzbar gemacht. So können Entwickler neue Out-of-the-Box-Produkte und -Funktionen –selbst kleinere Tests und Alpha-Projekte – in sicherer, skalierbarer und zuverlässiger Weise erstellen. Da kleinere Entwicklerteams beim Launch von etwas Neuem nicht länger ihre eigene Version der Kernsysteme rekonstruieren müssen, wird unsere Architektur sicherer. Höchst sicheren und robusten Code zu erstellen wird jedem leicht gemacht, aber das alleine reicht Fastly nicht.

Selbst nach Schlichtung der dringlichsten Risikofaktoren sucht die RTF weiterhin nach Verbesserungspotenzial und wir arbeiten schon jetzt an der nächsten Iteration unserer Kontroll- und Datenebene. Neue Verbesserungen vollständig zu implementieren kann Jahre dauern, weshalb schon heute mit der Arbeit begonnen werden muss. Wir stecken mitten in der Planung zur weiteren Entkopplung von unflexiblen Systemabstraktionen in der Kontrollebene, was nicht nur für mehr Stabilität sorgen, sondern uns auch zu beschleunigter Produktentwicklung verhelfen wird.

Netzwerkstabilität (über die Kontrollebene hinaus)

Ausfälle von Rechenzentren, die sich auf Kontroll- und Datenebene einer Plattform auswirken, sind nicht die einzige Herausforderung, der sich Betreiber eines globalen Edge-Netzwerks gegenübersehen, das niedrige Latenzen und hohe Verfügbarkeit verspricht. Im nächsten Abschnitt gehen wir auf die Bauweise des Fastly Edge-Netzwerks ein. Sie wurde so gewählt, dass Single Points of Failure vermieden und Probleme automatisch, intelligent und unmittelbar behoben werden. Wenn wir bei Fastly von Netzwerkstabilität sprechen, beziehen wir uns damit meist auf unser Edge-Netzwerk und unsere Content Delivery Services. Lassen Sie uns also loslegen.

Zuverlässiger Umgang mit Traffic- und Netzwerkausfällen

Traffic-Anomalien, Latenzprobleme und Internetausfälle sind tägliche Begleiter für ein Netzwerk, das so groß ist wie Fastlys. Jeden Tag haben Transit-Anbieter im Internet kollektiv mit vorübergehenden, kurzlebigen Verbindungs- oder Leistungseinbußen zu kämpfen. Man spricht hier auch vom „Internetwetter“. Auf manch weitreichende Internetausfälle wird die ganze Welt aufmerksam. Meistens handelt es sich jedoch (lediglich) um kleinere Ausfälle, die schnell behoben werden. Allerdings untergraben selbst diese die Latenz und die Performance eines Systems und können ernsthafte Auswirkungen nach sich ziehen. 

Gemäß branchenweiten Best Practices werden Hilfsmittel wie Border Gateway Protocol (BGP) Umleitungen angewendet, aber da BGP über keine integrierte Ausfallserkennung auf der Anwendungsebene verfügt, können Stunden vergehen, ehe ein Problem gelöst wird. Ein außerhalb von BGP genutztes Monitoring- oder Observability-System muss den Vorfall erkennen, die problembehafteten Routen ableiten, eine Lösung erarbeiten und dann mithilfe von BGP Anweisungen zur Änderung der Netzwerktopologie sowie zur Beseitigung von fehlerhaften Routen ausstellen. Sind diese Anweisungen einmal ausgestellt, behebt BGP das Problem schnell, aber wie gesagt kann es lange dauern, bis dieser Punkt überhaupt erreicht wird. BGP ist also beim Finetuning von kleinere Unterbrechungen oder Ausfälle im Netzwerk betreffenden Änderungen nicht sehr hilfreich. In den meisten Fällen hat sich das Problem bis zu dem Zeitpunkt, an dem die BGP-Änderung greift, von selbst gelöst. Für die Websites und Anwendungen, denen jede Ausfallssekunde echten Schaden zufügt, kommt dann ohnehin jede Hilfe zu spät.

Die Tatsache, dass wir nicht das gesamte globale Netzwerk kontrollieren können, gilt für Fastly nicht als Entschuldigung, unseren Kunden keine besseren und robusteren Services zu bieten. Fastlys Innovationsgeist liefert Kunden und deren Endnutzern die auf dem Markt verfügbaren schnellsten, zuverlässigsten Erlebnisse. Unsere Fortschritte im Edge-Netzwerkbetrieb sind nur dank unserer modernen Netzwerkarchitektur und unseres vollends softwaregesteuerten Netzwerks möglich. Letzteres lässt uns Logik auf jeder Ebene anwenden und Netzwerkabläufe programmatisch skalieren und nach Bedarf anpassen, um Internetprobleme zu umgehen und hohe Verfügbarkeit und Zuverlässigkeit zu gewähren.

Besonders hervorzuheben sind die folgenden Innovationen: 1) Unsere Systeme sind automatisiert, reparieren sich selbst und reagieren selbst ohne menschliches Eingreifen sofort und 2) sie werden in allen unseren POPs bereitgestellt.

Keine Abhängigkeiten, kein „Internetwetter“

Wir sind leidenschaftliche Tüftler, weshalb wir wirklich nicht davon begeistert sind, dass sich die eigentliche Ursache des Problems mit dem Internetwetter nicht beheben lässt. Das Ganze geschieht da draußen auf einem Teil der weltweiten Internetinfrastruktur, für den jemand anderes verantwortlich ist und der sich unserer Kontrolle entzieht. Gewisse Dinge unterliegen allerdings unserer Kontrolle und so konnten wir Möglichkeiten entwickeln, um schlechtes Internetwetter herum zu navigieren. Allen voran sei eine Technologie genannt, die wir als „Fast Path Failover” bezeichnen. 

Fast Path Failover erkennt automatisch leistungsschwache Edge-Verbindungen auf der Transportebene und leitet sie um, sodass wir die Auswirkungen von Internetproblemen, die außerhalb unserer eigenen POPs auftreten, abfedern können. Oft verursacht das Internetwetter Probleme wie Latenzen, was bedeutet, dass die Verbindung im Netzwerk streng genommen immer noch aktiv ist, obgleich stark beeinträchtigt. Standardmäßig stützt man sich auf BGP, um Traffic von kaputten Internetpfaden wegzuleiten, was bei vollständig unterbrochenen Verbindungen Abhilfe schafft, bei geschwächten Verbindungen jedoch eine katastrophale Lösung ist. 

Wenn eine Verbindung entlang des Pfads ausfällt, kann BGP die diese Verbindung betreffenden Routen aussondern und ggf. alternative Pfade vorschlagen. Dies veranlasst Internet Service Providers (ISPs) dazu, den Traffic umzuleiten und das Problem zu umgehen. Allerdings wird in Situationen, in denen ein Pfad stark beeinträchtigt, aber nicht vollständig unterbrochen ist, eine Routenaussonderung durch BGP möglicherweise überhaupt nicht ausgelöst. Manchmal muss der ISP betroffenen Traffic selbst aufspüren und manuell umleiten, was je nach Anbieter zwischen einigen Minuten und mehreren Stunden dauern kann. 

Fast Path Failover wartet nicht darauf, dass BGP Probleme für Fastly Kunden behebt – wenn etwas ausfällt, wollen wir schnell vorwärtskommen, schnell umleiten und schnell wieder funktionsfähig sein. Wie bereits erwähnt erkennt Fast Path Failover leistungsschwache Edge-Verbindungen automatisch und leitet sie um, und zwar ohne eine netzwerkweite BGP-Lösung abzuwarten. Wir müssen nicht darauf warten, dass uns Peering-Netzwerke und Transit-Anbieter auf einen gebrochenen Pfad hinweisen, denn wir sehen ihn ja selbst. Und wir müssen nicht auf ihre Routing-Lösung warten, sondern können selbst eine andere Route probieren. Unsere Edge-Cloud-Server können feststellen, ob Verbindungen durchgehen, den Zustandsstatus des Internetpfads ableiten und bei Bedarf schnell einen alternativen Pfad wählen. 

Als weiterer Pluspunkt für die verteilte Architektur sei erwähnt, dass wir von einem noch schnelleren Routing profitieren, da wir nicht auf zentralisierte Hardware-Router angewiesen sind, die Routing-Entscheidungen für einen gesamten POP ausbremsen. Unsere Edge-Server können in der dezentralen Umgebung schneller agieren und Routing-Entscheidungen pro Verbindung treffen. Dies ermöglicht präzise Failover-Entscheidungen, in Folge derer ausschließlich beeinträchtigte, nicht aber funktionsfähige Verbindungen umgeleitet werden. Dieser Mechanismus ist ausgesprochen wirksam bei der Erkennung und Abwehr von Internetwetterauswirkungen, die in der Regel zu gering und zu kurzlebig sind, um von den üblichen Netzwerküberwachungstechniken erfasst und abgewehrt zu werden. Hier erfahren Sie mehr über Fast Path Failover.

Lassen Sie uns diesen Gedanken noch weiterführen: In Fällen, in denen das Internetwetter in der Netzwerktopologie eine relativ zentrale Position einnimmt, gibt es möglicherweise keinen alternativen Pfad, über den der Traffic umgeleitet werden könnte. Andere Anbieter wissen sich bei solchen Problemen möglicherweise nicht mehr weiterzuhelfen, aber Aufgeben kommt für uns keinesfalls in Frage. Fastly verfügt über eine so umfangreiche Vielfalt an Peering-Netzwerken und Transit-Anbietern, dass das Risiko, in Netzwerkengpässen stecken zu bleiben, wenn Endkunden erreicht werden sollen, verschwindend gering ist.

Intelligentes, automatisiertes Traffic-Routing 

Neben Fast Path Failover, das wie oben erläutert die Konnektivität für Content-Anfragen von Fastlys Edge-Cloud-Plattform verbessert, haben wir auch zwei weitere Technologien namens „Precision Path“ und „Autopilot“ entwickelt. Beide sorgen dafür, die Performance in Teilen des Netzwerks zu verbessern, die Fastly kontrollieren kann.  

Precision Path wird zur Verbesserung der Performance auf den Internetpfaden zwischen den Origin-Servern des Kunden und unserem Netzwerk eingesetzt, während Autopilot unsere automatisierte Lösung für das Routing von Egress-Traffic ist. In Kombination können die beiden Erstaunliches leisten. Sie ermöglichen es uns, sofort und ohne menschliche Analyse und Planung zu reagieren. Dies ist entscheidend, denn eine schnellere Reaktion verhindert, dass sich Probleme ausbreiten und weitere Teile des Netzwerks beeinträchtigen.

Precision Path

Precision Path überwacht kontinuierlich alle Origin-Verbindungen in jedem Fastly POP weltweit. Wird eine leistungsschwache Origin-Verbindung feststellt (z. B. aufgrund von Internetwetter), ermittelt die Technologie automatisch alle verfügbaren alternativen Pfade zu diesem beeinträchtigten Origin-Server und leitet die Verbindung in Echtzeit auf die beste Alternative um. Häufig können wir eine stabile Origin-Verbindung wiederherstellen, noch bevor 5xx-Serverfehler an die Endnutzer ausgeliefert werden. Beinah so, als hätte es die Netzwerkprobleme nie gegeben. Auch unser Log Streaming in Echtzeit kann zur Überwachung von Verbindungsumleitungen verwendet werden, die bei Fastly Services möglicherweise auftreten. 

Precision Path konzentriert sich ferner darauf, Inhalte über unsere Edge-Cloud-Plattform zuverlässig an Endnutzer auszuliefern. Bei der Bereitstellung dieser Inhalte verfolgen wir den Zustand jeder TCP-Verbindung. Wenn wir eine Beeinträchtigung der Verbindung feststellen (z. B. eine Überlastung), verwenden wir Fast Path Failover, um die Zustellung automatisch auf einen neuen Netzwerkpfad umzuleiten und das Problem so zu umgehen. Diese automatische Risikominderung ist standardmäßig auf allen unseren POPs aktiviert und gilt für sämtlichen Fastly Traffic. Eine zusätzliche Konfiguration ist nicht erforderlich.

Autopilot

Autopilot hat es uns ermöglicht, während des letzten Super Bowl einen Traffic-Rekord von 81,9 Tbit/s ganz ohne menschliches Zutun aufzustellen, d. h. es war keinerlei manuelles Eingreifen während dieses trafficintensiven und kritischen Großereignisses erforderlich. Seit Februar konnten wir zudem viele weitere Traffic-Rekorde verzeichnen. Jeder Tag hat also das Potenzial, so wichtig wie der Super Bowl Tag zu sein. Diese flexible Skalierbarkeit ist nicht nur einmal im Jahr nützlich. Wir verlassen uns 365 Tage im Jahr darauf.

Ähnlich wie Fast Path Failover wurde auch Autopilot entwickelt, um Unzulänglichkeiten im BGP-Protokoll zu begegnen. BGP weist eine „Capacity Awareness Gap“ auf – das Protokoll kann lediglich mitteilen, ob ein Internetziel erreicht werden kann oder nicht. Es kann nicht beurteilen, ob die Kapazität für die gewünschte Menge an Traffic ausreichen oder wie groß der Durchsatz oder die Latenzzeit für diese Übertragung sein würde. Das ist in etwa so, als würde ein Kurier der Auslieferung Ihres Pakets zustimmen und es Ihnen abnehmen, nur um später festzustellen, dass es gar nicht in sein Auto passt.

Autopilot geht dieses Problem an, indem es die freie Kapazität unserer Verbindungen und die Leistungsfähigkeit der Netzwerkpfade kontinuierlich bewertet. Diese Informationen werden im Minutentakt über Netzwerkmessungen ermittelt und zur Optimierung der Traffic-Zuweisung verwendet, so dass wir einer Überlastung der Verbindungen proaktiv vorbeugen. Precision Path ist blitzschnell, aber der Fokus liegt darauf, sich von instabilen Verbindungen zu distanzieren. Die Technologie „weiß“ nicht viel über die neue Verbindung. Autopilot besitzt eine etwas langsamere Reaktionszeit als Precision Path, trifft aber fundiertere Entscheidungen anhand von hochauflösenden Netzwerk-Telemetriedaten, die über einen Zeitraum von mehreren Minuten erfasst werden. Anstatt (wie Precision Path) Traffic lediglich von einem ausgefallenen Pfad wegzuleiten, werden größere Mengen an Traffic in Richtung besserer Netzwerkabschnitte weitergeleitet. 

Durch das Zusammenspiel von Precision Path und Autopilot lassen sich problematische Traffic Flows schnell auf funktionierende Pfade umleiten. Außerdem können wir unsere gesamte Routing-Konfiguration regelmäßig anpassen und verfügen über genügend Daten, um sichere Entscheidungen zu treffen. Unsere Systeme sind rund um die Uhr im Einsatz, spielten aber während des letzten Super Bowl eine besonders wichtige Rolle, als sie 300 Gbit/s bzw. 9 Tbit/s an Traffic umleiteten, der andernfalls über fehlerhafte, überlastete oder nicht ausreichend performante Pfade ausgeliefert worden wäre und Fastlys Netzwerkkapazität überlastet hätte. Dank dieser Selbstverwaltungsfunktionen reagieren wir schneller und häufiger auf potenzielle Ausfälle, Überlastungen und Performance-Einbußen in unserem Netzwerk.

Autopilot hat zahlreiche Vorteile für Fastly, noch besser ist diese Funktion aber für unsere Kunden. Sie können sich nämlich jetzt mehr als je zuvor darauf verlassen, dass wir Ereignisse wie Ausfälle von Netzwerkanbietern oder DDoS-Angriffe und unerwartete Traffic-Spitzen im Griff haben, ohne dabei das Erlebnis ihrer Endnutzer zu beeinträchtigen. Hier erfahren Sie mehr über Autopilot und Precision Path. 

Automatisierter Schutz vor großvolumigen DDoS-Angriffen

Nicht alle Netzwerkprobleme sind unbeabsichtigt. Ein entscheidender Aspekt der Netzwerkstabilität ist die Fähigkeit, großvolumigen Distributed Denial of Service (DDoS)-Vorfällen wie dem jüngsten Rapid-Reset-Angriff standzuhalten. Diese Art von Angriff verursacht weiterhin Probleme im Internet, allerdings bleibt Fastly davon unbetroffen, weil unser automatisiertes System in der Lage ist, den Angriff mittels einer Technologie namens „Attribute Unmasking“ sofort zu erkennen und abzuwehren.

Attribute Unmasking

DDoS-Angriffe werden mit der Zeit immer wirkungsvoller und lassen sich auch immer schneller skalieren. Der Sprung von null Anfragen pro Sekunde (requests per second, RPS) auf Millionen oder gar Hunderte von Millionen RPS dauert oft nur wenige Sekunden und ebenso schnell endet der Angriff zuweilen auch wieder. DDoS-Angriffe werden darüber hinaus zunehmend ausgeklügelter, wie beispielsweise der jüngste Rapid-Reset-Angriff, der sich eine Eigenschaft des HTTP/2-Protokolls zunutze machte, die zuvor noch nicht ausgenutzt worden war. 

Für die meisten der großen Plattformen, die von Rapid Reset betroffen waren, stellte dies einen neuartigen Angriff dar, der immensen Schaden anrichtete. Attribute Unmasking erlaubte es Fastly jedoch, inmitten des Angriffs schnell und automatisch präzise Fingerabdrücke aus dem Netzwerk-Traffic zu extrahieren. Bei anderen komplizierten Angriffen lässt sich diese Technologie in gleicher Weise anwenden. Jede über ein Netzwerk eingehende Anfrage besitzt zahllose Eigenschaften, die zur Beschreibung des Traffics verwendet werden können, darunter Layer-3- und Layer-4-Header, TLS-Informationen, Layer-7-Details und vieles mehr. Unser System erfasst die Metadaten von eingehenden Anfragen und verwendet diese, um bösartigen von gutem Traffic zu unterscheiden. Auf diese Weise lässt sich Angriffs-Traffic blockieren, während legitimer durchgelassen wird.

Zu Zwecken schnellerer Antwortzeiten wird DDoS-Schutz auf der Edge unseres Netzwerks ausgeführt, wobei die Erkennungs- und Abwehrfunktionen in unseren Kernel und den verarbeitenden Stack auf Anwendungsebene integriert sind. Hierbei handelt es sich um ein weiteres Beispiel für eine verteilte Lösung (siehe Fast Path Failover), die nur deshalb möglich ist, weil unser Netzwerk vollständig softwaregesteuert ist. Mit anderen Worten können wir Funktionen in dezentralerer Art und Weise ausführen, und zwar auf allen unseren Servern gleichzeitig. Unser System ist außerdem modular aufgebaut, weshalb wir unsere Erkennungs- und Abwehrfunktionen bei Entdeckung neuer Angriffsarten schnell verstärken können, ohne dafür einen völlig neuen Schutzmechanismus entwickeln zu müssen. Wenn ein Angriff wie Rapid Reset auf der Bildfläche erscheint, fügen wir unseren Erkennungs- und Abwehrmodulen einfach ein paar neue Features hinzu. So bleiben unsere Antwortzeiten selbst bei neuartigen Cyberattacken extrem kurz. Hier erfahren Sie mehr über Attribute Unmasking und den Rapid-Reset-Angriff.

Netzwerkstabilität ist ein Entwicklungsprozess

Dieser Blogpost steckt voller Details, weshalb wir nachfolgend die wichtigsten Punkte zusammenfassen: 

1. Wir bei Fastly überlegen mit Nachdruck, was schief gehen könnte, BEVOR etwas schief geht.

2. Wir wenden erhebliche Ressourcen für die Verbesserung unserer Architektur auf.

3. Wir identifizieren und beseitigen Single Points of Failure kontinuierlich.

4. Wir erarbeiten innovative Möglichkeiten, um uns auf außerhalb unserer Verantwortungshoheit liegende Probleme vorzubereiten und diese zu lösen.

5. Wir sehen unsere Arbeit nie als abgeschlossen an. Wir bereiten uns unentwegt auf die Probleme von morgen vor und fragen uns immer, was noch getan werden könnte. 

Wenn Sie mehr über unsere Arbeitsweise und die Performance- und Sicherheitsvorteile erfahren möchten, von denen Fastly Kunden dank dieser effizienten Innovationen profitieren, entdecken Sie Fastly kostenlos oder setzen Sie sich noch heute mit uns in Verbindung.