Google PCD: Wydajność, skalowalność i inżynieria odporności — Przewodnik do nauki

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

Przegląd

Inżynieria wydajności, skalowalności i odporności na Google Cloud koncentruje się na utrzymaniu usług o niskim opóźnieniu i efektywnych kosztowo przy zmiennym obciążeniu, jednocześnie tolerując awarie bez naruszania wskaźników SLO. Projekt musi dopasować sygnały autoskalowania do charakterystyki obciążenia, rozmieszczać dane i zasoby obliczeniowe w celu minimalizacji opóźnień typu tail latency (długiego ogona) oraz implementować mechanizmy kontroli przeciążenia, ponowienia prób i przełączania awaryjnego (failover), aby unikać awarii kaskadowych. Ta sekcja szczegółowo opisuje wzorce, mechanizmy kontrolne i kompromisy, które mają znaczenie dla deweloperów aplikacji w warstwach obliczeniowej, sieciowej i danych.

Skalowanie i dystrybucja obciążenia

Skalowanie horyzontalne a wertykalne

Skalowanie horyzontalne dodaje instancje lub pody w celu zwiększenia pojemności i odporności. Preferowane dla usług bezstanowych i gdy potrzebna jest szybka elastyczność. Używaj Managed Instance Groups (MIGs), rewizji Cloud Run lub wdrożeń GKE (Deployments).
Skalowanie wertykalne zwiększa rozmiar maszyny. Przydatne dla obciążeń jednowątkowych lub ograniczonych pamięcią, lub w celu zmniejszenia koordynacji międzywęzłowej, ale oferuje ograniczony zapas mocy i dłuższy czas restartu.
Współbieżność: Dostosuj współbieżność żądań do profili obciążenia – ograniczonych przez CPU (CPU-bound) vs. ograniczonych przez I/O (I/O-bound). Cloud Run wspiera współbieżność na poziomie rewizji; pody GKE mogą obsługiwać wiele żądań, jeśli środowisko uruchomieniowe jest nieblokujące; dla ścisłej izolacji ustaw współbieżność na 1.

Sygnały autoskalowania i ciepła pojemność (warm capacity)

Autoskalowanie MIG wspiera wykorzystanie CPU, wykorzystanie load balancera oraz niestandardowe metryki za pośrednictwem Cloud Monitoring. W przypadku nagłych skoków ruchu, opieraj skalowanie na metrykach żądań (rps, głębokość kolejki) zamiast na CPU.
GKE Horizontal Pod Autoscaler (HPA) może skalować na podstawie CPU, pamięci lub metryk niestandardowych/zewnętrznych (np. długość kolejki Pub/Sub). Używaj Vertical Pod Autoscaler (VPA) do optymalizacji rozmiaru (right-sizing), ale unikaj aktualizacji VPA na żywo na szybko skalujących się frontendach, aby zapobiec częstym zmianom (churn).
Cloud Run skaluje się na podstawie współbieżnego obciążenia żądaniami i opcjonalnie metryk niestandardowych. Unikaj zimnych startów (cold starts), utrzymując ciepłą pojemność (warm capacity): skonfiguruj minimalną liczbę instancji, utrzymuj niską współbieżność w stanie bezczynności i w razie potrzeby wykonuj wstępne rozgrzewanie za pomocą syntetycznych pingów sprawdzających kondycję.
Autoskalowanie predykcyjne w MIGs i ustawienie min replicas w Deployment/Revision pomaga zamaskować opóźnienia w provisioningu podczas dobowych szczytów obciążenia.

Równoważenie obciążenia, globalna dystrybucja ruchu, kontrole kondycji i przełączanie awaryjne (failover)

Używaj globalnego zewnętrznego Application Load Balancer dla ogólnoświatowego anycast VIP, HTTP/2 i HTTP/3 oraz terminacji na brzegu sieci z Cloud CDN. Backendami mogą być grupy instancji, zonalne/regionalne NEG, serwerowe NEG (Cloud Run/Functions) lub GKE Ingress.
Kontrole kondycji odsuwają ruch od niesprawnych backendów. Upewnij się, że Twoje punkty końcowe kontroli kondycji weryfikują zależności w wąskim zakresie (np. proces i krytyczne zasoby lokalne), aby uniknąć awarii cyklicznych podczas niedostępności usług zależnych.
Listy dozwolonych adresów w zaporze sieciowej (firewall) muszą zezwalać na ruch od mechanizmów kontroli kondycji. Jeśli kontrole na porcie 80 kończą się niepowodzeniem, zezwól na zakresy Google:

undefined

Failover: Skonfiguruj główne/zapasowe usługi backendowe lub polityki ruchu, które kierują ruch do alternatywnych regionów w przypadku awarii kondycji. W celu przełączania awaryjnego na poziomie DNS, użyj polityk Cloud DNS z kontrolami kondycji dla punktów końcowych innych niż HTTP.

Opóźnienia i efektywność

Budżety opóźnień

Alokuj budżet opóźnień end-to-end dla każdej warstwy (klient, brzeg sieci, aplikacja, dane). Monitoruj p95/p99, a nie wartości średnie. Użyj Cloud Trace, aby znaleźć źródła opóźnień między usługami i blokowanie na początku kolejki (head-of-line blocking). Stosuj terminy końcowe (deadlines) do wywołań RPC, aby anulowanie operacji przez usługę nadrzędną zwalniało zasoby.

Użycie pamięci podręcznej (caching) i CDN

Warstwy pamięci podręcznej: pamięć podręczna klienta/przeglądarki, brzegowa pamięć podręczna CDN (Cloud CDN) oraz regionalne/pamięciowe pamięci podręczne (Memorystore lub wewnątrzprocesowe). Starannie dobieraj klucze pamięci podręcznej i nagłówki Vary. Ustawiaj TTL w oparciu o świeżość danych i ryzyko ich nieaktualności; rozważ negatywne buforowanie (negative caching) dla odpowiedzi 404, gdy jest to bezpieczne.
Serwuj zasoby statyczne z Cloud Storage za pośrednictwem Cloud CDN, aby zmniejszyć obciążenie serwera źródłowego i opóźnienia typu tail latency. Używaj podpisanych adresów URL/nagłówków w celu kontrolowanego dostępu.

Ponowne wykorzystanie połączeń

Preferuj HTTP/2 lub gRPC dla multipleksacji i kompresji nagłówków. Włącz keep-alives i pulę połączeń (connection pooling), aby zmniejszyć narzut związany z uzgadnianiem połączenia (handshake). Uważaj na wyczerpanie portów NAT; dostosuj pule połączeń klienta i czasy bezczynności oraz, w stosownych przypadkach, określ liczbę portów Cloud NAT na maszynę wirtualną.

Efektywność ładunku (payload)

Używaj kodowań binarnych (np. protobuf) i kompresuj ładunki tekstowe (gzip/brotli) powyżej określonego progu rozmiaru. Starannie projektuj pola żądań/odpowiedzi; stosuj paginację, filtruj po stronie serwera i unikaj pobierania nadmiarowych danych (over-fetching). Używaj ETagów i żądań warunkowych (If-None-Match), aby uniknąć zbędnych transferów. W przypadku Cloud Storage, używaj warunków wstępnych opartych na generacji (generation preconditions) oraz odczytów zakresu (Range reads) dla częściowej zawartości.

Wzorce odporności na przeciążenie

Ograniczanie szybkości (rate limiting), przeciwciśnienie (backpressure), kolejkowanie i przetwarzanie wsadowe

Wymuszaj limity szybkości na brzegu sieci (Cloud Armor do ograniczania szybkości na podstawie IP/geolokalizacji/usługi) i na warstwie API (kwoty Apigee, tokeny per klient API). Implementuj po stronie serwera algorytmy token-bucket lub leaky-bucket w celu sprawiedliwego podziału zasobów.
Przeciwciśnienie (backpressure): Nie wyprzedzaj systemów podrzędnych (downstream). Używaj kolejek (Pub/Sub do obsługi zdarzeń z gwarancją co najmniej jednokrotnego dostarczenia; Cloud Tasks do ograniczania przepustowości per kolejka i per cel z harmonogramowaniem i ponowieniami). Propaguj błędy 429 Too Many Requests lub 503 z nagłówkiem Retry-After, aby odpychać klientów.
Przetwarzanie wsadowe (batching) może zwiększyć przepustowość i zmniejszyć narzut na pojedyncze wywołanie (np. wsadowe modyfikacje w bazach danych lub wsadowe potwierdzenia Pub/Sub), wymieniając zwiększoną latencję na wydajność. Dostosuj rozmiar wsadu i maksymalny czas oczekiwania.

