{"id":92806,"date":"2020-08-31T07:42:03","date_gmt":"2020-08-31T05:42:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita"},"modified":"2020-08-31T07:42:03","modified_gmt":"2020-08-31T05:42:03","slug":"kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita","title":{"rendered":"Wie man aufh\u00f6rt sich zu sorgen und beginnt, ohne Monolith zu leben","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Wie
\n
\nWir alle lieben Geschichten. Es macht uns Freude, am Lagerfeuer von unseren fr\u00fcheren Siegen, K\u00e4mpfen oder einfach von unseren Erfahrungen zu erz\u00e4hlen.<\/p>\n

Heute ist genau so ein Tag. Und auch wenn ihr gerade nicht am Lagerfeuer sitzt, haben wir eine Geschichte f\u00fcr euch. Eine Geschichte dar\u00fcber, wie wir begannen, mit dem Tarantool-Speicher zu arbeiten.<\/p>\n

Es war einmal in unserem Unternehmen, dass es einige 'Monolithen' gab und eine gemeinsame 'Decke', die diese Monolithen langsam, aber sicher n\u00e4her kamen, und so den Flug unseres Unternehmens und unser Wachstum einschr\u00e4nkten. Es gab ein klares Verst\u00e4ndnis: Eines Tages w\u00fcrden wir gegen diese Decke sto\u00dfen.
\n<\/a><\/noindex>
\nHeute herrscht bei uns die Ideologie der Trennung von allem, angefangen bei der Hardware bis hin zur Gesch\u00e4ftslogik. Infolgedessen haben wir beispielsweise zwei Rechenzentren, die auf Netzwerkebene praktisch unabh\u00e4ngig sind. Damals war alles ganz anders.<\/p>\n

Heutzutage gibt es viele Werkzeuge und Mittel zur Implementierung von \u00c4nderungen in Form von CI\/CD, K8S usw. In der 'Monolith-Zeit' ben\u00f6tigten wir so viele fremde Begriffe nicht. Es gen\u00fcgte, einfach die 'Datenbank' zu korrigieren.<\/p>\n

Aber die Zeit verging, und die Anzahl der Anfragen wuchs mit ihr, wobei die RPS gelegentlich \u00fcber unsere M\u00f6glichkeiten hinaus schoss. Mit dem Markteintritt in den GUS-Staaten fiel die CPU-Auslastung des ersten Monolithen nie unter 90 %, und die RPS lagen bei 2400. Und das waren keine einfachen Abfragen, sondern umfangreiche Anfragen mit zahlreichen Pr\u00fcfungen und JOINs, die fast die H\u00e4lfte der Daten in einem gro\u00dfen IO durchsuchen konnten.<\/p>\n

Als dann vollst\u00e4ndige Rabatte am \"Black Friday\" auftraten \u2013 und Wildberries begann, diese als eines der ersten Unternehmen in Russland anzubieten \u2013 wurde die Situation wirklich trist. Denn die Last an solchen Tagen steigt dreimal an.
\nAch, diese \u201emonolithischen Zeiten\u201c! Ich bin mir sicher, dass auch Sie damit konfrontiert waren und bis heute nicht verstehen k\u00f6nnen, wie so etwas Ihnen passieren konnte.<\/p>\n

Was soll man tun \u2013 Mode geh\u00f6rt auch zu den Technologien. Vor etwa f\u00fcnf Jahren mussten wir einen solchen Trend \u00fcberdenken, in Form einer bestehenden Website auf .NET und MS SQL-Servern, die alle Logik der Website sorgf\u00e4ltig speicherte. So sorgf\u00e4ltig, dass es sich als langwierige und ziemlich unangenehme Aufgabe herausstellte, einen solchen Monolithen zu zerlegen.
\nEin kleiner Einschub. <\/p>\n

Bei verschiedenen Veranstaltungen sage ich: \u201eWenn Sie den Monolithen nicht aufteilen, sind Sie nicht gewachsen!\u201c Ich w\u00fcrde gerne Ihre Meinung dazu h\u00f6ren, bitte schreiben Sie sie in die Kommentare.<\/p>\n

Und der Donner ging nieder<\/h3>\n

\nKehren wir zu unserem \u201eMonolithen\u201c zur\u00fcck. Um die Last der \u201emonolithischen\u201c Funktionalit\u00e4t zu verteilen, haben wir beschlossen, das System in Mikrodienste zu unterteilen, die auf Open-Source-Technologien basieren. Denn deren Skalierung ist mindestens kosteng\u00fcnstiger. Und wir wussten ganz genau, dass wir in der Lage sein w\u00fcrden zu skalieren (und das ziemlich stark). Schlie\u00dflich hatten wir zu diesem Zeitpunkt bereits die M\u00e4rkte der Nachbarl\u00e4nder erreicht, und die Anzahl der Registrierungen sowie die Anzahl der Bestellungen begannen noch st\u00e4rker zu steigen.<\/p>\n

Nachdem wir die ersten Kandidaten f\u00fcr den Wechsel von Monolithen zu Mikrodiensten analysiert hatten, verstanden wir, dass in 80 % der F\u00e4lle 99 % der Schreibvorg\u00e4nge von Back-Office-Systemen stammen, w\u00e4hrend das Lesen von der Front kommt. Dies betraf zun\u00e4chst zwei f\u00fcr uns wichtige Teilsysteme \u2014 Nutzerdaten und das System zur Berechnung des Endpreises von Waren auf Basis von Informationen \u00fcber zus\u00e4tzliche Kundenerm\u00e4\u00dfigungen und Gutscheine.<\/p>\n

In Anf\u00fchrungszeichen. Es ist schwer vorstellbar, aber neben den oben genannten Subsystemen wurden auch Produktkataloge, der Warenkorb, ein Produktsuchsystem, ein Filtersystem f\u00fcr Produktkataloge und verschiedene Empfehlungssysteme aus unserem Monolithen ausgegliedert. F\u00fcr jeden von ihnen gibt es separate Klassen von spezialisierten Systemen, aber einst lebten sie alle in einem \"Haus\". <\/p>\n

Die Daten \u00fcber unsere Kunden sollten sofort in ein sharding-basiertes System ausgelagert werden. Die Auslagerung der Funktionalit\u00e4t zur Berechnung der Endpreise der Produkte erforderte jedoch eine gute Skalierbarkeit im Lesen, da diese die gr\u00f6\u00dfte Last in Bezug auf RPS verursachte und f\u00fcr die Datenbank am kompliziertesten umzusetzen war (sehr viele Daten sind in den Berechnungsprozess involviert). <\/p>\n

Infolgedessen entstand bei uns ein Schema, das gut mit Tarantool harmoniert.<\/p>\n

Zu dieser Zeit wurden f\u00fcr den Betrieb der Mikrodienste Schemas mit mehreren Rechenzentren auf virtuellen und physischen Maschinen gew\u00e4hlt. Wie in den Abbildungen gezeigt, wurden sowohl Master-Master- als auch Master-Slave-Replikationsvarianten von Tarantool verwendet. <\/p>\n

\"Wie
\nArchitektur. Variante 1. Benutzerservice<\/i><\/p>\n

Aktuell besteht dies aus 24 Shards, von denen jeder 2 Instanzen hat (eine f\u00fcr jedes Rechenzentrum), alle im Master-Master-Modus.<\/p>\n

\u00dcber der Datenbank befinden sich Anwendungen, die auf die Replikate zugreifen. Die Anwendungen arbeiten mit Tarantool \u00fcber unsere benutzerdefinierte Bibliothek, die die Schnittstelle des Go-Tarantool-Treibers implementiert. Sie sieht alle Replikate und kann mit dem Master lesen und schreiben. Im Wesentlichen implementiert sie ein Replica-Set-Modell, bei dem Logik f\u00fcr die Auswahl der Replikate, Wiederholungsversuche, Circuit Breaker und Rate Limiting hinzugef\u00fcgt wurde.<\/p>\n

Dabei gibt es die M\u00f6glichkeit, die Auswahlpolitik der Replikate auf Shard-Ebene zu konfigurieren. Zum Beispiel durch Round-Robin.<\/p>\n

\"Wie
\nArchitektur. Option 2. Dienst zur Berechnung der Endpreise von Waren.<\/i><\/p>\n

Vor einigen Monaten ging der Gro\u00dfteil der Anfragen zur Berechnung der Endpreise von Waren an einen neuen Dienst, der grunds\u00e4tzlich ohne Datenbanken funktioniert, aber vor einiger Zeit wurden alle 100% vom Dienst mit Tarantool im Hintergrund verarbeitet.<\/p>\n

Die Datenbank des Dienstes besteht aus 4 Mastern, in denen der Synchronisierer Daten sammelt, und jeder dieser Master verteilt den Daten \u00fcber readonly-Replikate. Jeder Master hat etwa 15 solcher Replikate.<\/p>\n

Sowohl im ersten als auch im zweiten Schema kann die Anwendung bei Nichtverf\u00fcgbarkeit eines Rechenzentrums Daten aus dem zweiten abrufen.<\/p>\n

Es ist erw\u00e4hnenswert, dass die Replikation in Tarantool ziemlich flexibel ist und zur Laufzeit konfiguriert werden kann. In anderen Systemen gab es diesbez\u00fcglich Schwierigkeiten. Zum Beispiel erfordert die \u00c4nderung der Parameter max_wal_senders und max_replication_slots in PostgreSQL einen Neustart des Masters, was in einigen F\u00e4llen zu Verbindungsabbr\u00fcchen zwischen der Anwendung und der Datenbank f\u00fchren kann.<\/p>\n

Suche und du wirst finden!<\/h3>\n

\nWarum haben wir nicht \u201ewie normale Menschen\u201c gehandelt und einen typischen Weg gew\u00e4hlt? Es h\u00e4ngt davon ab, was man als normal ansieht. Viele erstellen \u00fcberhaupt ein Cluster aus MongoDB und verteilen es \u00fcber drei geo-redundante Rechenzentren.<\/p>\n

Zu diesem Zeitpunkt hatten wir bereits zwei Projekte auf Redis. Das erste war ein Cache, das zweite diente als persistentes Speicher f\u00fcr nicht allzu kritische Daten. Damit hatten wir es ziemlich schwer, teilweise wegen unserer eigenen Fehler. Manchmal waren ziemlich gro\u00dfe Datenmengen in einem Schl\u00fcssel gespeichert, und von Zeit zu Zeit hatte die Website Performance-Probleme. Dieses System nutzten wir im Master-Slave-Modus. Es gab viele F\u00e4lle, in denen etwas mit dem Master passierte und die Replikation unterbrochen wurde. <\/p>\n

Das bedeutet, dass Redis gut f\u00fcr zustandslose Aufgaben ist, nicht f\u00fcr zustandsbehaftete. Im Grunde genommen konnte es die meisten Aufgaben erf\u00fcllen, aber nur, wenn es sich um Key-Value-L\u00f6sungen mit ein paar Indizes handelte. Zu diesem Zeitpunkt war die Persistenz und Replikation von Redis jedoch ziemlich entt\u00e4uschend. Au\u00dferdem gab es Bedenken hinsichtlich der Leistung.<\/p>\n

Wir haben an MySQL und PostgreSQL gedacht. Aber MySQL hat sich irgendwie bei uns nicht durchgesetzt, w\u00e4hrend PostgreSQL ein sehr anspruchsvolles Produkt ist, und es w\u00e4re unrentabel, darauf einfache Dienste aufzubauen.
\nWir haben RIAK, Cassandra und sogar eine graphbasierte Datenbank ausprobiert. All diese L\u00f6sungen sind ziemlich nischig und eigneten sich nicht als allgemeines, universelles Werkzeug zur Erstellung von Diensten.<\/p>\n

Letztendlich entschieden wir uns f\u00fcr Tarantool.<\/p>\n

Wir haben uns an es gewandt, als es sich in der Version 1.6 befand. Uns interessierte die Symbiose von Key-Value und der Funktionalit\u00e4t einer relationalen Datenbank. Es gibt sekund\u00e4re Indizes, Transaktionen und Spaces, das sind wie Tabellen, aber nicht einfach; man kann unterschiedliche Spaltenanzahlen darin speichern. Das Killer-Feature von Tarantool waren die sekund\u00e4ren Indizes in Kombination mit Key-Value und Transaktionsf\u00e4higkeit.<\/p>\n

Ein ebenso wichtiger Faktor war die hilfsbereite russischsprachige Gemeinschaft, die bereit war, im Chat Unterst\u00fctzung zu leisten. Wir haben das aktiv genutzt und lebten praktisch im Chat. Und nicht zu vergessen ist die anst\u00e4ndige kontinuierliche Leistung ohne offensichtliche Fehler und Pannen. Wenn wir auf unsere Geschichte mit Tarantool zur\u00fcckblicken, hatten wir viele Herausforderungen und Probleme mit der Replikation, aber wir haben dank seiner Zuverl\u00e4ssigkeit niemals Daten verloren!<\/p>\n

Die Implementierung begann schwierig.<\/h3>\n

\nZu diesem Zeitpunkt war unser Haupt-Entwicklungstechnologie-Stack .NET, f\u00fcr den es keinen Connector f\u00fcr Tarantool gab. Wir haben sofort angefangen, etwas in Go zu entwickeln. Auch mit Lua kamen wir ganz gut zurecht. Das Hauptproblem zu der Zeit war das Debugging: In .NET lief alles gro\u00dfartig, aber dann in die Welt von embedded Lua einzutauchen, in der du, abgesehen von den Logs, keine Debugging-Optionen hast, war ziemlich herausfordernd. Au\u00dferdem brach die Replikation aus irgendeinem Grund gelegentlich zusammen, was uns zwang, die Funktionsweise des Tarantool-Engines zu verstehen. Dabei half der Chat, die Dokumentation in geringerem Ma\u00dfe; manchmal schauten wir uns auch den Code an. Zu jener Zeit war die Dokumentation eher mittelm\u00e4\u00dfig.<\/p>\n

So haben wir in den letzten Monaten viele Erfahrungen gesammelt und anst\u00e4ndige Ergebnisse bei der Arbeit mit Tarantool erzielt. Wir haben im Git Referenzarbeiten erstellt, die bei der Entwicklung neuer Mikrodienste hilfreich waren. Zum Beispiel, wenn die Aufgabe entstand, einen weiteren Mikrodienst zu erstellen, schaute der Entwickler auf den Quellcode der Referenzl\u00f6sung im Repository, und die Erstellung eines neuen dauerte nicht l\u00e4nger als eine Woche. <\/p>\n

Das waren besondere Zeiten. Man konnte damals einfach zum Admin am Nachbartisch gehen und fragen: \u201eGib mir eine Virtual Machine\u201c. Nach etwa drei\u00dfig Minuten war die Maschine schon bei dir. Du hast dich selbst verbunden, alles installiert und dir wurde Traffic darauf eingeleitet.<\/p>\n

Heute ist das nicht mehr m\u00f6glich: Man muss das Monitoring und Logging f\u00fcr den Dienst einrichten, die Funktionalit\u00e4t mit Tests abdecken, eine Virtual Machine oder eine Bereitstellung in Kubernetes bestellen usw. Insgesamt wird es so besser sein, obwohl es l\u00e4nger dauert und aufw\u00e4ndiger ist.<\/p>\n

Teilen und herrschen. Wie steht es um Lua?<\/h3>\n

\nEs gab ein ernstes Dilemma: Einige Teams hatten Schwierigkeiten, \u00c4nderungen an einem Dienst mit einer gro\u00dfen Menge an Logik in Lua zuverl\u00e4ssig auszurollen. Oft ging dies mit der Unbrauchbarkeit des Dienstes einher. <\/p>\n

Das hei\u00dft, die Entwickler bereiten eine \u00c4nderung vor. Tarantool beginnt mit der Migration, w\u00e4hrend die Replikation noch mit dem alten Code arbeitet; dabei wird \u00fcber die Replikation irgendein DDL empfangen, etwas anderes, und der Code bricht einfach zusammen, weil das nicht ber\u00fccksichtigt wurde. Infolgedessen war der Aktualisierungsprozess f\u00fcr die Admins auf ein A4-Blatt geschrieben: Replikation stoppen, das aktualisieren, Replikation einschalten, hier ausschalten, dort aktualisieren. Ein Albtraum! <\/p>\n

Letztendlich versuchen wir heutzutage meistens, in Lua nichts zu machen. Einfach \u00fcber iproto (ein Bin\u00e4rprotokoll zur Kommunikation mit dem Server), und das war's. M\u00f6glicherweise ist das ein Wissensmangel der Entwickler, aber aus dieser Perspektive ist das System kompliziert.<\/p>\n

Wir folgen diesem Szenario nicht immer blind. Heute gibt es bei uns kein Schwarz und Wei\u00df: entweder alles in Lua oder alles in Go. Wir verstehen bereits, wie wir kombinieren k\u00f6nnen, um sp\u00e4ter keine Probleme mit der Migration zu bekommen.<\/p>\n

Wo ist Tarantool jetzt?
\nTarantool wird im Dienst zur Berechnung des Endpreises von Produkten unter Ber\u00fccksichtigung von Rabattcoupons verwendet, bekannt als \"Promotizer\". Wie bereits erw\u00e4hnt, wird er jetzt eingestellt: Ein neuer Katalogdienst mit vorab berechneten Preisen ersetzt ihn. Vor einem halben Jahr wurden alle Berechnungen im \"Promotizer\" durchgef\u00fchrt. Zuvor war die H\u00e4lfte seiner Logik in Lua geschrieben. Vor zwei Jahren wurde der Dienst in ein Speicher-System umgewandelt und die Logik auf Go neu geschrieben, da sich die Mechanik der Rabatte etwas ver\u00e4ndert hat und dem Dienst die Leistung fehlte. <\/p>\n

Einer der kritischsten Dienste ist das Benutzerprofil. Das bedeutet, dass alle Wildberries-Nutzer in Tarantool gespeichert sind, etwa 50 Millionen. Ein nach Benutzer-ID shardiertes System, verteilt \u00fcber mehrere Rechenzentren mit einer Anbindung an Go-Services.
\nFr\u00fcher war \"Promotaiser\" der Marktf\u00fchrer in Bezug auf RPS, mit bis zu 6.000 Anfragen. Zu einem bestimmten Zeitpunkt hatten wir 50-60 Instanzen. Jetzt ist der Marktf\u00fchrer bei RPS die Benutzerprofile, mit etwa 12.000. Dieser Dienst verwendet eine benutzerdefinierte Shardierung, die auf Benutzer-ID-Bereichen basiert. Der Dienst betreut mehr als 20 Maschinen, aber das ist zu viel; wir planen, die zugewiesenen Ressourcen zu reduzieren, da 4-5 Maschinen ausreichend Kapazit\u00e4ten bieten.<\/p>\n

Der Session-Dienst ist unser erster Dienst auf vshard und Cartridge. Die Einrichtung von vshard und das Update von Cartridge erforderten einen gewissen Arbeitsaufwand, aber letztendlich hat alles gut geklappt.<\/p>\n

Der Dienst zur Anzeige verschiedener Banner auf der Website und in der mobilen Anwendung geh\u00f6rte zu den ersten, die sofort auf Tarantool ver\u00f6ffentlicht wurden. Dieser Dienst ist bemerkenswert, da er etwa 6-7 Jahre alt ist, immer noch in Betrieb ist und noch nie neu gestartet wurde. Es wurde eine Master-Master-Replikation verwendet. Es ist nie etwas kaputt gegangen.<\/p>\n

Es gibt ein Beispiel f\u00fcr die Verwendung von Tarantool zur Funktionalit\u00e4t schneller Nachschlagewerke in einem Lagersystem, um Informationen in bestimmten F\u00e4llen schnell zu \u00fcberpr\u00fcfen. Wir haben versucht, daf\u00fcr Redis zu verwenden, aber die Datenschichtung im Speicher nahm mehr Platz ein als bei Tarantool.<\/p>\n

Die Dienste f\u00fcr Wartelisten, Kundenabonnements, die derzeit beliebten Stories und vorgemerkte Produkte funktionieren ebenfalls mit Tarantool. Der letzte Dienst ben\u00f6tigt im Speicher etwa 120 GB. Dies ist der gr\u00f6\u00dfte Dienst aus den oben genannten. <\/p>\n

Fazit<\/h3>\n

\nDank der sekund\u00e4ren Indizes in Kombination mit Key-Value und Transaktionsf\u00e4higkeit eignet sich Tarantool hervorragend f\u00fcr architektonische L\u00f6sungen basierend auf Microservices. Wir hatten jedoch Schwierigkeiten beim Einspielen von \u00c4nderungen in Dienste mit viel Logik in Lua \u2013 die Dienste h\u00f6rten oft auf zu funktionieren. Das haben wir nicht \u00fcberwunden, und im Laufe der Zeit sind wir zu verschiedenen Kombinationen von Lua und Go gekommen: Wir wissen, wann wir die eine Sprache und wann wir die andere nutzen sollten.<\/p>\n

Weitere Lesetipps zu diesem Thema<\/b><\/p>\n