Standbild aus dem Film „Unser geheimes Universum: Das verborgene Leben der Zelle“

Das Investmentgeschäft ist einer der komplexesten Bereiche der Bankenwelt, denn es gibt nicht nur Kredite, Anleihen und Einlagen, sondern auch Wertpapiere, Währungen, Rohstoffe, Derivate und allerlei Komplexitäten in Form von strukturierten Produkten.

In letzter Zeit beobachten wir einen Anstieg der Finanzkompetenz der Bevölkerung. Immer mehr Menschen engagieren sich im Handel an den Wertpapiermärkten. Individuelle Anlagekonten sind vor nicht allzu langer Zeit aufgetaucht. Sie ermöglichen es Ihnen, an den Wertpapiermärkten zu handeln und entweder Steuerabzüge zu erhalten oder die Zahlung von Steuern zu vermeiden. Und alle Kunden, die zu uns kommen, möchten ihr Portfolio verwalten und Berichte in Echtzeit sehen. Darüber hinaus handelt es sich bei diesem Portfolio meist um Multiproduktportfolios, d. h. die Menschen sind Kunden verschiedener Geschäftsbereiche.

Darüber hinaus wachsen die Anforderungen russischer und ausländischer Regulierungsbehörden.

Um den aktuellen Anforderungen gerecht zu werden und den Grundstein für zukünftige Upgrades zu legen, haben wir einen auf Tarantool basierenden Investitionsgeschäftskern entwickelt.

Einige Statistiken. Das Investmentgeschäft der Alfa-Bank bietet Maklerdienstleistungen für Einzelpersonen und juristische Personen, um die Möglichkeit zum Handel auf verschiedenen Wertpapiermärkten zu bieten, Depotdienstleistungen für die Aufbewahrung von Wertpapieren, Treuhandverwaltungsdienstleistungen für Einzelpersonen mit privatem und großem Kapital sowie Dienstleistungen für die Ausgabe von Wertpapieren für andere Unternehmen . Das Investmentgeschäft der Alfa-Bank umfasst mehr als 3 Kurse pro Sekunde, die von verschiedenen Handelsplattformen heruntergeladen werden. Im Laufe des Arbeitstages werden auf den Märkten im Namen der Bank oder ihrer Kunden mehr als 300 Transaktionen abgeschlossen. Auf externen und internen Plattformen finden bis zu 5 Orderausführungen pro Sekunde statt. Gleichzeitig möchten alle Kunden, sowohl interne als auch externe, ihre Positionen in Echtzeit sehen.

Vorgeschichte

Irgendwann seit Anfang der 2000er Jahre entwickelten sich unsere Bereiche des Investmentgeschäfts eigenständig: Börsenhandel, Maklerdienstleistungen, Devisenhandel, außerbörslicher Handel mit Wertpapieren und verschiedenen Derivaten. Dadurch sind wir in die Falle funktionsfähiger Brunnen getappt. Was ist das? Jeder Geschäftsbereich verfügt über eigene Systeme, die die Funktionen der anderen Geschäftsbereiche duplizieren. Jedes System verfügt über ein eigenes Datenmodell, obwohl sie mit denselben Konzepten arbeiten: Transaktionen, Instrumente, Gegenparteien, Kurse und so weiter. Und da sich jedes System unabhängig weiterentwickelte, entstand ein vielfältiger Zoo an Technologien.

Zudem ist die Codebasis der Systeme bereits recht veraltet, da einige Produkte ihren Ursprung in der Mitte der 1990er Jahre haben. Und in einigen Bereichen verlangsamte dies den Entwicklungsprozess und es kam zu Performance-Problemen.

Anforderungen an eine neue Lösung

Unternehmen haben erkannt, dass der technologische Wandel für die weitere Entwicklung von entscheidender Bedeutung ist. Uns wurden Aufgaben gestellt:

1. Sammeln Sie alle Geschäftsdaten in einem einzigen, schnellen Speicher und in einem einzigen Datenmodell.
2. Wir dürfen diese Informationen nicht verlieren oder ändern.
3. Es ist notwendig, die Daten zu versionieren, da die Regulierungsbehörde jederzeit Statistiken für frühere Jahre anfordern kann.
4. Wir müssen nicht nur ein neues, modisches DBMS einführen, sondern eine Plattform zur Lösung geschäftlicher Probleme schaffen.

Darüber hinaus legen unsere Architekten ihre eigenen Bedingungen fest:

1. Die neue Lösung muss Enterprise-Klasse sein, das heißt, sie muss bereits in einigen großen Unternehmen getestet werden.
2. Der Betriebsmodus der Lösung sollte geschäftskritisch sein. Das heißt, wir müssen in mehreren Rechenzentren gleichzeitig präsent sein und den Ausfall eines Rechenzentrums gelassen überstehen.
3. Das System muss horizontal skalierbar sein. Tatsache ist, dass alle unsere aktuellen Systeme nur vertikal skalierbar sind und wir aufgrund des geringen Wachstums der Hardwareleistung bereits an die Grenze stoßen. Daher ist der Moment gekommen, in dem wir ein horizontal skalierbares System benötigen, um zu überleben.
4. Unter anderem wurde uns gesagt, dass die Lösung günstig sein müsse.

Wir gingen den Standardweg: Wir formulierten die Anforderungen und kontaktierten den Einkauf. Von dort erhielten wir eine Liste von Unternehmen, die grundsätzlich bereit sind, dies für uns zu tun. Wir haben allen von dem Problem erzählt und von sechs von ihnen eine Bewertung der Lösungen erhalten.

Bei der Bank verlassen wir uns nicht auf das Wort von irgendjemandem, sondern testen gerne alles selbst. Eine zwingende Voraussetzung unseres Ausschreibungswettbewerbs war daher das Bestehen der Belastungstests. Wir haben Lasttestaufgaben formuliert und drei von sechs Unternehmen haben sich bereits bereit erklärt, auf eigene Kosten eine prototypische Lösung auf Basis von In-Memory-Technologien zu implementieren und zu testen.

Ich werde Ihnen nicht sagen, wie wir alles getestet haben und wie lange es gedauert hat. Ich fasse nur zusammen: Die beste Leistung bei Lasttests zeigte eine Prototyplösung auf Basis von Tarantool vom Entwicklungsteam der Mail.ru Group. Wir unterzeichneten eine Vereinbarung und begannen mit der Entwicklung. Es waren vier Personen von der Mail.ru Group und von der Alfa-Bank drei Entwickler, drei Systemanalysten, ein Lösungsarchitekt, ein Produktbesitzer und ein Scrum-Master.

Als nächstes erzähle ich Ihnen, wie unser System gewachsen ist, wie es sich entwickelt hat, was wir getan haben und warum genau das passiert ist.

Entwicklung

Die erste Frage, die wir uns stellten, war, wie wir Daten aus unseren aktuellen Systemen erhalten. Wir haben entschieden, dass HTTP für uns durchaus geeignet ist, da alle aktuellen Systeme miteinander kommunizieren, indem sie XML oder JSON über HTTP senden.

Wir verwenden den in Tarantool integrierten HTTP-Server, da wir SSL-Sitzungen nicht beenden müssen und seine Leistung für uns ausreichend ist.

Wie ich bereits sagte, leben alle unsere Systeme in unterschiedlichen Datenmodellen, und am Eingang müssen wir das Objekt in das Modell bringen, das wir selbst beschreiben. Es wurde eine Sprache benötigt, die die Transformation von Daten ermöglichte. Wir haben uns für den Imperativ Lua entschieden. Wir führen den gesamten Datenkonvertierungscode in einer Sandbox aus – dies ist ein sicherer Ort, über den der laufende Code nicht hinausgeht. Dazu laden wir einfach den erforderlichen Code per Loadstring und schaffen so eine Umgebung mit Funktionen, die nichts blockieren oder löschen können.

