Couchbase bei Telecom

Die digitale Transformation ist ein globaler Trend für große Unternehmen und für die Anpassung eines Unternehmens an moderne Kundenbedürfnisse von entscheidender Bedeutung. Neben den üblichen Problemen der Zentralisierung von Systemen für große Unternehmen und der Kombination von Abrechnungssystemen und Abonnentendatenbanken kommen Anforderungen an eine hohe Verfügbarkeit und eine Echtzeitbetriebsart hinzu, an die Kunden bereits von Branchenführern (Google, Amazon, Netflix) gewöhnt sind.

Neue Herausforderungen erfordern neue Technologien und Ansätze, die erforderlich sind, um die Zeit für die Einführung von Funktionen zu verkürzen, die für den Kunden bequem sind, personalisierte kommerzielle Angebote, eine schnelle Reaktion auf die Angebote der Wettbewerber sowie die Kostenkontrolle für Systeme, IT-Infrastruktur, Rechenzentren und qualifiziertes Personal. Diese Trends sind auch ein großes Minus: die Komplexität der Architektur und der aufgeblähten Transaktionsdatenbanken, die den Informationsfluss und die Verarbeitung von Informationen nicht bewältigen können. Technologien der vorherigen Generation haben eine vertikale Skalierungsobergrenze. Beispielsweise wird eine Oracle DBMS-Instanz auf x86-Prozessoren mit einer Last von einer Milliarde Transaktionen pro Tag an der Grenze des leistungsstärksten Servers ausgeführt.

Um einer solchen Belastung standzuhalten, mit der die Internetbranche seit langem konfrontiert ist, wird ein neuer Stapel von Technologien verwendet, z. B. In-Memory-Caches und NoSQL-Datenbanken. Apple verwendet also Cassandra, Sberbank - Ignite (GridGain), in MegaFon verwenden wir Couchbase und Tarantool.

MegaFon verwendet verschiedene Architekturmuster für das In-Memory-DBMS:

1. Einfacher Cache, der planmäßig oder nach Ereignis aus der Datenbank und den Anwendungen aktualisiert wird
2. Alle Änderungen an der Datenbank werden über den Cache (Durchschreibeskript) vorgenommen, z. B. durch Verbinden eines Oracle-Clients mit DCP Couchbase

Für eines unserer Entscheidungsfindungssysteme für die Lebensdauer des Abonnenten verwenden wir die erste Vorlage, da nur eine Anwendung für die Gesamtheit der Daten eine Entscheidung trifft und diese an alle Systeme einschließlich der Oracle-Datenbank sendet. Einer der hellsten Fälle bei der Verwendung des Lebenszyklus eines Teilnehmers ist das Sperren und Entsperren bei einem negativen Kontostand. Schließlich möchten alle Teilnehmer von Mobilfunkbetreibern nach dem Auffüllen des Guthabens sofort Kontakt aufnehmen und Anrufe tätigen. Dank einer separaten Anwendung und Couchbase konnten wir die Zeit zum Verlassen der Sperre von 90 Sekunden auf 30 Sekunden verkürzen, und dies ist nicht die Grenze. Nur die Aufzeichnung über die Änderung des Status des Teilnehmers wird in die Hauptdatenbank aufgenommen (Abb. 1).

Durch den Einsatz neuer Technologien konnten wir die Zeit bis zum Verlassen der Finanzsperre dreimal verkürzen. Um die aktuellen Ergebnisse zu erhalten, haben wir bei der architektonischen Transformation der Abrechnungsschaltung und bei der Auswahl der NoSQL-Datenbank einen langen Weg zurückgelegt.

Warum haben wir uns für Couchbase entschieden? Dafür gibt es mehrere Gründe.

Leistungsanforderung

1. Verarbeitung von bis zu 200.000 Anfragen pro Sekunde.
2. Die durchschnittliche Antwortzeit (50%) beträgt bis zu 5 ms (innerhalb eines einzelnen Rechenzentrums).
3. Die maximale Antwortzeit (99%) beträgt bis zu 15 ms (innerhalb eines Rechenzentrums).
4. Maximale Einfügeleistung 500 MB / Sek
5. Maximale Anzahl von Einfügevorgängen 100.000 / s
6. Maximale Anzahl von Änderungsvorgängen (Dokumentaktualisierungen) 100.000 / s
7. Maximale Leistung von Änderungen (Dokumentaktualisierungen) 500 MB / s
8. Maximale Anzahl von Lesevorgängen 100.000 / s
9. Maximale Lesegeschwindigkeit 500 MB / s

