/ Case Study

Case Study: Pacific.org i wykorzystanie rozwiązań Google Cloud

Z artykułu dowiesz się:

  1. jakie są doświadczenia Centurii w pracy z Google Cloud na przykładzie projektu z branży FinTech 
  2. czy i dlaczego warto wybrać Google Cloud 
  3. czy Google Cloud spełnił wszystkie wymagania naszego Partnera
  4. jakie są ograniczenia technologii oferowanych przez Google

Pacific.org to poznański startup oferujący rozwiązania z zakresu technologii finansowych. Jego głównym produktem jest aplikacja mobilna, którą nazwano również Pacific.org.

Aplikacja ta oferuje m.in. takie funkcjonalności jak:

  • market place i kupowanie produktów bezpośrednio w aplikacji lub poprzez social media (za pomocą kodów QR)
  • dedykowany czat ze znajomymi umożliwiający łatwy transfer środków finansowych

Aplikacja jest dostępna zarówno na telefony z systemem Android, jak i te z iOS. Jednym z priorytetów firmy jest dbanie o środowisko (np. karty płatnicze oferowane przez Pacific.org są stworzone z plastiku pozyskanego ze śmieci zalegających w morzach i oceanach).

Dodatkowo, spółka przeznacza 0,1% każdej transakcji płatniczej wykonanej za pomocą wspomnianych wyżej kart na rzecz fundacji oczyszczającej oceany. Więcej o tym projekcie tutaj.  

Pacific.org zwrócił się do Centurii w maju 2021, poszukując profesjonalnego wsparcia w zakresie usług DevOps.

Naszym zadaniem było wdrożenie środowiska API Pacific w ramach chmury publicznej Google Cloud Platform oraz pomoc we wdrożeniu procesu CI/CD dla tej aplikacji. Z systemem tym łączy się aplikacja mobilna, a on sam komunikuje się z systemami informatycznymi banku. 

Po okresie wdrożenia Centuria miała zająć się utrzymaniem wdrożonego systemu w trybie 24/7, zgodnie z wymaganiami klienta.  

Pierwotne założenia technologiczne

Aplikacja API od samego początku była tworzona i testowana przez Pacific.org w ramach chmury publicznej Google Cloud.

Partner zgłosił się do nas z gotową wizją, która zakładała jak największe użycie technologii cloud‑native oferowanych przez GCP. W szczególności potrzebne było zaprojektowanie infrastruktury pod kątem sieciowym, zapewnienie bezpiecznego dostępu VPN oraz szyfrowanej łączności site‑to‑site z systemami banku.

Dodatkowo, otrzymaliśmy prośbę dotyczącą przeprowadzenia migracji repozytorium kodu z Bitbucket na Gitlab, ze względu na dość częste problemy z dostępnością i niestabilność jej działania. 

Google Cloud dla aplikacji – zalety i wady tego rozwiązania

Tak, jak wspomnieliśmy wcześniej, projekt od początku był tworzony w GCP, więc tutaj przeniesienie do innego dostawcy nie było nawet rozważane. W teorii byłoby to oczywiście możliwe, ale oznaczałoby dla Pacific.org dodatkowy koszt i przede wszystkich znacznie dłuższy time‑to‑market. 

Warto również podkreślić, że aplikacja mobilna korzysta z technologii Google, więc dzięki temu całość projektu pozostała spójna i istnieje możliwość centralnego zarządzania kwestią dostępów do jej zasobów za pomocą Google IAM.  

Naszym zdaniem Google IAM jest świetnym narzędziem, w szczególności w połączeniu z Google Workspace lub jego darmową wersją, czyli Cloud Identity (którą w Centurii z powodzeniem wykorzystujemy). 

Dużą zaletą Google Cloud jest na pewno jej obecność w Polsce. 13 kwietnia 2021 oficjalnie został otwarty region dla Google Cloud w Warszawie.  

