Google PCA: Koszty, wydajność i zrównoważone projektowanie chmury — 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

Koszt, wydajność i zrównoważony projekt chmury to dyscypliny optymalizowane wspólnie. Budowanie wydajnych architektur w Google Cloud wymaga obserwowalności finansowej, elastycznej pojemności podążającej za popytem, rygorystycznego zarządzania cyklem życia danych, świadomego rozmieszczania zasobów i buforowania w sieci oraz ciągłych pomiarów. Ta sekcja wyjaśnia wzorce projektowe i operacyjne, które redukują marnotrawstwo bez poświęcania niezawodności, bezpieczeństwa czy wydajności, a także podkreśla typowe błędy i kompromisy, aby unikać kosztownych niespodzianek.

Architektura kosztów i odpowiedzialność finansowa

Ustanów mechanizmy kontroli finansowej jako część bazowej konfiguracji platformy.

• Analiza i alokacja rozliczeń

  • Eksportuj dane rozliczeniowe do BigQuery w celu analizy wydatków niemal w czasie rzeczywistym, z możliwością odpytywania według projektu, usługi, SKU i etykiety. Partycjonuj według dnia, aby zapewnić skalowalność zapytań, i skonfiguruj kontrolę dostępu do zbioru danych dla interesariuszy z działów finansowych i inżynieryjnych.
  • Używaj budżetów z progami alertów, aby zapobiegać niekontrolowanemu wzrostowi wydatków. Przekierowuj alerty budżetowe do Pub/Sub i automatyzuj reakcje (na przykład wstrzymywanie obciążeń niekrytycznych). Pamiętaj, że alerty nie są transakcyjne i mogą mieć opóźnienia w raportowaniu; nie polegaj na nich jako jedynym mechanizmie kontroli dla niekontrolowanych zadań.

• Etykiety, tagi i atrybucja kosztów

  • Standaryzuj etykiety w całej organizacji (cost_center, env, owner, app) i wymuszaj ich stosowanie podczas provisioningu za pomocą szablonów wdrożeń lub polityki jako kodu (policy-as-code).
  • Preferuj hierarchiczne tagi oraz strukturę folderów/projektów, aby odzwierciedlać modele chargeback/showback. Używaj zarówno etykiet (na poziomie zasobu), jak i tagów (zakres polityki i rozliczeń), aby osiągnąć precyzyjną alokację.

• Bariery budżetowe i wykrywanie anomalii

  • Konfiguruj budżety dla poszczególnych projektów i portfolio; ustawiaj wiele progów (na przykład 50, 80, 100 procent) oraz alerty „prognozowane” (forecasted) w celu proaktywnego działania.
  • Korzystaj z rekomendacji Recommender (nieaktywne maszyny wirtualne, niepodłączone dyski, adresy IP, niewykorzystane zobowiązania), aby stale eliminować marnotrawstwo.

• Praktyczne przykłady

  • Stosowanie etykiet przy tworzeniu:
    • gcloud compute instances create api-1 –labels=env=prod,cost_center=retail,owner=eng
  • Odpytuj eksport danych rozliczeniowych w poszukiwaniu nieoznaczonych wydatków, aby wymusić zgodność za pomocą kontroli w CI/CD.

Typowe błędy i kompromisy:

• Niespójne etykiety uniemożliwiają alokację kosztów; wymuszaj ich stosowanie za pomocą polityk organizacyjnych i walidacji w potokach (pipelines).
• Scentralizowane rozliczenia bez budżetów dla poszczególnych zespołów utrudniają rozliczalność; twórz budżety na poziomie zespołu lub produktu.
• Opóźnione alerty budżetowe oznaczają, że gwałtowne skoki wydatków mogą przekroczyć budżet; stosuj dodatkowe limity i przydziały (quotas), gdzie to możliwe.

Wydajność obliczeniowa

Dopasuj zasoby do profili obciążeń; zautomatyzuj elastyczność; rezerwuj lub uzyskaj rabaty na stałe obciążenie bazowe.

