Google PCD: Koszty, zarządzanie i zrównoważone operacje aplikacji — 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

Koszty, ład i zrównoważone operacje są nierozłączne w nowoczesnym tworzeniu aplikacji na Google Cloud. Celem jest uwidacznianie i kontrolowanie wydatków, projektowanie usług skalujących się w sposób ekonomiczny oraz egzekwowanie mechanizmów zabezpieczających, które utrzymują środowiska bezpiecznymi, zgodnymi z regulacjami i uporządkowanymi — przy jednoczesnym zachowaniu równowagi między wydajnością a niezawodnością. Ta sekcja szczegółowo opisuje praktyczne mechanizmy (rozliczenia i etykiety, opcje autoskalowania, limity i polityki), ekonomię specyficzną dla obciążeń (Cloud Run, GKE, platformy danych) oraz wybory świadome pod kątem zrównoważonego rozwoju, które redukują marnotrawstwo zasobów w stanie bezczynności i ślad węglowy bez pogarszania doświadczenia użytkownika.

Kontrola i widoczność kosztów

• Konta rozliczeniowe, etykiety, alokacja kosztów, budżety, alerty i widoczność
  • Używaj dedykowanego konta rozliczeniowego dla każdej jednostki biznesowej lub źródła finansowania, aby wyizolować odpowiedzialność i umożliwić szczegółowe uprawnienia. Eksportuj dane rozliczeniowe do BigQuery w celu szczegółowej analizy, prognozowania i realizacji obciążeń zwrotnych (chargeback).
  • Etykiety to pary klucz-wartość przypisywane do zasobów w celu atrybucji kosztów. Standaryzuj klucze etykiet (np. team, app, env, cost-center) i wymuszaj ich stosowanie za pomocą polityki organizacji oraz sprawdzeń w CI. Uwaga: etykiety nie działają wstecz; zasoby bez etykiet zakłócają raporty.
  • Używaj budżetów i alertów na poziomie konta rozliczeniowego i projektu. Łącz progi (np. 50, 90, 100 procent) z wyzwalaczami opartymi na prognozach. Kieruj powiadomienia budżetowe do Pub/Sub i przekazuj je do narzędzi typu Chat/Ops. Budżety wysyłają alerty; nie wymuszają limitów.
  • Dla platform współdzielonych (np. GKE, BigQuery) używaj etykiet per-przestrzeń nazw (namespace) lub per-zadanie i dołączaj je do logów oraz danych o użyciu, aby umożliwić showback/chargeback.

Przykład: dodawanie etykiet gcloud compute instances update web-01 –labels=team=payments,app=checkout,env=prod

• Limity (quotas), ograniczenia, prognozowanie zużycia i zarządzanie pojemnością
  • Limity (quotas) chronią usługi i ograniczają niekontrolowany wzrost kosztów. Regularnie przeglądaj limity usług, dopasowuj ich wielkość dla każdego projektu i wnioskuj o ich zwiększenie przed wdrożeniami. Wprowadź sprawdzenia przedwdrożeniowe, które porównują oczekiwane szczytowe użycie z limitami.
  • Prognozuj wydatki, używając eksportu danych rozliczeniowych oraz telemetrii użycia produktów (metryki Cloud Monitoring, metryki oparte na logach). Modeluj scenariusze (oczekiwana liczba QPS, ilość skanowanych danych) i weryfikuj je w środowisku przedprodukcyjnym.
  • Scenariusze awarii: osiągnięcie limitu w trakcie incydentu lub wdrożenia produktu prowadzi do dławienia (throttling, błędy 429/403), częściowych awarii lub cichej degradacji usługi. Zawyżone limity zwiększają promień rażenia (blast radius) wadliwych zadań.

Przykład: listowanie limitów Compute Engine gcloud services quota list
–service=compute.googleapis.com
–consumer=projects/$PROJECT_ID

Elastyczność i ekonomia zasobów obliczeniowych

