O kliencie:
Nasz klient to średniej wielkości bank komercyjny działający w jednym z krajów Europy Środkowo-Wschodniej i obsługujący klientów indywidualnych, małe i średnie przedsiębiorstwa oraz korporacje. Z jego usług korzysta pół miliona użytkowników.
Opis kanału bankowości mobilnej klienta:
Wśród cyfrowych kanałów najważniejsza jest bankowość mobilna ze względu na:
- szybko rosnącą liczbę aktywnych użytkowników (ok. 300 tys.),
- dużą liczbę logowań (ok. 30 miesięcznie, ok. 3-krotnie więcej w stosunku do bankowości internetowej),
- kluczowe znaczenie dla płatności (mobilnych i zabezpieczenia transakcji dokonywanych kartą płatniczą, tzw. 3D Secure).
Aplikacja mobilna banku uważana jest przez rynek za innowacyjną. Rozwiązanie może obsługiwać klientów detalicznych i firmowych oraz wspiera różne rodzaje płatności, w tym natychmiastowe przelewy międzybankowe, transakcje e-commerce, Apple Pay/Google Pay, autoryzacje typu 3D Secure i wypłaty z bankomatów bez użycia karty.
Design bankowości mobilnej została zaprojektowana i uruchomiona kilka lat temu przy użyciu nowoczesnych rozwiązań technologicznych (natywnych aplikacji w językach Kotlin i Swift), architektury mikroserwisowej, bazy danych Oracle oraz zarządzana jest przy użyciu OpenShift.
Platformę zainstalowano w środowisku lokalnym, a infrastruktura sprzętowa jest gotowa na obsługę miesięcznych szczytów obciążenia (np. dni wypłaty pod koniec miesiąca) oraz okresowych szczytów (takich jak Black Friday, wyprzedaże po świętach Bożego Narodzenia i letnie przeceny).
Wyzwanie: rozległa infrastruktura i wysokie koszty utrzymania
CTO banku zidentyfikował następujące wyzwania związane z utrzymaniem platformy mobilnej:
Koszty rozbudowy infrastruktury
Infrastruktura lokalna musi być gotowa do obsługi szybkiego wzrostu liczby użytkowników i kilku szczytów użytkowania w ciągu roku.
Ponadto powinna być wysoce wydajna, ponieważ ma kluczowe znaczenie dla realizacji płatności. W związku z tym wymaga niezbędnej rezerwy mocy zużywanej tylko kilka razy w roku.
Koszty utrzymania zasobów dla różnych środowisk
W przypadku infrastruktury lokalnej bank musi inwestować w utrzymanie różnych środowisk sprzętowych.
Przykładami są środowiska developerskie, pomostowe, testowe (ang. User Acceptance Tests, UAT), przedprodukcyjne, produkcyjne i referencyjne (kopia środowiska produkcyjnego w celu replikacji ewentualnych błędów).
Każde środowisko obejmuje sprzęt, który należy konserwować, okresowo odnawiać i/lub kupować w celu wspierania nowych inicjatyw.
Koszt licencji na korzystanie z bazy danych
Znaczącym kosztem obciążającym budżet IT jest roczna opłata licencyjna dla dostawcy rozwiązania bazodanowego.
Bank rozważa migrację do alternatywnej bazy danych typu open-source.
Rozwiązanie:
Odpowiedzią na powyższe wyzwania była migracja platformy do chmury, wyposażonej w skalowalną i wysoce dostępną bazę danych, oferowaną w formie usługi i rozliczanej za faktyczne wykorzystanie mocy obliczeniowej.
Dodatkowa korzyść to natychmiastowy dostęp do narzędzi pozwalających na budowanie zautomatyzowanych procesów CI/CD. Ze względu na brak wewnętrznych ekspertów w tej dziedzinie, nasz klient poszukiwał doświadczonego doradcy, który pomógłby zespołowi bankowemu w migracji platformy i dokonaniu niezbędnej optymalizacji kodu.
Migracja do chmury krok po kroku:
- 1. Migracja z OpenShift do Google Kubernetes Engine
- 2. Konfiguracja Cloud SQL dla PostgreSQL
- 3. Migracja danych do Cloud SQL dla PostgreSQL
- 4. Migracja na środowisko produkcyjne
Aby wykonać migrację do GKE, dostosowaliśmy aplikację i przeprowadziliśmy niezbędne testy:
- Adaptację back-endu bankowości mobilnej dla Kubernetes
- Integrację z natywnymi usługami Google Cloud, takimi jak Pub/Sub
- Pierwsze testowe uruchomienie mobilnej platformy bankowej na Kubernetes
- Zbudowanie i skonfigurowanie dojrzałego potoku CI/CD
- Przygotowanie wymaganych środowisk w Google Cloud (testowe, pomostowe, produkcyjne)
- Testowe uruchomienie mobilnego banku na GKE z testami E2E, testami wydajnościowymi i wymiarowaniem dla produkcji
- Konfigurację bezpiecznego ruchu wejściowego/wyjściowego oraz integrację z usługami zewnętrznymi spoza chmury publicznej
- Przekierowanie ruchu ze środowiska lokalnego na Google Cloud
Aby zacząć korzystać z Cloud SQL dla PostgreSQL, wykonaliśmy następujące zadania:
- Przygotowaliśmy i zweryfikowaliśmy zestawy zmian Liquibase
- Testowo uruchomiliśmy system w środowisku lokalnym z bazą danych PostgreSQL
- Określiliśmy wymiarowanie dla Cloud SQL
- Zmigrowaliśmy dane z Oracle do Cloud SQL dla PostgreSQL w środowisku testowym
- Przeprowadziliśmy testy wydajności i strojenie bazy danych
- Ukończyliśmy testową migrację produkcyjnej bazy danych
- Zmigrowaliśmy produkcyjną bazę danych
Aby zacząć korzystać z Cloud SQL dla PostgreSQL, wykonaliśmy następujące zadania:
- Konfigurację Cloud SQL dla środowiska przedprodukcyjnego
- Migrację danych, a następnie walidację wyników migracji
- Testowe uruchomienie bankowości mobilnej z bazą danych Cloud SQL
- Testy wydajności i weryfikację kluczowych wskaźników efektywności
- Testową konfigurację zasad tworzenia kopii zapasowych i testy przywracania
Po pozytywnych wynikach testów powtórzyliśmy migrację na środowisko produkcyjne z aktualnymi danymi i wykonaliśmy następujące czynności:
- Konfigurację Cloud SQL dla środowiska produkcyjnego
- Migrację danych, a następnie walidację wyników migracji
- Testy wydajności i weryfikację kluczowych wskaźników efektywności
- Konfigurację zasad tworzenia kopii zapasowych i testy przywracania
- Przełączyliśmy ruch systemu do bazy danych Cloud SQL
Sprawmy, aby doświadczenia finansowe były
łatwe i przyjemne!
Powiedz nam, czego potrzebujesz, a my się z Tobą skontaktujemy.