• Rightsizing i niestandardowe typy maszyn

  • Ciągle analizuj wykorzystanie CPU, pamięci, IOPS dysku i sieci, aby dobrać odpowiedni rozmiar zasobów (rightsizing). Używaj niestandardowych typów maszyn, aby dopasować vCPU i pamięć do rzeczywistych potrzeb aplikacji i unikać płacenia za nieużywaną pamięć.
  • Zwracaj uwagę na zapas (headroom): celuj w 60–75 procent stałego obciążenia CPU i zapewnij wystarczający zapas pamięci na potrzeby GC lub nagłych skoków. Zbyt agresywny rightsizing zwiększa ryzyko dławienia (throttling) lub błędów braku pamięci (OOMs).

• Autoskalowanie i harmonogram cyklu życia

  • Używaj autoskalowania zarządzanych grup instancji w oparciu o odpowiednie sygnały (CPU, przepustowość load balancera lub niestandardowa głębokość kolejki). Skonfiguruj okresy rozgrzewania (warmup) i mechanizmy kontroli skalowania w dół (scale-in), aby zapobiec niestabilnemu działaniu.
  • Dla środowisk, które nie działają 24/7, zaplanuj uruchamianie/zatrzymywanie maszyn wirtualnych, pul nodów GKE lub minimalnej liczby instancji Cloud Run, aby unikać kosztów bezczynności. Prostym pierwszym krokiem jest użycie Cloud Scheduler do wywoływania zadania w Cloud Run, które co noc zatrzymuje instancje deweloperskie.

• Instrumenty rabatowe

  • Rabaty za zobowiązanie użycia (Committed-use discounts): zadeklaruj użycie na 1–3 lata dla stałych obciążeń kwalifikujących się do zobowiązań. Dopasuj wielkość zobowiązania do historycznego użycia i prognoz biznesowych; zbyt duże zobowiązanie generuje straty.
  • Spot VMs: idealne dla obciążeń odpornych na błędy, wsadowych lub rozproszonych. Mogą zostać odebrane w dowolnym momencie; zaimplementuj checkpointing i grupy wielu instancji z opcją awaryjnego przejścia na instancje na żądanie (on-demand).
    • Przykład: gcloud compute instances create etl-spot –provisioning-model=SPOT
  • Rezerwacje pojemności: rezerwuj pojemność strefową lub regionalną dla krytycznych flot, aby zminimalizować ryzyko niepowodzenia skalowania w górę podczas regionalnych niedoborów zasobów.
    • Przykład: gcloud compute reservations create web-capacity –zone=us-central1-a –machine-type=n2-standard-4 –vm-count=10

• Metryki wykorzystania i dostrajanie wydajności

  • Instrumentuj aplikacje za pomocą Cloud Monitoring, Profiler i Trace. Mierz opóźnienia p50/p95, czas kradzieży CPU (CPU steal), czas GC i zaległości w kolejkach. Optymalizuj krytyczne ścieżki kodu przed skalowaniem w poziomie.
  • Przypinaj obciążenia wrażliwe na wydajność do regionów i stref z odpowiednimi platformami CPU i rozważ użycie dysków trwałych o wysokiej przepustowości lub Hyperdisk, gdy jest to potrzebne.

Typowe błędy i kompromisy:

• Nieograniczone autoskalowanie może przekroczyć przydziały (quotas) i cele kosztowe; zawczasu zwiększ przydziały, ustaw maksymalną liczbę replik i używaj autoskalowania predykcyjnego dla znanych szczytów obciążenia.
• Spot VMs mogą powodować rotację części floty; dywersyfikuj strefy i implementuj hooki do łagodnego zamykania instancji (graceful termination).
• Zbyt duże zobowiązania CUDs lub niewykorzystane rezerwacje tworzą koszty utopione; przeglądaj zobowiązania co kwartał.

Optymalizacja kosztowo-wydajnościowa pamięci masowej, baz danych i analityki

Wybieraj klasy pamięci masowej i modele pojemności baz danych, które odzwierciedlają wzorce dostępu, retencję i cele SLO dotyczące wydajności.