Nach der Konvertierung müssen die Daten auf Übereinstimmung mit dem von uns erstellten Modell überprüft werden. Wir diskutierten lange darüber, wie das Modell aussehen sollte und mit welcher Sprache wir es beschreiben sollten. Wir haben uns für Apache Avro entschieden, weil die Sprache einfach ist und von Tarantool unterstützt wird. Neue Versionen des Modells und des benutzerdefinierten Codes können mehrmals täglich, auch unter Last oder ohne, zu jeder Tageszeit in Betrieb genommen werden und passen sich sehr schnell an Änderungen an.

Nach der Überprüfung müssen die Daten gespeichert werden. Wir tun dies mit vshard (wir haben geografisch verteilte Replikate von Shards).

Darüber hinaus ist die Besonderheit so groß, dass es den meisten Systemen, die uns Daten senden, egal ist, ob wir sie erhalten haben oder nicht. Deshalb haben wir von Anfang an eine Reparaturwarteschlange implementiert. Was ist das? Wenn ein Objekt aus irgendeinem Grund keiner Datentransformation oder Überprüfung unterzogen wird, bestätigen wir trotzdem den Empfang, speichern das Objekt aber gleichzeitig in der Reparaturwarteschlange. Es ist konsistent und befindet sich im Hauptdatenlager des Unternehmens. Wir haben sofort eine Administratoroberfläche dafür geschrieben, verschiedene Metriken und Warnungen. Dadurch gehen uns keine Daten verloren. Selbst wenn sich in der Quelle etwas geändert hat, erkennen wir eine Änderung des Datenmodells sofort und können uns anpassen.

Jetzt müssen Sie lernen, wie Sie gespeicherte Daten abrufen. Wir haben unsere Systeme sorgfältig analysiert und festgestellt, dass der klassische Stack von Java und Oracle notwendigerweise eine Art ORM enthält, das Daten von relationalen in objektbezogene Daten umwandelt. Warum also nicht gleich Objekte in Form eines Graphen an Systeme übergeben? Deshalb haben wir GraphQL gerne übernommen, da es alle unsere Anforderungen erfüllte. Es ermöglicht Ihnen, Daten in Form von Diagrammen zu empfangen und nur das abzurufen, was Sie gerade benötigen. Sie können die API sogar mit ziemlich viel Flexibilität versionieren.

Fast sofort wurde uns klar, dass die Daten, die wir extrahierten, nicht ausreichten. Wir haben Funktionen erstellt, die mit Objekten im Modell verknüpft werden können – im Wesentlichen berechnete Felder. Das heißt, wir fügen dem Feld eine bestimmte Funktion hinzu, die beispielsweise den durchschnittlichen Angebotspreis berechnet. Und der externe Verbraucher, der die Daten anfordert, weiß nicht einmal, dass es sich um ein berechnetes Feld handelt.

Ein Authentifizierungssystem wurde implementiert.

Dann stellten wir fest, dass sich in unserer Entscheidung mehrere Rollen herauskristallisierten. Eine Rolle ist eine Art Aggregator von Funktionen. Normalerweise haben Rollen unterschiedliche Gerätenutzungsprofile:

• T-Connect: Verarbeitet eingehende Verbindungen, CPU-begrenzt, geringer Speicherverbrauch, zustandslos.
• IB-Core: transformiert die Daten, die es über das Tarantool-Protokoll empfängt, d. h. es arbeitet mit Tabellen. Es speichert außerdem keinen Status und ist skalierbar.
• Speicherung: speichert nur Daten, verwendet keine Logik. Diese Rolle implementiert die einfachsten Schnittstellen. Skalierbar dank vshard.

Das heißt, wir haben mithilfe von Rollen verschiedene Teile des Clusters voneinander entkoppelt, die unabhängig voneinander skaliert werden können.

