Google PCA: Migracja, modernizacja i strategia chmury hybrydowej — Przewodnik do nauki

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Część Google Professional Cloud Architect — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Google, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Udana strategia migracji, modernizacji i chmury hybrydowej dopasowuje wybory platformy do wyników biznesowych, jednocześnie zarządzając ryzykiem dla dostępności, integralności danych, opóźnień, bezpieczeństwa i kosztów. Ścieżka ta równoważy szybki rehosting w celu zmniejszenia ryzyka związanego z centrum danych z ukierunkowanym refaktoringiem w celu wykorzystania korzyści płynących z chmury. Model operacyjny musi ewoluować wraz z technologią, aby utrzymać ulepszenia. Ta sekcja dostarcza pragmatyczny plan oceny i planowania fal migracji, ram decyzyjnych, mechaniki migracji, integracji hybrydowej, wzorców modernizacji, zagadnień dotyczących polityk i wielochmurowości oraz optymalizacji po migracji, z naciskiem na tryby awarii i kompromisy.

Ocena, gotowość i planowanie fal migracji

• Odkrywanie i analiza zależności

  • Przeprowadź inwentaryzację obciążeń, wersji, jąder systemu operacyjnego, pamięci masowej, IAM i klasyfikacji danych. Zmapuj zależności w przepływach web→API→DB, usługach współdzielonych (LDAP/AD, DNS, NTP), potokach wsadowych i zewnętrznych API.
  • Użyj profilowania aplikacji i śledzenia rozproszonego w środowiskach przedmigracyjnych, aby ujawnić ukryte zależności i opóźnienia typu “long-tail”. Włącz VPC Flow Logs i instrumentację na poziomie aplikacji (Cloud Logging, Cloud Monitoring, Cloud Trace).
  • Zidentyfikuj granice stanu i “grawitację danych” (data gravity): rozmiar, wzorce dostępu (mieszanka R/W), oczekiwania dotyczące spójności i topologię replikacji.

• Gotowość i umiejętności

  • Oceń umiejętności w zakresie podstaw chmury, IaC, CI/CD, SRE, bezpieczeństwa, sieci i baz danych. Zdefiniuj ścieżkę szkoleń i certyfikacji opartą na rolach oraz zaplanuj w budżecie czas na podnoszenie kwalifikacji i dyżury w trybie “shadow”.
  • Ustanów “landing zone” (projekty, foldery, Shared VPC, polityki organizacyjne, ujścia audytowe, strategia CMEK) przed pierwszą falą migracji.

• Planowanie fal migracji

  • Grupuj aplikacje w fale według powinowactwa i “promienia rażenia” (blast radius): współdzielone dane, zależności synchroniczne i okna zmian. Przenieś zależności wysokiego ryzyka do tej samej fali lub zastąp je zaślepkami (stub) z dobrze zdefiniowanymi kontraktami API.
  • Zdefiniuj dla każdej fali SLO, RTO/RPO, kryteria wycofania zmian (rollback) i bramki walidacyjne (sprawdzanie schematów, syntetyczne ścieżki użytkownika, progi wydajności).
  • Przygotuj “runbooki” i zarządzanie zmianą: kroki przełączenia (cutover), punkty kontrolne, wycofywanie zmian i zbieranie dowodów do zatwierdzenia.

• Kompatybilność, licencjonowanie i bazowe pomiary wydajności

  • Zweryfikuj wsparcie dla systemów operacyjnych i oprogramowania pośredniczącego (middleware) w Compute Engine i usługach zarządzanych. Sprawdź warunki licencji komercyjnych, ograniczenia BYOL, wymagania dotyczące modułów jądra i powinowactwa sprzętowe.
  • Zbierz bazowe wartości dla CPU, pamięci, IOPS, przepustowości i opóźnień, uwzględniając wartości szczytowe i 95. percentyla, aby zwymiarować zasoby docelowe i zweryfikować korzyści.

• Zarządzanie danymi (Data governance)

  • Klasyfikuj dane PII/PCI. Zaplanuj deidentyfikację lub tokenizację przy przyjmowaniu danych (ingest) za pomocą Cloud DLP. Zdefiniuj polityki audytu, retencji i eksportu, zanim zostanie zapisany pierwszy log produkcyjny.