• Właściwe dobieranie zasobów (right-sizing), autoskalowanie, rozliczanie na podstawie żądań, zobowiązania do użycia i pojemność spot

  • Dobieraj właściwy rozmiar vCPU i pamięci, korzystając z Cloud Monitoring i rekomendacji Recommender; weryfikuj za pomocą testów obciążeniowych. Niedostateczna alokacja powoduje skoki opóźnień i dławienie CPU (throttling) lub błędy OOM (Out of Memory); nadmierna alokacja marnuje budżet.
  • Autoskalowanie przekształca nadmiarowe przydzielanie zasobów (podobne do capex) w elastyczny opex. Używaj HPA/VPA dla GKE oraz autoskalowania na żądanie dla usług serverless (Cloud Run), aby dopasować pojemność do zapotrzebowania.
  • Rozliczanie na podstawie żądań (Cloud Run, Cloud Functions, GKE Autopilot) dostosowuje koszt do zużycia i redukuje bezczynność. Uważaj na narzuty związane z obsługą pojedynczych żądań i zimne starty (cold starts); w razie potrzeby dostosuj minimalną liczbę instancji.
  • Zobowiązania do użycia (Committed use) są przeznaczone dla stałego, bazowego obciążenia. Używaj CUDs opartych na zasobach dla Compute Engine i elastycznych CUDs dla kwalifikujących się produktów zarządzanych/serverless. Nie obejmuj zobowiązaniami zmiennych obciążeń.
  • Pojemność spot (Spot capacity) redukuje koszt zasobów obliczeniowych dla zadań, które mogą być przerywane i są odporne na błędy. Zawsze implementuj mechanizmy łagodnego zamykania (graceful termination handlers); utrzymuj redundancję i częste tworzenie punktów kontrolnych (checkpointing). Spodziewaj się zakończenia działania w dowolnym momencie z krótkim wyprzedzeniem.

• Kompromisy między współbieżnością a minimalną liczbą instancji w Cloud Run

  • Współbieżność (concurrency) kontroluje, ile żądań pojedyncza instancja może obsłużyć jednocześnie.
    • Wyższa współbieżność poprawia wykorzystanie zasobów i efektywność kosztową, ale może zwiększyć opóźnienia krańcowe (tail latency) z powodu blokowania head-of-line wewnątrz kontenera.
    • Współbieżność równa 1 izoluje żądania (przydatne dla kodu intensywnie wykorzystującego CPU lub niebędącego bezpiecznym wątkowo), ale często zwiększa liczbę instancji i koszt.
  • Minimalna liczba instancji redukuje zimne starty i wygładza opóźnienia kosztem stałego, bazowego wydatku. Używaj tej opcji tylko wtedy, gdy wymagają tego wskaźniki SLO, i weryfikuj wartość progową na podstawie wzorców zapotrzebowania.

Przykład: Konfiguracja Cloud Run (service.yaml) apiVersion: serving.knative.dev/v1 kind: Service metadata: name: img-api annotations: autoscaling.knative.dev/minScale: “2” spec: template: spec: containerConcurrency: 40 containers: - image: gcr.io/PROJECT/img-api resources: limits: memory: “512Mi”

