In-Memory Architektur für Web-Services: Grundlagen der Technologie und Prinzipien

In-Memory — ein Satz von Konzepten zur Datenspeicherung, bei denen Daten im Arbeitsspeicher der Anwendung gespeichert werden, während die Festplatte für Backups verwendet wird. In klassischen Ansätzen werden Daten auf der Festplatte gespeichert, und der Arbeitsspeicher fungiert als Cache. Zum Beispiel fordert eine Webanwendung mit Backend zur Datenverarbeitung Daten aus dem Speicher an: sie erhält, transformiert und überträgt viele Daten über das Netz. Bei In-Memory werden Berechnungen direkt an die Daten gesendet — in den Speicher, wo sie verarbeitet werden, und das Netzwerk wird weniger belastet.

Dank seiner Architektur ist der Zugriff auf Daten bei In-Memory vielfach, manchmal sogar um Größenordnungen schneller. Zum Beispiel möchten Bankanalytiker in einer Analyseanwendung einen Bericht über die vergebenen Kredite im Zeitverlauf nach Tagen des letzten Jahres einsehen. Dieser Prozess würde mit einer klassischen DBMS Minuten in Anspruch nehmen, während er mit In-Memory fast sofort verfügbar ist. Das liegt daran, dass der Ansatz es ermöglicht, viel mehr Informationen zwischenzuspeichern, die im Arbeitsspeicher «greifbar» gehalten werden. Die Anwendung muss keine Daten von der Festplatte anfordern, deren Verfügbarkeit durch die Geschwindigkeit des Netzwerks und der Festplatte begrenzt ist.

Welche weiteren Möglichkeiten bietet In-Memory und was ist dieser Ansatz, wird Wladimir Pligin — Ingenieur bei der Firma GridGain. Dieses Übersichtsmaterial wird Entwicklern von Backend-Webanwendungen nützlich sein, die nicht mit In-Memory gearbeitet haben und es ausprobieren möchten oder sich für moderne Trends in der Softwareentwicklung und Architekturdesign interessieren.

Hinweis. Der Artikel basiert auf der Transkription von Wladimirs Vortrag auf der Konferenz #GetIT Conf. Vor der Einführung der Selbstisolierung führten wir regelmäßig Meetups und Konferenzen für Entwickler in Moskau und St. Petersburg durch: wir diskutierten Trends, aktuelle Entwicklungsthemen, Probleme und deren Lösungen. Jetzt können keine Konferenzen stattfinden, aber es ist die richtige Zeit, um nützliche Materialien aus der Vergangenheit zu teilen.

Wer und wie nutzt In-Memory

In-Memory wird häufig dort eingesetzt, wo eine schnelle Interaktion mit dem Benutzer oder die Verarbeitung großer Datenmengen erforderlich ist.

• Banken nutzen In-Memory beispielsweise, um Verzögerungen bei der Nutzung von Anwendungen durch Kunden zu verringern oder um Kundenanalysen vor der Kreditvergabe durchzuführen.
• FinTech nutzt In-Memory, um die Leistung von Dienstleistungen und Anwendungen für Banken zu verbessern, die die Datenverarbeitung und -analyse auslagern. 
• Versicherungsunternehmen: zur Risikobewertung, zum Beispiel durch die Analyse von Kundendaten über mehrere Jahre.
• Logistikunternehmen. Sie bearbeiten viele Daten, um beispielsweise die optimalen Routen für Fracht- und Personentransporte mit Tausenden von Parametern zu berechnen und den Status der Sendungen zu verfolgen.
• Einzelhandel. In-Memory-Lösungen helfen dabei, die Kunden schneller zu bedienen und große Informationsmengen zu verarbeiten: Auslieferungen, Rechnungen, Transaktionen, Verfügbarkeit von Tausenden von Produkten im Lager und die Erstellung analytischer Berichte.
• Im IoT In-Memory ersetzt traditionelle Datenbanken.
• Pharmazeutische Unternehmen nutzen In-Memory, beispielsweise um Kombinationen von Arzneimitteln zu durchlaufen. 

