Google PCD: Prestaties, schaalbaarheid en Resilience Engineering — Studiegids

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

Onderdeel van de Google Professional Cloud Developer — Studiegids. Oefen met geverifieerde antwoorden in het Google-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Engineering voor prestaties, schaalbaarheid en veerkracht op Google Cloud richt zich op het handhaven van een kosteneffectieve service met lage latentie onder variabele belasting, terwijl fouten worden getolereerd zonder SLO’s te schenden. Het ontwerp moet autoscaling-signalen afstemmen op de kenmerken van de workload, data en compute plaatsen om tail latency te minimaliseren, en overload-controles, retries en failover implementeren om cascading failures te voorkomen. Dit gedeelte beschrijft de patronen, controles en afwegingen die van belang zijn voor applicatieontwikkelaars op de compute-, netwerk- en datalagen.

Schalen en Taakverdeling

Horizontale versus verticale schaling

Horizontale schaling voegt instances of pods toe om de capaciteit en veerkracht te vergroten. Geef hier de voorkeur aan voor stateless services en wanneer snelle elasticiteit vereist is. Gebruik Managed Instance Groups (MIGs), Cloud Run-revisies of GKE Deployments.
Verticale schaling vergroot de machinegrootte. Nuttig voor single-threaded of memory-bound workloads, of om coördinatie tussen nodes te verminderen, maar biedt beperkte speelruimte en langere herstarttijden.
Concurrency: Stem de request concurrency af op CPU-bound versus I/O-bound profielen. Cloud Run ondersteunt concurrency per revisie; GKE-pods kunnen meerdere requests verwerken als uw runtime non-blocking is; stel voor strikte isolatie de concurrency in op 1.

Autoscaling-signalen en ‘warm capacity’

MIG-autoscaling ondersteunt CPU-gebruik, load balancing-gebruik en custom metrics via Cloud Monitoring. Baseer voor piekend verkeer de schaling op request-metrics (rps, wachtrijdiepte) in plaats van op CPU.
GKE Horizontal Pod Autoscaler (HPA) kan schalen op basis van CPU, geheugen of custom/externe metrics (bijv. de lengte van een Pub/Sub-wachtrij). Gebruik Vertical Pod Autoscaler (VPA) voor right-sizing, maar vermijd live updates van VPA op snel schaalbare frontends om ‘churn’ te voorkomen.
Cloud Run schaalt op basis van de gelijktijdige request-belasting en optioneel op custom metrics. Voorkom cold starts door ‘warm capacity’ aan te houden: configureer een minimumaantal instances, houd de idle concurrency laag en warm indien nodig vooraf op via synthetische health pings.
Predictive autoscaling in MIG’s en het instellen van min-replica’s op een Deployment/Revision helpen de provisioning-latentie tijdens dagelijkse pieken te maskeren.

Load balancing, globale verkeersdistributie, health checks en failover

Gebruik de globale externe Application Load Balancer voor een wereldwijde anycast VIP, HTTP/2 en HTTP/3, en edge-terminatie met Cloud CDN. Backends kunnen instance groups, zonale/regionale NEG’s, serverless NEG’s (Cloud Run/Functions) of GKE Ingress zijn.
Health checks leiden verkeer weg van ongezonde backends. Zorg ervoor dat uw health-eindpunten afhankelijkheden nauwkeurig valideren (bijv. het proces en kritieke lokale resources) om circulaire storingen bij uitval van downstream-systemen te voorkomen.
Firewall-allowlists moeten de health checkers toestaan. Als checks naar poort 80 mislukken, sta dan de ranges van Google toe: 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
Failover: Configureer primaire/backup backend-services of traffic-beleid dat verkeer naar alternatieve regio’s stuurt bij een health-storing. Gebruik voor failover op DNS-niveau Cloud DNS-beleid met health checks voor niet-HTTP-eindpunten.

Latentie en Efficiëntie

Latency-budgetten

Wijs een end-to-end latency-budget toe per laag (client, edge, app, data). Monitor p95/p99, niet de gemiddelden. Gebruik Cloud Trace om cross-service bijdragers en head-of-line blocking te vinden. Pas deadlines toe op RPC’s zodat annulering door een upstream-systeem capaciteit vrijmaakt.

Gebruik van caching en CDN

Gelaagde caches: client/browser-cache, CDN-edge (Cloud CDN) en regionale/geheugencaches (Memorystore of in-process). Kies cache-sleutels en ‘vary’-headers zorgvuldig. Stel TTL’s in op basis van de versheid van data en het risico op verouderde data; overweeg ’negative caching’ voor 404’s wanneer dit veilig is.
Serveer statische assets vanuit Cloud Storage achter Cloud CDN om de belasting op de origin en tail latency te verminderen. Gebruik signed URL’s/headers voor gecontroleerde toegang.