• Żądania i limity zasobów w GKE, zachowanie Cluster Autoscaler i czyszczenie nieużywanych zasobów
  • Żądania (requests) determinują przydzielanie (scheduling); limity ograniczają szczytowe zużycie. Ustawiaj żądania blisko obserwowanego stałego zapotrzebowania, a limity nieco wyżej, aby pozwolić na krótkie skoki. Zbyt niskie limity powodują dławienie CPU (throttling); zbyt niskie limity pamięci powodują błędy OOMKilled. Żądania znacznie przewyższające rzeczywiste potrzeby blokują zasoby i utrudniają przydzielanie podów.
  • Cluster Autoscaler skaluje pule węzłów (node pools) w oparciu o pody, których nie można zaplanować (z powodu niewystarczających zagregowanych żądań). Respektuje PodDisruptionBudgets i nie może usuwać niektórych podów (np. z lokalną pamięcią masową lub restrykcyjnymi PDB), co może uniemożliwić skalowanie w dół. DaemonSets oraz tainy/affinity węzłów również mogą blokować efektywność skalowania.
  • Horizontal Pod Autoscaler (HPA) wiąże skalowanie ze zużyciem CPU/pamięci lub metrykami niestandardowymi; Vertical Pod Autoscaler (VPA) z czasem dopasowuje wielkość żądań. Koordynuj działanie HPA i VPA, aby unikać oscylacji; używaj VPA w trybie rekomendacji (recommend) lub automatycznym (auto) w zależności od potrzeb.
  • Czyszczenie nieużywanych zasobów: usuwaj nieużywane load balancery, dyski trwałe, snapshoty i statyczne adresy IP. Korzystaj z rekomendacji Active Assist i zautomatyzowanych skryptów czyszczących (janitors), aby wykrywać i usuwać nieaktywne zasoby.

Przykład: Deployment GKE z żądaniami/limitami apiVersion: apps/v1 kind: Deployment metadata: name: api spec: replicas: 3 template: spec: containers: - name: api image: gcr.io/PROJECT/api:stable resources: requests: cpu: “500m” memory: “512Mi” limits: cpu: “1” memory: “768Mi”

Zarządzanie kosztami danych, analityki i sieci

• Klasy pamięci masowej, mechanizmy cyklu życia, skalowanie baz danych i projektowanie ruchu wychodzącego (egress)
  • Wybieraj klasy Cloud Storage na podstawie wzorca dostępu: Standard dla danych gorących (hot data); Nearline, Coldline lub Archive dla danych zimniejszych (colder data). Pamiętaj o minimalnych opłatach za odczyt i wczesne usunięcie w zimniejszych warstwach.
  • Reguły cyklu życia (lifecycle rules) automatyzują przenoszenie i usuwanie danych. Używaj dual-region dla odporności na awarie, gdy opóźnienia multi-region są akceptowalne; umieszczaj zasoby obliczeniowe i dane w tej samej lokalizacji, aby zredukować koszty ruchu wychodzącego i opóźnienia.
  • Skalowanie baz danych:
    • Cloud SQL: skaluj wertykalnie z ostrożnością; używaj replik do odczytu (read replicas); korzystaj z automatycznego skalowania pamięci masowej; używaj planów zapytań i puli połączeń. Wysoka przepustowość zapisu może wymagać shardingu lub migracji do Spanner/Bigtable.
    • Spanner: skalowanie horyzontalne przez dodawanie węzłów; konfiguracje multi-region dla wysokiej dostępności i globalnych odczytów; projektuj schematy i klucze w celu zrównoważenia obciążenia.
    • Bigtable: projektuj klucze wierszy (row keys), aby unikać hotspotów; skaluj węzły klastra i pamięć masową niezależnie.
  • Ruch wychodzący (egress): unikaj ruchu między regionami; w miarę możliwości umieszczaj klientów i dane w tym samym regionie. Używaj Cloud CDN dla treści o skali internetowej, Cloud Interconnect/Peering dla rozwiązań hybrydowych oraz Private Google Access lub Private Service Connect, aby uzyskiwać prywatny dostęp do API Google. Niepotrzebny ruch między strefami/regionami zwiększa koszty i opóźnienia.

Przykład: cykl życia w Cloud Storage cat > policy.json « ‘EOF’ { “rule”: [ { “action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 30} }, { “action”: {“type”: “Delete”}, “condition”: {“age”: 365} } ] } EOF gsutil lifecycle set policy.json gs://my-bucket