Ochrona przed przeciążeniem

Stosuj timeouty i deadline’y do każdego wywołania RPC. Używaj wyłączników awaryjnych (circuit breakers), aby przestać wysyłać zadania do niedziałających zależności i umożliwić szybkie przełączenie na mechanizmy zapasowe (fallback). Implementuj zrzucanie obciążenia (load shedding) w oparciu o głębokość kolejki, użycie CPU lub naruszenie SLO latencji, aby chronić kluczowe funkcjonalności.

Odporne ponowienia, wykładniczy backoff, jitter, idempotentność i obsługa duplikatów

Ponawiaj próby tylko wtedy, gdy jest to bezpieczne: timeouty sieciowe, błędy 5xx lub udokumentowane kody błędów pozwalające na ponowienie (np. Cloud Storage 429/5xx). Nigdy nie ponawiaj prób przy błędach 4xx, takich jak 400/401/403, chyba że jest to wyraźnie określone.
Używaj skróconego wykładniczego backoffu (truncated exponential backoff) z jitterem, aby uniknąć zsynchronizowanych ponowień. Preferuj pełny jitter (full jitter). Przykład:

undefined

Zapewnij idempotentność. Używaj kluczy idempotentności (np. unikalnego ID operacji) oraz operacji upsert/zapisu warunkowego, aby tolerować duplikaty. W przypadku Pub/Sub, usuwaj duplikaty używając messageId lub kluczy aplikacyjnych; projektuj handlery tak, aby były bezpieczne dla dostarczania typu co najmniej raz (at-least-once). W przypadku zapisów do Cloud Storage, używaj warunków wstępnych generation-match, aby uniknąć nadpisywania danych.

Rozgrzewanie (ramp-up) nieaktywnych zasobów

Niektóre usługi wymuszają limity adaptacyjne. W przypadku Cloud Storage, stopniowo zwiększaj liczbę żądań do wcześniej nieaktywnych bucketów, aby zredukować przejściowe błędy 429/5xx podczas nagłych skoków ruchu. Ograniczaj producentów (throttle) i rozgrzewaj buckety kontrolowanym ruchem przed pełnym obciążeniem.

Wysoka dostępność, dane, odtwarzanie po awarii (DR) i testowanie

Wiele stref, regiony, wiele regionów; active-active vs active-passive

Wdrażaj w różnych domenach awarii. Używaj regionalnych grup MIG lub regionalnych klastrów GKE dla odporności na awarie stref. W przypadku usług globalnych używaj wielu regionów z globalnym load balancerem.
Architektura active-active redukuje RTO i opóźnienia, ale wymaga danych bezkonfliktowych i starannego zarządzania spójnością. Architektura active-passive upraszcza semantykę zapisu, ale wiąże się z wyższym RTO i potencjalnie zimną pojemnością.

RTO, RPO, kopie zapasowe, odtwarzanie i testowanie odtwarzania po awarii

Zdefiniuj RTO (czas na odzyskanie usługi) i RPO (dopuszczalna utrata danych) dla każdego obciążenia. Dopasuj je do możliwości platformy:
- Cloud Spanner: wiele regionów z dostępnością na poziomie pięciu dziewiątek i synchroniczna replikacja dla RPO bliskiego zeru.
- Cloud SQL: Wysoka Dostępność w obrębie regionu; używaj replik międzyregionalnych do celów DR, włącz PITR (point-in-time recovery) i weryfikuj procedury (runbooks) przełączania awaryjnego (failover) i powrotu po awarii (failback).
- Firestore i Bigtable oferują opcje regionalne i wieloregionalne; wybierz je tak, aby spełnić wymagania RTO/RPO.
- Zasobniki (buckets) Cloud Storage typu dual- lub multi-region zapewniają geograficzną redundancję; weryfikuj procedury odtwarzania i ponowne wystawianie podpisanych adresów URL.
Testuj DR: Regularnie przeprowadzaj ćwiczenia przełączania awaryjnego. Weryfikuj kopie zapasowe, odtwarzając je w izolowanym środowisku, ćwicz przełączanie ruchu/DNS i mierz rzeczywiste wartości RTO/RPO.

Wydajność baz danych i pamięci masowej, projektowanie indeksów, gorące klucze (hot keys) i rywalizacja o zasoby (contention)

