So stellen Sie die Verfügbarkeit eines Webdienstes in der Cloud bei einem Ausfall des Rechenzentrums sicher

In diesem Artikel wird die Option beschrieben, die Verfügbarkeit eines in der Cloud bereitgestellten Webdienstes im Falle einer Fehlfunktion im Rechenzentrum sicherzustellen. Die vorgeschlagene Lösung basiert auf einem Kompromiss, der aus einer teilweisen Vervielfältigung besteht : Ein Sicherungssystem wird in einem anderen Rechenzentrum bereitgestellt, das in einem Modus mit eingeschränkter Funktionalität betrieben werden kann, wenn das Hauptrechenzentrum nicht verfügbar ist. Dieses Schema zielt in erster Linie auf die Anwendung bei kurzfristigen Ausfällen ab, bietet aber auch die Möglichkeit, das Backup-System bei großen Problemen schnell zum Haupt-System zu machen.

Problembeschreibung

Letztes Jahr waren wir von einem Vorfall im Rechenzentrum eines bekannten Cloud-Anbieters betroffen - einer unserer Dienste war für Benutzer eine halbe Stunde lang nicht verfügbar. Dann haben wir mit eigenen Augen gesehen, dass es bei Problemen im Cloud-Rechenzentrum praktisch keine Hebel gibt, um die Anwendung wiederherzustellen, und für das für die Anwendung verantwortliche Team bleibt nichts anderes übrig, als aufzustellen und zu warten. Diese Erfahrung hat uns ernsthaft über die Verwendung von Clouds für unsere Produkte nachdenken lassen.

Was genau an diesem Tag passiert ist, wurde nie herausgefunden. Wir sind es gewohnt, die Wolken als unzerstörbaren Außenposten wahrzunehmen, aber das ist nicht so. Die Wahrheit ist, dass es in der Cloud keine hundertprozentige Garantie für die Verfügbarkeit von Diensten gibt, wie an jedem anderen Ort. Wolken sind eine Abstraktion, hinter der alle gleichen Racks mit Eisen in Rechenzentren und dem menschlichen Faktor verborgen sind. Jede Hardware fällt früher oder später aus (obwohl Hardwarefehler in Rechenzentren eher eine normale Situation sind). Darüber hinaus gibt es Fälle schwerwiegenderer Probleme, die zur Unzugänglichkeit von Rechenzentren führen: Brände, DDoS-Angriffe, Naturkatastrophen, Unterbrechungen der Stromversorgung und des Internets usw.

Wenn wir über den menschlichen Faktor sprechen, ist dies nicht die jüngste Unfallursache: "Laut Statistik sind bei 80% der Netzwerkinfrastrukturausfälle die Menschen schuld . " Menschen, egal wie gut gemeint sie geführt werden, sind unzuverlässig. Selbst Sie und Ihre Kollegen - Personen, die direkt an der Stabilität unterstützter Produkte interessiert sind - haben wahrscheinlich Fehler gemacht, ganz zu schweigen vom Personal eines anderen Unternehmens, für das sich Ihre Instanzen nicht von Tausenden anderen unterscheiden. Unabhängig vom professionellen Team hinter der Infrastruktur ist ein neuer Fehler eine Frage der Zeit.

Alles hat einen Preis. Wenn Sie in die Cloud wechseln, erhalten Sie eine einfache Abstraktion, mit der Sie bequem arbeiten können, eine schwache Abhängigkeit von Ihrer Betriebsabteilung als Gegenleistung für die vollständige Kontrolle über die Situation. In diesem Fall wird dies niemand tun, wenn Sie nicht im Voraus auf sich selbst aufpassen und die Möglichkeit von Fehlern anderer Personen vorausgesehen haben.

Lösungsoptionen

Für uns ist die Nichtverfügbarkeit des Dienstes auch für einige Minuten bereits von entscheidender Bedeutung. Deshalb haben wir uns entschlossen, einen Weg zu finden, um uns in Zukunft gegen ähnliche Probleme zu versichern, ohne die Wolken zu verlassen.

