Google PCD: Kosten, governance en duurzame applicatie-operaties — 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

Kosten, governance en duurzame operaties zijn onlosmakelijk verbonden in de moderne applicatieontwikkeling op Google Cloud. Het doel is om uitgaven inzichtelijk te maken en te beheersen, services te ontwerpen die economisch schalen, en richtlijnen af te dwingen die omgevingen veilig, compliant en opgeruimd houden—terwijl prestaties en betrouwbaarheid in balans blijven. Dit gedeelte beschrijft praktische mechanismen (facturering en labels, autoscaling-instellingen, quota’s en policies), de economie van specifieke workloads (Cloud Run, GKE, dataplatforms) en de duurzaamheidsbewuste keuzes die ongebruikte resources en CO2-impact verminderen zonder de gebruikerservaring te ondermijnen.

Kostenbeheersing en Inzichtelijkheid

• Billing-accounts, labels, kostentoewijzing, budgetten, alerts en inzichtelijkheid
  • Gebruik een toegewezen billing-account per businessunit of financieringsbron om eigenaarschap te isoleren en granulaire permissies mogelijk te maken. Exporteer factureringsgegevens naar BigQuery voor gedetailleerde analyse, prognoses en doorbelasting (chargeback).
  • Labels zijn key-value-paren op resources voor kostentoerekening. Standaardiseer label-keys (team, app, env, cost-center) en dwing dit af via een organization policy en CI-controles. Let op: labels zijn niet retroactief; niet-gelabelde resources vertekenen rapportages.
  • Gebruik budgetten en alerts op het niveau van billing-accounts en projecten. Combineer drempelwaarden (bijv. 50, 90, 100 procent) met op prognoses gebaseerde triggers. Stuur budgetnotificaties naar Pub/Sub en door naar Chat/Ops-tools. Budgetten waarschuwen; ze dwingen niets af.
  • Voor gedeelde platformen (bijv. GKE, BigQuery), gebruik labels per namespace of per job en koppel deze aan logs en verbruik om showback/chargeback mogelijk te maken.

Voorbeeld: labels toevoegen

undefined

• Quota’s, limieten, verbruiksprognoses en capaciteitsbeheer
  • Quota’s beschermen services en beperken uit de hand lopende kosten. Controleer servicequota’s regelmatig, pas de grootte per project aan (“right-sizing”) en vraag verhogingen aan vóór lanceringen. Implementeer pre-deploy-controles die het verwachte piekgebruik vergelijken met de quota’s.
  • Maak prognoses van uitgaven met behulp van de Billing-export plus telemetrie over productgebruik (Cloud Monitoring-metrics, op logs gebaseerde metrics). Modelleer scenario’s (verwachte QPS, gescande data) en valideer deze in pre-productie.
  • Faalscenario’s: het bereiken van een quota tijdens een incident of productlancering leidt tot throttling (429/403), gedeeltelijke storingen of stille degradatie. Te ruime quota’s vergroten de ‘blast radius’ van foutieve taken.

Voorbeeld: Compute Engine-quota’s weergeven

undefined

Elasticiteit en Compute-economie

• Right-sizing, autoscaling, facturering op basis van requests, committed use en spot-capaciteit

  • Kies de juiste omvang (right-size) voor vCPU en geheugen met behulp van inzichten uit Cloud Monitoring en Recommender; valideer met loadtests. Te lage toewijzingen veroorzaken pieken in latentie en OOM/CPU-throttling; te hoge toewijzingen verspillen budget.
  • Autoscaling zet capex-achtige overprovisioning om in elastische opex. Gebruik HPA/VPA voor GKE en autoscaling per request voor serverless (Cloud Run) om capaciteit af te stemmen op de vraag.
  • Facturering op basis van requests (Cloud Run, Cloud Functions, GKE Autopilot) brengt kosten in lijn met gebruik en vermindert ongebruikte capaciteit (idle). Pas op voor overhead per request en cold starts; stel waar nodig min instances in.
  • Committed use is voor een stabiele, voorspelbare basislast (steady-state baseline). Gebruik resource-based CUDs voor Compute Engine en flexibele CUDs voor in aanmerking komende managed/serverless producten. Sluit geen CUDs af voor volatiele workloads (overcommit niet).
  • Spot-capaciteit verlaagt de compute-kosten voor onderbreekbare, fouttolerante taken. Implementeer altijd ‘graceful termination handlers’; zorg voor redundantie en snelle checkpointing. Verwacht beëindiging op elk moment met een korte aankondigingstijd.

• Cloud Run: afwegingen tussen concurrency en minimum instances

  • Concurrency bepaalt hoeveel requests een enkele instance tegelijk kan verwerken.
    • Hogere concurrency verbetert de bezettingsgraad en kostenefficiëntie, maar kan de ’tail latency’ verhogen door ‘head-of-line blocking’ binnen de container.
    • Een concurrency van 1 isoleert requests (nuttig voor CPU-gebonden of niet-thread-safe code), maar verhoogt vaak het aantal instances en de kosten.
  • Minimum instances verminderen cold starts en vlakken de latentie af, ten koste van een basisuitgave. Gebruik dit alleen waar SLO’s dit vereisen en valideer het minimumaantal aan de hand van vraagpatronen.

