Geheimnisse der Fehlertoleranz unseres Front Office

Wie ist eine moderne Bank aufgebaut? Es gibt ein Backoffice, in dem verschiedene Vorgänge ausgeführt, Konten und Berichte geführt werden. Es gibt ein mittleres Büro, in dem Entscheidungen getroffen und Risiken bewertet werden, in dem Kreditrisiken bewertet und Betrügern entgegengewirkt wird. Und es gibt ein Front Office, in dem sie Kunden bedienen und über verschiedene Kanäle für die Interaktion mit der Bank verantwortlich sind.



Die Sberbank verfügt über Hunderte von Systemen mit unterschiedlicher Verfügbarkeit und Zuverlässigkeit. Es hat eine eigene Entwicklung und Boxed-Lösungen mit unterschiedlichem Anpassungsgrad und unterschiedlichen SLAs. Alle Systeme sind auf vielfältige Weise miteinander integriert. In diesem Beitrag erfahren Sie, wie dieser gesamte Front-End-Ameisenhaufen so gebaut ist, dass ein kontinuierlicher Kundenservice gewährleistet ist.

Beginnen wir mit der Theorie. Die wichtigsten Prinzipien, nach denen ein ausfallsicheres System aufgebaut ist, können von einem U-Boot ausgeliehen werden:

1. Das U-Boot ist in unabhängige Abteile unterteilt. Wenn ein Abteil überflutet ist, überlebt der Rest noch.
   
2. Alle kritischen Komponenten sind reserviert. Motoren, Sauerstofftanks. Und die Beatles reservierten auch Periskope mit Bullaugen.
   
3. Das U-Boot ist vor kritischen Bedingungen an der Oberfläche geschützt - bei Bedarf kann es tiefer gehen und dort arbeiten, als wäre nichts passiert.
   

Wir veranschaulichen das erste Prinzip anhand eines Beispiels aus unserer Praxis. Wir hatten ein verteiltes Cache-System. Und einmal unter Last ist einer der Cache-Datenknoten ausgefallen. Es ist in Ordnung: Um eine ordnungsgemäße Replikation aufrechtzuerhalten, verteilte der Controller die Daten auf die verbleibenden Knoten. Infolge der Umverteilung stieg der Netzwerkverkehr jedoch an und Pakete gingen verloren - einschließlich des Cache-Overheads. An einem Punkt entschied der Controller, dass ein anderer Datenknoten ausfiel, verteilte die Daten erneut, der Datenverkehr nahm zu ... Infolgedessen fiel das System in weniger als einer Minute vollständig aus. Zum Glück war es ein Lastkreis und niemand wurde verletzt. Aber wir haben viel Zeit damit verbracht, nach der Ursache zu suchen.

Es kann argumentiert werden, dass dies bei Clusterdatenbanken und High-End-Servern nicht der Fall ist - dort ist Redundanz auf Hardwareebene eingebaut. Um Werner Vogels, CTO Amazon, zu zitieren: „Alles scheitert ständig.“ Wir fielen und Datenbankcluster und High-End-Server. Stürzte aufgrund von Konfigurationsfehlern aufgrund von Problemen in der Verwaltungssoftware. Mit der Lösung jedes Problems nahm unser Vertrauen in solche Lösungen ab. Infolgedessen kamen wir zu dem Schluss: Nur diejenigen Systeme, die in voneinander unabhängige Teile unterteilt sind - hauptsächlich unabhängig im Management -, lehnen dies nicht ab.

Multi-Block-Architektur

Die Lösung für unsere Probleme war eine Mehrblockarchitektur. Darin sind alle Hardwarekomponenten, einschließlich Datenbanken, in lose gekoppelte, fast unabhängige Blöcke unterteilt. Jeder Block dient einem Teil der Clients, wie beim Sharding in Datenbanken. Die Knoten in jedem Block sind auf allen Ebenen reserviert, einschließlich Geo-Redundanz. Ein Problem in einem Block wirkt sich nicht auf die anderen aus. Mit zunehmender Anzahl von Kunden können wir problemlos neue Blöcke hinzufügen und normal weiterarbeiten.


Allgemeine Blockarchitektur. Alle Blöcke sind gemäß dem 2N-Schema reserviert. Jedes Rechenzentrum verfügt über einen leistungsstarken Hardware-Load-Balancer. Rechenzentren sind über 2-3 unabhängige Kommunikationskanäle verbunden.

Server sind in Blöcken von fünf Typen verteilt:

• Router - eine Steuereinheit, die Clients an die übrigen Einheiten verteilt
  
• Client-Block - Der Hauptblock, der bis zu 10 Millionen Clients bedient
  