Typowe tryby awarii: nieznane zależności synchroniczne powodujące kaskadowe przekroczenia limitu czasu po przełączeniu; nakładające się zakresy IP blokujące łączność; luki w zgodności licencyjnej; brak parytetu wycofywania zmian (rollback), gdy mutacje danych nie mogą być cofnięte.

Wzorce migracji, przenoszenie danych i przełączenie (cutover)

• Ramy decyzyjne (model 6R)

  • Rehost (przeniesienie): przeniesienie bez zmian (as-is) do Compute Engine. Najszybszy czas wdrożenia w chmurze, minimalne zmiany. Ryzyko: przeniesienie długu technicznego i nieefektywnego doboru zasobów.
  • Replatform (dostosowanie platformy): niewielkie zmiany w celu adaptacji usług zarządzanych (np. Cloud SQL, Cloud Load Balancing). Szybsze korzyści operacyjne przy niewielkich zmianach w kodzie.
  • Refactor (refaktoryzacja): dekompozycja lub konteneryzacja dla GKE/Cloud Run; adaptacja wzorców sterowanych zdarzeniami. Największe korzyści długoterminowe, ale z ryzykiem wdrożeniowym.
  • Retire (wycofanie): usunięcie nieużywanych systemów po udowodnieniu braku ich wykorzystania i zależności.
  • Retain (zachowanie): pozostawienie w środowisku on-premise z powodów regulacyjnych lub opóźnień; integracja poprzez rozwiązanie hybrydowe.
  • Relocate (relokacja): przeniesienie obciążeń vSphere do Google Cloud VMware Engine; zachowuje narzędzia i minimalizuje zmiany.

• Narzędzia do migracji zasobów obliczeniowych i baz danych

  • Migrate to Virtual Machines przyspiesza migrację typu rehost do Compute Engine, zachowując dyski i konfigurację sieciową. Należy zweryfikować wsparcie dla systemu operacyjnego gościa i sterowników jądra.
  • Database Migration Service zapewnia homogeniczną replikację online (np. MySQL, PostgreSQL) do Cloud SQL z niskim czasem przestoju. Należy upewnić się, że ustawienia binlog/replikacji są poprawne, a opóźnienie pozwala na nadrobienie zaległości niemal w czasie rzeczywistym.
  • Dobierz bazy danych do obciążenia:
    • Cloud SQL dla zarządzanych relacyjnych baz danych; włącz automatyczne zwiększanie przestrzeni dyskowej i monitoruj użycie procesora w okolicach 75% na rdzeń; śledź opóźnienie replikacji (replication lag) i w razie zbliżania się do progów wykonaj sharding lub skalowanie w górę.
    • Bigtable do przetwarzania szeregów czasowych o niskim opóźnieniu i wysokiej przepustowości (np. dane z czujników).
    • Spanner dla globalnej skali i silnej spójności; zrozum kompromis między uzależnieniem od dostawcy (lock-in) a przenośnością (portability).
  • Przenoszenie danych
    • Storage Transfer Service do transferów ciągłych lub zaplanowanych; zrównoleglony i odporny na błędy (z ponawianiem prób).
    • Transfer Appliance do jednorazowego, masowego przesyłania danych (dziesiątki do setek TB) w celu skrócenia czasu transferu sieciowego i zmniejszenia ryzyka.
    • gsutil i równoległe przesyłanie złożone (parallel composite uploads) dla małych i średnich zbiorów danych.

• Migracja online vs offline

  • Online: ciągła replikacja z krótkim przełączeniem (cutover). Zalety: minimalny czas przestoju; Wady: wymaga stabilnego opóźnienia i przepustowości; konieczność unikania podwójnego zapisu (dual-write).
  • Offline: migawka (snapshot) i import masowy. Zalety: prostota i przewidywalność; Wady: czas przestoju równy czasowi kopiowania.