Bei der Lösung des Problems der Verfügbarkeit von Diensten in der Cloud sollte berücksichtigt werden, dass die Barrierefreiheit ein ziemlich umfassendes Konzept ist und je nachdem, was damit gemeint ist, verschiedene Szenarien für die Bereitstellung berücksichtigt werden. Obwohl in diesem Artikel nur das Problem der Barrierefreiheit infolge eines Ausfalls des Rechenzentrums behandelt wird, ist es angebracht, einige Worte zu Lösungen für andere Barrierefreiheitsprobleme zu sagen.

Verfügbarkeit als technische Möglichkeit, bei einer bestimmten Last für eine bestimmte Zeit Zugriff auf eine Ressource zu gewähren. Das Problem tritt auf, wenn der Dienst ausgeführt wird. Aufgrund der begrenzten Ressourcen und des Architekturrahmens des Systems können jedoch nicht alle Benutzer in einer bestimmten Antwortzeit darauf zugreifen. Die Aufgabe wird meistens gelöst, indem zusätzliche Instanzen mit der Anwendung bereitgestellt werden. Mit dieser Skalierung machen die Wolken einen tollen Job.

Barrierefreiheit als Verfügbarkeit eines Webdienstes für Benutzer aus einer bestimmten Region. Die offensichtliche Lösung hier ist Scherben. Mit anderen Worten: Aufteilen des Systems in mehrere unabhängige Anwendungen in verschiedenen Rechenzentren mit eigenen Daten und Zuweisen jedes Benutzers zu seiner Systeminstanz, beispielsweise basierend auf seinem geografischen Standort. Beim Sharding führt der Ausfall eines Rechenzentrums im schlimmsten Fall dazu, dass der Dienst nur für einen Teil der an dieses Rechenzentrum gebundenen Benutzer nicht verfügbar ist. Nicht das letzte Argument für Sharding sind die unterschiedlichen Ping-Zeiten zum Rechenzentrum in verschiedenen Regionen.

Häufig sind jedoch Einschränkungen bei der Arbeit mit der Cloud und die Notwendigkeit einer Dezentralisierung gesetzliche Anforderungen, die in der Regel bereits in der Phase des Systemdesigns berücksichtigt werden. Diese Anforderungen umfassen: Yarovaya-Gesetz - Speicherung personenbezogener Daten (PD) von Benutzern in Russland; Allgemeine Datenschutzverordnung (DSGVO) - Beschränkungen für den grenzüberschreitenden Transfer von PD von EU-Nutzern in einige Länder; und chinesische Internet-Zensur, bei der sich ALLE Kommunikationen und ALLE Teile der Anwendung in China und vorzugsweise auf ihren Servern befinden sollten.

Das Problem der technischen Unzugänglichkeit des Rechenzentrums wird durch Duplizieren des Dienstes in einem anderen Rechenzentrum gelöst. Dies ist keine einfache technische Aufgabe. Das Haupthindernis für die parallele Bereitstellung von Diensten in verschiedenen Rechenzentren ist die Datenbank. In der Regel verwenden kleine Systeme eine Architektur mit nur einem Assistenten. In diesem Fall macht der Ausfall des Rechenzentrums mit dem Master das gesamte System funktionsunfähig. Ein Master-Replikationsreplikationsschema ist möglich, bringt jedoch starke Einschränkungen mit sich, die nicht jeder versteht. Tatsächlich wird der Datensatz nicht in die Datenbank skaliert, sondern es wird sogar eine geringe Zeitstrafe verhängt, da alle Knoten bestätigt werden müssen, dass die Transaktion akzeptiert wurde. Die Schreibvorgangszeit erhöht sich noch mehr, wenn die Knoten in verschiedenen Rechenzentren beabstandet sein müssen.

Begründung der Entscheidung

Die Analyse der Auslastung unseres Dienstes ergab, dass durchschnittlich etwa 70% der Aufrufe der API über GET-Methoden erfolgen. Diese Methoden verwenden eine schreibgeschützte Datenbank.