Deshalb haben wir eine asynchrone Aufzeichnung des Transaktionsdatenflusses und eine Reparaturwarteschlange mit einer Admin-Schnittstelle erstellt. Aus geschäftlicher Sicht ist die Aufzeichnung asynchron: Wenn wir garantiert Daten in uns selbst schreiben, egal wo, dann werden wir dies bestätigen. Wird dies nicht bestätigt, ist ein Fehler aufgetreten und die Daten müssen gesendet werden. Dies ist die asynchrone Aufzeichnung.

Testing

Gleich zu Beginn des Projekts haben wir beschlossen, dass wir versuchen würden, eine testgetriebene Entwicklung umzusetzen. Wir schreiben Unit-Tests in Lua mit dem Tarantool/Tap-Framework und Integrationstests in Python mit dem Pytest-Framework. Gleichzeitig beziehen wir sowohl Entwickler als auch Analysten in die Erstellung von Integrationstests ein.

Wie nutzen wir testgetriebene Entwicklung?

Wenn wir eine neue Funktion wünschen, versuchen wir zunächst, einen Test dafür zu schreiben. Wenn wir einen Fehler entdecken, schreiben wir zunächst einen Test und beheben ihn erst dann. Anfangs ist es schwierig, so zu arbeiten, es kommt zu Missverständnissen seitens der Mitarbeiter, ja sogar zu Sabotage: „Lasst uns das jetzt schnell beheben, etwas Neues machen und es dann mit Tests abdecken.“ Nur dieses „später“ kommt fast nie.

Daher müssen Sie sich dazu zwingen, zuerst Tests zu schreiben und andere darum zu bitten. Glauben Sie mir, testgetriebene Entwicklung bringt auch kurzfristig Vorteile. Sie werden spüren, dass Ihr Leben einfacher geworden ist. Wir sind der Meinung, dass mittlerweile 99 % des Codes durch Tests abgedeckt sind. Das scheint viel zu sein, aber wir haben keine Probleme: Bei jedem Commit werden Tests ausgeführt.

Was wir jedoch am meisten lieben, sind Lasttests; wir halten sie für das Wichtigste und führen sie regelmäßig durch.

Ich erzähle Ihnen eine kleine Geschichte darüber, wie wir die erste Phase des Lasttests einer der ersten Versionen durchgeführt haben. Wir haben das System auf dem Laptop des Entwicklers installiert, die Last eingeschaltet und 4 Transaktionen pro Sekunde empfangen. Gutes Ergebnis für einen Laptop. Wir haben es auf einer virtuellen Lastbank mit vier Servern installiert, schwächer als in der Produktion. Auf ein Minimum reduziert. Wir starten es und erhalten in einem Thread ein schlechteres Ergebnis als auf einem Laptop. Schockierter Inhalt.

Wir waren sehr traurig. Wir schauen uns die Serverauslastung an, aber es stellt sich heraus, dass sie im Leerlauf sind.

Wir rufen die Entwickler an und sie erklären uns, Leuten, die aus der Java-Welt kommen, dass Tarantool Single-Threaded ist. Unter Last kann er nur von einem Prozessorkern effektiv genutzt werden. Dann haben wir die maximal mögliche Anzahl an Tarantool-Instanzen auf jedem Server bereitgestellt, die Last eingeschaltet und bereits 14,5 Tausend Transaktionen pro Sekunde empfangen.

Lassen Sie es mich noch einmal erklären. Aufgrund der Aufteilung in Rollen, die Ressourcen unterschiedlich nutzen, belasteten unsere Rollen, die für die Verarbeitung von Verbindungen und die Datentransformation verantwortlich sind, nur den Prozessor und zwar streng proportional zur Last.

In diesem Fall wurde der Speicher nur für die Verarbeitung eingehender Verbindungen und temporärer Objekte verwendet.

Im Gegenteil, auf Speicherservern stieg die Prozessorlast, allerdings deutlich langsamer als auf Servern, die Verbindungen verarbeiten.