Ich werde einige Beispiele nennen, wie unsere Kunden In-Memory-Lösungen nutzen und wie Sie diese bei sich implementieren können.

In-Memory als primäre Speicherung

Einer unserer Kunden ist ein großer Anbieter medizinischer Forschungsausrüstung aus den USA. Sie verwenden die In-Memory-Lösung als primäre Datenspeicherung. Alle Daten werden auf der Festplatte gespeichert, während eine Untermenge der aktiv genutzten Daten im Arbeitsspeicher gehalten wird. Die Zugriffsverfahren auf den Speicher sind standardisiert – GDBC (Generic Database Connector) und die Abfragesprache SQL.

Dies wird zusammen als In-Memory-Datenbank (IMDB) oder Memory-Centric Storage bezeichnet. Diese Klasse von Lösungen hat viele Namen, das sind nicht die einzigen. 

Besonderheiten der IMDB:

• Die Daten, die in In-Memory gespeichert und über SQL abgerufen werden, sind identisch mit denen in anderen Ansätzen. Sie sind synchronisiert, nur die Präsentationsweise und der Zugriff unterscheiden sich. Zwischen den Daten gibt es Transaktionsfähigkeit.

• IMDB sind schneller als relationale Datenbanken, da das Abrufen von Informationen aus dem Arbeitsspeicher schneller ist als von der Festplatte. 
• Die internen Optimierungsalgorithmen haben weniger Anweisungen.
• IMDB eignen sich für die Verwaltung von Daten, Ereignissen und Transaktionen in Anwendungen.

IMDB unterstützen teilweise ACID: Atomarität, Konsistenz und Isolation. Aber sie unterstützen keine "Dauerhaftigkeit" – beim Stromausfall gehen alle Daten verloren. Um dieses Problem zu lösen, können Snapshots verwendet werden – ein "Snapshot" der Datenbank, ähnlich einem Backup einer DB auf die Festplatte, oder Transaktionen (Logs) aufgezeichnet werden, um die Daten nach einem Neustart wiederherzustellen.

Für den Aufbau ausfallsicherer Anwendungen

Stellen wir uns die klassische Architektur einer ausfallsicheren Webanwendung vor. Sie funktioniert so: Alle Anfragen werden von einem Web-Load-Balancer zwischen Servern verteilt. Dieses System ist widerstandsfähig, weil die Server sich gegenseitig duplizieren und im Fall von Vorfällen abfangen.

Der Load-Balancer leitet alle Anfragen einer Sitzung strikt an einen einzigen Server. Dies ist der Mechanismus der Sticky-Sessions: Jede Sitzung wird an zu einem Server, wo sie lokal gespeichert und verarbeitet wird. 

Was passiert, wenn einer der Server?

Server ausfällt? Der Dienst wird nicht beeinträchtigt, da die Architektur dupliziert ist. Aber wir verlieren eine Teilmenge der Sitzungen des ausgefallenen Servers. Und damit auch die Benutzer, die an diesen Sitzungen hängen. Zum Beispiel bestellt ein Kunde etwas und wird plötzlich aus dem Konto geworfen. Er wird unzufrieden sein, wenn er sich erneut anmeldet und feststellt, dass er alles noch einmal bestellen muss.

Das Webanwendung muss in der Lage sein, eine große Anzahl von Benutzern zu unterstützen, ohne dass es zu Verzögerungen kommt, damit sie komfortabel arbeiten können. Aber im Falle eines Ausfalls wird das Zeitintervall für die Kommunikation mit dem Sitzungsspeicher bei jeder weiteren Anfrage immer länger. Dies erhöht die durchschnittliche Latenz für die anderen Benutzer. Aber sie möchten nicht länger warten als gewohnt.

Dieses Problem kann wie bei einem anderen unserer Kunden — einem großen PASS-Anbieter aus den USA — gelöst werden. Er verwendet In-Memory, um Web-Sitzungen zu clusterisieren. Dafür werden sie nicht lokal, sondern zentral in einem In-Memory-Cluster gespeichert. In diesem Fall sind die Sitzungen viel schneller verfügbar, da sie bereits im Arbeitsspeicher liegen.

