Vermeidung von technischen Ausfällen durch den Aufbau einer widerstandsfähigen Infrastruktur
Ohne Elektrizität läuft im 21. Jahrhundert nahezu nichts mehr. Das gilt natürlich insbesondere für Dienstleistungen wie Websites, Online-Tools, mobile Apps und Spiele, die in irgendeiner Art und Weise auf Cloud-Anbieter für ihren gesamten Hardwarebedarf angewiesen sind.
Wenn es hier zu Störungen oder Ausfällen kommt, sind Millionen Menschen weltweit davon betroffen und die Auswirkungen können überwältigend sein. So auch im Dezember 2021, als es beim Cloud-Computing-Anbieter Amazon Web Services (Amazon AWS) zu einem Serverausfall in den Regionen US-WEST-1 und US-WEST-2 kam.
Obwohl sich Wix zu einem gewissen Maße auf die betreffenden Amazon-Dienste verlässt (einschließlich der betroffenen Region), wurde der Vorfall von keinem der zahlreichen Benutzer:innen von Wix oder Besucher:innen einer von Wix betriebenen Website bemerkt.
Bei Wix stehen Resilienz und Flexibilität im Zentrum. Dadurch sind wir in der Lage, mit nur einem Fingerschnippen, Ressourcen und Daten zwischen Servern zu verschieben, die Tausende von Kilometern voneinander entfernt sind.
In diesem Artikel verraten wir im Detail, wie es uns gelungen ist, ein solches System zu entwickeln.
Geografische Verteilung
Wix ist sehr benutzerorientiert. Unsere Produktionstechnik agiert daher nach dem Leitsatz: „Alles, was schiefgehen kann, geht auch schief“. Tatsächlich gibt es bei uns Mitarbeiter, deren einzige Aufgabe darin besteht, unser Produkt über die Maßen zu strapazieren, Fehler zu finden und so gut es geht daran zu arbeiten, dass eben nichts schiefgeht.
So stellen wir sicher, dass alles, was unsere Benutzer mit Wix erstellen, jederzeit verfügbar und für ihre Nutzer bereitgestellt werden kann (diese Nutzer nennen wir intern Nutzer von Nutzern). Das bedeutet auch, dass wir nicht einfach das Handtuch werfen können, wenn es bei einem unserer Infrastrukturpartner zu Problemen oder Ausfällen kommt und wir dadurch
an einem bestimmten geografischen Ort offline geschaltet werden.
Vor diesem Hintergrund bauen wir die gesamte Infrastruktur, auf der alle Wix-Dienste ausgeführt werden, so auf, dass wir die entsprechenden Gegenmaßnahmen ergreifen können, sobald etwas schiefgeht. So können wir gewährleisten dass unsere Nutzer nicht betroffen sind.
Eine spezielle Besonderheit unseres Ansatzes besteht darin, die Hochverfügbarkeit (HA), die von Cloud-Anbietern standardmäßig angeboten wird, noch über das Offensichtliche hinaus zu steigern. Hochverfügbarkeit beschreibt die Fähigkeit eines Systems den Betrieb trotz Ausfalls mit einer hohen Wahrscheinlichkeit (von oft 99,99 % oder mehr) zu gewährleisten. Wir betrachten Hochverfügbarkeit durch eine multi-geografische Linse und konzentrieren uns nicht nur auf HA-Zonen in denselben Regionen.
Wir nutzen alles, was Verfügbarkeitszonen zu bieten haben und gehen zusätzlich noch darüber hinaus. Wir können uns nicht einfach auf eine gemeinsam genutzte Infrastruktur verlassen, die eine ganze Zone plötzlich lahmgelegt. Daher setzen wir auf geografisch verteilte Hochverfügbarkeit. Wir nehmen alle hochverfügbaren Zonen, die über Tausende von Kilometern (an der US-Ostküste, in Europa, in Asien) an (insgesamt 15) verschiedenen geografischen Standorten verteilt sind und nutzen sie alle jederzeit.
Alle diese Standorte werden entsprechend der Menge an Traffic skaliert, den sie empfangen und bedienen. Anstatt also einen sehr großen Standort zu haben, der alle versorgt, haben wir 15 „kleine“ Standorte, deren Größe ungefähr 6,6 % eines großen Standorts entspricht.
Wenn nun einer dieser Standorte aus irgendeinem Grund ausfällt, verbleiben 14 andere, auf denen die Last des Ausfalls verteilt werden können. Üblicherweise geschieht dies durch die Nutzung der 2-3 nächstgelegenen Standorte. Wir haben mehrere Algorithmen entwickelt, die uns dieses Vorgehen einerseits überhaupt erst ermöglichen und es andererseits auch noch so gestalten, dass es wirtschaftlich effizient ist und alles ordnungsgemäß funktioniert.
Wirtschaftliche Effizienz bedeutet in diesem Fall, dass alle unsere Standorte im täglichen Verlauf stets für Traffic genutzt werden und nicht ungenutzt bleiben.
Krisen antizipieren und abwenden
Monitoring ist das Prinzip, was allem zugrunde liegt. All unsere Standorte werden aktiv überwacht. Und das sowohl aus der Perspektive eines „Nutzers unserer Nutzer“ bis hin zum letzten Dienst, der an einem bestimmten Standort ausgeführt wird.
Dieses Monitoring ermöglicht ein sehr tiefes Verständnis des Status aller Standorte. Somit sind wir in der Lage, die Standorte jederzeit zu evaluieren und einzuschätzen, ob ein Standort zu einem bestimmten Zeitpunkt, sagen wir, „gut genug“ ist, um den anfallenden Traffic in so zu bedienen, wie wir es wünschen und erwarten.
Wir müssen nicht darauf warten, dass eine Katastrophe einen ganzen Standort heimsucht – sobald wir auch nur das geringste Anzeichen für ein eventuelles Problem sehen, können wir proaktiv handeln anstatt rumzusitzen und abzuwarten.
Das bringt uns zu unserem obigen Beispiel vom Ausfall bei Amazon zurück. Alles begann mit einigen geringeren Problemen kleiner Dienste im Zusammenhang mit DynamoDB (einem Amazon Datenbankservice).
Stark vereinfacht ausgedrückt: Die Situation wurde „angespannt“, als unserer System intern die Meldung erhielt, dass mehrere Dienste nicht mehr „ganz rund” liefen. Zu diesem Zeitpunkt hatte sich Amazon noch nicht zur Situation geäußert, sodass das Problem noch niemandem bewusst war. Dennoch entschieden wir uns zu handeln und keinen Traffic mehr über den US-EAST Standort zu leiten, sondern den Traffic “abzuziehen”. Das Resultat – obwohl es letztendlich zu einem Ausfall bei unserem Anbieter kam, waren unsere Nutzer nicht betroffen und haben davon nichts mitbekommen.
Methodisches Vorgehen – Was steckt dahinter?
Wie ist es uns gelungen, ein System einzurichten, das es uns ermöglicht, Ressourcen an einen anderen Ort zu verlagern und das Problem dann in Ruhe zu untersuchen, ohne die User Experience unserer Nutzer zu gefährden?
Das ist unser methodisches Vorgehen, in vereinfachten Worten ausgedrückt:
Wir überwachen das gesamte System und lernen so, in welchem Bereich Probleme entstehen.
Wir haben die Möglichkeit, Datenverkehr von verschiedenen Standorten zu bedienen (durch die Verwendung von DNS-Anbietern zum Verlagern von Traffic zwischen verschiedenen Rechenzentren).
Wir können unsere Ressourcen automatisch und sehr schnell skalieren und somit schnell auf Änderungen in der Nachfrage reagieren.
Wir haben die Datentiefe, um zu verstehen, ob eine Anfrage, die wir auf einer Seite des Globus empfangen, mit einer Anfrage in Zusammenhang steht, die am anderen Ende der Welt gestartet wurde.
Darüber hinaus muss unsere gesamte Infrastruktur, obwohl sie geografisch weit verteilt ist, sehr genau wissen, was die Anfrage ist, wie sie eingegangen ist und wie sie verarbeitet werden muss, wenn sie sich zwischen verschiedenen geografischen Standorten bewegt.
Das bedeutet beispielsweise: Wenn eine Bezahlvorgang auf der Website eines unserer Nutzer stattfindet, muss hinter dieser Transaktion eine fehlertolerante Infrastruktur stehen. Denn der Bezahlvorgang muss auch dann nahtlos und kontinuierlich fortgesetzt werden können, wenn sie auf einer Reihe von Servern an einem Standort startet, jedoch an einem anderen Standort fortgesetzt wird. Und das über Tausende physischer Kilometer.
Um flexibel genug zu sein und Traffic schnell “abziehen” zu können, muss unser gesamtes System wissen, wie es wachsen kann, um sich an die nötigen Änderungen anzupassen. Das ist Auto-Skalierung. Darüber hinaus verfügt unser System auch immer über einen Puffer an Ressourcen, um sicherzustellen, dass wir über ausreichende Kapazitäten für einen Wechsel verfügen.
Dieses Vorgehen ermöglicht uns:
Niemals in nur einer einzigen geografischen Zone zu arbeiten
Jede Anfrage zwischen all diesen Standorten nahtlos zu verfolgen und im Blick zu haben
Sicherzustellen, dass jeder Standort bei Bedarf automatisch skaliert werden kann
Kleine Teile an Traffic zu bewegen, anstatt das gesamte System zu migrieren
All dies ermöglicht es uns, sehr schnell auf alle Ereignisse zu reagieren und Vertrauen in unser System zu haben. Und dieses Vertrauen wurde zum Rückgrat unseres Systems.
Wie wir bereits gesagt haben – was schiefgehen kann, geht schief – doch unser System ermöglicht es uns, Dinge in Bewegung zu setzten, bevor sich ernsthafte Probleme in nennenswerter Weise manifestieren können. Im Wesentlichen können wir potenzielle Probleme mit der Infrastruktur eines Cloud-Anbieters erkennen und uns sicher sein, dass unser System schnell handelt und den Traffic zu jedem beliebigen Zeitpunkt automatisch umverteilt.
Unsere Ingenieure und Entwickler haben das System in den vergangenen zweieinhalb Jahren auf Herz und Nieren geprüft, um sicherzustellen, das wir im Fall der Fälle handlungsbereit sind. Das hat sich während des letzten Ausfalls bewährt – wir haben schnell und automatisch gehandelt, noch bevor unser Anbieter überhaupt verstanden hat, was das Problem war.
Fazit
Gute Vorbereitung ist das A und O in der Produktionstechnik und unser Team von Ingenieuren und Entwicklern tut alles, damit wirklich nichts schief geht.
Das bedeutet, dass die gesamte Infrastruktur auf Stabilität und Flexibilität ausgelegt ist, damit unsere Nutzer die Vorteile von Wix voll ausschöpfen können, ohne sich um einen möglichen Ausfall sorgen zu müssen.
Das Team von Wix
Hallo zusammen! Wenn du dich für CS interessierst und gerne tief in die Spielgeschichte eintauchst, MUSST du dir https://bloodycase.com/de/case/operationbreakout ansehen. Diese Seite enthält einige der interessantesten und detailliertesten Fälle, die ich je gesehen habe. Die Art und Weise, wie sie jede Operation aufschlüsseln, ist unglaublich und verleiht dem Spiel wirklich eine zusätzliche Ebene der Spannung. Ich habe Stunden damit verbracht, den Fall Operation Breakout durchzulesen, und ich konnte nicht genug davon bekommen.