Istnieje jednak również kilka wad tego rozwiązania, które wynikają głównie z jego dynamicznego rozwoju: 

  • świeżo uruchomione projekty mają często nakładane dość restrykcyjne limity wykorzystania zasobów (zmiana wymaga bezpośredniego kontaktu z Google i nie może być wykonana ad hoc)
  • interfejs chmury i jej dokumentacja nie zawsze są do końca jasne i logiczne
  • polski region już jest dostępny, jednak nie posiada jeszcze wszystkich usług i funkcjonalności czy typów maszyn, tak jak na przykład regiony europe‑west, dlatego też wybraliśmy Frankfurt (europe‑west3). 

Środowiska 

W fazie wczesnego rozwoju aplikacja była budowana i utrzymywana w ramach jednego projektu GCP.

Po przejściu w fazę przedprodukcyjną otrzymaliśmy zadanie utworzenia oddzielnych projektów dla środowisk:

  • dev (deweloperskiego)
  • uat (user acceptance test)
  • prod (produkcyjnego)

Dodatkowo potrzebne było wyniesienie do osobnych projektów środowisk:

  • build‑env (do budowania aplikacji)
  • monitoring‑logs (do monitorowania i zbierania logów z aplikacji).

W przypadku środowisk rozwojowych (dev i uat) stworzyliśmy mechanizm pozwalający na automatyczne okresowe wyłączanie zasobów i w konsekwencji realne oszczędności finansowe. 

Oferujemy usługi z zakresu automatyzacji procesów IT: projektowania, wdrożenia i utrzymania środowisk chmurowych oraz procesu CI/CD.

Sprawdź w naszej ofercie.

Wsparcie DevOps

Użyte technologie

Terraform 

Do deploymentu środowiska użyliśmy narzędzia Terraform autorstwa firmy HashiCorp. Więcej informacji o narzędziu tutaj. Dzięki niemu uzyskaliśmy wersjonowanie konfiguracji i powtarzalności tworzonych środowisk.

Tak jak wcześniej wspomnieliśmy, interfejs GCP nie zawsze jest do końca przejrzysty. Wszystko da się oczywiście “wyklikać”, ale nawet przy dużej sprawności w tym temacie łatwo o czymś zapomnieć i w konsekwencji stracić długie godziny na diagnostykę. 

Przygotowanie kodu modułów Terraform oznacza konieczność jednorazowego poświęcenia czasu, ale ta inwestycja zwraca się z nawiązką.

 

OpenVPN

GCP na tę chwilę nie oferuje usługi VPN typu dial‑up. W związku z tym potrzebne było wybranie rozwiązania skalowalnego, łatwego w obsłudze, w rozsądnej cenie… a także będącego standardem branżowym. Razem z Pacific.org wybraliśmy OpenVPN Access Server. 

Ma on wiele zalet: 

  • szybki i prosty deploy z GCP Marketplace
  • darmowy dla mało używanych środowisk  
  • WebGUI pozwalające na konfigurację serwera, a także wygenerowanie profili dostępowych bezpośrednio przez użytkownika (brak konieczności wysyłania plików mailem itd.)
  • stosunkowo niska cena licencji (75$/msc), która może być użyta na wielu instancjach OpenVPN AS jednocześnie (licencjonowane nie są instancje, ale aktywne/zestawione tunele OpenVPN)
  • niewielkie wymagania sprzętowe

Jedyną wadą tego rozwiązania jest fakt, że… nie jest to rozwiązanie Google typu cloud‑native 😊 Jeśli takowe by się pojawiło, to na pewno rozważylibyśmy jego użycie. 

 

Google Classic VPN

Użyty został Classic VPN, ponieważ HA VPN ma ograniczenia dotyczące zestawiania tuneli w ramach adresacji Google.

Jedyną opcją jest użycie HA VPN po obu stronach (co w naszym przypadku nie było możliwe). Zgodnie z dokumentacją samego Google: “HA VPN rejects Google Cloud IP addresses when they are configured in an external VPN gateway resource—for example, using the external IP address of a VM instance as the external IP address for the external VPN gateway resource. The only supported HA VPN topology between Google Cloud networks is where HA VPN is used on both sides,(…)”. Więcej informacji na temat tego rozwiązania tutaj