• Pilotblock - hier testen wir neue Versionen von Anwendungen bei treuen Kunden (ca. 300.000 Personen, hauptsächlich Sberbank-Mitarbeiter)
  
• Gasteinheit - nicht authentifizierte Benutzer werden über diese Einheit bedient; diejenigen, die zum Beispiel durch die Website kommen
  
• Reserveblock - ein Sicherheitsblock, der stark genug ist, um zwei Clientblöcke gleichzeitig zu ersetzen
  

Innerhalb jedes Blocks sind der Anwendungsserver und der Webserver durch Dienstkanäle getrennt, aber die Datenbanken sind gemeinsam. So können wir die häufigsten Fehlerszenarien isolieren, damit sie nicht über die Grenzen unseres Kanals hinausgehen.

Wie funktioniert es

Zuerst betritt der Benutzer die Router-Einheit. Dieser Block prüft, zu welchem ​​Client-Block die Person gehört, und sendet ihn dorthin (oder an den Gastblock). Außerdem arbeitet eine Person ruhig in ihrem Block. Wenn in der nativen Einheit ein Fehler auftritt, kehrt die Person zum Router zurück und erhält automatisch eine Anweisung an die Sicherungseinheit zur weiteren Arbeit.

Was passiert mit Daten während des Betriebs? Informationen über die Interaktion des Kunden mit der Bank werden kontinuierlich von Kundenblöcken in die Archivdatenbank repliziert. Nachdem der Benutzer den Benutzer getroffen hat, ruft er die erforderlichen Informationen über ihn aus der Archivdatenbank ab und stellt bei Bedarf Daten bereit, sodass der Benutzer nicht einfriert, wenn Probleme unsererseits auftreten.

Die in der Sicherungseinheit ausgeführten Vorgänge werden darin gespeichert. Wenn der native Clientblock des Benutzers wiederhergestellt ist, geht er zurück. Die im Sicherungsblock akkumulierten Operationen werden asynchron auf die erforderlichen Clientblöcke übertragen. Während die Daten auf Konsistenz reduziert sind, wird dem Client eine Meldung angezeigt, dass alle Vorgänge akzeptiert und gespeichert wurden. Aufgrund technischer Arbeiten werden die neuesten Vorgänge möglicherweise nicht angezeigt.


Allgemeines Schema des Systems

In einigen Fällen ist der Wechsel zum Sicherungsblock im Voraus geplant - beispielsweise beim Aktualisieren im Clientblock. Dann nimmt die Sicherungseinheit keine Client-Sitzungen auf, sondern startet zu einem bestimmten Zeitpunkt einfach alle neuen Vorgänge. Wenn Sie dringend zur Sicherungseinheit wechseln müssen, kann der Administrator alle Sitzungen deaktivieren. In diesem Fall wird die Benutzersitzung unterbrochen und eine neue auf der Sicherungseinheit gestartet. Die Router-Einheit verfügt übrigens über eine eigene Backup-Einheit. So bleibt niemand ohne Reserverad.

Systemaktualisierung

Neue Softwareversionen werden zuerst auf dem Pilotblock bereitgestellt und einer begrenzten Zielgruppe angezeigt. Dann nach und nach auf den Client-Blöcken und schon am Ende - auf den Reserveblöcken. Wenn es also Probleme im Clientblock mit der neuen Version der Software gibt, können wir Clients vom alten auf den Sicherungsblock übertragen.

Wenn eine neue Funktionalität auf einen Block rollt, wird sie nicht automatisch eingeschaltet. Administratoren tun dies mithilfe von Kontrollkästchen - Funktionsumschaltung. Sie können Clients nach Gruppen auf die neue Version umstellen. Auf diese Weise überprüfen wir die Reaktion von Updates auf das Publikumswachstum.

Autonomie

Unser System an sich ist zuverlässig, hängt jedoch immer noch vom Backend ab, das für den Betrieb verwendet wird. Wie schützen Sie sich vor Problemen? Wir verwenden drei Werkzeuge.

