Aplikacje w Google Cloud
Budujemy i wdrażamy aplikacje w Google Cloud. Kontenery uruchamiamy w Cloud Run, który sam skaluje aplikację i nie pobiera opłat, gdy nikt z niej nie korzysta. Dane mogą pozostać w Polsce, bo Google Cloud ma region w Warszawie.
Kiedy aplikacja dobrze sprawdzi się w Google Cloud
-
Aplikacja działa w kontenerze, a ruch jest nierówny
Cloud Run uruchamia kontener przy pierwszym żądaniu i zatrzymuje go, gdy ruch ustaje. Przy aplikacji używanej kilka godzin dziennie płacisz tylko za ten czas.
-
Firma analizuje duże ilości danych
Dane z aplikacji trafiają do BigQuery, gdzie zapytania na milionach rekordów trwają sekundy. Raporty nie spowalniają bazy, z której korzystają użytkownicy.
-
Dane mają pozostać w Warszawie
Region europe-central2 działa w Warszawie. Aplikację, bazę i pliki uruchamiamy w nim w całości.
-
Aplikacja ma korzystać z modeli Gemini
Vertex AI udostępnia modele Gemini i inne modele w tym samym projekcie Google Cloud co aplikacja, z danymi przetwarzanymi w wybranym regionie.
Kiedy wybrać Google Cloud, a kiedy coś innego
Google Cloud polecamy, gdy aplikacja działa w kontenerze i ma nierówny ruch, gdy firma chce analizować duże ilości danych z aplikacji albo gdy ma już projekt w Google Cloud. Cloud Run to jeden z najprostszych sposobów uruchomienia kontenera w chmurze, a BigQuery należy do najwygodniejszych narzędzi do analiz.
Gdy aplikacja powstaje w .NET, a firma ma subskrypcję Microsoft, zwykle wygodniej wybrać Microsoft Azure. Gdy aplikacja opiera się na wielu zdarzeniach i procesach wieloetapowych, szerszy wybór usług daje AWS. Rekomendację podajemy z szacunkiem kosztów dla przewidywanego ruchu.
Przykładowa architektura aplikacji w Google Cloud
- Interfejs w Next.js i backend działają jako osobne usługi w Cloud Run, za wspólnym adresem HTTPS.
- Dane aplikacji zapisujemy w Cloud SQL for PostgreSQL w regionie europe-central2.
- Pliki użytkowników trafiają do Cloud Storage, a nowy plik uruchamia funkcję, która go przetwarza.
- Zdarzenia między częściami aplikacji przekazuje Pub/Sub, więc chwilowa awaria jednej usługi nie gubi danych.
- Dane do raportów trafiają do BigQuery, gdzie analizy nie obciążają bazy aplikacji.
- Cloud Monitoring zbiera logi i wysyła alarm przy błędach, a budżet w Cloud Billing informuje o zbliżaniu się do ustalonej kwoty.
Przykład: aplikacja w Cloud Run z raportami w BigQuery
Tak może wyglądać aplikacja dla firmy, która potrzebuje systemu dla pracowników i klientów oraz raportów dla zarządu. Opisujemy scenariusz, a nie konkretne wdrożenie.
- Interfejs i backend działają jako dwie usługi w Cloud Run, w regionie europe-central2 w Warszawie. Poza godzinami pracy, gdy nikt nie korzysta z aplikacji, usługi nie generują kosztów obliczeniowych.
- Dane zamówień i klientów zapisujemy w Cloud SQL for PostgreSQL w tym samym regionie.
- Raz na dobę, albo na bieżąco przez Pub/Sub, dane potrzebne do analiz trafiają do BigQuery.
- Zarząd ogląda zestawienia sprzedaży i czasu realizacji zamówień w panelu aplikacji, a zapytania analityczne nie spowalniają pracy użytkowników.
- Nowa wersja aplikacji przejmuje ruch stopniowo, a przy błędzie wracamy do poprzedniej jednym poleceniem.
Taki układ wybieramy, gdy aplikacja ma nierówny ruch, a firma chce analizować dane bez budowy osobnej hurtowni.
Cloud Run dobrze sprawdza się w produktach, które startują z małym ruchem i rosną z liczbą klientów, dlatego często proponujemy go przy platformach SaaS i MVP. Automatyzację wdrożeń opisujemy na stronie DevOps dla aplikacji.
Co robimy
- Projektujemy architekturę aplikacji w Google Cloud i szacujemy koszt w kalkulatorze cen Google Cloud
- Uruchamiamy aplikacje Next.js, .NET i Node.js w kontenerach w Cloud Run
- Budujemy funkcje uruchamiane zdarzeniami w Cloud Run functions
- Dobieramy bazę danych, Cloud SQL for PostgreSQL albo Firestore
- Przekazujemy zdarzenia między częściami aplikacji przez Pub/Sub
- Przechowujemy pliki w Cloud Storage, a hasła i klucze w Secret Manager
- Przygotowujemy analizy i raporty na danych aplikacji w BigQuery
- Opisujemy infrastrukturę w Terraform i automatyzujemy wdrożenia
Dla kogo
- Planujesz aplikację w kontenerze, której ruch zmienia się w ciągu dnia
- Twoja firma ma projekt w Google Cloud i szuka zespołu, który zbuduje na nim aplikację
- Chcesz analizować dane z aplikacji bez obciążania jej bazy
- Dane aplikacji muszą być przechowywane w Polsce
Cloud Run: kontenery bez serwerów
W Cloud Run uruchamiamy ten sam obraz Docker, który powstaje w naszym pipeline. Usługa przyjmuje ruch przez HTTPS, dodaje kopie kontenera przy większej liczbie żądań i zatrzymuje je, gdy ruch ustaje. Nowa wersja może przejąć najpierw część ruchu, a dopiero po sprawdzeniu całość. To jeden z najprostszych sposobów uruchomienia aplikacji w chmurze bez zarządzania serwerami i klastrem.
- Brak opłat, gdy aplikacja nie obsługuje żądań
- Stopniowe przełączanie ruchu na nową wersję
- Ten sam obraz Docker co w innych chmurach
Cloud SQL i Firestore
Gdy aplikacja potrzebuje relacji i transakcji, wybieramy Cloud SQL for PostgreSQL, tę samą bazę, na której działają nasze realizacje. Gdy dane są proste, a aplikacja ma działać w czasie rzeczywistym, na przykład pokazywać zmiany statusu wszystkim użytkownikom naraz, wybieramy Firestore. Obie bazy są zarządzane przez Google, z automatycznymi kopiami i aktualizacjami.
- PostgreSQL jako usługa zarządzana
- Firestore dla danych w czasie rzeczywistym
- Automatyczne kopie bazy
BigQuery dla raportów i analiz
Raporty liczone bezpośrednio w bazie aplikacji spowalniają ją dla użytkowników. Dlatego dane, które mają służyć analizom, przekazujemy do BigQuery. Tam zarząd może zestawiać sprzedaż, zamówienia czy czas obsługi na milionach rekordów, a wyniki pokazujemy w panelu aplikacji albo w narzędziu raportowym.
- Analizy bez obciążania bazy aplikacji
- Zapytania SQL na dużych zbiorach danych
- Opłata za przetworzone dane
Jak pracujemy
-
Przegląd projektu
Sprawdzamy, co działa w Twoim projekcie Google Cloud, jakie są uprawnienia i w którym regionie mają być dane.
-
Architektura i koszt
Rozpisujemy usługi Google Cloud dla aplikacji i podajemy szacunkowy miesięczny koszt dla przewidywanego ruchu.
-
Budowa i środowisko testowe
Infrastrukturę tworzymy z plików Terraform, a każdą zmianę w kodzie wdrażamy automatycznie do Cloud Run.
-
Wdrożenie produkcyjne
Nowa wersja w Cloud Run przejmuje najpierw część ruchu, a po sprawdzeniu logów całość. Wtedy przełączamy domenę.
Doświadczenie
- Nasze realizacje działają w kontenerach Docker z bazą PostgreSQL, więc można je uruchomić w Cloud Run z Cloud SQL bez zmian w architekturze.
Realizacje
-
INVENTA Licenses
System do zarządzania użytkownikami i licencjami aplikacji VR do szkolenia pracowników, z panelami klienta, dystrybutora i administratora.
Najczęstsze pytania
Czym Cloud Run różni się od Kubernetes?
Cloud Run uruchamia pojedyncze kontenery i sam zarządza ich skalowaniem, więc nie trzeba konfigurować klastra. Google Kubernetes Engine daje pełną kontrolę nad wieloma usługami, ale wymaga więcej pracy. Dla większości aplikacji firmowych wystarcza Cloud Run.
Czy dane w Google Cloud mogą pozostać w Polsce?
Tak. Region europe-central2 działa w Warszawie. Uruchamiamy w nim aplikację, bazę i pliki, a przed startem sprawdzamy, czy każda potrzebna usługa jest w nim dostępna.
Czy Firestore zastąpi bazę SQL?
Tylko w części aplikacji. Firestore dobrze sprawdza się przy prostych danych i aktualizacjach w czasie rzeczywistym, ale nie obsługuje złożonych zapytań i raportów tak jak PostgreSQL. Często łączymy obie bazy w jednej aplikacji.
Zobacz także
-
Platformy SaaS i MVP dla startupów
Budujemy pierwszą wersję produktu (MVP) i platformy SaaS z kontami użytkowników, subskrypcjami, płatnościami, licencjami i API.
-
Systemy rezerwacji i rejestracji online
Klienci rezerwują terminy przez internet, pracownicy zarządzają harmonogramem, a system wysyła potwierdzenia e-mail i SMS.