Potrzebowaliśmy połączenia środowiska aplikacyjnego (dev,uat,prod) z monitoring‑logs. Tutaj świetnie sprawdził się VPC Peering – rozwiązanie bardzo proste do wdrożenia, eliminujące dodatkowe tunele site‑to‑site. Więcej szczegółów na temat VPC Peering  tutaj.

Google Cloud DNS

To kolejny element typu cloud‑native. Pozwala na tworzenie prywatnych stref DNS, a także nadpisywanie publicznych wpisów.

Jego użycie znacząco ułatwia rozwijanie aplikacji, ponieważ umożliwia zastosowanie w kodzie nazw DNS, które są potem rozwiązywane przez Google Cloud DNS.   Więcej o Google Cloud DNS tutaj.

 

Google Secret Manager

Umożliwia proste i bezpieczne zarządzanie wszystkimi hasłami, tokenami, itd., których używa aplikacja. Dostęp ograniczany jest przez IAM.  

Wady tego rozwiązania: nie każda usługa na tę chwilę jest w stanie bezpośrednio korzystać z Google Secret Managera (GSM). Przykładowo, GKE w tym momencie nie jest w stanie korzystać z certyfikatów SSL umieszczonych w GSM. Można mieć tylko nadzieję, że sytuacja się zmieni w przyszłości. Więcej informacji o Google Secret Manager tutaj.

 

Google Kubernetes Engine

Aplikacja API jest tutaj w pełni skonteneryzowana. To de facto modularny monolit, który korzysta z zewnętrznych usług (Cloud SQL i Elasticsearch). Kubernetes w Google ma sporo zalet.

Przede wszystkim autorem Kubernetes jest Google i to Google wypuściło pierwszy managed Kubernetes w 2015 roku.

Dodatkowo GKE jest, naszym zdaniem, najbardziej elastycznym rozwiązaniem tego typu. Ma, w porównaniu do Azure AKS i Amazon EKS, największą liczbę dostępnych wersji k8s (więcej informacji tutaj). Dobrze działa automatyczny upgrade control plane i node pool.

Każdy node może mieć włączoną opcję auto‑repair, która (jak sama nazwa wskazuje) jest w stanie przywrócić go do życia w wypadku problemów (więcej informacji tutaj).

Node’y używają Container‑Optimized OS, który został specjalnie stworzony i zoptymalizowany przez Google pod kątem obsługi kontenerów (więcej informacji tutaj).

Zarządzanie GKE możliwe jest z poziomu WebGUI, ale największą siłę ma jednak command line (więcej informacji tutaj).

Oczywiście, jeśli w swoim projekcie używamy konkretnych rozwiązań Microsoft lub Amazon, to użycie GKE niekoniecznie jest najlepszym wyjściem. Czas, który moglibyśmy wykorzystać na rozwijanie aplikacji stracimy na tworzenie i utrzymywanie integracji.

W naszym przypadku, jednak od początku chodziło o wykorzystanie usług Google, zatem nie było lepszej alternatywy niż wykorzystanie GKE.

GKE można polecić również dla projektów hybrydowych (on‑premise + cloud) oraz tych, które nie są wprost związane z jednym vendorem.

 

Google Cloud SQL

API korzysta z bazy PostgreSQL. Użycie natywnego Google Cloud SQL znacząco upraszcza zarządzanie instancją. Można kilkoma kliknięciami ustawić HA, automatyczne backupowanie bazy… a przywrócenie bazy jest równie proste. Więcej informacji o Google Cloud SQL tutaj.

 

Elasticsearch Cloud

Początkowo chcieliśmy użyć Elastic Cloud SaaS, natomiast w momencie uruchamiania projektu nie było możliwości zestawienia bezpiecznego (prywatnego) połączenia z GCP. 

Z tego powodu zdecydowaliśmy się na Elastic Cloud on Kubernetes. W przyszłości to rozwiązanie daje możliwość łatwej migracji na Elastic Cloud SaaS, jeśli pojawi się taka potrzeba.

9 września 2021 ogłoszono możliwość użycia Google Cloud Private Service Connect, szczegółowe informacje na ten temat znajdziesz tutaj.

 

Google Cloud Build