• Planowanie przełączenia (cutover), wycofywanie zmian (rollback) i kontrola czasu przestoju

  • Obniż wartości DNS TTL na kilka dni przed przełączeniem, zamroź nieistotne zmiany i zaplanuj okno serwisowe.
  • Wykonaj bramki walidacyjne: zgodność schematów, sumy kontrolne lub liczby wierszy, testy typu smoke test aplikacji, ruch kanarkowy (canary traffic) i sondy wydajnościowe.
  • Wycofanie (rollback): zapewnij wstecznie kompatybilne zmiany schematu, flagi funkcji (feature flags) i zachowanie danych źródłowych (source-of-truth). Unikaj nieodwracalnych zapisów, dopóki stabilność nie zostanie potwierdzona.
  • Przykład rozszerzenia dysku VM z minimalnym czasem przestoju:
    • Zmień rozmiar dysku w konsoli lub CLI:

undefined

- W systemie Linux z ext4:

undefined

• Aktualizacje kroczące (rolling updates) aplikacji w GKE z minimalnym wpływem:

undefined

Typowe przyczyny awarii: utrata pakietów przez Cloud VPN zakłócająca replikację bazy danych (użyj Dedicated Interconnect lub Partner Interconnect), rozbieżność danych przy podwójnym zapisie (dual-write) podczas przełączania, brakujące kontrole stanu (health checks) zatrzymujące aktualizacje kroczące.

Tożsamość hybrydowa, łączność i integracja ze środowiskiem on-premises

• Tożsamość

  • Zachowaj Active Directory jako źródło prawdy (source of truth). Użyj Google Cloud Directory Sync do synchronizacji kont i grup oraz skonfiguruj SAML SSO, aby umożliwić użytkownikom dostęp do Google Cloud.
  • Nadawaj uprawnienia IAM zgodnie z zasadą najmniejszych uprawnień (least-privilege) za pomocą ról, używaj kont usług (service accounts) dla obciążeń i preferuj Workload Identity Federation zamiast kluczy o długim okresie ważności.

• Łączność hybrydowa i routing

  • Użyj Cloud VPN dla początkowych potrzeb o niskiej przepustowości i do testów; przejdź na Dedicated Interconnect dla stałej przepustowości, niższych opóźnień i przewidywalnej wydajności replikacji. Wdróż redundantne załączniki VLAN (VLAN attachments) i HA VPN lub podwójne połączenia interconnect dla zapewnienia odporności.
  • Upewnij się, że zakresy IP Google Cloud nie pokrywają się z zakresami CIDR on-premises, aby zachować kompleksową osiągalność (end-to-end reachability).

  • Wymuszaj dostęp warstwowy za pomocą reguł zapory sieciowej i tagów. Przykład zezwolenia na ruch tylko z warstwy web do API:

undefined

• Używaj Private Service Connect i prywatnego dostępu Google (private Google access) do komunikacji między usługami bez publicznego ruchu wychodzącego (egress); segmentuj za pomocą VPC Service Controls tam, gdzie to stosowne.

• Hybrydowy DNS: użyj Cloud DNS z przekierowywaniem (forwarding) oraz politykami przychodzącymi/wychodzącymi (inbound/outbound policies) do rozwiązywania nazw zarówno on-prem, jak i w chmurze.

• Integracja ze środowiskiem on-premises i opóźnienia

  • Utrzymuj stan blisko zasobów obliczeniowych lub odwrotnie; jeśli baza danych on-prem musi pozostać autorytatywna, rozważ App Engine flexible lub Compute Engine z Cloud VPN/Interconnect dla dostępu prywatnego.
  • Wprowadź pamięci podręczne (cache) i kolejki, aby oddzielić ścieżki synchroniczne i absorbować wahania opóźnień (latency jitter); mierz opóźnienia p95/p99, a nie tylko średnie.

Typowe przyczyny awarii: nakładające się zakresy CIDR blokujące trasy, niewystarczająca redundancja sesji BGP, wycieki przez publiczny DNS lub ruch wychodzący (egress) ujawniające prywatne usługi oraz nieprzewidziane, “gadatliwe” protokoły (chatty protocols) cierpiące na łączach o wysokim opóźnieniu.