• Kontrola zapytań BigQuery, przechowywanie danych i koszty użycia analityki
  • Kontroluj liczbę skanowanych bajtów: zawsze filtruj po kluczach partycji/klastra; unikaj SELECT *; używaj zmaterializowanych widoków i buforowania wyników (result caching) dla powtarzających się zapytań; w miarę możliwości stosuj agregacje przybliżone.
  • Ograniczaj koszt skanowania za pomocą maximum bytes billed i ustawiaj priorytet zadania na batch dla zadań, które nie są pilne, aby zmniejszyć zakłócenia i koszty.
  • Wybierz model cenowy: on-demand dla sporadycznych obciążeń; rezerwacje (slots) ze zobowiązaniami dla stałych, dużych obciążeń. Używaj oddzielnych rezerwacji i przypisań, aby izolować zespoły.
  • Przechowywanie danych: ustawiaj wygasanie dla zbiorów danych/tabel i partycji w celach zarządczych; wdrażaj warstwową pamięć masową lub eksport w celu archiwizacji.
  • Scenariusze awarii: duże tabele bez partycji powodują eksplozję kosztów; zapytania bez filtrów partycji skanują całe tabele; zbyt agresywne wygasanie usuwa potrzebne dane; nadmierna rywalizacja o slots pogarsza SLA.

Przykład: ograniczenie kosztu zapytania bq query –use_legacy_sql=false –maximum_bytes_billed=1000000000
‘SELECT user_id, COUNT(*) FROM proj.ds.events WHERE _PARTITIONDATE >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) GROUP BY user_id’

Zarządzanie organizacją i higiena środowiska

• Polityki organizacyjne, nazewnictwo zasobów, tagowanie i separacja projektów

  • Używaj polityk organizacyjnych do egzekwowania zasad ochronnych (guardrails): ograniczaj lokalizacje zasobów, blokuj zewnętrzne adresy IP, wymagaj CMEK, ograniczaj dozwolone usługi, kontroluj VPC peering i wymuszaj OS Login tam, gdzie to potrzebne. Stosuj na poziomie organizacji lub folderu, z wyjątkami modelowanymi za pomocą hierarchii.
  • Standaryzuj nazewnictwo zasobów, aby kodować środowisko, projekt, aplikację i region (np. app-env-region-suffix). Egzekwuj za pomocą kontroli CI lub polityki jako kodu (policy-as-code).
  • Rozróżnij:
    • Etykiety (Labels): atrybucja dla rozliczeń/operacji.
    • Tagi (Tags, pierwszorzędne): dołączaj do zasobów i używaj w warunkach IAM oraz do targetowania w politykach organizacyjnych.
    • Tagi sieciowe (Network tags): dla reguł zapory sieciowej w Compute Engine.
  • Separacja projektów: izoluj środowiska (prod, staging, dev) i wrażliwe obciążenia. Używaj Shared VPC do scentralizowanego zarządzania siecią i projektów usługowych z minimalnymi uprawnieniami (least-privilege). Zmniejsza to promień rażenia (blast radius) i upraszcza IAM.

• Cykl życia środowiska, efemeryczne środowiska testowe i automatyzacja czyszczenia

  • Provisionuj środowiska za pomocą IaC (Terraform) i włącz efemeryczne środowiska per-PR. Ustawiaj etykiety TTL i automatyczne usuwanie po zmergowaniu lub braku aktywności.
  • Używaj Cloud Scheduler w połączeniu z zadaniami Cloud Run lub Cloud Functions do wyszukiwania i usuwania nieaktualnych zasobów na podstawie etykiet/wieku. Eksportuj inwentarz za pomocą Cloud Asset Inventory, aby napędzać audyty.
  • Scenariusze awarii: porzucone środowiska deweloperskie (sandboxes) generują koszty; brakujące etykiety TTL lub inne etykiety uniemożliwiają czyszczenie; zbyt agresywne czyszczenie może usunąć aktywne zasoby — dodaj listy dozwolonych (allowlists) i okresy karencji.