Hergebruik van verbindingen

Geef de voorkeur aan HTTP/2 of gRPC voor multiplexing en header-compressie. Schakel keep-alives en connection pooling in om de handshake-overhead te verminderen. Let op uitputting van NAT-poorten; stem client connection pools en idle timeouts af, en bepaal de grootte van Cloud NAT-poorten per VM indien van toepassing.

Payload-efficiëntie

Gebruik binaire encoderingen (bijv. protobuf) en comprimeer tekst-payloads (gzip/brotli) boven een bepaalde groottedrempel. Ontwerp request/response-velden zorgvuldig; pagineer, filter aan de serverzijde en vermijd ‘over-fetching’. Gebruik ETags en conditionele requests (If-None-Match) om redundante overdrachten te voorkomen. Gebruik voor Cloud Storage ‘generation preconditions’ en ‘Range reads’ voor gedeeltelijke content.

Overbelastings- en Veerkrachtpatronen

Rate limiting, backpressure, wachtrijen en batchverwerking

Handhaaf rate limits aan de edge (Cloud Armor voor op IP/geo/service gebaseerde rate limiting) en op de API-laag (Apigee-quota’s, per-API client tokens). Implementeer token-bucket- of leaky-bucket-algoritmen server-side voor eerlijke verdeling.
Backpressure: Overbelast downstreams niet. Gebruik wachtrijen (Pub/Sub voor at-least-once eventing; Cloud Tasks voor per-wachtrij en per-doel throttling met planning en retries). Propageer 429 Too Many Requests of 503 met Retry-After om clients af te remmen.
Batchverwerking kan de doorvoer verhogen en de overhead per aanroep verminderen, waarbij verhoogde latency wordt ingeruild voor efficiëntie. Optimaliseer de batchgrootte en maximale wachttijd.

Bescherming tegen overbelasting

Pas timeouts en deadlines toe op elke RPC. Gebruik circuit breakers om te stoppen met het sturen van werk naar falende afhankelijkheden en om snelle fallbacks mogelijk te maken. Implementeer load shedding op basis van wachtrijdiepte, CPU, of een overschrijding van de latency-SLO om kernfunctionaliteit te beschermen.

Veerkrachtige retries, exponential backoff, jitter, idempotentie en afhandeling van duplicaten

Voer alleen een retry uit wanneer dit veilig is: bij netwerk-timeouts, 5xx-fouten, of gedocumenteerde codes die een retry toestaan (bv. Cloud Storage 429/5xx). Voer nooit een retry uit bij 4xx-fouten zoals 400/401/403, tenzij anders aangegeven.
Gebruik truncated exponential backoff met jitter om gesynchroniseerde retries te voorkomen. Geef de voorkeur aan full jitter. Voorbeeld:

undefined

Zorg voor idempotentie. Gebruik idempotentiesleutels (bv. een unieke operatie-ID) en upserts/conditionele schrijfacties om duplicaten te tolereren. Voor Pub/Sub, ontdubbel met behulp van de messageId of applicatiesleutels; ontwerp handlers zodat ze veilig zijn voor at-least-once delivery. Gebruik voor schrijfacties naar Cloud Storage generation-match preconditions om overschrijvingen te voorkomen.

Opstarten van slapende resources

Sommige services hanteren adaptieve limieten. Voor Cloud Storage, voer de request rates op voorheen inactieve buckets geleidelijk op om tijdelijke 429/5xx-fouten tijdens plotselinge pieken te verminderen. Throttel producers en warm buckets op met gecontroleerd verkeer vóór de volledige belasting.

Hoge Beschikbaarheid, Data, DR en Testen

Multi-zone, regionaal, multi-region; active-active vs. active-passive

Implementeer over ‘failure domains’. Gebruik regionale MIGs of regionale GKE-clusters voor tolerantie tegen zone-uitval. Gebruik voor wereldwijde services meerdere regio’s met de global load balancer.
Active-active verlaagt de RTO en latency, maar vereist conflictvrije data en zorgvuldig beheer van consistentie. Active-passive vereenvoudigt de semantiek voor schrijfacties, maar leidt tot een hogere RTO en potentieel ‘koude’ capaciteit.

RTO, RPO, back-up, herstel en disaster-recovery-testen