• Klasy pamięci masowej i polityki cyklu życia
  • Używaj klasy Standard dla danych gorących (hot), Nearline dla dostępu co miesiąc, Coldline dla dostępu co kwartał i Archive dla długoterminowego, rzadkiego dostępu. Przechowuj dane i zasoby obliczeniowe w tym samym regionie, aby uniknąć opłat za ruch wychodzący (egress).
  • Stosuj zarządzanie cyklem życia (lifecycle management), aby automatycznie przenosić lub usuwać obiekty. Pamiętaj o minimalnych okresach przechowywania i opłatach za odczyt; przedwczesne przenoszenie między klasami może kosztować więcej, niż pozwala zaoszczędzić.

  • Przykładowa polityka cyklu życia (usuwanie obiektów starszych niż 90 dni):

undefined

-

undefined

• Transfer i archiwizacja danych

  • Dostęp międzyregionalny często wiąże się z opłatami za ruch wychodzący (egress); umieszczaj producentów i konsumentów danych w tej samej lokalizacji. Używaj Private Google Access i VPC-SC do bezpiecznego i zoptymalizowanego kosztowo dostępu do interfejsów API Google. W przypadku archiwów długoterminowych unikaj częstego odczytywania danych z klasy Archive, aby zapobiec wysokim opłatom za odczyt.

• Dobór rozmiaru i wydajność baz danych

  • Relacyjne: dobieraj rozmiar pod kątem zestawu roboczego rezydującego w pamięci (working set), liczby operacji IOPS i replik do odczytu (read replicas). Włącz automatyczne zwiększanie przestrzeni dyskowej i monitoruj opóźnienie replikacji (replication lag); skaluj wertykalnie lub stosuj sharding horyzontalny, gdy opóźnienie zagraża RPO/RTO.
  • NoSQL/szeregi czasowe: używaj Bigtable do przetwarzania danych wejściowych o wysokiej przepustowości i niskim opóźnieniu, z odpowiednim projektem klucza wiersza (row key), aby unikać hotspotów.

• Kontrola kosztów i modele pojemności w BigQuery

  • On-demand (płatność za przeskanowany TB): szybki start, ryzyko skoków kosztów. Rezerwacje oparte na pojemności: przewidywalne wydatki, kontrola nad współbieżnością i przepustowością. Zobowiązania Flex (Flex commitments) absorbują krótkoterminowe skoki zapotrzebowania.

  • Optymalizuj zapytania za pomocą partycjonowania i klastrowania; wymagaj filtrów partycji, aby zapobiec skanowaniu całych tabel:

undefined

• Ustaw maksymalną liczbę bajtów rozliczanych dla zadania, aby ograniczyć wydatki:

undefined

• Używaj zmaterializowanych widoków (materialized views), pamięci podręcznej wyników (result cache), agregacji przybliżonych i unikaj SELECT * w środowisku produkcyjnym. Przechowuj dane i zasoby obliczeniowe w tym samym regionie.

Scenariusze awarii i kompromisy:

• Przenoszenie gorących obiektów (hot) do Coldline/Archive powoduje naliczenie kosztów odczytu i opłat za wczesne usunięcie.
• BigQuery w modelu on-demand bez mechanizmów kontroli może generować niekontrolowane koszty z powodu niefiltrowanych skanów; wymuszaj stosowanie maksymalnej liczby rozliczanych bajtów i filtrów partycji.
• Nadmierny sharding baz danych zwiększa złożoność operacyjną; wykonaj testy wydajnościowe (benchmark) przed podziałem.

Sieci, przepustowość, limity i zrównoważone projektowanie

Sposób przesyłania danych i projekt współbieżności mają duży wpływ na koszty i wydajność; wybory dotyczące zrównoważonego rozwoju dodatkowo precyzują rozmieszczenie i harmonogramowanie zasobów.