Pierwotnie zakładaliśmy, że cała aplikacja będzie budowana i testowana na Cloud Build. Niestety – wykryliśmy ograniczenia, które to uniemożliwiły.

O ile samo budowanie aplikacji nie sprawiało większych problemów, to testowanie w naszym przypadku wymagało bezpośredniego dostępu do usług (testowa baza danych Cloud SQL oraz instancja Elasticsearch).

Google dopiero sierpniu 2021 udostępniło Cloud Build Private Pools, które pozwalają na proste łączenie Cloud Build z VPC.

 

Kaniko

Próbowaliśmy również zrealizować budowanie obrazów bezpośrednio na Kubernetes z użyciem Kaniko, jednak problemy z cache spowodowały porzucenie tego pomysłu. 

 

Docker

Problemy z Kaniko spowodowały zmianę koncepcji i powrót do Dockera, który był wcześniej wykorzystywany lokalnie przez deweloperów. 

 

Gitlab

Ostatecznie zrezygnowaliśmy z Cloud Build na rzecz Gitlab, który początkowo tylko pełnił rolę repozytorium kodu i uruchamiał Cloud Build (gdzie był uruchamiany pipeline).

Aktualnie cały pipeline został przeniesiony do Gitlab, a budowanie i testowanie aplikacji odbywa się na maszynie wirtualnej z zainstalowanym Dockerem i Gitlab Runner. 

 

Prometheus

Ze względu na dość specyficzne wymagania Klienta zaproponowaliśmy wdrożenie dedykowanego, zewnętrznego (ale hostowanego również w GCP) oprogramowania do monitoringu.

Dane zbierane są w ramach konkretnego środowiska i przesyłane do centralnej instancji umieszczonej w środowisku monitoring‑logs. Dodatkowo dane z monitoringu przesyłane są do naszej wewnętrznej instancji Prometheus, której Centuria ServiceDesk używa do monitoringu 24/7. 

Wewnętrzne rozwiązanie do przechowywania i analizy logów (Google Cloud Logging) jest dosyć ciężkie i mało elastyczne. Dlatego wybraliśmy Graylog (darmowe oprogramowanie oparte na stacku ELK). 

 

Fluent Bit

Jednym z naszych dodatkowych zadań było stworzenie automatyki wykrywającej numery kart kredytowych, które potencjalnie mogą być w jakiś sposób przetwarzane przez aplikację (a nie powinny).

Mieliśmy zamiar zrealizować temat za pomocą Grayloga, jednak okazało się to niemożliwe, ze względu na ograniczenia Elasticsearch, z którego sam Graylog korzysta. 

Ostatecznie jako pośrednią warstwę filtrującą użyliśmy Fluent Bit, który sprawdził się bardzo dobrze w tej roli. 

Co przed nami?

Aplikacja działa już produkcyjnie! Zespół programistów intensywnie pracuje nad nowymi wersjami i nowymi funkcjonalnościami. Ilość użytkowników aplikacji sukcesywnie rośnie.

Na pewno konieczna będzie dalsza analiza obciążenia infrastruktury, a także (być może) przeskalowanie zasobów. Z racji tego, że infrastruktura działa już kilka miesięcy i obserwujemy trendy zużycia zasobów, kolejnym krokiem będzie także skorzystanie ze zniżek związanych z jedno lub kilkuletnim commitmentem na zasoby.

Dobór odpowiedniego planu może znacznie obniżyć koszty infrastruktury o nawet kilkadziesiąt procent.

Dodatkowe informacje na temat zniżek związanych z commitmentem znajdziesz tutaj.

Przed nami także dużo żmudniejsza, ale równie ważna praca związana:

  • z utrzymaniem środowiska, w tym jego monitoringiem w trybie 24/7
  • aktualizacjami
  • utrzymywaniem dokumentacji
  • reagowaniem na awarie i incydenty
norbert-hes

O autorze

Norbert Hęś

Customer Project Manager, Centuria Sp. z o.o.

pawel-dlugosz

O autorze

Paweł Długosz

Advisory Board IT, Centuria Sp. z o.o.

Zobacz także

Zobacz więcej