Und der Speicherverbrauch stieg direkt proportional zur Menge der geladenen Daten.

Dienstleistungen

Um unser neues Produkt speziell als Anwendungsplattform zu entwickeln, haben wir eine Komponente für die Bereitstellung von Diensten und Bibliotheken darauf erstellt.

Dienste sind nicht nur kleine Codeteile, die bestimmte Felder bearbeiten. Dabei kann es sich um recht große und komplexe Strukturen handeln, die Teil eines Clusters sind, Referenzdaten prüfen, Geschäftslogik ausführen und Antworten zurückgeben. Wir exportieren das Serviceschema auch nach GraphQL, und der Verbraucher erhält einen universellen Zugriffspunkt auf die Daten mit Selbstbeobachtung über das gesamte Modell. Es ist sehr bequem.

Da Dienste viel mehr Funktionen enthalten, haben wir beschlossen, dass es Bibliotheken geben sollte, in die wir häufig verwendeten Code verschieben. Wir haben sie der sicheren Umgebung hinzugefügt, nachdem wir zuvor überprüft hatten, dass es für uns keine Schäden verursacht. Und jetzt können wir Funktionen zusätzliche Umgebungen in Form von Bibliotheken zuweisen.

Wir wollten eine Plattform nicht nur für die Speicherung, sondern auch für die Datenverarbeitung. Und da wir bereits eine Menge Replikate und Shards hatten, implementierten wir eine Art verteiltes Rechnen und nannten es Map Reduce, weil es dem ursprünglichen Map Reduce ähnelte.

Alte Systeme

Nicht alle unserer Legacy-Systeme können uns über HTTP anrufen und GraphQL verwenden, obwohl sie das Protokoll unterstützen. Deshalb haben wir einen Mechanismus geschaffen, der die Replikation von Daten in diese Systeme ermöglicht.

Wenn sich für uns etwas ändert, werden in der Storage-Rolle eindeutige Trigger ausgelöst und die Nachricht mit den Änderungen landet in der Verarbeitungswarteschlange. Es wird über eine separate Replikatorrolle an ein externes System gesendet. Diese Rolle speichert keinen Status.

Neue Verbesserungen

Wie Sie sich erinnern, haben wir aus geschäftlicher Sicht eine asynchrone Aufzeichnung durchgeführt. Dann wurde ihnen jedoch klar, dass dies nicht ausreichen würde, da es eine Klasse von Systemen gibt, die sofort eine Antwort über den Status des Vorgangs erhalten müssen. Also haben wir unser GraphQL erweitert und Mutationen hinzugefügt. Sie fügen sich organisch in das bestehende Paradigma der Arbeit mit Daten ein. Für uns ist dies ein einziger Lese- und Schreibpunkt für eine andere Klasse von Systemen.

Wir haben auch erkannt, dass Dienstleistungen allein für uns nicht ausreichen würden, da es ziemlich umfangreiche Berichte gibt, die einmal am Tag, in der Woche, im Monat erstellt werden müssen. Dies kann lange dauern und Berichte können sogar die Ereignisschleife von Tarantool blockieren. Aus diesem Grund haben wir separate Rollen erstellt: Planer und Läufer. Runner speichern keinen Status. Sie erledigen schwere Aufgaben, die wir nicht im Handumdrehen berechnen können. Und die Scheduler-Rolle überwacht den Startplan dieser Aufgaben, der in der Konfiguration beschrieben wird. Die Aufgaben selbst werden am selben Ort wie die Geschäftsdaten gespeichert. Wenn der richtige Zeitpunkt gekommen ist, übernimmt der Planer die Aufgabe, gibt sie an einen Läufer weiter, der sie zählt und das Ergebnis speichert.