Definieer RTO (tijd om de service te herstellen) en RPO (aanvaardbaar dataverlies) per workload. Koppel dit aan de platformmogelijkheden:
- Cloud Spanner: multi-region met ‘five 9s’ beschikbaarheid en synchrone replicatie voor een RPO van bijna nul.
- Cloud SQL: Hoge Beschikbaarheid binnen een regio; gebruik cross-region replica’s voor DR, schakel PITR in en valideer failover/failback-draaiboeken.
- Firestore en Bigtable bieden regionale en multi-regionale opties; maak een keuze die voldoet aan de RTO/RPO.
- Cloud Storage dual- of multi-region buckets bieden geo-redundantie; verifieer herstelprocedures en de heruitgifte van signed URL’s.
Test DR: Voer regelmatig failover-oefeningen uit. Valideer back-ups door ze te herstellen in een geïsoleerde omgeving, oefen DNS/traffic failover en meet de daadwerkelijke RTO/RPO.

Database- en opslagprestaties, indexontwerp, ‘hot keys’ en conflicten

Cloud Spanner: Vermijd monotoon oplopende primary keys die ‘hotspotting’ veroorzaken. Gebruik ‘interleaved tables’ voor lokaliteit, secundaire indexen voor leespatronen en ‘bounded transactions’ om lock-conflicten te verminderen. Dimensioner het aantal nodes voor QPS en opslag; behoud minstens drie nodes voor productiequorum en ‘headroom’.
Cloud SQL: Analyseer query’s, voeg ‘covering indexes’ toe, vermijd lange transacties en gebruik ‘connection pools’. Stem InnoDB- of Postgres-instellingen oordeelkundig af; schaal ‘read replicas’ op voor workloads met veel leesverkeer.
Bigtable: Ontwerp ‘row keys’ om de belasting gelijkmatig te verdelen (‘salting’ of omkeren van velden). Gebruik ‘multi-cluster routing’ voor hoge beschikbaarheid over regio’s heen, indien beschikbaar.
Firestore: Gebruik ‘composite indexes’ voor query’s over meerdere velden; wees bedacht op ‘hotspotting’ wanneer veel schrijfacties gericht zijn op hetzelfde documentpad.
Cloud Storage: Sterke ‘read-after-write’-consistentie voor nieuwe objecten; gebruik parallelle uploads en ‘chunking’ voor doorvoersnelheid. Voer verkeer op ‘idle’ buckets geleidelijk op; geef de voorkeur aan de CDN-edge voor veelgevraagde (‘hot’) leesacties. Voor veel VM’s die dezelfde grote read-only dataset nodig hebben, koppel een persistent disk in read-only modus aan meerdere instances voor snelle lokale toegang tegen lage kosten.

Load tests, chaos-experimenten, fault injection en capaciteitsplanning

Load testing: Simuleer realistische verkeerspatronen en dataverdelingen. Warm caches en autoscalers op; test p95/p99 latency onder belasting en tijdens schaal-events. Spiegel een klein deel van het live verkeer naar ‘shadow stacks’ om het gedrag te valideren bij productiecomplexiteit.
Chaos en fault injection: Stop pods/VM’s, sluit een zone af (‘cordon’), injecteer latency/fouten in de service mesh (bijv. Envoy/Istio) om de ‘blast radius’ en veerkracht te observeren. Verifieer dat ‘circuit breakers’ en retries zich gedragen zoals bedoeld.
Capaciteitsplanning: Maak prognoses op basis van historische vraag en geplande evenementen. Houd ‘headroom’ aan voor N+1-uitval en ‘rebalancing’. Stem de ‘cooldowns’ en maximale snelheden van de autoscaler af op verwachte pieken; provisioneer vooraf (‘pre-provision’) tijdens voorspelbare piekmomenten.

Afwegingen in beschikbaarheid tussen managed services en maatwerkarchitecturen

Compute: Cloud Run biedt snelle ‘scale-to-zero’ en lage operationele overhead, maar heeft ‘cold starts’ en beperkingen op het gebied van ‘request concurrency’. GKE biedt fijnmazige controle en portabiliteit tegen hogere operationele kosten. Compute Engine VM’s bieden maximale controle met de hoogste operationele last.
Data: Cloud Spanner biedt wereldwijde consistentie en hoge beschikbaarheid tegen hogere kosten en met strikte schemavereisten. Cloud SQL is geschikt voor traditionele RDBMS met eenvoudigere operaties, maar beperkte HA/schaalbaarheid. Bigtable excelleert in key-value/time-series op massale schaal met lage latency. Firestore biedt flexibele schema’s met sterke consistentie en wereldwijde opties.
Netwerken: Global load balancers en Cloud CDN zijn hoog beschikbaar en opereren aan de ’edge’ van Google; doe-het-zelf-proxy’s bieden maatwerk, maar creëren operationele en faalrisico’s.
Geef de voorkeur aan managed services voor een hogere basisbeschikbaarheid en DDoS-weerstand, maar houd in je ontwerp rekening met quota’s, ‘cold starts’ en servicespecifieke semantiek.