Cloud Spanner: Unikaj monotonicznie rosnących kluczy głównych, które powodują hotspotting. Używaj tabel przeplatanych (interleaved tables) dla zachowania lokalności danych, indeksów dodatkowych dla wzorców odczytu oraz transakcji o ograniczonym zakresie (bounded transactions), aby zredukować konflikty blokad. Dobierz rozmiar węzłów do liczby zapytań na sekundę (QPS) i pojemności pamięci masowej; utrzymuj co najmniej trzy węzły dla kworum produkcyjnego i zapasu mocy (headroom).
Cloud SQL: Analizuj zapytania, dodawaj indeksy pokrywające (covering indexes), unikaj długich transakcji i używaj pul połączeń. Rozsądnie dostrajaj ustawienia InnoDB lub Postgres; skaluj repliki do odczytu dla obciążeń z dużą liczbą operacji odczytu.
Bigtable: Projektuj klucze wierszy tak, aby równomiernie rozkładać obciążenie (przez salting lub odwracanie pól). Używaj routingu wieloklastrowego (multi-cluster routing) dla wysokiej dostępności między regionami, jeśli jest dostępny.
Firestore: Używaj indeksów złożonych (composite indexes) dla zapytań wielopolowych; bądź świadomy hotspottingu, gdy wiele zapisów jest kierowanych do tej samej ścieżki dokumentu.
Cloud Storage: Silna spójność odczytu po zapisie (read-after-write) dla nowych obiektów; używaj równoległego przesyłania i dzielenia na części (chunking) dla zwiększenia przepustowości. Stopniowo zwiększaj ruch na nieaktywnych zasobnikach; preferuj brzeg sieci CDN dla częstych odczytów (hot reads). Dla wielu maszyn wirtualnych potrzebujących tego samego dużego zestawu danych tylko do odczytu, podłącz dysk trwały w trybie tylko do odczytu do wielu instancji, aby uzyskać szybki dostęp lokalny przy niskich kosztach.

Testy obciążeniowe, eksperymenty chaosu, wstrzykiwanie błędów i planowanie pojemności

Testy obciążeniowe: Symuluj realistyczne kształty ruchu i rozkłady danych. Rozgrzej pamięci podręczne i autoskalery; testuj opóźnienia p95/p99 pod obciążeniem i podczas zdarzeń skalowania. Odbijaj niewielką część ruchu na żywo do stosów cieni (shadow stacks), aby zweryfikować zachowanie przy złożoności produkcyjnej.
Chaos i wstrzykiwanie błędów: Zabijaj pody/maszyny wirtualne, odgradzaj strefę (cordon a zone), wstrzykuj opóźnienia/błędy na poziomie siatki usług (service mesh), np. Envoy/Istio, aby obserwować promień rażenia (blast radius) i odporność. Sprawdź, czy wyłączniki awaryjne (circuit breakers) i ponowienia prób (retries) działają zgodnie z zamierzeniami.
Planowanie pojemności: Prognozuj na podstawie historycznego zapotrzebowania i planowanych wydarzeń. Utrzymuj zapas mocy (headroom) na awarie N+1 i rebalansowanie. Dostosuj czasy uspokojenia (cooldowns) i maksymalne tempo autoskalera do oczekiwanych skoków ruchu; prealokuj zasoby podczas przewidywalnych szczytów.

Kompromisy w zakresie dostępności między usługami zarządzanymi a architekturami niestandardowymi

Zasoby obliczeniowe: Cloud Run oferuje szybkie skalowanie do zera i niski narzut operacyjny, ale ma zimne starty i ograniczenia współbieżności żądań. GKE zapewnia szczegółową kontrolę i przenośność przy wyższym koszcie operacyjnym. Maszyny wirtualne Compute Engine zapewniają maksymalną kontrolę przy największym obciążeniu operacyjnym.
Dane: Cloud Spanner zapewnia globalną spójność i wysoką dostępność przy wyższym koszcie i rygorze schematu. Cloud SQL pasuje do tradycyjnych RDBMS z prostszymi operacjami, ale ograniczoną wysoką dostępnością/skalowalnością. Bigtable doskonale sprawdza się w zastosowaniach klucz-wartość/szeregi czasowe na masową skalę z niskimi opóźnieniami. Firestore zapewnia elastyczne schematy z silną spójnością i opcjami globalnymi.
Sieć: Globalne load balancery i Cloud CDN są wysoce dostępne i działają na brzegu sieci Google; proxy typu DIY oferują możliwość dostosowania, ale tworzą ryzyko operacyjne i awarii.
Preferuj usługi zarządzane dla wyższej bazowej dostępności i odporności na ataki DDoS, ale uwzględnij w swoim projekcie limity (quotas), zimne starty i semantykę specyficzną dla usługi.