• Architektura zorientowana na zrównoważony rozwój oraz równoważenie kosztów, wydajności i niezawodności

  • Preferuj usługi zarządzane i serverless, aby zredukować bezczynność i poprawić wykorzystanie zasobów.
  • Wybieraj regiony o niższej intensywności emisji dwutlenku węgla, jeśli jest to zgodne z wymaganiami; planuj zadania wsadowe (batch) w okresach większej dostępności energii bezemisyjnej, gdy to możliwe.
  • Optymalizuj grawitację danych (data gravity) i buforowanie, aby zmniejszyć zużycie energii przez sieć. Dostosuj autoskalowanie i współbieżność, aby zmniejszyć niedostateczne wykorzystanie zasobów. Używaj profilowania do usuwania marnotrawnych ścieżek kodu, które powodują nadmierne użycie mocy obliczeniowej lub operacji I/O.
  • Równowaga: dodawaj minimalną liczbę instancji lub replik tylko tam, gdzie wymagają tego wskaźniki SLO; oceniaj opóźnienie ogonowe (tail latency) w stosunku do współbieżności oraz nadmiarowość w stosunku do użycia instancji Spot. Weryfikuj za pomocą testów obciążeniowych opartych na SLO oraz modelowania kosztów/wydajności.

Praktyczny scenariusz problemowy

NimbusMarket, firma e-commerce, doświadcza skokowego ruchu podczas wyprzedaży błyskawicznych i rosnących wydatków na analitykę. Uruchamiają API dla klientów na Cloud Run, zadania w tle na GKE, a analitykę produktową w BigQuery. Kierownictwo prosi o 25-procentową redukcję kosztów bez naruszania SLO na poziomie 99,9% dla API.

Podejście:

1. Ustanowienie widoczności kosztów i zasad ochronnych

   • Utwórz budżety z alertami prognozującymi na poziomie 60, 90 i 100 procent dla konta rozliczeniowego, z powiadomieniami Pub/Sub kierowanymi do dyżuru (on-call).
   • Standaryzuj etykiety (team, app, env, cost-center) i wymuszaj ich stosowanie za pomocą CI na planach Terraform; dodaj politykę organizacyjną, która ogranicza lokalizacje zasobów do zatwierdzonych regionów. Uzasadnienie: Budżety dają wczesne ostrzeżenie; etykiety umożliwiają raportowanie per zespół; polityki zapobiegają przypadkowemu użyciu regionów o wysokich kosztach egressu i poprawiają zgodność z regulacjami.

2. Dostosowanie Cloud Run do ekonomicznego skalowania

   • Ustaw containerConcurrency na 40 dla bezstanowego API po profilowaniu, które potwierdziło średni czas CPU 30 ms i nieblokujące operacje I/O. Skonfiguruj minScale=2, aby unikać zimnych startów w normalnych godzinach; ustaw zaplanowaną politykę, aby obniżyć minScale do 0 w nocy. Uzasadnienie: Wyższa współbieżność poprawia wykorzystanie zasobów i zmniejsza liczbę instancji; minimalna stała liczba instancji utrzymuje SLO przy ograniczonym koszcie bazowym, który jest eliminowany poza godzinami szczytu.

3. Dopasowanie rozmiaru obciążeń GKE i włączenie wydajnego autoskalowania

   • Zastosuj żądania (requests) 500m CPU/512Mi i limity (limits) 1 CPU/768Mi dla podów workerów na podstawie profilowania. Włącz HPA na podstawie głębokości kolejki i opóźnienia przetwarzania oraz VPA w trybie rekomendacji, aby iteracyjnie dopracowywać żądania. Sprawdź, czy PodDisruptionBudgets pozwalają na skalowanie w dół. Włącz Cluster Autoscaler na puli z wieloma mniejszymi węzłami. Uzasadnienie: Dokładne żądania napędzają efektywne harmonogramowanie i autoskalowanie; HPA dostosowuje pojemność do zaległości; VPA unika dryfu konfiguracji; wiele małych węzłów zmniejsza osieroconą pojemność i przyspiesza zdarzenia skalowania.