Nicht alle Aufgaben müssen nach einem Zeitplan ausgeführt werden. Einige Berichte müssen auf Anfrage gelesen werden. Sobald diese Anforderung eintrifft, wird in der Sandbox eine Aufgabe erstellt und zur Ausführung an den Runner gesendet. Nach einiger Zeit erhält der Benutzer eine asynchrone Antwort, dass alles berechnet wurde und der Bericht fertig ist.

Zunächst hielten wir an dem Paradigma fest, alle Daten zu speichern, zu versionieren und nicht zu löschen. Aber im Leben muss man von Zeit zu Zeit immer noch etwas löschen, meist Roh- oder Zwischeninformationen. Basierend auf dem Ablaufdatum haben wir einen Mechanismus zum Bereinigen des Speichers von veralteten Daten erstellt.

Wir verstehen auch, dass es früher oder später zu einer Situation kommen wird, in der nicht mehr genügend Platz zum Speichern von Daten im Speicher vorhanden ist, die Daten aber dennoch gespeichert werden müssen. Für diese Zwecke werden wir bald Festplattenspeicher schaffen.

Abschluss

Wir begannen mit der Aufgabe, Daten in ein einzelnes Modell zu laden, und verbrachten drei Monate damit, es zu entwickeln. Wir hatten sechs Datenversorgungssysteme. Der gesamte Transformationscode in ein einzelnes Modell umfasst in Lua etwa 30 Zeilen. Und der Großteil der Arbeit liegt noch vor uns. Manchmal fehlt die Motivation benachbarter Teams und es gibt viele Umstände, die die Arbeit erschweren. Wenn Sie jemals vor einer ähnlichen Aufgabe stehen, multiplizieren Sie die Zeit, die Ihnen für die Umsetzung normal erscheint, mit drei oder sogar vier.

Denken Sie auch daran, dass bestehende Probleme in Geschäftsprozessen nicht mit einem neuen DBMS gelöst werden können, auch nicht mit einem sehr produktiven. Was ich meine? Zu Beginn unseres Projekts haben wir bei den Kunden den Eindruck erweckt, dass wir jetzt eine neue schnelle Datenbank bringen und leben werden! Die Prozesse werden schneller gehen, alles wird gut. Tatsächlich löst Technologie die Probleme von Geschäftsprozessen nicht, denn bei Geschäftsprozessen handelt es sich um Menschen. Und Sie müssen mit Menschen arbeiten, nicht mit Technologie.

Testgetriebene Entwicklung kann in der Anfangsphase schmerzhaft und zeitaufwändig sein. Der positive Effekt wird sich jedoch auch kurzfristig bemerkbar machen, wenn Sie für die Durchführung von Regressionstests nichts tun müssen.

Es ist äußerst wichtig, in allen Phasen der Entwicklung Lasttests durchzuführen. Je früher Sie einen Fehler in der Architektur bemerken, desto einfacher ist es, ihn zu beheben, was Ihnen in Zukunft viel Zeit sparen wird.

Mit Lua ist nichts falsch. Jeder kann darin schreiben lernen: Java-Entwickler, JavaScript-Entwickler, Python-Entwickler, Front-End oder Back-End. Sogar unsere Analysten schreiben darüber.

Wenn wir darüber sprechen, dass wir kein SQL haben, versetzt das die Menschen in Angst und Schrecken. „Wie kommt man an Daten ohne SQL? Ist das möglich? Sicherlich. In einem OLTP-Klassensystem ist SQL nicht erforderlich. Es gibt eine Alternative in Form einer Sprache, die Sie sofort zu einer dokumentorientierten Ansicht zurückführt. Zum Beispiel GraphQL. Und es gibt eine Alternative in Form von verteiltem Rechnen.

Wenn Sie verstehen, dass Sie skalieren müssen, entwerfen Sie Ihre Lösung auf Tarantool so, dass sie auf Dutzenden von Tarantool-Instanzen parallel ausgeführt werden kann. Wenn Sie dies nicht tun, wird es später schwierig und schmerzhaft, da Tarantool nur einen Prozessorkern effektiv nutzen kann.

Source: habr.com