Nationwide bleibt bei der Migration von Daten von SQL zu MongoDB „fokussiert, fit und schnell”

EINLEITUNG

Die weltweit größte Bausparkasse beginnt mit der Migration

Unabhängig davon, für welche Bank Sie sich entscheiden – der Name Nationwide Building Society ist im gesamten Vereinigten Königreich bekannt. Das Unternehmen ist nicht nur die weltweit größte Bausparkasse, sondern auch schon sehr lange auf dem Markt: Es wurde 1884 gegründet, hat heute über 16 Millionen Kunden und verwaltet fast 10 % der Ersparnisse britischer Haushalte. Der Status von Nationwide als Genossenschaft – sie gehört ihren Mitgliedern und wird für diese geführt, nicht für Aktionäre – untermauert die strategischen Triebkräfte der Bausparkasse: lohnende Beziehungen, exzellenter Kundenservice und kontinuierliche Verbesserung. Als Teil des Kreditrisikoteams sitzt die leitende Ingenieurin Neha Yadav im Herzen von Nationwide – sie klassifiziert die Risikobewertung jedes Kreditprodukts, das bei der Bausparkasse eingeht, auf deren Grundlage Kredite angenommen, bevorzugt oder abgelehnt werden. „Wir versuchen immer, auf die neueste Technologie umzusteigen, und konzentrieren uns stets darauf, die beste Datenqualität zu erzielen“, sagt Yadav. „Wir sind ein hochgradig fittes, fokussiertes und schnelles Team – denn alles, was wir tun, soll unseren Mitgliedern zugutekommen.“

DIE HERAUSFORDERUNG

Risiko am Ende der Lebensdauer mindern

Es war diese Entschlossenheit, „fit, fokussiert und schnell“ zu sein, die Nationwide dazu bewog, sich von seiner bisherigen, vollständig lokalen Plattform zu verabschieden. „Um Sicherheitsvorkehrungen zu treffen und den gegenseitigen Nutzen für die Kunden zu gewährleisten, war die Idee, alle alten Server zu entfernen, alles in die Cloud zu verlagern und eine NoSQL-Datenbank einzurichten“, sagt Yadav, „um so der Gesellschaft und ihren Mitgliedern einen optimalen Service zu bieten.“

Ursprünglich hatte das Team vor, einige der Cloud-Funktionen von AWS zu nutzen und MongoDB ausschließlich als Teil eines Auditspeichers einzusetzen – „das war die ursprüngliche Idee“, sagt Yadav, der zu dieser Zeit das lokale Team mit etwa 12 Mitarbeitern leitete. Die Überziehungsdatenbank von Nationwide befand sich vor Ort – ihre Dienste wurden von verschiedenen Bereichen innerhalb der Bausparkasse genutzt und näherten sich dem Ende ihrer Lebensdauer. Im Rahmen der Umstellung auf eine vollständig externe Datenspeicherung entschied das Team, dass die Überziehungsdatenbank ein guter Ausgangspunkt wäre.

Im April 2023 begann das Team mit der Analyse der erforderlichen Änderungen und konsultierte MongoDB – mit dem es bereits eine etablierte Beziehung unterhielt – hinsichtlich der Frage, wie das Unternehmen diesen Prozess unterstützen könnte. Angesichts der Herausforderungen bei der Minderung des Risikos am Ende der Lebensdauer war es für Nationwide ein wichtiges Kriterium, die Daten mit möglichst geringem manuellem Aufwand und Entwicklungsaufwand zu migrieren. „Wir hatten also nicht viel Zeit, uns auf die Datenmigration zu konzentrieren“, sagt Yadav. „Da schlug MongoDB die Preview-Version des Relational Migrator vor.“

Es war das erste Mal, dass das Produkt im Vereinigten Königreich zum Einsatz kam.

DIE LÖSUNG

Daten schnell, sicher und mit Validierung migrieren

Mit dem MongoDB Relational Migrator führten Yadav und ihr Team während einer geplanten Wartung eine einzige Migration der Überziehungsdatenbank von SQL zu MongoDB Atlas durch. „Wir wollten die Integrität der Umgebung erhalten und das Risiko verringern, dass bei einer kontinuierlichen Datenmigration etwas übersehen oder nicht überprüft wird“, erklärt sie. „Deshalb haben wir uns für eine Snapshot-Migration entschieden.“

Dennoch kann man sagen, dass das Team angesichts der Komplexität von Migrationen im Allgemeinen und der Unsicherheit darüber, wie die migrierten Daten validiert werden oder letztendlich funktionieren würden, eine gewisse Nervosität verspürte. Das Team konnte Testmigrationen durchführen, um den Produktionsprozess zu validieren. Dazu wurde eine ähnliche Testumgebung erstellt, die mehrere Anfragen empfangen würde – diese wurden dann gestoppt, um zu sehen, wie sich das System verhalten würde. „Auf diese Weise waren wir ziemlich sicher, dass es klappen würde“, sagt Yadav. „Und um auf Nummer sicher zu gehen, führten wir die Live-Migration im Büro durch.“

Das komplette Migrationsprojekt, von der On-Premise-API in die Cloud, nahm etwa sechs Monate in Anspruch. Das Team stellte Microservices in seinem AWS-Cluster bereit, sodass zahlreiche lokale ETL-Feeds ebenfalls verschoben werden mussten, einschließlich der Entwicklungszeit für Lambdas.

„Es war nicht nur die Datenmigration“, sagt Yadav, „es war die Migration der Feeds, der API und der Daten.“

Sie fügt hinzu: „Es erforderte viele Konzeptnachweise und gemeinsame Ressourcen. Wenn ich alle Verzögerungen herausrechne, hätte es drei Monate gedauert – es ging sehr schnell. „Ich würde sagen, dass wir mit Relational Migrator 50 % unseres Aufwands einsparen konnten.“

Eine besonders gefragte Funktion von Relational Migrator war Query Converter, ein KI-Tool zur Migration von SQL-Abfragen in MongoDB-Aggregationspipelines. „Das war eine sehr hilfreiche Funktion, um unser Verständnis zu überprüfen und sicherzustellen, dass alles, was wir geschrieben hatten, auch korrekt war“, sagt Yadav.

DAS ERGEBNIS

Vertrauen in die Möglichkeit, Daten ohne Entwicklungsaufwand von lokalen Systemen in die Cloud zu übertragen

„Relational Migrator gab uns die Gewissheit, dass wir keine manuelle Entwicklung oder Validierung der Daten vornehmen mussten, um unsere Daten von lokalen Servern in die Cloud zu übertragen“, fasst Yadav zusammen. Die Migration der Überziehungsdatenbank von SQL zu MongoDB Atlas war für das Team eine so positive Erfahrung, dass es nun dabei ist, weitere Datenbanken in die Cloud zu übertragen. „Relational Migrator ist sehr einfach zu bedienen“, erklärt Yadav. „Jeder mit Grundkenntnissen kann ihn verwenden. Das ist der beste Teil davon.“

Und es hat sich ausgezahlt. „In SQL dauerte es früher mindestens eine Stunde, um einen unserer Feeds zu generieren“, sagt Yadav. „Seit wir zu MongoDB gewechselt sind, beträgt die maximale Zeit zwei Minuten.“ Das Team hat zwar erfolgreich Daten zu MongoDB migriert, Abfragen optimiert und die Gesamtleistung verbessert, aber der mit Abstand größte Gewinn besteht darin, dass es das Risiko des Endes der Lebensdauer gemindert hat. „Wir haben uns sehr spät dazu entschlossen, die Überziehungsdatenbank vollständig in die Cloud zu verlagern, was eigentlich unser Ziel für Phase drei war, aber wir haben es auf Phase zwei vorgezogen. Mein wichtigster Erfolg ist also, dass wir das erfolgreich umgesetzt haben.“

Es gibt jedoch noch einen weiteren Grund zur Freude: „Zuvor wurde Relational Migrator bei Nationwide noch nicht eingesetzt“, sagt Yadav. „Das war mit einem gewissen Risiko verbunden, denn wenn es nicht so funktioniert hätte, wie ich es mir vorgestellt hatte, hätte viel auf dem Spiel gestanden. Ich bin stolz darauf, dass das IT-Team von Nationwide es zum Laufen gebracht hat und dass dies eine Premiere war.“

„Die erfolgreiche Modernisierung eines Anwendungs-Backends in nur sechs Monaten ist besonders beeindruckend in der Finanzwelt, wo größere Infrastruktur-Upgrades oft mehrere Jahre dauern“, fügt sie hinzu. „Diese neue Agilität wird Nationwide helfen, seine Marktführerschaft in einem zunehmend technologieorientierten Bankenumfeld zu behaupten.“