Verteilung von HTTP-Methodenaufrufen für Webdienste

Ich denke, diese Ergebnisse spiegeln das Gesamtbild der allgemein verfügbaren Webdienste wider. Daher können wir sagen, dass in der durchschnittlichen Webdienst-API Lesemethoden viel häufiger aufgerufen werden als Schreibmethoden .

Die zweite Aussage, die ich vorbringen möchte, ist, dass die Kunden des Dienstes , wenn wir über absolute Zugänglichkeit sprechen, diese Zugänglichkeit nicht nur für die Fülle der verfügbaren API-Methoden benötigen, sondern nur für diejenigen, die erforderlich sind, um die „übliche“ Arbeit mit dem System fortzusetzen und Ausführen von "normalen" Abfragen . Niemand wird verärgert sein, wenn eine Methode, auf die mehrmals im Monat zugegriffen wird, mehrere Minuten lang nicht verfügbar ist. Oft wird der „normale“ Fluss durch Lesemethoden abgedeckt.

Daher kann die Sicherstellung der absoluten Verfügbarkeit nur von Lesemethoden bereits als mögliche Option für eine kurzfristige Lösung des Problems der Systemverfügbarkeit bei Ausfall des Rechenzentrums in Betracht gezogen werden.

Was wollen wir umsetzen?

Bei Ausfällen im Rechenzentrum möchten wir den Datenverkehr auf ein Sicherungssystem in einem anderen Rechenzentrum umschalten. Im Sicherungssystem sollten alle Lesemethoden verfügbar sein. Wenn beim Aufrufen der verbleibenden Methoden kein Schreiben in die Datenbank möglich ist, sollte der richtige Fehler angezeigt werden.

Im normalen Betrieb wird die Benutzeranforderung an den Balancer gesendet, der sie wiederum an die Haupt-API umleitet. Wenn der Hauptdienst nicht verfügbar ist, ermittelt der Balancer diese Tatsache und leitet Anforderungen an das Sicherungssystem weiter, das im eingeschränkten Funktionsmodus arbeitet. Zu diesem Zeitpunkt analysiert das Team das Problem und beschließt, auf die Wiederherstellung des Rechenzentrums zu warten oder das Sicherungssystem in den Hauptmodus zu schalten.

Implementierungsalgorithmus

Notwendige Infrastrukturänderungen

1. Erstellen einer Datenbank-Slave-Replikation in einem anderen Rechenzentrum.
2. Einrichten einer Webdienstbereitstellung, Sammeln von Protokollen und Metriken im zweiten Rechenzentrum.
3. Die Balancer-Konfiguration zum Umschalten des Datenverkehrs in ein Ersatz-Rechenzentrum, falls das erste nicht verfügbar ist.

Codeänderungen:

1. Hinzufügen einer separaten Verbindung zum Replikat im Webdienst.
2. Migrieren Sie alle schreibgeschützten API-Routen zu einem Replikat.
3. Bei den übrigen Methoden funktioniert die Einführung des schreibgeschützten Modus über eine Umgebungsvariable oder einen anderen Trigger, bei dem sie nicht in die Datenbank schreiben, teilweise oder gibt einen korrekten Fehler aus, wenn ihre Funktionalität ohne Schreiben in die Datenbank unterbrochen wird.
4. Verbesserungen am Frontend, um den korrekten Fehler beim Aufrufen von Aufnahmemethoden anzuzeigen.

Vor- und Nachteile der beschriebenen Lösung

Die Vorteile