Wenn der Server ausfällt, leitet der Load-Balancer die Anfragen des ausgefallenen Servers an andere Server weiter, genau wie in der klassischen Architektur. Aber es gibt einen wichtigen Unterschied: Die Sitzungen werden in einem In-Memory-Cluster gespeichert und die Server haben Zugriff auf die Sitzungen des ausgefallenen Servers.

Dieser Aufbau erhöht die Ausfallsicherheit des gesamten Systems. Darüber hinaus kann man auf den Mechanismus der Sticky-Sessions ganz verzichten.

Hybride transaktional-analytische Verarbeitung (HTAP)

Normalerweise werden transaktionale und analytische Systeme getrennt gehalten. Wenn sie getrennt sind, belastet die Hauptdatenbank die Last. Für die analytische Verarbeitung werden die Daten in eine Replik kopiert, damit die analytische Verarbeitung die transaktionalen Prozesse nicht stört. Aber die Kopierung erfolgt mit Verzögerung – ohne Verzögerung ist eine Replikation nicht möglich. Wenn wir das synchron machen, wird die Hauptdatenbank ebenfalls verlangsamt und wir erzielen keinen Gewinn.

Bei HTAP funktioniert alles anders – dasselbe Datenschatz wird sowohl für die transaktionale Last von Anwendungen als auch für analytische Abfragen verwendet, die lange dauern können. Wenn die Daten im Arbeitsspeicher liegen, werden analytische Abfragen schneller ausgeführt, und der Datenbankserver wird weniger belastet (im Durchschnitt).

Der hybride Ansatz „durchbricht die Mauer“ zwischen Transaktionsverarbeitung und Analyse. Wenn wir Analysen im selben Speicher durchführen, werden analytische Abfragen auf Daten aus dem Arbeitsspeicher ausgeführt. Sie sind viel präziser, besser interpretierbar und adäquater.

Integration von In-Memory-Lösungen

Eine einfache (relativ) Möglichkeit – alles von Grund auf neu zu entwickeln. Wir halten die Daten auf der Festplatte, während die heißen im Speicher liegen. Das hilft, Serverneustarts oder Ausfälle zu überstehen.

Hier gibt es zwei Hauptszenarien, wenn die Daten auf der Festplatte gespeichert sind. Im ersten möchten wir Abstürze oder reguläre Neustarts des Clusters oder von Teilen überstehen – wir möchten ihn als einfache Datenbank nutzen. Im zweiten Szenario, wenn die Datenmenge zu groß ist, liegt ein Teil davon im Speicher.

Wenn es nicht möglich ist, alles von Grund auf neu zu erstellen, kann In-Memory möglicherweise in die bereits bestehende Architektur integriert werden.. Aber nicht alle In-Memory-Lösungen sind dafür geeignet. Es gibt drei zwingende Voraussetzungen. Die In-Memory-Lösung muss unterstützen:

• eine Standardverbindung zur Datenbank, die darunter liegen wird (z. B. MySQL);
• eine Standardsprache für Abfragen, damit die Logik zum Umgang mit dem Speicher nicht umgeschrieben und verändert werden muss;
• Transaktionalität – das bedeutet, die Semantik der Interaktion zu bewahren.

Wenn alle drei Voraussetzungen erfüllt sind, ist die Integration möglich. Wir stellen ein In-Memory-Datenraster zwischen der Anwendung und der Datenbank bereit. Jetzt werden Schreibanfragen an die untergeordnete Datenbank delegiert, während Leseanfragen an die Datenbank gerichtet werden, wenn die Daten im Cache nicht vorhanden sind.

Wenn Ihnen der schnelle Zugriff auf Daten und deren Verarbeitung, beispielsweise für die Geschäftsanalyse, wichtig ist, sollten Sie über die Implementierung von In-Memory nachdenken. Für die Umsetzung können Sie beide Methoden bei der Planung einer neuen Architektur verwenden.

Quelle: habr.com