Modernizacja, model operacyjny i optymalizacja

• Wzorce modernizacji starszych systemów

  • Wzorzec dusiciela (strangler fig): umieść fasadę API przed monolitem i stopniowo przekierowuj domeny do nowych usług.
  • Konteneryzacja: standaryzuj obrazy bazowe (preferuj odchudzone obrazy, takie jak Alpine, jeśli są kompatybilne), porządkuj warstwy w pliku Dockerfile, aby buforować instalację zależności przed kopiowaniem kodu źródłowego w celu skrócenia czasu budowy, i wdróż potok CI/CD z automatycznymi testami w środowisku stagingowym.
  • Zarządzane dane: przenieś operacyjne magazyny danych do zarządzanych baz danych; wybieraj per domena: Cloud SQL dla danych transakcyjnych, Bigtable dla szeregów czasowych, Spanner dla obciążeń wymagających globalnej spójności.

• Weryfikacja kompatybilności, spójności i wydajności aplikacji

  • Potwierdź wsparcie dla systemu operacyjnego i oprogramowania pośredniczącego (middleware), limity wątków i połączeń oraz semantykę systemu plików. Zweryfikuj przenośność licencji i sposób naliczania opłat za użytkowanie.
  • Zdefiniuj wymagania dotyczące spójności danych (read-your-write, odczyty monotoniczne, spójność ostateczna vs. silna). Dopasuj je do docelowych baz danych i wzorców dostępu.
  • Zweryfikuj wydajność za pomocą testów obciążeniowych i syntetycznych ścieżek użytkownika; upewnij się, że budżety SLO są osiągalne po migracji.

• Obserwowalność i zgodność z przepisami

  • Instrumentuj aplikacje za pomocą Cloud Logging, Monitoring i Trace, aby lokalizować opóźnienia między mikrousługami.
  • Eksportuj dzienniki audytu i zmiany w politykach IAM do BigQuery i udostępniaj je audytorom za pomocą widoków i uprawnień IAM na zbiorach danych. Eksportuj długoterminowe metryki do Cloud Storage, aby spełnić wieloletnie wymagania dotyczące retencji.

• Model operacyjny i odpowiedzialność

  • Wdróż praktyki SRE: SLO, budżety błędów, reagowanie na incydenty i analizy poincydentalne bez wskazywania winnych (blameless postmortems). Zdefiniuj odpowiedzialność za usługi, runbooki i rotacje dyżurów (on-call).
  • Używaj IaC (np. Terraform) do spójnego provisioningu infrastruktury. Pamiętaj, że Deployment Manager jest specyficzny dla Google, może ograniczać automatyzację zasobów w środowisku wielochmurowym i jest nieznany wielu inżynierom.
  • Automatyzuj spójność polityk za pomocą Organization Policy, IAM Conditions, Config Sync i Policy Controller (OPA Gatekeeper) w różnych projektach i środowiskach.

• Strategia wielochmurowa i kompromisy związane z uzależnieniem od dostawcy (lock-in)

  • Zwiększ przenośność dzięki Kubernetes, praktykom 12-factor app, kontraktom zdefiniowanym przez OpenAPI i abstrakcjom dla egressu danych. Zrównoważ przenośność z obciążeniem operacyjnym i wydajnością; usługi zarządzane zmniejszają żmudną pracę ręczną (toil), ale mogą zwiększyć koszt zmiany dostawcy.

• Optymalizacja kosztów i wydajności; wycofywanie systemów

  • Skaluj bezstanowe instancje Compute Engine za pomocą zarządzanych grup instancji i autoskalowania; wybieraj rozwiązania bezserwerowe (Cloud Functions lub Cloud Run) dla obciążeń o gwałtownych wzrostach lub MVP, które korzystają ze skalowania do zera.
  • Dopasowuj rozmiar maszyn wirtualnych, włącz autoskalowanie w GKE, stosuj rabaty za zobowiązanie użycia (committed use discounts) i wycofuj nieużywane artefakty. Śledź realizację korzyści za pomocą wskaźników KPI (dostępność, opóźnienia, koszt obsługi).
  • Wycofaj systemy lokalne po okresie przejściowym (cooling period) i potwierdzeniu zależności. Archiwizuj lub usuwaj dane zgodnie z polityką retencji i zaktualizuj CMDB.