• Ruch wychodzący z sieci (egress), ruch międzyregionalny, CDN i buforowanie

  • Minimalizuj przeskoki między regionami; replikuj dane tylko tam, gdzie wymaga tego bliskość użytkownika lub zgodność z przepisami. Używaj Cloud CDN do odciążenia zawartości statycznej i dynamicznej nadającej się do buforowania; dostosuj klucze pamięci podręcznej, TTL i podpisane adresy URL w celu uzyskania wysokich wskaźników trafień (hit ratio).
  • Buforuj blisko klientów (CDN), na brzegu VPC (proxy cache) i wewnątrz usług (pamięci podręczne w pamięci operacyjnej, jak Memorystore). Uważaj na nieaktualne dane i lawiny unieważnień (invalidation storms); definiuj jawne nagłówki cache-control.

• Pomiar wydajności, testy obciążeniowe i skalowanie

  • Ustal wskaźniki SLO i mierz je za pomocą Cloud Monitoring, Uptime checks, Cloud Trace i Profiler. Śledź opóźnienia p95/p99 i sygnały nasycenia (saturation signals).
  • Przeprowadzaj testy obciążeniowe z realistycznymi danymi i czasem na zastanowienie (think time). Realizuj testy etapami, aby uniknąć uruchomienia globalnych limitów zapytań; wnioskuj o tymczasowe zwiększenie limitów (quota).
  • Skaluj przepustowość za pomocą replik horyzontalnych, kolejek podzielonych na fragmenty (sharded queues), partycjonowanych tematów i autoskalerów sterowanych metrykami zaległości (backlog). W miarę możliwości preferuj potoki asynchroniczne.

• Limity (quotas), współbieżność, limity zapytań i mechanizm przeciwciśnienia (backpressure)

  • Zrób inwentaryzację limitów dla poszczególnych usług w każdym regionie; wymuszaj po stronie klienta wykładnicze ponawianie z losowym opóźnieniem (exponential backoff with jitter) dla odpowiedzi 429/5xx. Zaimplementuj kontrolę dostępu (admission control) i mechanizm przeciwciśnienia oparty na kolejkach, aby chronić zależności.
  • Dostosuj kontrolę przepływu (flow control) w Pub/Sub (maksymalna liczba niepotwierdzonych wiadomości/bajtów), przetwarzanie wsadowe (batching) i równoległość. W Cloud Run i GKE dopasuj współbieżność do zasobów procesora i pamięci, zapobiegając wzrostowi opóźnień krańcowych (tail-latency inflation).

• Projektowanie z uwzględnieniem zrównoważonego rozwoju

  • Preferuj usługi bezserwerowe i zarządzane o wysokim stopniu wykorzystania. Wybieraj regiony z wyższym odsetkiem energii bezemisyjnej, gdy pozwalają na to wymagania dotyczące opóźnień i zgodności.
  • Planuj zadania wsadowe i elastyczne w oknach czasowych o niskiej emisji dwutlenku węgla; używaj raportów Carbon Footprint do śledzenia wpływu.
  • Używaj energooszczędnych typów maszyn i rozważ obliczenia oparte na architekturze ARM, jeśli są kompatybilne, aby poprawić wydajność na wat.

• Zarządzanie równoważące niezawodność, bezpieczeństwo, wydajność i koszty

  • Zdefiniuj architektoniczne barierki ochronne (guardrails): obowiązkowe etykiety, alerty budżetowe, polityki organizacyjne (np. ograniczanie zewnętrznych adresów IP), budżety błędów SLO/error budgets i wskaźniki SLO dla kosztów.
  • Przeprowadzaj regularne przeglądy kosztów i wydajności z udziałem zespołów inżynieryjnych, bezpieczeństwa i finansów. Zintegruj Recommender i niestandardowe pulpity nawigacyjne; twórz podręczniki naprawcze (runbooks).
  • Jawnie równoważ kompromisy: wieloregionowe a regionalne (trwałość i opóźnienia kontra koszty i ruch wychodzący), warstwy szyfrowania i inspekcji (bezpieczeństwo kontra zużycie procesora i opóźnienia) oraz agresywne autoskalowanie (wydajność kontra limity i ryzyko związane z wydatkami).

Typowe tryby awarii i kompromisy:

• Analityka międzyregionalna na zbiorze danych z jednego regionu generuje stały ruch wychodzący; zreplikuj dane lub przenieś zasoby obliczeniowe.
• Błędna konfiguracja CDN skutkuje niskimi wskaźnikami trafień; monitoruj trafienia w pamięci podręcznej i ruch wychodzący z serwera źródłowego, aby zweryfikować oszczędności.
• Brak mechanizmu przeciwciśnienia (backpressure) podczas częściowych awarii potęguje skutki; zaimplementuj wyłączniki awaryjne (circuit breakers) i płynnie odrzucaj nadmiarowe obciążenie.

Praktyczny scenariusz problemowy

Acme Learn, firma z branży edukacji online, doświadcza nieprzewidywalnych wieczornych skoków obciążenia podczas wydarzeń na żywo. Koszty gwałtownie rosną z powodu zapytań BigQuery między regionami, gwałtownych działań autoskalowania i ruchu wychodzącego generowanego przez zasoby statyczne. Kierownictwo chce również zmniejszyć ślad węglowy bez pogarszania doświadczenia użytkownika.

Podejście:

1. Skonsoliduj wgląd w rozliczenia i wymuś alokację kosztów

   • Utwórz eksport danych rozliczeniowych do BigQuery oraz pulpity nawigacyjne posegmentowane według produktu, środowiska i regionu, używając etykiet i tagów ustandaryzowanych w szablonach wdrożeniowych.
   • Uzasadnienie: Wgląd w czasie niemal rzeczywistym powiązuje wydatki z odpowiedzialnymi zespołami, umożliwiając rozliczanie budżetu. Etykiety pozwalają na szczegółowe obciążanie kosztami (chargeback) i wykrywanie anomalii.

2. Przeprojektuj analitykę, aby współlokować zasoby obliczeniowe i pamięć masową

   • Przenieś analityczne zbiory danych o zdarzeniach i zaplanowane zapytania do tego samego regionu, w którym działają procesory strumieniowe. W przypadku BigQuery przełącz zespoły generujące duży ruch z modelu na żądanie (on-demand) na rezerwacje pojemności (capacity reservations) zwymiarowane pod szczytową współbieżność z małym elastycznym buforem.
   • Uzasadnienie: Współlokacja eliminuje ruch wychodzący między regionami. Model oparty na pojemności w BigQuery stabilizuje koszty pod obciążeniem, zachowując wydajność.

3. Zoptymalizuj dostarczanie treści za pomocą buforowania na brzegu sieci (edge caching)

   • Obsłuż statyczne i częściowo dynamiczne zasoby lekcji za pomocą Cloud CDN, ustawiając jawne nagłówki cache-control i podpisane adresy URL dla treści premium. Dostosuj wartości TTL w oparciu o zmienność treści.
   • Uzasadnienie: Wysokie wskaźniki trafień w pamięci podręcznej przenoszą ruch z serwerów źródłowych na brzeg sieci, redukując ruch wychodzący i obciążenie serwerów źródłowych, jednocześnie poprawiając opóźnienia w okresach szczytowego obciążenia.

4. Wzmocnij autoskalowanie i rezerwacje na potrzeby wydarzeń na żywo

   • Dodaj regionalną zarządzaną grupę instancji (managed instance group) dla warstwy API z celami autoskalera opartymi zarówno na użyciu procesora, jak i na zaległościach w żądaniach (request backlog). Utwórz małą strefową rezerwację pojemności, aby zagwarantować zapas mocy obliczeniowej na nagłe skoki obciążenia podczas wydarzeń. Włącz predykcyjne autoskalowanie przed zaplanowanymi sesjami.
   • Uzasadnienie: Autoskalowanie oparte na dwóch sygnałach reaguje zarówno na wykorzystanie zasobów, jak i na zapotrzebowanie, podczas gdy rezerwacje i predykcyjne rozgrzewanie pozwalają uniknąć opóźnień związanych z zimnym startem i niedoborów pojemności.