• Der Hauptvorteil des vorgeschlagenen Schemas besteht darin, dass es immer einen doppelten Dienst gibt, der jederzeit bereit ist, Benutzer zu bedienen. Bei Problemen mit dem Hauptrechenzentrum müssen Sie keine Bereitstellungsskripte für eine andere Infrastruktur schreiben und diese schnell ausführen.
• Die Lösung ist kostengünstig zu implementieren und zu warten. Wenn Sie über eine Microservice-Architektur verfügen und das Produkt nicht nur einen, sondern mehrere Services benötigt, sollten in diesem Fall keine besonderen Probleme bei der Übertragung aller Microservices auf dieses Schema auftreten.
• Es besteht keine Gefahr eines Datenverlusts, da sich auf dem Replikat in einem anderen Rechenzentrum immer eine vollständige Kopie der Datenbank befindet.
• Die Lösung ist hauptsächlich für die vorübergehende Verkehrsumschaltung von bis zu einer halben Stunde vorgesehen. Diese halbe Stunde reicht nicht aus, um bei Problemen mit der Infrastruktur zu navigieren. Wenn während dieser Zeit das erste Rechenzentrum nicht wiederhergestellt wird, wird das Slave-Replikat der Datenbank zu einem Master, und der doppelte Dienst wird zum Hauptdienst.
• In dem vorgeschlagenen Schema befinden sich die Anwendung und die Datenbank im selben Rechenzentrum. Wenn Sie eine API und eine Datenbank in verschiedenen Rechenzentren haben, übertragen Sie diese am besten in eines: Dadurch wird die Ausführungszeit für Abfragen erheblich verkürzt. Unsere Messungen haben beispielsweise gezeigt, dass für Google Cloud die Anforderung von der API an die Datenbank in einem Rechenzentrum durchschnittlich 6 ms beträgt. Wenn Daten in ein anderes Rechenzentrum übertragen werden, erhöht sich die Zeit um mehrere zehn Millisekunden.

Nachteile

• Der Hauptnachteil des gesamten Schemas besteht darin, dass für die sofortige Verkehrsumschaltung ein Balancer erforderlich ist, der sich nicht im selben Rechenzentrum wie der Hauptdienst befindet. Der Balancer ist der Fehlerpunkt: Wenn das Rechenzentrum mit dem Balancer ausfällt, ist Ihr Dienst in jedem Fall nicht mehr verfügbar.
• Sie müssen den Code auf einem anderen Server bereitstellen und zusätzliche Ressourcen überwachen. Überwachen Sie beispielsweise das Replikat, damit es nicht zu Verzögerungen kommt.

Fazit

Sie können kein System erstellen, das gegen alle Arten von Fehlern resistent ist. Trotzdem ist es machbar, sich vor bestimmten Typen zu schützen. Die im Artikel beschriebene Lösung, mit der die Verfügbarkeit der Anwendung bei Störungen im Rechenzentrum sichergestellt werden kann, kann in vielen Fällen in praktischen Anwendungen interessant und nützlich sein.

Die Konvertierung eines regulären Webdienstes in ein vollständig verteiltes System zum Schutz vor hypothetischen Ausfällen im Rechenzentrum ist höchstwahrscheinlich unpraktisch. Auf den ersten Blick erscheint sogar das vorgeschlagene Schema überflüssig und „schwer“, aber diese Nachteile werden durch seine Vorteile und die einfache Implementierung mehr als überlappt. Sie können eine Analogie zur Unfallversicherung ziehen: Es besteht eine hohe Wahrscheinlichkeit, dass Sie eine solche Versicherung niemals benötigen, aber wenn sich ein Unfall ereignet, ist dies sehr willkommen. Mit dem vorgeschlagenen Schema können Sie sicher sein, dass Sie immer ein Backup-System bereit haben, das bei kurzfristigen Problemen die Verfügbarkeit der meisten Servicemethoden sicherstellt und bei langen Ausfällen innerhalb weniger Minuten vollständig zum Hauptsystem wird. Viele werden zustimmen, diesen Preis für dieses Vertrauen zu zahlen.

Jedes System hat seine eigenen Lastparameter und Zugänglichkeitsanforderungen. Aus diesem Grund gibt es keine richtige oder falsche Antwort auf die Frage: "Können Sie Google Cloud oder AWS vollständig vertrauen?" - In jeder spezifischen Situation wird er sein eigener sein.