4. Zastosowanie pojemności Spot dla odpornych na błędy zadań wsadowych

   • Przenieś generowanie miniaturek obrazów do puli węzłów opartej na instancjach Spot z checkpointingiem. Zaimplementuj hooki preStop, aby zakończyć przetwarzanie bieżących zadań, oraz kontroler do ponownego planowania przerwanych zadań. Uzasadnienie: Generowanie miniaturek jest idempotentne i elastyczne czasowo, co czyni je idealnym kandydatem do oszczędności dzięki instancjom Spot przy minimalnym wpływie na doświadczenie użytkownika.

5. Redukcja kosztów skanowania w analityce i izolacja obciążeń

   • Partycjonuj i klasteryzuj tabelę zdarzeń według event_date i customer_id. Dodaj wygasanie tabeli dla surowych zdarzeń po 180 dniach. Przypisz analityków marketingowych do oddzielnej rezerwacji BigQuery z limitem slotów; wymuś maximum_bytes_billed w ich zaplanowanych zapytaniach. Konwertuj nocne raporty na priorytet wsadowy (batch). Uzasadnienie: Partycjonowanie i klasteryzacja ograniczają liczbę bajtów na zapytanie; wygasanie wymusza zarządzanie danymi; rezerwacje izolują „hałaśliwych sąsiadów”; priorytet batch zmniejsza rywalizację o zasoby i koszt dla zadań, które nie są pilne.

6. Optymalizacja cyklu życia pamięci masowej i kosztów egressu

   • Przechowuj obrazy produktów w lokalizacji dual-region blisko klientów; przenoś obrazy nietknięte przez 30 dni do Coldline za pomocą reguł cyklu życia; serwuj przez Cloud CDN. Umieść usługi Cloud Run w tym samym regionie co Cloud SQL i włącz Private Service Connect do interfejsów API Google. Uzasadnienie: CDN redukuje koszty egressu i opóźnienia; cykl życia przenosi zimne dane do tańszej pamięci masowej; kolokacja minimalizuje egress i poprawia wydajność.

7. Implementacja automatyzacji czyszczenia i kontroli zrównoważonego rozwoju

   • Oznaczaj efemeryczne środowiska etykietą ttl-hours i uruchamiaj nocne zadanie w Cloud Run, które usuwa wygasłe zasoby. Użyj raportów Carbon Footprint, aby rozważyć przeniesienie zadań wsadowych do regionu o niższej emisji dwutlenku węgla i zaplanować je na godziny o niższej emisji. Uzasadnienie: Zautomatyzowane czyszczenie zapobiega wyciekom kosztów; planowanie z uwzględnieniem śladu węglowego zmniejsza wpływ na środowisko bez wpływu na SLO.

8. Walidacja za pomocą testów obciążeniowych uwzględniających SLO i modeli kosztów

   • Uruchom testy obciążeniowe, które odtwarzają wzorce ruchu z wyprzedaży błyskawicznych; zweryfikuj opóźnienie p95 i budżety błędów. Porównaj koszty przed i po, używając dashboardów eksportu rozliczeń. Uzasadnienie: Potwierdza, że optymalizacja spełnia cele niezawodności, jednocześnie przynosząc mierzalne oszczędności zgodne z celami.

Realizując te kroki, NimbusMarket dostosowuje wydatki do zapotrzebowania, zapobiega marnotrawstwu zasobów w stanie bezczynności i egzekwuje zasady ładu korporacyjnego, osiągając docelowe oszczędności przy jednoczesnym utrzymaniu SLO na poziomie 99,9% dla API i poprawiając swoją postawę w zakresie zrównoważonego rozwoju.

← Testowanie · Wszystkie domeny

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

Przeglądaj Google →