Praktyczny scenariusz problemowy

Firma Acme Weather Networks musi zmigrować swoją platformę czujników czasu rzeczywistego oraz starszy interfejs administracyjny J2EE z lokalnego centrum danych do Google Cloud. System przetwarza dane z 50 000 czujników, z których każdy wysyła 10 odczytów na sekundę, i przechowuje pięć lat danych historycznych (75 TB). Musi zachować prywatny dostęp do lokalnego systemu ERP i Active Directory podczas przejścia, zminimalizować przestoje lokalnej bazy danych MySQL i wyeliminować sporadyczne błędy replikacji obserwowane przez VPN.

1. Ustanów bezpieczną strefę startową (landing zone)

   • Utwórz organizację, foldery oraz projekty produkcyjne i nieprodukcyjne. Skonfiguruj Shared VPC z niepokrywającymi się zakresami IP, aby zapewnić osiągalność zasobów lokalnych przez łączność hybrydową. Zastosuj polityki organizacji i scentralizowany eksport dzienników audytu do BigQuery z dostępem o najniższych uprawnieniach.
   • Uzasadnienie: Zapobieganie konfliktom routingu i egzekwowanie podstawowego ładu korporacyjnego przed wdrożeniem obciążeń.

2. Zaimplementuj tożsamość hybrydową

   • Skonfiguruj Google Cloud Directory Sync do synchronizacji tożsamości i grup z AD oraz ustaw SAML SSO. Użyj kont usług i niestandardowych ról IAM dla platformy i obciążeń.
   • Uzasadnienie: Utrzymanie tożsamości korporacyjnej jako źródła prawdy i umożliwienie kontroli dostępu opartej na zasadzie najniższych uprawnień.

3. Zapewnij łączność i zaplanuj wydajność

   • Zacznij od HA Cloud VPN dla środowisk deweloperskich i testowych. Dla produkcyjnej replikacji bazy danych i stałego napływu danych z czujników, provisionuj Dedicated Interconnect z podwójnymi załącznikami VLAN i sesjami BGP.
   • Uzasadnienie: Interconnect zapewnia niższe opóźnienia i mniej utraconych pakietów niż VPN, stabilizując replikację MySQL i strumieniowe przesyłanie danych.

4. Efektywnie przenieś dane historyczne

   • Zamów Transfer Appliances, załaduj lokalnie zbiór danych o wielkości 75 TB, wyślij i odtwórz w Cloud Storage. Użyj Storage Transfer Service do bieżących aktualizacji przyrostowych, jeśli to konieczne. Uruchom Cloud DLP na logach wsparcia, aby zanonimizować dane osobowe (PII) przed zapisaniem ich w Bigtable lub BigQuery.
   • Uzasadnienie: Masowy transfer offline zmniejsza ryzyko związane z oknem wdrożeniowym (cutover) i pozwala uniknąć nasycenia łączy.

5. Przeprowadź rehosting interfejsu administracyjnego J2EE

   • Użyj Migrate to Virtual Machines, aby przenieść maszynę wirtualną z J2EE do Compute Engine metodą lift-and-shift. Umieść instancje w zarządzanej grupie instancji za load balancerem HTTP(S). Zastosuj reguły zapory sieciowej oparte na tagach, aby wymusić przepływ ruchu tylko w schemacie web→API→DB. Przykład:

undefined

• Uzasadnienie: Szybka redukcja ryzyka dzięki znanemu środowisku uruchomieniowemu przy jednoczesnym egzekwowaniu ścieżek sieciowych o najniższych uprawnieniach.

6. Zmigruj MySQL do Cloud SQL z minimalnym przestojem

   • Zmierz bazową wydajność i włącz logowanie binarne na źródle. Użyj Database Migration Service do skonfigurowania ciągłej replikacji do Cloud SQL. Włącz automatyczne zwiększanie przestrzeni dyskowej i utwórz alerty dla użycia procesora bliskiego 75% i opóźnienia replikacji poniżej 60 sekund.
   • Uzasadnienie: Migracja online zapewnia niski czas przestoju; zarządzana usługa SQL zmniejsza żmudną pracę ręczną i wymusza operacyjne SLO.