1. Ausstehende Anfragen . Der Client fordert den Abschluss des Vorgangs an. Wir speichern es in unserer Datenbank und versuchen es im Backend auszuführen. Wenn das Backend nicht antwortet, zeigen wir dem Client eine Nachricht an, dass der Vorgang akzeptiert wurde und verarbeitet wird. Wenn das Backend ansteigt, liest ein separater "Docker" unvollständige Vorgänge aus der Datenbank und "schiebt" sie in Stapel im Backend-System. Um die Haupttabelle nicht mit Operationen mit einer großen Anzahl von Abfragen mit geringem Wirkungsgrad zu überladen, verwenden wir zusätzlich die sogenannte Token-Tabelle - eine Liste von Kennungen unvollständiger Operationen. Um das gerade um Hunderttausende von Vorgängen gestiegene Backend nicht zu löschen, verwenden wir Batching - wir löschen zweihundert Vorgänge und warten beispielsweise einige Sekunden.
   
   
   
   Was aber, wenn zwischen der Anforderung des Benutzers und der Wiederherstellung des Backends wichtige Änderungen vorgenommen wurden? Haben sich beispielsweise die Wechselkurse verschoben? In diesem Fall wird eine doppelte Überprüfung ausgelöst. Diese Vorgänge werden bei der Eingabe gespeichert und bei der Ausführung überprüft. Wenn etwas nicht konvergiert, wird der Vorgang angepasst oder abgelehnt.
   
2. Daten-Caching . Wenn ein Benutzer beispielsweise Sberbank Online betritt, sind bereits alle erforderlichen Informationen über ihn sichtbar - Rechnungen, Karten, Kredite usw. Diese Daten werden über einen Servicebus von einem Dutzend Systemen angefordert. Wenn die Antwort schnell erfasst wurde, zeigen wir die Daten dem Client in wenigen Sekunden an und speichern sie im Systemcache unserer Datenbank. Wenn nicht, suchen wir in der Datenbank nach zuvor zwischengespeicherten Daten und zeigen sie dem Client an. Dazu darf der Cache natürlich nicht älter als ein bestimmtes Alter sein. Wenn der Servicebus dennoch die erforderlichen Daten bei Bedarf sammelt, werden diese im Datenbankcache aktualisiert und anstelle älterer Daten an den Client gesendet.
   
   Wenn Sie die Anwendung verwenden, bedeutet dies, dass eine Person einige Sekunden nach der Eingabe den Status ihres Kontos sieht. Obwohl die Daten etwas veraltet sein können. In diesem Fall werden die Daten in der Regel nach einigen Sekunden durch die tatsächlichen Daten ersetzt. Dies bedeutet, dass der Servicebus alles gesammelt hat, was Sie benötigen.
   
   Darüber hinaus haben wir Pre-Caching mit Replikation. Meistens für unterschiedliche Referenzdaten. Wir laden diese Daten vorab in das Backend, der Client stellt ruhig eine Anfrage für den Vorgang und wir senden sie. Auch wenn die für die Datenpflege verantwortlichen Systeme nicht funktionieren, muss der Benutzer nicht noch einmal warten.
   
3. Technische Pausen . Wenn das Backend-System abgestürzt ist oder gewartet wird, kennzeichnen wir es. Und dann werden die durchlaufenden Operationen sofort von der Ablehnung erfüllt. Daher verhindern wir, dass der Anwendungsserver mit Anforderungen überfüllt ist, die auf eine Antwort per Timeout warten. In diesem Modus kann das zuvor beschriebene Caching von Operationen und Daten verwendet werden. Technische Pausen werden für jedes Integrationsszenario manuell vom Administrator oder automatisch festgelegt, basierend auf der Anzahl der Anforderungen.
   

In jedem Fall versuchen wir, die Erwartungen des Benutzers zu minimieren. Wenn es Probleme gibt, erhält er sofort eine Nachricht über die Unmöglichkeit des Vorgangs. Wir versuchen, die Anzahl solcher Nachrichten zu minimieren, daher verlängern wir die Lebensdauer einiger zwischengespeicherter Daten. Dadurch können wir die normale Interaktion mit den Diensten der Bank verlängern.

In einigen Szenarien sollte das Caching nicht weggenommen werden - beispielsweise bei der Ausgabe von Bargeld. Es ist möglicher Betrug seitens des Kunden. Solche Operationen an Geldautomaten und Filialen werden nicht zwischengespeichert. In der Internetbank ist dies einfacher - wir akzeptieren den Antrag, bearbeiten ihn dann oder lehnen ihn ab.

Wenn Sie die im Artikel beschriebenen Prinzipien beachten, erhalten Sie Systeme mit einer Verfügbarkeit von 99,99% und höher.

Unsere Pläne

Jetzt ist geplant, die Markteinführungszeit unseres einzelnen Systems zu minimieren, um die Omnichannelität unter Berücksichtigung der technischen und geschäftlichen Merkmale der Kanäle sicherzustellen. Migrieren Sie auch Legacy-Systeme, während Sie während des Umzugs funktionsfähig bleiben.

Wir danken Roman Shekhovtsov für die aktive Unterstützung bei der Vorbereitung des Postens