Praktyczny scenariusz problemowy

NimbusMart, globalna firma e-commerce, potrzebuje API katalogu produktów o niskim opóźnieniu, dostępności na poziomie pięciu dziewiątek i zminimalizowanym opóźnieniu odczytu dla użytkowników w Ameryce Północnej, Europie i regionie Azji i Pacyfiku. Zapisy muszą być globalnie spójne. Ruch jest nierównomierny podczas wyprzedaży błyskawicznych (flash sales), a historyczne incydenty obejmowały kaskadowe ponowienia prób i przeciążenie systemu źródłowego (origin overload).

Podejście:

Uruchom wieloregionalną instancję Cloud Spanner używając konfiguracji nam-asia-eur1 z co najmniej trzema węzłami.

Uzasadnienie: Zapewnia globalnie spójne odczyty/zapisy z dostępnością na poziomie pięciu dziewiątek i umieszcza repliki blisko użytkowników, aby zredukować opóźnienie odczytu. Minimum trzy węzły zapewniają solidność kworum i zapas mocy na potrzeby rebalansowania.

Zaimplementuj bezstanową warstwę API w wielu regionach za globalnym zewnętrznym Application Load Balancer.

Uzasadnienie: Anycast VIP i globalny routing redukują czas nawiązywania połączenia i kierują użytkowników do najbliższego sprawnego regionu. Usługi bezstanowe ułatwiają skalowanie horyzontalne i przełączanie awaryjne.

Skonfiguruj kontrole stanu (health checks) i reguły zapory sieciowej dla zapewnienia osiągalności load balancera.

Uzasadnienie: Kontrole stanu zapobiegają kierowaniu ruchu do niesprawnych backendów. Zezwól na ruch z zakresów IP kontroli stanu Google, aby kontrole kończyły się powodzeniem: gcloud compute firewall-rules create allow-lb –network load-balancer –allow tcp –source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS

Zaimplementuj autoskalowanie oparte na metrykach żądań z utrzymaniem ciepłej pojemności.

Uzasadnienie: Skaluj grupy MIG lub GKE HPA na podstawie QPS/opóźnienia, a nie użycia CPU, aby reagować na ruch podczas wyprzedaży błyskawicznych. Utrzymuj minimalną liczbę replik w każdym regionie, aby uniknąć zimnych startów i włącz autoskalowanie predykcyjne przed znanymi wydarzeniami.

Dodaj Cloud CDN dla statycznych mediów produktowych przechowywanych w Cloud Storage.

Uzasadnienie: Buforowanie na brzegu sieci (edge caching) odciąża system źródłowy, redukuje opóźnienia krańcowe (tail latency) i łagodzi wzmocnienie gwałtownych wzrostów ruchu na warstwie aplikacji i pamięci masowej. Używaj podpisanych adresów URL i odpowiednich kluczy pamięci podręcznej/wartości TTL.

Wymuś ochronę przed przeciążeniem i ograniczanie szybkości (rate limiting) na brzegu sieci i w usłudze.

Uzasadnienie: Skonfiguruj limity szybkości w Cloud Armor, aby absorbować gwałtowne, szkodliwe skoki ruchu. W usłudze używaj limitów opartych na algorytmie token-bucket na klienta i odrzucaj żądania o niskim priorytecie, gdy cele SLO dotyczące opóźnień są zagrożone. Stosuj terminy ostateczne (deadlines) do każdego wywołania w dół strumienia (downstream call).

Stosuj odporne ponowienia prób z ucinanym wykładniczym czasem oczekiwania (truncated exponential backoff) i pełnym rozproszeniem (full jitter); zapewnij idempotentność za pomocą identyfikatorów operacji.

Uzasadnienie: Zapobiegaj efektowi thundering herd i zduplikowanym zapisom podczas częściowych awarii. Klucze idempotentności zapewniają bezpieczne powtórzenia; dla operacji na pamięci masowej używaj warunków wstępnych (conditional preconditions).