7. Przeprowadź kontrolowane przełączenie (cutover)

   • Obniż TTL w DNS na 48 godzin przed, zablokuj zmiany w schemacie i zaplanuj okno konserwacyjne. Zatrzymaj zapisy w systemie lokalnym, upewnij się, że opóźnienie DMS wynosi zero, uruchom sumy kontrolne i testy dymne aplikacji, a następnie skieruj klientów na Cloud SQL. Przygotuj plan awaryjny (rollback), w którym zapisy mogą być przekierowane z powrotem do systemu lokalnego, jeśli walidacja się nie powiedzie.
   • Uzasadnienie: Deterministyczne kroki ograniczają RTO i utrzymują spójność danych.

8. Zbuduj pozyskiwanie danych telemetrycznych w czasie rzeczywistym

   • Pozyskuj dane przez Pub/Sub, przetwarzaj je za pomocą Dataflow i przechowuj szeregi czasowe w Bigtable, aby zapewnić niskie opóźnienia zapisu i odczytu. Utrzymaj integrację z ERP jako prywatną przez Interconnect.
   • Uzasadnienie: Bigtable pasuje do profilu szeregów czasowych o wysokiej przepustowości, a Pub/Sub oddziela producentów o zmiennym obciążeniu od konsumentów.

9. Skonteneryzuj usługi i wprowadź CI/CD

   • Skonteneryzuj bezstanowe usługi dla GKE. Zoptymalizuj pliki Dockerfile, używając odchudzonych obrazów bazowych i porządkując warstwy tak, aby instalacja zależności poprzedzała kopiowanie kodu źródłowego. Zaimplementuj potok CI/CD z automatycznymi testami w środowisku stagingowym i wdrożeniami kanarkowymi (canary). Aktualizuj z minimalnym przestojem:

undefined

• Uzasadnienie: Poprawia szybkość, niezawodność i skalowalność wdrożeń bez konieczności przepisywania całości od zera (big-bang rewrite).

10. Popraw obserwowalność i audyt

    • Instrumentuj Cloud Logging, Monitoring i Trace, aby precyzyjnie lokalizować opóźnienia między mikrousługami. Eksportuj dzienniki audytu do BigQuery i udostępniaj widoki o ograniczonym zakresie dla audytorów. Eksportuj długoterminowe metryki do Cloud Storage, aby spełnić pięcioletnie wymagania retencji.
    • Uzasadnienie: Pełna telemetria wspiera realizację SLO i zgodność z przepisami.

11. Optymalizuj i wycofaj

    • Włącz autoskalowanie w MIG i GKE, dopasuj rozmiar instancji, zastosuj rabaty za zobowiązanie użycia i zaplanuj obciążenia niedziałające w trybie 24x7 na platformach bezserwerowych (np. Cloud Functions do zadań pomocniczych), aby skalowały się do zera. Po okresie stabilizacji i okresie przejściowym (cooling period), wycofaj systemy lokalne, zaktualizuj CMDB i opublikuj zrealizowane korzyści.
    • Uzasadnienie: Uzyskanie oszczędności kosztowych i operacyjnych przy jednoczesnej eliminacji kosztów utrzymywania dwóch systemów.

12. Operacjonalizuj i szkol

    • Sfinalizuj runbooki, macierz RACI, rotacje dyżurów oraz budżety SLO/błędów. Zapewnij ukierunkowane szkolenia i plany certyfikacji, aby uzupełnić luki w umiejętnościach. Preferuj Terraform dla IaC; pamiętaj, że Deployment Manager jest specyficzny dla Google i może nie obsługiwać zasobów spoza Google.
    • Uzasadnienie: Dojrzały model operacyjny podtrzymuje niezawodność i szybkość działania po zakończeniu migracji.

← Niezawodność · Wszystkie domeny · Operacje →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Google →