5. Zastosuj mieszankę zasobów obliczeniowych: podstawowe obciążenie na zobowiązaniach, skoki na maszynach Spot

   • Wykup roczne zobowiązania (commitments) dla bazowego obciążenia API i zadań przetwarzania danych. Skonfiguruj wsadowe transkodowanie i zadania wzbogacania danych na maszynach Spot VM z mechanizmem checkpointingu i wielostrefowymi grupami instancji.
   • Uzasadnienie: Zobowiązania redukują koszty stałe; maszyny Spot VM zapewniają tanią elastyczność dla zadań, które mogą być przerywane, bez ryzyka dla ruchu użytkowników.

6. Wprowadź cykl życia pamięci masowej i rozmieszczenie regionalne

   • Przechowuj gorące metadane kursów i miniatury w regionalnej klasie Standard blisko zasobów obliczeniowych obsługujących ruch. Przenoś logi i surowe strumienie kliknięć do klasy Nearline po 30 dniach i usuwaj po 180 dniach. Dla archiwów wymaganych przez przepisy używaj klasy Archive z udokumentowanymi umowami SLA dotyczącymi odzyskiwania danych.
   • Uzasadnienie: Dopasowuje klasę pamięci masowej do wzorców dostępu, redukując bieżące koszty przy jednoczesnym poszanowaniu zasad retencji.

7. Wprowadź barierki ochronne (guardrails) dla użycia BigQuery

   • Wymagaj filtrów partycji na dużych tabelach i ustaw domyślne limity na poziomie projektu dla maksymalnej liczby bajtów rozliczanych w zadaniu. Wprowadź zmaterializowane widoki dla popularnych agregacji i wzorce pozyskiwania danych z partycjonowaniem.
   • Uzasadnienie: Zapobiega przypadkowym pełnym skanowaniom tabel, stabilizuje wydatki i przyspiesza często wykonywane zapytania.

8. Zaprojektuj pod kątem przepustowości z uwzględnieniem mechanizmu przeciwciśnienia (backpressure) i limitów

   • Zintegruj Cloud Tasks dla przepływów pracy z ograniczoną szybkością zapytań i skonfiguruj subskrybentów Pub/Sub z kontrolą przepływu. Zaimplementuj wykładnicze ponawianie z losowym opóźnieniem dla interfejsów API firm trzecich i ustaw limity współbieżności dla poszczególnych usług w Cloud Run.
   • Uzasadnienie: Kontroluje zapotrzebowanie, aby przestrzegać limitów, chroni zależności podczas gwałtownych wzrostów obciążenia i pozwala uniknąć awarii kaskadowych.

9. Włącz zrównoważony rozwój w działania operacyjne

   • Preferuj usługi bezserwerowe tam, gdzie to możliwe, wybieraj regiony z wyższym odsetkiem energii bezemisyjnej dla analityki i planuj niepilne zadania wsadowe w oknach czasowych o niskiej emisji dwutlenku węgla. Śledź emisje za pomocą Carbon Footprint i uwzględniaj je w kwartalnych przeglądach.
   • Uzasadnienie: Poprawia wydajność na wat i zmniejsza ślad węglowy przy minimalnych kompromisach odczuwalnych przez użytkownika.

10. Zarządzaj w sposób ciągły

    • Twórz budżety i alerty dla każdego produktu, wymuszaj stosowanie etykiet za pomocą polityk i ustanów comiesięczne przeglądy kosztów, wydajności i wskaźników SLO. Zautomatyzuj czyszczenie nieużywanych zasobów i niepodłączonych dysków w oparciu o rekomendacje z Recommender.
    • Uzasadnienie: Ciągłe zarządzanie podtrzymuje uzyskane korzyści, zapobiega regresjom i z czasem równoważy niezawodność, bezpieczeństwo, wydajność i koszty.

Ten projekt redukuje ruch wychodzący, stabilizuje koszty analityki, zapewnia przewidywalną wydajność podczas wydarzeń na żywo i wspiera cele zrównoważonego rozwoju bez pogarszania doświadczenia użytkownika.

← DevOps · Wszystkie domeny

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

Przeglądaj Google →