Warum benötigt eine Corporation wie MegaFon Tarantool fĂŒr das Abrechnungssystem? Von auĂen betrachtet sieht es so aus, als wĂŒrde ein Anbieter kommen, eine groĂe Box bringen, den Stecker in die Steckdose stecken â und voilĂ , das Abrechnungssystem ist da! FrĂŒher war es so, aber heute gehört das der Vergangenheit an, und solche Dinosaurier sterben entweder aus oder sind bereits ausgestorben. UrsprĂŒnglich war Abrechnung ein System zur Rechnungsstellung â eine Rechnung oder ein Taschenrechner. In der modernen Telekommunikation ist es ein System zur Automatisierung des gesamten Lebenszyklus der Interaktion mit dem Kunden, von der Vertragsunterzeichnung bis zur KĂŒndigung, einschlieĂlich Echtzeit-Tarifierung, Zahlungsannahme und noch vielem mehr. Die Abrechnung in Telekommunikationsunternehmen Ă€hnelt einem Kampfroboter â groĂ, stark und mit Waffen ausgerĂŒstet.
Was hat es nun mit Tarantool auf sich? DarĂŒber werden berichten Oleg Ivlev und Andrei Knyazev. Oleg ist der Hauptarchitekt des Unternehmens mit umfangreicher Erfahrung in auslĂ€ndischen Unternehmen, Andrei ist Direktor fĂŒr GeschĂ€ftssysteme. Aus der Auswertung ihrer PrĂ€sentation auf der  Sie erfahren, warum R&D in Unternehmen notwendig ist, was Tarantool ist, wie die Falle der vertikalen Skalierung und die Globalisierung die Entstehung dieser Datenbank im Unternehmen bedingten, sowie die technologischen Herausforderungen, die Transformation der Architektur und was den Technologiestack von MegaFon mit Netflix, Google und Amazon verbindet.
Projekt âEinheitliches Billingâ
Das Projekt, ĂŒber das wir sprechen werden, heiĂt âEinheitliches Billingâ. Hier hat Tarantool seine besten Eigenschaften gezeigt.
Das Wachstum der Leistung von Hi-End-Hardware konnte mit dem Anstieg der Abonnentenzahl und der angebotenen Dienstleistungen nicht Schritt halten. Ein weiterer Anstieg der Abonnenten und Dienstleistungen wurde durch M2M und IoT erwartet, wÀhrend die speziellen Anforderungen der Filialen die Time-to-Market verschlechterten. Das Unternehmen beschloss, ein einheitliches GeschÀftssystem mit einer einzigartigen modularen Architektur auf Weltklasse-Niveau zu schaffen, anstelle von acht bestehenden verschiedenen Abrechnungssystemen.
MegaFon ist acht Unternehmen in einem.. Im Jahr 2009 wurde die Reorganisation abgeschlossen: Die Niederlassungen in ganz Russland wurden zu einer einzigen Gesellschaft, der OAO âMegaFonâ (jetzt PJSC), zusammengefĂŒhrt. Dadurch entstanden in der Gesellschaft 8 Abrechnungssysteme mit eigenen âmaĂgeschneidertenâ Lösungen, filialenbezogenen Besonderheiten und unterschiedlichen organisatorischen Strukturen, IT- und Marketingabteilungen.
Alles lief gut, bis ein gemeinsames bundesweites Produkt lanciert werden musste. Hier traten viele Schwierigkeiten auf: Bei manchen wurde nach oben gerundet, bei anderen nach unten, und wieder andere verwendeten das einfache arithmetische Mittel. Solcherlei Punkte gibt es Tausende.
Obwohl die Version des Abrechnungssystems einheitlich ist und es einen einzigen Anbieter gibt, zeigten sich die Einstellungen so unterschiedlich, dass man lange daran arbeiten musste. Wir versuchten, deren Zahl zu reduzieren und stieĂen auf ein zweites Problem, das vielen Unternehmen bekannt ist.
Vertikales Scaling. Selbst die damals beste Hardware konnte den Anforderungen nicht gerecht werden. In der Praxis kam Hardware von Hewlett-Packard, Superdome Hi-End-Serien, zum Einsatz, doch sie erfĂŒllte nicht einmal die BedĂŒrfnisse von zwei Niederlassungen. Man wĂŒnschte sich horizontales Scaling ohne hohe Betriebskosten und Investitionen.
Erwartung des Wachstums der Abonnentenzahl und Dienstleistungen. Berater haben schon lange Geschichten ĂŒber IoT und M2M in die Telekommunikationswelt gebracht: Es wird Zeiten kommen, in denen in jedem Telefon und BĂŒgeleisen eine SIM-Karte und in jedem KĂŒhlschrank zwei sein werden. Heute haben wir eine bestimmte Anzahl von Abonnenten, aber in naher Zukunft wird es deutlich mehr geben.
Technologische Herausforderungen
Diese vier GrĂŒnde haben uns zu ernsthaften VerĂ€nderungen bewegt. Es gab die Wahl zwischen der Modernisierung des Systems und der Neugestaltung von Grund auf. Wir haben lange nachgedacht, ernste Entscheidungen getroffen und Ausschreibungen gespielt. Letztendlich haben wir uns entschieden, von Grund auf neu zu entwerfen, und haben uns spannenden Herausforderungen â technologischen Herausforderungen â gestellt.
Skalierbarkeit
Wenn es frĂŒher, sagen wir mal, 8 Abrechnungssysteme mit 15 Millionen Abonnenten, und es jetzt 100 Millionen Abonnenten und mehr â die Belastung ist viel höher.
Wir sind in Bezug auf die GröĂe mit groĂen Internet-Spielern wie Mail.ru oder Netflix vergleichbar geworden.
Aber die weitere Bewegung zur Erhöhung der Belastung und der Abonnentenzahl hat uns vor ernsthafte Aufgaben gestellt.
Die Geographie unseres riesigen Landes
Zwischen Kaliningrad und Wladiwostok 7500 km und 10 Zeitzonen. Die Lichtgeschwindigkeit ist endlich, und bei solchen Entfernungen sind die Verzögerungen bereits signifikant. 150 ms auf den fortschrittlichsten modernen optischen KanĂ€len sind fĂŒr die Echtzeit-Tarifierung, insbesondere wie sie derzeit im Telekommunikationssektor in Russland praktiziert wird, zu viel. AuĂerdem muss eine Aktualisierung innerhalb eines Arbeitstags erfolgen, was mit verschiedenen Zeitzonen ein Problem darstellt.
Wir bieten nicht nur Dienstleistungen gegen GebĂŒhr an, sondern verfĂŒgen auch ĂŒber komplexe Tarife, Pakete und verschiedene Modifikatoren. Es geht darum, dem Nutzer nicht nur zu erlauben oder zu verbieten, zu sprechen, sondern ihm auch ein definiertes Kontingent zu geben â Anrufe und Aktionen in Echtzeit zu berechnen, sodass er es nicht bemerkt.
Ausfallsicherheit
Das ist die Kehrseite der Zentralisierung.
Wenn wir alle Abonnenten in einem System bĂŒndeln, sind alle NotfĂ€lle und Katastrophen katastrophal fĂŒr das GeschĂ€ft. Daher entwerfen wir das System so, dass die Auswirkungen von NotfĂ€llen auf die gesamte Abonnentendatenbank ausgeschlossen werden.
Dies ist erneut die Folge der Abkehr vom vertikalen Skalieren. Als wir zum horizontalen Skalieren ĂŒbergingen, erhöhten wir die Anzahl der Server von Hunderten auf Tausende. Diese mĂŒssen verwaltet und austauschbar gebaut werden, um die IT-Infrastruktur automatisch zu sichern und das verteilte System wiederherzustellen.
Solche spannenden Herausforderungen lagen vor uns. Wir entwarfen ein System und versuchten in diesem Moment, weltweite Best Practices zu finden, um zu ĂŒberprĂŒfen, wie gut wir im Trend liegen und ob wir den neuesten Technologien folgen.
Weltweite Best Practices
Erstaunlicherweise fanden wir im globalen Telekommunikationsbereich keinen einzigen Referenzpunkt.
Europa fiel aufgrund der Abonnentenzahl und der GröĂe weg, die USA aufgrund der Struktur ihrer Tarife. Einiges sahen wir in China, und in Indien fanden wir Spezialisten von Vodafone India.
FĂŒr die Analyse der Architektur versammelten wir ein Dream Team unter der Leitung von IBM â Architekten aus verschiedenen Bereichen. Diese Personen konnten adĂ€quat bewerten, was wir tun, und spezifisches Wissen in unsere Architektur einbringen.
Skalierung
Einige Zahlen zur Veranschaulichung.
Wir entwerfen ein System fĂŒr 80 Millionen Abonnenten mit einer Reserve fĂŒr eine Milliarde.. So beseitigen wir zukĂŒnftige EngpĂ€sse. Das liegt nicht daran, dass wir planen, China zu erobern, sondern wegen des Drucks durch IoT und M2M.
300 Millionen Dokumente werden in Echtzeit verarbeitet. Obwohl wir 80 Millionen Abonnenten haben, arbeiten wir auch mit potenziellen Kunden und denen, die uns verlassen haben, um AuĂenstĂ€nde einzutreiben. Daher sind die realen Volumina deutlich höher.
2 Milliarden Transaktionen Ă€ndern tĂ€glich den Saldo â es handelt sich um Zahlungen, Gutschriften, Anrufe und andere Ereignisse. 200 TB Daten verĂ€ndern sich aktiv, etwas langsamer verĂ€ndern sich 8 PB Daten, und das sind keine Archive, sondern lebendige Daten in einem einheitlichen Abrechnungssystem. Der Umfang ĂŒber die Rechenzentren betrĂ€gt 5000 Server an 14 Standorten.
Technologischer Stack
Als wir die Architektur planten und mit dem Aufbau des Systems begannen, haben wir uns die interessantesten und fortschrittlichsten Technologien importiert. So entstand ein technischer Stack, der jedem Akteur im Internet und Unternehmen, die hochbelastete Systeme erstellen, bekannt ist.
Der Stack ist Ă€hnlich den Stacks anderer groĂer Akteure: Netflix, Twitter, Viber. Er besteht aus 6 Komponenten, aber wir möchten ihn verkleinern und vereinheitlichen.
FlexibilitĂ€t ist wichtig, jedoch ist in einem groĂen Unternehmen eine einheitliche Lösung unerlĂ€sslich.
Wir planen nicht, Oracle durch Tarantool zu ersetzen. In groĂen Unternehmen ist das eine Utopie oder ein langwieriger Prozess von 5â10 Jahren mit ungewissem Ausgang. Cassandra und Couchbase hingegen können gut durch Tarantool ersetzt werden, und darauf streben wir hin.
Warum Tarantool?
Es gibt 4 einfache Kriterien, warum wir uns fĂŒr diese Datenbank entschieden haben.
Geschwindigkeit. Wir haben Lasttests auf industriellen Systemen von MegaFon durchgefĂŒhrt. Tarantool hat gewonnen â es zeigte die beste Leistung.
Es wĂ€re falsch zu sagen, dass andere Systeme nicht den Anforderungen von MegaFon gerecht werden. Die aktuellen Memory-Lösungen sind so leistungsstark, dass die KapazitĂ€t der Firma bei weitem ausreichend ist. Aber wir sind daran interessiert, mit einem MarktfĂŒhrer zu arbeiten und nicht mit dem, der hinterherhinkt, auch in Bezug auf den Lasttest.
Tarantool erfĂŒllt die BedĂŒrfnisse des Unternehmens auch langfristig.
Die TCO-Kosten. Der Support fĂŒr Couchbase bei den Volumina von MegaFon ist astronomisch teuer, wĂ€hrend die Situation mit Tarantool deutlich angenehmer ist, und die FunktionalitĂ€t Ă€uĂerst vergleichbar ist.
Ein weiteres schönes Merkmal, das unsere Entscheidung beeinflusst hat, ist, dass Tarantool besser mit dem Speicher arbeitet als andere Datenbanken. Es zeigt maximale Effizienz.
ZuverlĂ€ssigkeit. MegaFon investiert in ZuverlĂ€ssigkeit wie kaum ein anderer. Daher haben wir beim Blick auf Tarantool schnell erkannt, dass wir sicherstellen mĂŒssen, dass es unseren Anforderungen gerecht wird.
Wir haben Zeit und Geld investiert und zusammen mit Mail.ru eine Enterprise-Version entwickelt, die jetzt bereits in mehreren anderen Unternehmen eingesetzt wird.
Tarantool-enterprise hat uns in Bezug auf Sicherheit, ZuverlĂ€ssigkeit und Logging vollstĂ€ndig ĂŒberzeugt.
Partnerschaft
Das Wichtigste fĂŒr mich ist der direkte Kontakt zum Entwickler. Das ist genau das, womit die Leute von Tarantool ĂŒberzeugt haben.
Wenn du zu einem Anbieter kommst, besonders zu einem, der mit einem GroĂkunden arbeitet, und sagst, dass du eine Datenbank benötigst, die das und das und das kann, antwortet er normalerweise:
â Gut, legen Sie die Anforderungen unten auf den Stapel â irgendwann werden wir uns sicher darum kĂŒmmern.
Viele Unternehmen haben einen Roadmap fĂŒr die nĂ€chsten 2-3 Jahre, und es ist nahezu unmöglich, sich dort einzufĂŒgen. Die Entwickler von Tarantool ĂŒberzeugen durch ihre Offenheit, nicht nur mit MegaFon, und passen ihr System auf die Anforderungen der Kunden an. Das ist beeindruckend und gefĂ€llt uns sehr.
Wo wir Tarantool eingesetzt haben
Bei uns kommt Tarantool in mehreren Komponenten zum Einsatz. Die erste ist im Pilotprojekt, das wir mit einem Adressverzeichnis-System entwickelt haben. UrsprĂŒnglich wollten wir ein System, das Ăhnlichkeiten mit Yandex Maps und Google Maps aufweist, aber es ist etwas anders geworden.
Zum Beispiel das Adressverzeichnis in der VerkaufsoberflĂ€che. Bei Oracle dauert die Suche nach der richtigen Adresse 12-13 Sekunden â das sind unangenehme Zahlen. Wenn wir auf Tarantool umschalten, Oracle in der Konsole durch eine andere Datenbank ersetzen und die gleiche Suche durchfĂŒhren, erzielen wir eine 200-fache Beschleunigung! Die Stadt wird nach dem dritten Buchstaben angezeigt. Wir passen derzeit die BenutzeroberflĂ€che an, damit dies bereits nach dem ersten Buchstaben geschieht. Dennoch ist die Reaktionsgeschwindigkeit ganz anders â jetzt sind es schon Millisekunden statt Sekunden.
Die zweite Anwendung ist ein modernes Thema, das als zweigleisige IT bezeichnet wird. Das liegt daran, dass Berater von ĂŒberall her sagen, dass Unternehmen dorthin gehen sollten.
Hier gibt es eine Infrastruktur-Ebene, darĂŒber liegen die Domains, zum Beispiel das Abrechnungssystem wie bei Telekommunikationsanbietern, Unternehmenssysteme und Unternehmensberichte. Das ist das Kernelement, das unangetastet bleiben sollte. NatĂŒrlich kann man das Ă€ndern, aber man muss paranoid darauf achten, die QualitĂ€t sicherzustellen, da es der Corporation Geld einbringt.
DarĂŒber hinaus gibt es die Mikroservices-Ebene â das, was den Betreiber oder einen anderen Akteur differenziert. Mikroservices können schnell basierend auf bestimmten Caches erstellt werden, indem Daten aus verschiedenen Domains dorthin hochgeladen werden. Hier gibt es Spielraum fĂŒr Experimente â wenn etwas nicht funktioniert, schlieĂt man einen Mikroservice und öffnet einen anderen. Das sorgt fĂŒr eine echte VerkĂŒrzung der MarkteinfĂŒhrungszeit und erhöht die ZuverlĂ€ssigkeit und Geschwindigkeit des Unternehmens.
Mikroservices sind wohl die Hauptrolle von Tarantool bei MegaFon.
Wo wir planen, Tarantool anzuwenden
Im Vergleich zu unserem erfolgreichen Abrechnungsprojekt und den Transformationsprogrammen von Deutsche Telekom, ĐĄĐČŃĐ·ŃĐșĐŸĐŒ, und Vodafone India wirkt unser Ansatz bemerkenswert dynamisch und kreativ. WĂ€hrend der Umsetzung dieses Projekts hat sich nicht nur MegaFon und seine Struktur verĂ€ndert, sondern es entstand auch Tarantool-enterprise bei Mail.ru und unser Anbieter Nexign (ehemals «ĐĐ”ŃĐ”Ń-ĐĄĐ”ŃĐČОѻ) bietet die BSS Box (eine fertige Abrechnungslösung) an.
In gewisser Weise handelt es sich um ein historisches Projekt fĂŒr den russischen Markt. Es ist vergleichbar mit dem, was in Frederic Brookss Buch «Mythical Man-Month» beschrieben wird. Damals, in den 60er Jahren, stellte IBM zur Entwicklung des neuen Betriebssystems OS/360 fĂŒr Mainframes 5.000 Personen ein. Bei uns sind es weniger â 1.800, aber wir sind effektiv und nutzen mit Blick auf Open Source und neue AnsĂ€tze unsere Ressourcen produktiver.
Nachfolgend sind die Domains fĂŒr das Billing aufgefĂŒhrt oder, breiter gefasst, die GeschĂ€ftssysteme. Personen aus dem Enterprise-Bereich kennen CRM bestens. Andere Systeme sollten bereits vorhanden sein: Open API, API Gateway.
Open API
Lassen Sie uns erneut einen Blick auf die Zahlen werfen und betrachten, wie Open API aktuell funktioniert. Seine Last betrĂ€gt â 10.000 Transaktionen pro Sekunde. Da wir planen, die Schicht der Mikrodienste aktiv auszubauen und eine öffentliche API fĂŒr MegaFon zu erstellen, erwarten wir kĂŒnftig ein deutliches Wachstum in diesem Bereich. 100.000 Transaktionen werden definitiv erreicht..
Ich weiĂ nicht, ob wir im SSO mit Mail.ru konkurrieren können â die haben anscheinend 10.000.000 Transaktionen pro Sekunde. Ihre Lösung ist fĂŒr uns sehr interessant und wir planen, deren Erfahrungen zu ĂŒbernehmen â zum Beispiel wollen wir ein funktionales SSO-Backup mit Tarantool erstellen. Momentan arbeiten die Entwickler von Mail.ru daran bei uns.
CRM
CRM â das sind die 80 Millionen Abonnenten, die wir auf eine Milliarde steigern möchten, denn es gibt bereits 300 Millionen Dokumente, die eine dreijĂ€hrige Historie umfassen. Wir erwarten tatsĂ€chlich neue Dienstleistungen, und hier ist der Wachstumspunkt â die verbundenen Dienstleistungen.. Das ist ein Bereich, der wachsen wird, weil es immer mehr Dienstleistungen geben wird. Entsprechend benötigen wir eine Historie, denn wir möchten hierbei nicht stolpern.
Das Billing selbst im Bereich Rechnungsstellung und im Umgang mit der ForderungsausfÀllen der Kunden hat sich in eine separate DomÀne transformiert.. Um die Leistung zu steigern, wurde das Architekturmodell der DomÀnenarchitektur angewendet..
Das System ist in Domains unterteilt, die Last ist verteilt und die Ausfallsicherheit ist gewĂ€hrleistet. DarĂŒber hinaus haben wir an der verteilten Architektur gearbeitet.
Alles andere sind Enterprise-Lösungen. Im Anrufspeicher â 2 Milliarden pro Tag, 60 Milliarden pro Monat. Manchmal mĂŒssen sie fĂŒr den Monat neu gezĂ€hlt werden, und es ist besser, das schnell zu tun. Finanzmonitoring ist genau das, was die 300 Millionen ausmacht, die stĂ€ndig wachsen: Abonnenten wechseln hĂ€ufig zwischen den Anbietern, was diesen Teil erhöht.
Der wichtigste Telekommunikationsaspekt im Mobilfunk ist die Online-Tarifierung. Das sind die Systeme, die Ihnen ermöglichen, Anrufe zu tÀtigen oder nicht; sie treffen Entscheidungen in Echtzeit. Hier gibt es eine Last von 30.000 Transaktionen pro Sekunde, aber mit dem Anstieg des Datenverkehrs planen wir 250.000 Transaktionen, und deshalb sind wir stark an Tarantool interessiert.
Das vorherige Bild zeigt die Domains, in denen wir Tarantool anwenden möchten. Das CRM selbst ist natĂŒrlich breiter und wir planen, es im Kern zu verwenden.
Die von uns kalkulierte Kennzahl fĂŒr die technischen Eigenschaften von 100 Millionen Abonnenten bereitet mir als Architekt Sorgen â was ist, wenn es 101 Millionen sind? MĂŒssen wir dann alles neu gestalten? Um dies zu vermeiden, setzen wir Caches ein, um die VerfĂŒgbarkeit zu erhöhen.
Insgesamt gibt es zwei AnsĂ€tze zur Implementierung von Tarantool. Der erste â alle Caches auf Ebene der Mikrodienste zu erstellen.Soweit ich verstehe, verfolgt VympelCom diesen Weg, um einen Kunden-Cache zu schaffen.
Wir sind weniger von Anbietern abhĂ€ngig und Ă€ndern das BSS-Kernsystem, daher haben wir bereits eine einheitliche Kundendatenbank direkt aus der Box. Aber wir möchten sie erweitern. Deshalb verfolgen wir einen etwas anderen Ansatz â wir integrieren Caches direkt in die Systeme..
So gibt es weniger AsynchronitĂ€t â ein System ist sowohl fĂŒr den Cache als auch fĂŒr die Hauptdatenquelle verantwortlich.
Die Methode passt gut zum Tarantool-Ansatz mit einem transaktionalen GerĂŒst, bei dem nur die Teile aktualisiert werden, die sich auf die Updates beziehen, also die DatenĂ€nderungen. Alles andere kann an einem anderen Ort gespeichert werden. Es gibt keinen riesigen Data Lake oder unkontrollierten globalen Cache. Caches werden fĂŒr Systeme entworfen, entweder fĂŒr Produkte oder fĂŒr Kunden, oder um den Betrieb zu erleichtern. Wenn ein unzufriedener Kunde anruft, möchte man ihm einen qualitativ hochwertigen Service bieten.
RTO und RPO
In der IT gibt es zwei Begriffe â RTO und RPO.
Recovery Time Objective â dies ist die Zeit, die benötigt wird, um den Dienst nach einem Ausfall wiederherzustellen. RTO = 0 bedeutet, dass der Dienst auch dann weiterlĂ€uft, wenn etwas ausfĂ€llt.
Recovery Point Objective â dies ist die Zeit, die benötigt wird, um Daten wiederherzustellen, also wie viele Daten wir ĂŒber einen bestimmten Zeitraum verlieren können. RPO = 0 bedeutet, dass wir keine Daten verlieren.
Aufgabe fĂŒr Tarantool
Lassen Sie uns versuchen, eine Aufgabe fĂŒr Tarantool zu lösen.
Gegeben: eine allgemein bekannte Anfrageliste, beispielsweise bei Amazon oder anderswo. Gefordert damit der Warenkorb rund um die Uhr, sieben Tage die Woche, oder 99,99 % der Zeit funktioniert. Bestellungen, die bei uns eingehen, mĂŒssen geordnet bleiben, denn wir können die Verbindung fĂŒr den Kunden nicht willkĂŒrlich ein- oder ausschalten â alles muss streng sequenziell sein. Das vorherige Abonnement beeinflusst das nĂ€chste, daher sind die Daten wichtig â nichts darf verloren gehen.
Lösung. Man kann versuchen, direkt zu fragen und die Datenbankentwickler zu konsultieren, aber das Problem lĂ€sst sich mathematisch nicht lösen. Man könnte sich an Theoreme, ErhaltungssĂ€tze oder Quantenphysik erinnern, aber warum â es kann auf der Ebene der Datenbank nicht gelöst werden.
Hier funktioniert der bewĂ€hrte architektonische Ansatz â man muss das Fachgebiet gut kennen, um dieses RĂ€tsel damit zu lösen.
Unsere Lösung: Wir erstellen ein verteiltes Antragssystem auf Tarantool â ein geografisch verteiltes Cluster. In der Grafik sind dies drei verschiedene Rechenzentren â zwei bis zum Ural, eines hinter dem Ural, und wir verteilen alle AntrĂ€ge auf diese Zentren.
Bei Netflix, das heute als einer der fĂŒhrenden Anbieter im IT-Bereich gilt, gab es bis 2012 nur ein Rechenzentrum. Am Vorabend von Weihnachten, dem 24. Dezember, fiel dieses Rechenzentrum aus. Nutzer in Kanada und den USA waren ohne ihre Lieblingsfilme und Ă€uĂerten ihren Unmut in sozialen Medien. Jetzt hat Netflix drei Rechenzentren an der West-Ost-KĂŒste und eines in Westeuropa.
Wir entwickeln von Anfang an eine geo-verteilte Lösung â dabei ist uns die Ausfallsicherheit wichtig.
Also haben wir einen Cluster, aber wie sieht es mit RPO = 0 und RTO = 0 aus? Die Lösung ist einfach und hÀngt vom Thema ab.
Was ist bei Anfragen wichtig? Zwei Teile: das Erstellen des Warenkorbs VOR der Kaufentscheidung, und NACH. Der Teil VOR wird im Telekommunikationssektor ĂŒblicherweise als Order Capture oder Order Negotiation. Im Telekommunikationsbereich kann das deutlich komplexer sein als im Online-Shop, da der Kunde bedient werden muss, fĂŒnf Optionen angeboten werden und dies eine gewisse Zeit in Anspruch nimmt, wĂ€hrend sich der Warenkorb fĂŒllt. In diesem Moment ist ein Ausfall möglich, aber das ist nicht schlimm, da es in einem interaktiven Modus unter Aufsicht einer Person geschieht.
Sollte das Moskauer Rechenzentrum unerwartet ausfallen, wechseln wir automatisch zu einem anderen Rechenzentrum, um den Betrieb fortzusetzen. Theoretisch könnte ein Produkt im Warenkorb verloren gehen, aber Sie sehen dies, fĂŒgen den Warenkorb erneut hinzu und arbeiten weiter. In diesem Fall betrĂ€gt RTO = 0.
Gleichzeitig gibt es eine zweite Option: Wenn wir âAbschickenâ klicken, wollen wir, dass die Daten nicht verloren gehen. Ab diesem Moment ĂŒbernimmt die Automatisierung â dies entspricht bereits RPO = 0. Die Anwendung dieser beiden unterschiedlichen Muster kann in einem Fall einfach ein geo-verteilter Cluster mit einem umschaltbaren Master sein, im anderen Fall kann es sich um eine Quorum-Aufzeichnung handeln. Die Vorlagen können variieren, aber wir lösen das Problem.
DarĂŒber hinaus können wir mit einem verteilten Antragsregister auch skalieren â viele Dispatcher und AusfĂŒhrer, die auf dieses Register zugreifen.
Cassandra und Tarantool zusammen
Es gibt noch einen weiteren Anwendungsfall â âSaldo-Dashboardâ. Hier handelt es sich um einen interessanten Fall, in dem Cassandra und Tarantool gemeinsam eingesetzt werden.
Wir setzen Cassandra ein, weil 2 Milliarden Anrufe pro Tag keine Grenze sind und es sogar mehr werden. Marketer lieben es, den Traffic nach Quellen aufzuschlĂŒsseln, und es gibt immer mehr Details zu sozialen Netzwerken. Das alles erweitert die Geschichte.
Cassandra ermöglicht horizontale Skalierung fĂŒr beliebige Volumen.
Wir fĂŒhlen uns mit Cassandra wohl, aber es gibt ein Problem â sie ist nicht optimal fĂŒr das Lesen. Beim Schreiben funktioniert alles in Ordnung, 30.000 pro Sekunde sind kein Problem â das Problem liegt im Lesen..
Daher entstand das Thema mit dem Cache, und wir haben gleichzeitig folgendes Problem gelöst: Es gibt einen alten, traditionellen Fall, wenn die AusrĂŒstung vom Switch zur Online-Abrechnung in Dateien kommt, die wir in Cassandra laden. Wir haben das Problem der zuverlĂ€ssigen Ăbertragung dieser Dateien angegangen und sogar auf den Rat eines IBM-Managers hin das File Transfer Management genutzt â es gibt solche Lösungen, die die DateiĂŒbertragung effizient mithilfe des UDP-Protokolls steuern, anstatt TCP. Das ist gut, aber es dauert dennoch Minuten, und solange wir das alles nicht geladen haben, kann der Operator im Callcenter dem Kunden nicht sagen, was mit seinem Guthaben passiert ist â man muss warten.
Um das zu vermeiden, haben wir wir verwenden parallele funktionale Redundanz. Wenn wir ein Event ĂŒber Kafka an Tarantool senden und die Aggregationen in Echtzeit neu berechnen, zum Beispiel fĂŒr heute, erhalten wir Balken Caches, die Balancen mit beliebiger Geschwindigkeit ausgeben können, beispielsweise 100.000 Transaktionen pro Sekunde innerhalb von genau 2 Sekunden.
Das Ziel ist, dass nach einem Anruf bereits nach 2 Sekunden im persönlichen Bereich nicht nur der geÀnderte Balance angezeigt wird, sondern auch die Information, warum er sich geÀndert hat.
Fazit
Das waren Beispiele fĂŒr den Einsatz von Tarantool. Wir schĂ€tzen die Offenheit von Mail.ru und ihre Bereitschaft, unterschiedliche FĂ€lle zu betrachten.
FĂŒr Berater von BCG oder McKinsey, Accenture oder IBM ist es schon schwer, uns mit etwas Neuem zu ĂŒberraschen â vieles von dem, was sie anbieten, machen wir bereits oder haben es gemacht, oder wir planen, es zu tun. Ich denke, dass Tarantool in unserem Technologiestack einen adĂ€quaten Platz einnehmen und viele bereits bestehende Technologien ersetzen wird. Wir befinden uns in einer aktiven Entwicklungsphase dieses Projekts.
Der Vortrag von Oleg und Andrei war einer der besten auf der Tarantool-Konferenz im letzten Jahr, und bereits am 17. Juni wird Oleg Ivlev bei  mit einem Vortrag auftreten . Auch von MegaFon wird Alexander Deulin mit einem Vortrag auftreten. . Wir erfahren, was sich geĂ€ndert hat und welche PlĂ€ne umgesetzt werden konnten. Machen Sie mit â die Konferenz ist kostenlos, man muss nur . Alle und das Programm der Konferenz wurde festgelegt: neue AnwendungsfĂ€lle, neue Erfahrungen mit Tarantool, Architektur, Enterprise, Tutorials und Microservices.
Quelle: habr.com