Praktijkscenario

NimbusMart, een wereldwijd e-commercebedrijf, heeft een productcatalogus-API nodig met lage latency, ‘five 9s’ beschikbaarheid en minimale leeslatency voor gebruikers in Noord-Amerika, Europa en Azië-Pacific. Schrijfacties moeten wereldwijd consistent zijn. Het verkeer is grillig tijdens ‘flash sales’, en incidenten uit het verleden omvatten ‘cascading retries’ en overbelasting van de ‘origin’.

Aanpak:

Provisioneer een multi-regionale Cloud Spanner-instance met nam-asia-eur1 en minstens drie nodes.

Rationale: Levert wereldwijd consistente lees-/schrijfacties met ‘five 9s’ beschikbaarheid en plaatst replica’s dicht bij gebruikers om de leeslatency te verlagen. Een minimum van drie nodes zorgt voor quorum-robuustheid en ‘headroom’ voor ‘rebalancing’.

Implementeer een stateless API-laag in meerdere regio’s achter de global external Application Load Balancer.

Rationale: Anycast VIP en wereldwijde routering verkorten de ‘connection setup’ en sturen gebruikers naar de dichtstbijzijnde gezonde regio. Stateless services vergemakkelijken horizontale schaalvergroting en failover.

Configureer health checks en firewallregels voor de bereikbaarheid van de load balancer.

Rationale: Health checks voorkomen dat verkeer naar ongezonde backends wordt gerouteerd. Sta de IP-ranges van Google health checks toe zodat de checks slagen: 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

Implementeer autoscaling op basis van request-metrics met ‘warme’ capaciteit.

Rationale: Schaal MIGs of GKE HPA op basis van QPS/latency in plaats van CPU om te reageren op ‘flash sale’-verkeer. Handhaaf een minimumaantal replica’s per regio om ‘cold starts’ te vermijden en maak ‘predictive autoscaling’ mogelijk vóór bekende evenementen.

Voeg Cloud CDN toe voor statische productmedia die is opgeslagen in Cloud Storage.

Rationale: ‘Edge caching’ ontlast de ‘origin’, vermindert ’tail latency’ en beperkt ‘burst amplification’ op de applicatie- en opslaglagen. Gebruik signed URL’s en geschikte ‘cache keys’/TTL’s.

Dwing overbelastingsbeveiliging en ‘rate limiting’ af aan de ’edge’ en in de service.

Rationale: Configureer Cloud Armor ‘rate limits’ om excessieve pieken op te vangen. Gebruik in de service ’token-bucket’-limieten per client en laat laag-prioritaire requests vallen wanneer de latency-SLO’s in gevaar komen. Pas ‘deadlines’ toe op elke ‘downstream call’.

Gebruik veerkrachtige retries met ’truncated exponential backoff’ en ‘full jitter’; zorg voor idempotentie met ‘operation ID’s’.

Rationale: Voorkom ’thundering herds’ en dubbele schrijfacties tijdens gedeeltelijke storingen. ‘Idempotency keys’ zorgen voor veilige ‘replays’; gebruik voor opslagoperaties conditionele precondities.

Introduceer een ‘write queue’ voor het afvlakken van pieken (‘burst smoothing’) en asynchroniciteit waar dit acceptabel is.

Rationale: Pub/Sub buffert plotselinge pieken van niet-kritieke schrijfacties (bijv. analytics-events), waardoor ‘producers’ worden losgekoppeld van Spanner en de primaire schrijfpaden worden beschermd tegen overbelasting.

Definieer SLO’s en latency-budgetten; instrumenteer tracing en dashboards.

Rationale: Budgetten per ’tier’ sturen de optimalisatie. Cloud Monitoring SLO’s met ’error budgets’ en Cloud Trace onthullen de bijdragen van cross-region en de datalaag aan de p99-latency.

Stel DR-draaiboeken op en test de failover.

Rationale: Oefen met multi-region Spanner en multi-regionale compute ‘region evacuation drills’. Verifieer de RTO met ’traffic drain’- en ‘ramp-up’-tijdlijnen, en valideer dat autoscalers

← Observability · Alle domeinen · Testen →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →