PRO INDIVIDUELLE INTEGRATIONSLÖSUNG
Heterogene Migration für mySugr
Maßgeschneidert für Ihre Bedürfnisse und modernen Systemanforderungen
Unser Kunde im Überblick
mySugr ist ein Wiener Startup, gegründet im Jahr 2012. Im Juni 2017 wurde mySugr Teil der Roche-Familie. Im Zusammenhang mit der Firmenintegration im Jahr 2018 stand die Gruppe vor zahlreichen systemischen Herausforderungen. Die Spezialisten von fireup.pro verstärkten das für die effektive Lösung dieser Herausforderungen dedizierte Team.
Die mySugr App ist ein Tool, das sich auf digitale Gesundheitslösungen konzentriert und darauf abzielt, das Leben von Menschen mit Diabetes zu verbessern. Die App liefert edukative Informationen und Begleitung, um den Alltag mit der Krankheit zu erleichtern. Es ist ein effektives System zur Verfolgung und zum Management von Diabetes, das alle wichtigen Informationen auf dem Smartphone nutzt und jederzeit einsatzbereit ist.
Herausforderung
Nach der Markteinführung der neuen Version des Amazon Web Services-Datenbanksystems namens Aurora 3 erwies sich eine heterogene Migration für die mySugr-Anwendung als notwendig.
Aufgrund der vorherigen Aktivierung von Aurora mySQL Backtrack konnte die Standardaktualisierung auf Aurora 3 nicht durchgeführt werden. Daher stand das Team von fireup.pro in Zusammenarbeit mit dem Kunden vor der Wahl eines Tools, das eine sichere Migration ermöglicht. Nach eingehender Analyse entschied sich das Team dafür, die geplanten Ziele zu bündeln und eine Migration von Aurora mySQL auf Aurora PostgreSQL durchzuführen.
Warum ist eine Migration notwendig und was ist das?
In der Systems Applications and Products in Data Processing-Technologie werden zwei Arten von Migrationen unterschieden: homogene und heterogene. Die Wahl des richtigen Typs ist entscheidend, da sie die Auswahl der richtigen Tools und Methoden für die Durchführung der Arbeiten ermöglicht.
Homogene Migration überträgt ein System auf eine neue Plattform, wobei die gleiche Datenbank und das gleiche Betriebssystem verwendet werden. Heterogene Migration hingegen ermöglicht die Änderung beider Elemente.
Das Übertragen von Konfigurationsdateien und Datenbanken in eine neue Umgebung ist eine Herausforderung, insbesondere wenn sich Hardware- oder Systemkomponenten ändern. Trotz der Schwierigkeiten sprechen die Vorteile beider Arten von Migrationen oft für ihre Durchführung.
Vermutete Mehrwerte des Migrationsprozesses
Senkung der Gesamtbetriebskosten
Steigerung der Systemleistung
Erhöhung der Systemverfügbarkeit
Verbesserung der Datensicherheit
Flexibilität durch die Virtualisierung von IT-Systemen
Optimierung der Ressourcennutzung der verwendeten Hardware
Herausforderungen in der Anwendung
Unser Ziel war es, einen Zweig der Anwendung mit der Möglichkeit zu schaffen, zwischen zwei Datenbanktypen umzuschalten, was wir für einen angemessenen Wartungsprozess als entscheidend erachteten. Aufgrund der Inkompatibilität einiger Funktionen der Tools war es eine große Herausforderung, ein zufriedenstellendes Ergebnis zu erzielen!
Wir mussten uns Herausforderungen wie der Tatsache stellen, dass MySQL den SQL-Standard und die Abfragesyntax freier interpretiert. Außerdem ist der standardmäßige und empfohlene Isolationsgrad für Transaktionen in beiden Systemen unterschiedlich. PostgreSQL ist restriktiver und versucht nicht, für den Benutzer zu denken, wie es bei MySQL der Fall ist.
Wir haben uns für das PostgreSQL-Managementsystem entschieden, da es beim Kunden das primäre Datenbanksystem ist und die Wartung von Datenbankschemata vereinfacht. Darüber hinaus sind Operationen im Vergleich zu MySQL weniger blockierend.
Wir erwarteten, dass dies zu einem reaktionsschnelleren System führen würde. Dies haben wir im kritischsten Fall getestet: beim Streaming großer Datenmengen. Zuvor funktionierte das Streaming von Daten für Benutzer mit einer großen Anzahl von Datensätzen in der Datenbank nicht korrekt.
Wir haben daher beschlossen, dass die beste Lösung darin besteht, den Code so zu gestalten, dass er auf beiden genannten Tools korrekt funktioniert.
Wie haben wir das geschafft?
Phasen eines Migrationsprojekts:
Theoretische Verifizierung des Konzepts der Verwendung von PostgreSQL und Erstellung eines Proof of Concept mit Smoke-Tests
Erstellung einer Anwendung, die sowohl mit PostgreSQL als auch mit MySQL läuft
Datenbankschemamigration
Erstellen von Tabellen in PostgreSQL mit passenden Datentypen und Vergleich von Quelldaten- und Zieltyp
Datenmigration von Proof of Concept zur realen Anwendung
Verifizierung von Risiken im Zusammenhang mit Unterschieden zwischen PostgreSQL und MySQL
Proof of Concept mit AWS DMS
Aufbau einer Infrastruktur für die Migration einer Entwicklerdatenbank
Erstellung der Migration für weitere Umgebungen basierend auf dem Proof of Concept in AWS DMS
Umschaltung von Entwicklungsumgebungen
2 Monate Tests
Verifizierung der Migration auf der QA-Umgebung
Hauptphase
Möglich nach positiver Verifizierung und mit einer Dauer von 2,5 Wochen
Umschaltung der QA-Umgebung
Umschaltung der Produktionsumgebung und Bereitstellung der Anwendung für den Kunden
Möglich nach positiver Rückmeldung der Tester
Verwendete Technologien
Für die Durchführung der Migrationsarbeiten nutzte das Team den AWS Database Migration Service. Diese Lösung ermöglichte es uns, den Prozess mit automatisierter Datenbankmigration durchzuführen und gleichzeitig Zeit, Ressourcen und Kosten zu sparen.
Phase 1
die initiale Ladung
Wir erstellen einen Snapshot der Quelldatenbank und importieren dann die Daten aus dem Snapshot in die neue Datenbank.
Phase 2
Echtzeit-Datenmigration mit CDC
Kontinuierliche Datenerfassung (CDC) erfasst alle Änderungen an den Daten der Quelldatenbank und wendet sie dann auf die Zieldatenbank an. Dadurch werden die Daten in beiden Datenbanken identisch gehalten.
Datenbankrisiken bei mySugr und Roche
Risiko 1
Unterschiede in der Datetime-Präzision
Typen von Datenbanken im Quell- und Zielsystem waren nicht identisch. Datetime in MySQL (mySugr) hat eine Genauigkeit von 1 Sekunde, während sie in PostgreSQL (Roche) Mikrosekunden bis zur 6. Dezimalstelle beträgt. Aus unserer Sicht war es notwendig zu überprüfen, ob diese Unterschiede die Funktionalität der Anwendung beeinflussen und ob eine Rundung der Daten auf volle Sekunden erforderlich ist.
Risiko 2
Inkompatibilität der Datentypen
Das PostgreSQL-Tool rundet Zahlen mit Dezimalteil vom Typ FLOAT double anders als MySQL beim Zurückgeben von Daten. Daher hatten wir es mit einer Inkompatibilität der Datentypen zu tun.
RISIKO 3
Unterschiede in der Groß- und Kleinschreibung
MySQL und PostgreSQL haben unterschiedliche Ansätze bei der Behandlung von Groß- und Kleinschreibung. MySQL vergleicht standardmäßig Strings ohne Berücksichtigung der Groß- und Kleinschreibung. Daher war es notwendig, eine manuelle Textsuche zu implementieren und die Tools zu vereinheitlichen, damit sich die Anwendung mit beiden Datenbanktypen identisch verhält.
RISIKO 4
Konvertierung und Interpretation von Daten:
Es gab auch Probleme bei der Umwandlung und Interpretation von Daten (auf Byte-Ebene) durch verschiedene Datenbanksysteme. Das Team musste daher einen Weg finden, um sicherzustellen, dass die Daten in beiden Fällen identisch sind.
Ergebnis
Da unser Kunde mySugr, der ursprünglich MySQL einsetzte, nun Teil der Roche-Gruppe mit PostgreSQL-System ist, entschieden wir uns für die Technologie-Stack-Vereinheitlichung als Hauptziel, das wir mit der Migration erfolgreich umgesetzt haben.
Die Wartungskosten der Anwendung konnten außerdem um 50% gesenkt werden. Dieses Ergebnis wurde durch die Implementierung der neuen Version von Aurora erzielt.
Zudem haben wir darauf geachtet, keine Komponenten ohne Support einzusetzen. Ohne entsprechende Migrationsmaßnahmen und die Anpassung an Aurora 3 würde AWS das alte System ab 2024 nicht weiter unterstützen.
Neunmonatige Arbeit, die mit Experimenten und Konzepten begann, mündete in der Entwicklung einer kompatiblen Anwendung. Wir implementierten eine vereinfachte Version des Prozesses zum Umschalten zwischen Datenbanken, die auf der Änderung eines Anwendungsparameters basiert. Das Ergebnis? Es gelang uns, die Systeme zu synchronisieren und dem Kunden ein Produkt zu liefern, das konsistent mit der Vision der Roche-Gruppe ist, der er beigetreten ist.
KundenmeinungEN
Entdecke, was unsere Kunden denken
Hast du jemals ein Formel-1-Rennen oder den Disney-Film "Cars" gesehen? Und warst du beeindruckt davon, wie schnell sie die Reifen wechseln können? Wir haben etwas Ähnliches erreicht! Allerdings mögen wir Herausforderungen, deshalb haben wir es geschafft, während das Auto noch im Rennen und in Position war.
Dieses 'Wir' ist tatsächlich ein sehr kleines Team der talentiertesten Leute, die ich je getroffen habe. Marcin, Krzysztof - Sie haben es einfach gemacht! Kein Problem war zu groß, keine Herausforderung zu steil. Sie haben alles herausgefunden und dafür gesorgt, dass die Migration so reibungslos verlief, wie sie es tat.
Karl Spies
Backend Entwickler bei mySugr