Voorbeeld: Cloud Run-configuratie (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”

• GKE: resource requests en limits, gedrag van de Cluster Autoscaler en het opruimen van ongebruikte resources
  • Requests bepalen de scheduling; limits beperken het piekgebruik. Stel requests in dicht bij de waargenomen stabiele behoefte en limits iets daarboven om korte pieken op te vangen. Te lage limits veroorzaken CPU-throttling; te lage geheugenlimits veroorzaken OOMKilled. Requests die veel hoger zijn dan de werkelijkheid, houden capaciteit vast (‘stranding’) en blokkeren scheduling.
  • Cluster Autoscaler schaalt node pools op basis van pods die niet ingepland kunnen worden (‘unschedulable’) vanwege onvoldoende geaggregeerde requests. Het respecteert PodDisruptionBudgets en kan bepaalde pods niet verwijderen (’evict’) (bijv. pods met local storage of restrictieve PDBs), wat ‘scale-down’ kan verhinderen. DaemonSets en node taints/affinities kunnen de schaalefficiëntie ook blokkeren.
  • Horizontal Pod Autoscaler koppelt schalen aan CPU/geheugen of custom metrics; Vertical Pod Autoscaler past de omvang van requests (‘right-sizes’) in de loop van de tijd aan. Coördineer HPA en VPA om oscillatie te voorkomen; gebruik VPA in ‘recommend’- of ‘auto’-modus waar van toepassing.
  • Opruimen van ongebruikte resources: verwijder ongebruikte load balancers, persistent disks, snapshots en statische IP-adressen. Gebruik Active Assist-aanbevelingen en geautomatiseerde ‘janitors’ om ongebruikte assets te detecteren en te verwijderen.

Voorbeeld: GKE-deployment met requests/limits 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”

Kostenbeheer voor data, analytics en netwerken

• Opslagklassen, lifecycle-beheer, databaseschaling en ontwerp van netwerk-egress
  • Kies Cloud Storage-klassen op basis van toegangspatroon: Standard voor ‘hot’ data; Nearline, Coldline of Archive voor ‘koudere’ data. Houd rekening met de minimumkosten voor ophalen en vroegtijdig verwijderen bij de koudere tiers.
  • Lifecycle-regels automatiseren overgangen en verwijderingen. Gebruik dual-region voor veerkracht waar multi-region latentie acceptabel is; plaats compute en data samen (co-locatie) om egress en latentie te verminderen.
  • Databaseschaling:
    • Cloud SQL: schaal verticaal met de nodige voorzichtigheid; gebruik read replicas voor leesoperaties; storage autoscaling; gebruik query plans en connection pooling. Hoge schrijfdoorvoer kan sharding of een overstap naar Spanner/Bigtable vereisen.
    • Spanner: horizontale schaling door nodes toe te voegen; multi-region configuraties voor beschikbaarheid en wereldwijde leesoperaties; ontwerp schema’s en keys voor een gebalanceerde load.
    • Bigtable: ontwerp row keys om hotspots te vermijden; schaal cluster nodes en opslag afzonderlijk van elkaar.
  • Netwerk-egress: vermijd verkeer tussen regio’s; plaats clients en data waar mogelijk in dezelfde regio. Gebruik Cloud CDN voor content op internetschaal, Cloud Interconnect/Peering voor hybride omgevingen, en Private Google Access of Private Service Connect voor privétoegang tot Google API’s. Onnodig verkeer tussen zones/regio’s verhoogt de kosten en latentie.

Voorbeeld: Cloud Storage lifecycle 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

• Beheer van BigQuery-query’s, dataretentie en kosten van analytics-gebruik
  • Beheers het aantal gescande bytes: filter altijd op partitie-/clusterkeys; vermijd SELECT *; gebruik materialized views en result caching voor herhaalde query’s; gebruik waar mogelijk geschatte aggregaties (approximate aggregations).
  • Beperk de scankosten met ‘maximum bytes billed’ en stel de jobprioriteit in op ‘batch’ voor niet-urgente taken om interferentie en kosten te verlagen.
  • Kies een prijsmodel: on-demand voor sporadische workloads; reserveringen (slots) met commitments voor stabiele, high-volume workloads. Gebruik afzonderlijke reserveringen en toewijzingen om teams te isoleren.
  • Dataretentie: stel vervaldatums in voor datasets/tabellen en partities voor governance; implementeer tiered storage of exporteer data voor archivering.
  • Faalscenario’s: niet-gepartitioneerde grote tabellen laten de kosten exploderen; query’s zonder partitiefilters scannen volledige tabellen; te agressieve vervalinstellingen verwijderen benodigde data; overmatige ‘slot contention’ verslechtert de SLA.

Voorbeeld: querykosten beperken 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’

← Testen · Alle domeinen

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

Blader door Google →