Hochleistungs-Schlüsselsuche und Datenzugriff

Das Herzstück von Couchbase ist Distributed Key Vault (KV). Das KV-Repository ist ein äußerst einfacher Datenverwaltungsansatz, bei dem eine eindeutige Kennung (Schlüssel) zusammen mit einer beliebigen Information gespeichert wird. Das KV-Repository selbst kann alle Daten akzeptieren, sei es ein binärer Blob oder ein JSON-Dokument. Aufgrund der Einfachheit der KV-Implementierung wird der Datenzugriff mit minimaler Verzögerung sichergestellt. Wie unsere Erfahrung zeigt, ist die Netzwerklatenz 2-3 Mal höher als die Bereitstellung von Schlüsseldaten auf der Couchbase-Seite.

Dynamisches Speicherschema ( JSON)

Dokumente werden im JSON-Format auf dem Couchbase-Server gespeichert. Das Format unterstützt sowohl grundlegende Datentypen wie Zahlen, Zeichenfolgen und komplexe Typen als auch integrierte Wörterbücher und Arrays.

Das Datenschema in Couchbase ist ein logisches Konstrukt, das von der Anwendung und dem Entwickler definiert wird. Aufgrund seiner Flexibilität und der Möglichkeit, mehrere Optionen zu verwenden, können wir im Dokument ein Tag verwenden, beispielsweise mit Versionsinformationen. Auf diese Weise kann die Anwendung bestimmen, in welchem ​​Modus das Dokument verarbeitet werden soll, und eine reibungslose Migration der Datenbank auf das neue Datenschema sicherstellen.

Hohe Verfügbarkeit

Einer der Bestandteile eines Informationssystems ist seine Verfügbarkeit. Couchbase bietet eine hohe Datenverfügbarkeit mit vielen verschiedenen Funktionen. Eine davon ist die Datenreplikation (die Verteilung mehrerer Kopien von Daten auf verschiedenen Clusterservern), mit der Sie einen Dienst während der routinemäßigen Wartung oder des Ausfalls einiger Server bereitstellen können.

Das zweite wichtige Merkmal für Hochverfügbarkeit ist das interne DCP (Database Change Protocol). Es bietet eine schnelle Übertragung von Änderungen an alle Kopien von Daten, Sekundärindizes (GSI), clusterübergreifender Replikation (XDCR) und externen Verbrauchern.

Bidirektionale Replikation

In Unternehmen empfiehlt es sich, Redundanz für alle Geschäftsprozesse und Geräte zu verwenden. Im Idealfall handelt es sich um eine Sicherung im Aktiv-Aktiv-Modus, wenn automatisch zwischen Problemknoten gewechselt wird. Die bidirektionale Replikation in Couchbase aktiviert den AA-Modus. Das Testen der Replikation hat jedoch gezeigt, dass sie nur in nahe gelegenen Rechenzentren wirksam ist. Bei einem Abstand von mehr als 100 km treten Konflikte auf. Couchbase verfügt über Konfliktlösungsmechanismen: basierend auf Zeitstempel und Sequenznummer. Aufgrund der Zeitverzögerung im Netzwerk gelangen veraltete Daten jedoch in die Datenbank. Wir haben die Verwendung der bidirektionalen Replikation (Cluster-übergreifende Konsistenz) aufgegeben. Alle Änderungen werden nur in einem Cluster ausgeführt. Die Datenverfügbarkeit im Lesemodus wird in allen Rechenzentren (AA) bereitgestellt.

Horizontale Skalierung

Eines der wichtigsten Merkmale der meisten NoSQL-Datenbanken ist die horizontale Skalierung (Abb. 3). Der Hauptunterschied von Couchbase ist die Unterstützung der mehrdimensionalen Skalierung, wenn wir im Cluster nur die Leistung des gewünschten Dienstes steigern können. Zum Beispiel verwendet das Spiel Pokemon GO eine geteilte Architektur. Zu Beginn des Projekts wurden 5 Server mit kombinierten Diensten verwendet. Nachdem sie die Last erhöht hatten, verwendeten sie eine vielfältige Architektur: 5 Datenserver und 55 Server für die Verarbeitung von Abfragen und Indizes. Einer der Nachteile der Skalierung mit Couchbase besteht darin, dass der Orchestrator Probleme hat, wenn mehr als 50 Datumsknoten im Cluster vorhanden sind.

Abbildung 3 MDB

IS-Anforderungen

Die Anforderungen an die Informationssicherheit haben unsere Wahl in geringerem Maße beeinflusst, aber ihre Präsenz im System hat ein zusätzliches Argument für die eine oder andere Datenbank geliefert. Da der Cache möglicherweise personenbezogene Daten enthält, müssen wir die Anforderungen des Regulators unbedingt befolgen. Es lohnt sich zu entscheiden: Werden wir zusätzliche Geräte verwenden oder können wir diese mit der Datenbank selbst bereitstellen ?!

In der Unternehmensversion unterstützt Couchbase die Verkehrsverschlüsselung, Datenverschlüsselung und den personalisierten Zugriff. Dies spart Geld bei Geräten wie dem Cisco ASA.

Einfaches Upgrade

Eine der wesentlichen Stärken von Couchbase ist der transparente Aktualisierungsmechanismus und die Unterstützung älterer Versionen der API. Während des Cluster-Upgrades funktioniert es im Kompatibilitätsmodus. Neue Mechanismen funktionieren erst nach einem vollständigen Cluster-Upgrade. Die Auswirkungen auf die Ausführung von Anwendungen sind aufgrund der Unterstützung der alten API minimal.

PS: Upgrade / Downgrade ist nur bei benachbarten Hauptversionen zulässig

Zusätzliche Funktionalität

Logische Verteilung

Ein weiteres interessantes Feature ist die Kombination von Servern in einem Cluster zu logischen Gruppen, an die Replikate angehängt sind. Auf diese Weise können Sie vollständige Kopien von Replikaten desselben Clusters an verschiedene Autogates verteilen. Dies ermöglicht, dass eines der Autohäuser keine vollständige Kopie der Daten in der zweiten hat

Sichern & Wiederherstellen

Couchbase enthält vorgefertigte Sicherungs- und Wiederherstellungstools. Der Sicherungsprozess kann in drei Modi ausgeführt werden: vollständig, differenziell und kumulativ. Dies ermöglicht in einigen Fällen, Speicherplatz und Prozessorressourcen zu sparen.

Couchbase gegen Mongo

Es ist schwierig, die Frage nach der Auswahl alternativer NoSQL-Datenbanken zu beantworten, und häufig ist das beste Unix das, das Ihr Administrator kennt. Versuchen wir zu formulieren, warum wir Couchbase bevorzugen und nicht eine andere sehr beliebte Plattform - MongoDB.

Es ist ziemlich schwierig, zwei verschiedene Projekte mit unterschiedlicher Architektur und Funktionalität zu vergleichen. Einer der Parameter, auf die wir geachtet haben, ist die einfache Wartung und die Möglichkeit, das System schnell neu zu konfigurieren, um die Anforderungen des Unternehmens zu erfüllen.

Tabelle 1 Vergleich

Tabelle 2 Replikationsvergleich

Insgesamt ist Couchbase flexibler und einfacher in den für unsere Aufgaben erforderlichen Einstellungen und der sich schnell ändernden Hybridarchitektur.

Betriebserfahrung

Zunächst möchten wir die Nummern angeben, mit denen das System und der Cluster jetzt auf Couchbase arbeiten.

1. Über 80 Millionen Abonnenten [i]
2. 380 Millionen JSON-Kundeninformationsdokumente
3. 3,5-TB-Festplatte (wir verwenden Memcached, Informationen auf der Festplatte werden für einen schnellen Start gespeichert)
4. 3 TB RAM
5. 50.000 Operationen pro Sekunde (Abb. 5)
6. 50 Microservices, die den gesamten Nachrichtenfluss verarbeiten

Die ersten Meilensteine ​​der Transformation haben wir mit der dritten Version von Couchbase begonnen. In der ersten Phase, zu Beginn des Projekts, funktionierten alle Anwendungen stabil. Bei der Übersetzung zusätzlicher Logik in einen neuen Mechanismus wurden wir jedoch mit der Tatsache konfrontiert, dass der View-Mechanismus unvorhersehbar zu funktionieren begann. Das heißt, Irgendwann friert der Prozess ein und diese Ansichten von einem solchen Knoten kehren nicht mehr zurück. Gleichzeitig wurde der Zugriff auf Daten und deren Verarbeitung nicht unterbrochen. Das Problem konnte recht einfach behoben werden - durch Neustart des Knotens, wodurch die Verfügbarkeit des Dienstes im Allgemeinen verringert wurde. Während der Kommunikation mit dem technischen Support von Couchbase wurde uns ein undokumentierter Befehl angeboten, der nur den Ansichtsprozess neu startet

curl -s --data 'cb_couch_sup: restart_couch ().' -u Administrator: pass http://127.0.0.1:8091/diag/eval [ii]

Der Befehl ist nur in Version 3.x gültig.

curl -s --data 'couch_server_sup: restart_core_server ().' -u Administrator: Administrator http://127.0.0.1:8091/diag/eval

Der Befehl ist nur in Version 4.x gültig.

Ein weiteres Problem der dritten Version war der Mechanismus zur Komprimierung fehlerhafter Daten (Komprimierung). Es musste manuell gemäß den ausgelösten Überwachungsmetriken gestartet werden. Beide Probleme hielten nicht nur die Schicht, sondern auch die Funktionsingenieure unter Spannung.

In diesem Zusammenhang haben wir uns für die Migration auf die vierte Version entschieden. Die Migration mit minimalen Auswirkungen auf den Service dauerte ungefähr zwei Wochen. Der Aktualisierungsprozess selbst erfordert keine komplexen Aktionen und Steuerelemente. Beim Hinzufügen oder Entfernen eines Knotens wird jedoch eine Neuverteilung gestartet, die mindestens zwei Stunden dauert. Dabei haben wir einen Weg gefunden, den Aktualisierungsprozess über einen Pufferserver zu beschleunigen: In diesem Fall wird kein sauberer Neuausgleichsprozess gestartet, sondern Daten von einem Knoten auf einen anderen übertragen. Dies reduzierte den Aktualisierungsprozess auf 30 Minuten.

Bei der Aktualisierung eines Industrieclusters muss die folgende Nuance berücksichtigt werden: Arbeiten im Kompatibilitätsmodus, wenn der Cluster im Modus der jüngsten Softwareversion arbeitet. Positiv zu vermerken ist, dass der Upgrade-Prozess reibungslos und problemlos abläuft. Sie können jedoch erst dann neue Funktionen wie den neuen Komprimierungsmechanismus N1QL verwenden, wenn der gesamte Cluster vollständig aktualisiert wurde.

Nach dem Update konnten wir nur ein Problem beheben - die Komprimierung. Es begann richtig zu funktionieren. Mit dem View-Mechanismus blieb das Problem weiterhin bestehen, obwohl es viel seltener wiederholt wurde. Es war nur durch die Kräfte der Couchbase-Entwickler in Version 4.6.4 möglich, dies zu korrigieren.

Im Rahmen der Lösung von Problemen mit dem technischen Support wurde klar, dass der Ansichtsmechanismus nicht mehr aktualisiert wird. Dies erfolgte auf der Grundlage, dass die meisten Couchbase-Clients keine Ansichten für die Zwecke verwenden, für die sie erstellt wurden, und Couchbase einen neuen N1QL-Mechanismus entwickelte. Es wird von einem separaten Dienst ausgeführt und ist jetzt nicht mehr von Datenknoten abhängig (Abb. 7).

Wir haben alle kritischen Probleme mit Version 4.6.4 geschlossen. Aufgrund der Zunahme der Datenmenge entschieden sie sich jedoch für die Migration auf die fünfte Version, wo sie eine neue Datenbank für die Indizes hinzufügten und bei unseren Daten die Menge an Speicher und Festplatten eineinhalb Mal abnahm. Leider konnten wir keinen Rückgang der Datenmenge auf Datenknoten feststellen.

Schlussfolgerungen

Im Allgemeinen erwies sich Couchbase als ausgereiftes System, das auch in unspezifischen Fällen eine hohe Last aufweist (Viber - wird als Datenbank verwendet). Innerhalb der MegaFon-Hybridarchitektur kann der Cluster ohne Ausfallzeiten der Geräte und ohne ernsthafte Serverrekonfiguration problemlos für jeden Zweck angepasst werden. Dadurch kann das Unternehmen im Allgemeinen die Personalkosten senken und den Service für den Teilnehmer so bequem wie möglich gestalten.

PAO MegaFon

2018 Kovalchuk Egor

[i] Das System verarbeitet nicht nur Teilnehmer, sondern auch Geräte mit integrierten SIM-Karten, Modems usw.

[ii] Konsultieren Sie vor dem Gebrauch einen Spezialisten