Pro indywidualne rozwiązanie integracji
Migracja heterogeniczna dla mySugr
Szyte na miarę potrzeb i nowoczesnych wymagań systemowych
Kilka słów o kliencie
mySugr to wiedeński startup, założony w 2012 roku. W czerwcu 2017 roku dołączył do rodziny Roche. W związku ze zintegrowaniem firm w 2018 roku grupa stanęła przed wieloma wyzwaniami systemowymi. Specjaliści z fireup.pro uzupełnili team dedykowany do ich efektywnego rozwiązania.
Aplikacja mySugr to narzędzie zorientowane na cyfrowe rozwiązania zdrowotne, mające na celu usprawnienie życia osób cierpiących na cukrzycę. Oferuje edukacjęi wsparcie, aby codzienna rutyna związana z chorobą stała się prostsza. Jest to efektywny system do śledzenia i zarządzania cukrzycą, wykorzystujący wszelkie, kluczowe informacje zapisane na smartfonie, gotowe do użycia w każdej chwili.
Problem
Po wprowadzeniu na rynek nowej wersji systemu baz danych Amazon Web Services o nazwie Aurora 3 niezbędnym okazało się przeprowadzenie migracji heterogenicznej dla aplikacji mySugr.
Z powodu wcześniejszej aktywacji Aurora mySQL Backtrack standardowa aktualizacja do Aurora 3 nie mogła zostać przeprowadzona. W związku z tym zespół fireup.pro we współpracy z klientem stanął przed wyborem narzędzia, które umożliwi bezpieczne przeprowadzenie migracji. Po wnikliwej analizie zespół zdecydował się na połączenie planowanych celów i przeprowadzenie migracji z Aurora mySQL do Aurora PostgreSQL.
Dlaczego migracja jest niezbędna i co to jest?
W technologii Systems Applications and Products in Data Processing wyróżniamy dwie migracje: homogeniczną i heterogeniczną. Wybór odpowiedniego typu jest kluczowy, pozwala bowiem na dobór właściwych narzędzi i metodyki przeprowadzanych prac.
Migracja homogeniczna przenosi system na nową platformę z zachowaniem tej samej bazy danych i systemu operacyjnego. Heterogeniczna natomiast pozwala na zmianę obu tych elementów.
Przeniesienie plików konfiguracyjnych i bazy danych do nowego środowiska to wyzwanie, zwłaszcza gdy zmieniają się komponenty hardwarowe czy systemowe. Mimo trudności, korzyści z obu rodzajów migracji często przemawiają za ich realizacją.
Przewidywane korzyści procesu migracyjnego
Obniżenie całkowitych kosztów utrzymania docelowej aplikacji klienta
Zwiększenie wydajności systemu
Zwiększenie dostępności systemu
Zwiększenie bezpieczeństwa danych
Elastyczność wynikająca z wirtualizacji systemów IT
Optymalizacja wykorzystania zasobów zastosowanego hardware'u
Wyzwania w aplikacji
Naszym celem było stworzenie jednej gałęzi aplikacji z możliwością przełączania między dwoma typami bazy danych, co uznaliśmy za kluczowe dla odpowiedniego procesu utrzymania. Ze względu na brak kompatybilności niektórych funkcjonalności narzędzi-osiągnięcie zadowalającego efektu było sporym wyzwaniem!
Musieliśmy stawić czoła takim problemom jak fakt, iż MySQL swobodniej podchodzi do standardu SQL czy składni zapytania. Co więcej, domyślny i zalecany poziom izolacji transakcji jest inny dla obu systemów. PostgreSQL jest bardziej restrykcyjny i nie stara się myśleć za użytkownika, jak jest w przypadku MySQL.
Wybraliśmy system zarządzania PostgreSQL, ponieważ u klienta jest to system baz danych pierwszego wyboru, oraz ze względu na to, że umożliwia łatwiejsze utrzymanie schematów bazodanowych, a operacje są mniej blokujące w porównaniu do MySQL.
Przewidywaliśmy, że dzięki temu system będzie bardziej responsywny. Co przetestowaliśmy w najbardziej krytycznym przypadku: streamingu znacznej ilości danych. Wcześniej, dla użytkowników z dużą liczbą rekordów w bazie streaming danych nie działał prawidłowo.
Postanowiliśmy zatem, że najlepszym rozwiązaniem będzie doprowadzenie kodu do postaci, która będzie poprawnie funkcjonować na obu, wspomnianych narzędziach.
Jak to zrobiliśmy?
Fazy projektu migracyjnego:
Teoretyczna weryfikacja koncepcji wykorzystania PostgreSQL oraz stworzenie proof of concept i wykonanie smoke testów
Stworzenie aplikacji, która uruchomi się zarówno z użyciem narzędzia PostgreSQL jak i MySQL.
Migracja schematu bazodanowego
Tworzenie tabel w PostgreSQL z odpowiednimi typami danych oraz porównanie typów danych źródłowych z docelowymi.
Przenoszenie danych z proof of concept do rzeczywistej aplikacji
Weryfikacja ryzyk związanych z różnicą między narzędziami PostgreSQL a MySQL
Proof of concept w AWS DMS
Stworzenie infrastruktury dla migracji bazy deweloperskiej.
Na podstawie punktu proof of concept w AWS DMS stworzenie migracji dla pozostałych środowisk
Przełączenie środowisk deweloperskich
2 miesiące testów
Weryfikacja migracji na środowisku QA
Faza główna
Możliwa do przeprowadzenia po pozytywnej weryfikacji i trwająca 2,5 tygodnia
Przełączenie QA
Przełączenie środowisk produkcyjnych i udostępnienie aplikacji klientowi
Możliwe po pozytywnej odpowiedzi testerów
Użyte technologie:
Do realizacji działań migracyjnych zespół użył AWS Database Migration Service. Rozwiązanie to umożliwiło nam przeprowadzenie procesu z automatyzacją migracji baz danych, zapewniając jednocześnie oszczędność czasu, zasobów i pieniędzy.
Etap 1
Initial-load
Tworzymy kopię źródłowej bazy danych (snapshot), następnie importujemy dane z kopii do nowej bazy danych.
Etap 2
Migracja w trybie ciągłym CDC
Continuous data capture gromadzi wszystkie zmiany w danych bazy źródłowej, a następnie aplikuje je na bazie docelowej. Dzięki temu dane w obu bazach danych są identyczne.
Ryzyka baz danych mySugr i Roche
Ryzko 1
Różnice w precyzji datetime
Typy baz danych w systemie źródłowym i docelowym, nie były takie same. Datetime w MySQL (mySugr) ma dokładność do 1s w przypadku PostgreSQL (Roche) wynosi ona mikrosekundę do 6 miejsca po przecinku. Z naszego punktu widzenia niezbędna okazała się weryfikacja czy przedstawione różnice nie będą miały znaczenia dla funkcjonalności aplikacji oraz zastosowanie zaokrąglenia danych do pełnej sekundy.
Ryzyko 2
Niezgodność w typach danych
Narzędzie PostgreSQL przy zwracaniu danych zmiennoprzecinkowych typu FLOAT double inaczej zaokrągla liczby z częścią ułamkową, niż MySQL. Mieliśmy więc do czynienia z niezgodnością w typach danych.
Ryzyko 3
Różnice w obsłudze wielkości znaków
MySQL i PostgreSQL prezentują odmienne podejście do wielkości znaków. MySQL domyślnie porównuje stringi, ignorując wielkość znaków. Niezbędnym zatem okazało się zastosowanie ręcznego wyszukiwania w tekście oraz ujednolicenie narzędzi, by aplikacja z oboma typami baz danych zachowywała się identycznie.
Ryzyko 4
Konwersja i interpretacja danych
Pojawiły się również kwestie związane z konwersją oraz interpretacją danych (na poziomie bajtów) przez różne systemy baz danych. Team zatem musiał znaleźć sposób na upewnienie się, że dane w obu przypadkach są takie same.
Efekt
W związku z tym, że nasz klient mySugr korzystający wyjściowo z MySQL jest częścią grupy Roche, użytkującej system PostgreSQL postanowiliśmy, że ujednolicenie stacku technologicznego będzie kluczowym celem, który dzięki migracji udało nam się osiągnąć.
Obniżyliśmy również o 50% koszty utrzymania aplikacji. Wynik ten został osiągnięty dzięki zaimplementowaniu nowej wersji Aurory.
Dodatkowo uniknęliśmy sytuacji, w której używamy komponentów niemających wsparcia. Bez działań migracyjnych i dopasowania do Aurory 3 do 2024 roku AWS nie wspierałby starego systemu.
9-miesięczna praca, począwszy od eksperymentów i koncepcji, zakończyła się stworzeniem kompatybilnej aplikacji. Zastosowaliśmy uproszczoną wersję procesu przełączania między bazami danych, który polega na zmianie parametru aplikacji. Efekt? Udało Nam się zsynchronizować systemy, oferując klientowi produkt spójny z wizją grupy Roche, do której dołączył.
Opinie
Zobacz, co sądzą o nas klienci
Czy kiedykolwiek widziałeś wyścig Formuły 1 lub film Disneya "Auta"? Byłeś pod wrażeniem, jak szybko potrafią zmieniać opony? My zrobiliśmy coś podobnego! Ale lubimy wyzwania, więc zrobiliśmy to, gdy samochód wciąż był na torze wyścigowym — w ruchu! To "my" to tak naprawdę bardzo mały zespół najbardziej utalentowanych ludzi, jakich kiedykolwiek spotkałem.
Karl Spies
Backend Developer w mySugr
