Google PCA: Compute, Applicatieplatforms en Workloadarchitectuur — Studiegids

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Overzicht

Dit domein behandelt het selecteren en ontwerpen van compute-platformen op Google Cloud, het packagen en deployen van applicaties, en het beheren van workloads voor betrouwbaarheid, prestaties, beveiliging en kostenefficiëntie. Het omvat virtuele machines, Kubernetes, serverless runtimes, load balancing, uitrolstrategieën, stateful en gespecialiseerde compute, en modernisatiepatronen die technische schuld verminderen en tegelijkertijd voldoen aan de veranderende vraag.

Compute Engine en op VM gebaseerde architecturen

Compute Engine biedt granulaire controle over besturingssystemen, netwerken en machine shapes. Kies machine families op basis van workload-kenmerken:

E2: kosten-geoptimaliseerd voor algemeen gebruik; goed voor dev/test, bursty apps.
N2/N2D: gebalanceerde prijs/prestatie voor de meeste productieworkloads; N2D gebruikt AMD CPU’s met sterke geheugenbandbreedte.
C2/C2D/C3: compute-geoptimaliseerd voor CPU-intensieve taken (bijv. API met hoge QPS, batchverwerking).
M3: geheugen-geoptimaliseerd voor grote in-memory datasets (caches, in-memory analytics).
A3: GPU-geoptimaliseerd (NVIDIA) voor training/inference; GPU’s kunnen ook aan andere families gekoppeld worden.
Confidential VM’s (op ondersteunde CPU’s) versleutelen data-in-use met minimale codewijzigingen.

Managed instance groups (MIGs) brengen elasticiteit en veerkracht:

Gebruik Instance Templates voor onveranderlijke configuratie en MIGs om horizontaal over zones te schalen.
Autoscaling-beleid: CPU, load balancer-gebruik, Cloud Monitoring-metrics, of wachtrijdiepte via custom metrics. Stel min/max replica’s en een cooldown-periode in om ’thrashing’ bij piekbelastingen te voorkomen.
Rolling updates en canaries verminderen het risico; houd de ‘surge’- en ‘unavailable’-instellingen conservatief voor stateful services of services met een lange koude start.

Load balancing en health checks:

De Global external HTTP(S) load balancer termineert TLS, ondersteunt URL-mapping en is de standaard front-end voor web-API’s; de internal HTTP(S) LB is voor oost-west verkeer.
Health checks moeten de backends kunnen bereiken. Een veelvoorkomende fout is dat geblokkeerde probes leiden tot het voortdurend herstarten van instances en het wegvallen van verkeer.
Sta de source ranges van de health check toe op de backend-poorten met VPC-firewallregels en target tags.

Voorbeeld om HTTP health checks naar een MIG toe te staan:

undefined

Overwegingen voor de VM-levenscyclus:

Gebruik startup-scripts of image-metadata voor bootstrapping; sla runtime-configuratie op in Secret Manager, niet ingebakken in images.
Voeg voor preemptible/Spot VM’s een shutdown-script toe om werk af te handelen na een beëindigingsbericht.
Patch via ‘baked images’ en ‘rolling replacement’ om configuratie-afwijking (configuration drift) te voorkomen.
Het resizen van een persistent disk kan online: vergroot de schijfgrootte en laat vervolgens het bestandssysteem groeien (bijv. met resize2fs op ext4) met minimale downtime.

Voorbeeld van PD resize:

undefined

Veilige identiteit en observability:

Koppel service accounts met de minste rechten (least privilege) aan instances; sluit geen statische credentials in.
Installeer de Ops Agent voor Cloud Logging en Cloud Monitoring. Gebruik Cloud Trace en Cloud Profiler om ’tail latency’ en ‘hot spots’ te verminderen.
Exporteer audit- en metric-data naar BigQuery of Cloud Storage voor langetermijnbewaring en -analyse.

Batch en gespecialiseerde compute:

Gebruik Cloud Batch of MIGs met preemptible VM’s voor fouttolerante batchverwerking om kosten te besparen; implementeer checkpointing.
Koppel GPU’s/TPU’s waar ML-acceleratie nodig is. Gebruik dedicated node pools of sole-tenant nodes om te voldoen aan compliance- of isolatievereisten.
Confidential VM’s beschermen gevoelige data in het geheugen; meet de overhead ten opzichte van de vereisten.

Overwegingen voor state:

Houd applicatie-instances stateless; externaliseer sessies naar een gedeelde store (bijv. Memorystore, Cloud SQL) om voor gebruikers zichtbare afwijkingen tijdens het schalen te voorkomen.
Gebruik voor state die aan een VM gebonden is, regional persistent disks of gerepliceerde databases; test de failover-paden.

Kubernetes en Containerplatformen (GKE)

GKE biedt een beheerd controlepaneel met flexibele worker node pools:

Regionale clusters repliceren het controlepaneel en de nodes over meerdere zones voor hoge beschikbaarheid; zonale clusters concentreren resources voor lagere kosten en latency-gevoeligheid.
Gebruik meerdere node pools om workloads te segmenteren (bijv. general purpose, GPU, high-memory, spot). Pas taints/tolerations en affinity/anti-affinity toe om de plaatsing te sturen en ’noisy-neighbor’-effecten te verminderen.
Autoscaling-lagen: de cluster autoscaler voegt nodes toe of verwijdert ze; de Horizontal Pod Autoscaler (HPA) schaalt replica’s op basis van CPU/custom metrics; de Vertical Pod Autoscaler (VPA) zorgt voor de juiste omvang van requests. Combineer HPA met de cluster autoscaler voor elasticiteit.

Workload-scheduling en services:

Kies de juiste omvang voor CPU/memory requests/limits om het risico op ’eviction’ te minimaliseren en de ‘binpacking’-efficiëntie te maximaliseren.
Gebruik PodDisruptionBudgets om de beschikbaarheid tijdens upgrades te waarborgen.
Service types: ClusterIP (in-cluster), NodePort/LoadBalancer (north-south), en Ingress voor HTTP(S)-routing met de globale LB. Voor canaries, stuur verkeer via aparte Services/Ingress-backends of een service mesh.

Upgrades en veerkracht:

Gebruik ‘surge upgrades’ en ‘maxUnavailable’ om de ‘churn’ te beheersen; pin kritieke workloads vast aan meerdere zones en pools.
Stel onderhoudsvensters/uitsluitingen in voor bedrijfskritieke periodes.
Valideer met een pre-productieomgeving en ‘canary’ node pools vóór een brede uitrol.

Images en beveiliging:

Sla container-images op in Artifact Registry; schakel vulnerability scanning in en configureer ‘binary authorization’ of ‘attestations’ voor herkomstbepaling (provenance).
Gebruik Workload Identity om een GSA aan een KSA te koppelen voor credentialless, least-privilege toegang tot Google API’s.
Haal runtime-configuratie op uit Secret Manager via de CSI-driver; vermijd Kubernetes Secrets voor zeer gevoelige waarden, tenzij ze versleuteld zijn met CMEK en RBAC strak is ingesteld.

Uitrol en rollback:

Geef de voorkeur aan ‘rolling updates’ van Deployments met kleine stappen en health probes; gebruik voor systemen met lage tolerantie ‘blue-green’ via twee Deployments achter één Service en wissel van labels/selector.
Definieer altijd readiness en liveness probes; verkeerd geconfigureerde probes veroorzaken ‘cascading restarts’ of ‘blackholes’ tijdens uitrol.

Serverless en Event-Driven Platformen

Google Cloud serverless abstraheert de infrastructuur en biedt tegelijkertijd sterke controle over schaal, beveiliging en kosten:

Cloud Run: container-native, getriggerd door HTTP-requests of Eventarc. Schaalt naar nul; configureerbare concurrency; verkeer splitsen per revisie voor canary en rollback. Stel ‘min instances’ in om ‘cold starts’ te verminderen voor latency-gevoelige endpoints. Integreer met VPC via Serverless VPC Access voor private egress.
App Engine: een ‘opinionated’ PaaS. Standard biedt snelle schaalvergroting en per-request concurrency-beperkingen per taal; Flexible draait containers op VM’s met meer controle. Vermijd sessiestatus die lokaal op de instance wordt opgeslagen; externaliseer dit naar gedeelde opslag om verouderde of dubbele gebruikerservaringen onder belasting te voorkomen.
Cloud Functions: granulariteit op functieniveau voor event-driven logica. Gebruik Pub/Sub, Cloud Storage of Eventarc triggers voor lichtgewicht micro-operaties; houd functies idempotent en stateless. Voor gecombineerde batch/stream-pipelines zonder bestaande code biedt Dataflow een uniforme verwerking met autoscaling.

Afwegingen bij platformkeuze:

Operationele controle: Compute Engine > GKE > Cloud Run/App Engine > Cloud Functions.
Portabiliteit: container-gebaseerd (GKE/Cloud Run/App Engine Flex) > VM-images > functions en App Engine Standard.
Latency: Cloud Run met ‘min instances’ of GKE voor lage ’tail latency’; vermijd ‘cold starts’ voor interactieve workloads.
Schalen: Cloud Functions/Run schalen het snelst; GKE HPA plus cluster autoscaler; MIGs vereisen opwarmtijd en health checks.
Kosten: serverless ‘pay-per-use’ voor piekbelasting/lage constante belasting; GKE/VM’s met ‘committed use discounts’ voor stabiele services met hoge doorvoer; preemptible/Spot voor batch.

Identiteit en configuratie:

Elke service moet een eigen service account gebruiken met ’least privilege’. Stel voor Cloud Run en Functions het runtime service account expliciet in.
Sla secrets op in Secret Manager en koppel toegang via IAM; injecteer ze via omgevingsvariabelen of ‘volume mounts’.

Architectuurpatronen, Delivery en Operations

Servicedecompositie en -grenzen:

Monoliet: eenvoudigste implementatie en transacties, maar beperkt onafhankelijke schaalvergroting en beheersing van de blast radius; kan prestatieproblemen diep in de call chains verbergen.
Modulaire monoliet: duidelijke interne modules, gedeeld proces; goede tussenstap—dwingt interfaces af zonder de nadelen van distributie.
Microservices: onafhankelijke implementeerbaarheid en schaalvergroting; introduceert netwerklatentie, gedistribueerde transacties en uitdagingen op het gebied van consistentie. Definieer duidelijke bounded contexts en data-eigendom; vermijd gedeelde databases om koppeling te voorkomen.

Moderniseringspatronen:

Strangler-fig: leid stapsgewijs een deel van het verkeer naar nieuwe componenten, en neem verouderde endpoints geleidelijk buiten gebruik.
Lift and shift: containeriseer of migreer eerst naar een VM om te stabiliseren, en refactor daarna.
Anti-corruption layer/facade: isoleer verouderde contracten terwijl nieuwe services worden gebouwd.
Geef prioriteit aan domeinen met veel veranderingen en frictie om de bedrijfswaarde te maximaliseren en risico’s te verminderen.

Delivery en rollouts:

CI/CD met geautomatiseerde tests en gefaseerde omgevingen vermindert het aantal rollbacks. Voeg canary-analyse, error budgets en progressive delivery toe.
Blue-green minimaliseert downtime en vereenvoudigt rollback ten koste van dubbele capaciteit.
Traffic splitting: Cloud Run/App Engine ondersteunen procentuele routering over revisies/versies; test met echt verkeer met krappe SLO error budgets.

Load balancing en health:

Gebruik globale L7 voor HTTP en TCP-proxy voor niet-HTTP-protocollen; interne LB’s voor private services. Configureer session affinity alleen wanneer nodig en externaliseer de sessiestatus.
Health checks moeten de beschikbaarheid van de app weerspiegelen (bijv. de status van afhankelijkheden); een simpele 200 OK die een falende datastore verbergt, kan leiden tot verkeerde verkeerssturing.

Observability en governance:

Instrumenteer traces voor end-to-end latentietoewijzing over services heen; activeer het loggen van request-ID’s om logs en traces te correleren.
Exporteer logs/metrics/audit trails naar BigQuery of Cloud Storage voor retentie- en auditdoeleinden; beveilig de toegang via views en IAM.
Installeer voor VM-logs de Ops Agent; definieer retentie en sinks om kosten en compliance te beheren.

Beveiligde software supply chain:

Gebruik Artifact Registry met scanning; houd images minimaal. Optimaliseer Dockerfiles: geef de voorkeur aan ‘slim’ basisimages, installeer eerst dependencies en kopieer dan de broncode om de build cache te benutten.

Netwerken en segmentatie:

Dwing gelaagde toegang af via VPC-firewalltags en -regels om alleen verwachte flows toe te staan (bijv. web → API → DB). Weiger directe toegang van web → DB.

Capaciteit, Prestaties en Gespecialiseerde Compute

Ontwerpen voor variabele vraag:

GCE: schaal MIG’s automatisch op basis van voorlopende indicatoren (wachtrijlengte) om CPU-verzadiging voor te zijn; voeg request-rate limiting en tegendruk toe om downstreamsystemen te beschermen.
GKE: combineer HPA op basis van requests-per-seconde of aangepaste metrics met de cluster autoscaler; voorzie een kleine buffer om vertraging bij het schalen te voorkomen.
Serverless: pas concurrency en min instances aan om een balans te vinden tussen kosten en latency; gebruik een regionale implementatie voor latency dicht bij de gebruiker.

Veerkracht en testen:

Voer synthetische belasting uit om autoscaling en SLO’s te valideren; neem chaos testing op (bijv. willekeurige instances/pods beëindigen) om te garanderen dat het systeem beschikbaar blijft tijdens storingen en upgrades.
Configureer PodDisruptionBudgets en graceful termination hooks om verbindingen af te bouwen voordat een pod/VM wordt afgesloten.

Prestaties en opslagselectie:

High-throughput, low-latency time-series en clickstream-ingestie passen goed bij Bigtable; ontwerp brede rijen en op tijd gebaseerde sleutels (time-bucketed keys) om hotspots te vermijden.
Gebruik Dataproc voor Spark/Hadoop met minimale operationele wijzigingen; bepaal de juiste clustergrootte met autoscaling.
Gebruik Dataflow met autoscaling en windowing voor gecombineerde uurlijkse batch- en streamingtaken zonder bestaande code, om pipelines te uniformeren.

Gegevensverplaatsing en connectiviteit:

Overweeg Dedicated Interconnect voor duurzame, private replicatie met hoge bandbreedte (bijv. databases van meerdere terabytes); gebruik VLAN attachments en Cloud Router voor dynamische routing. Voor ad-hoc of lagere doorvoer volstaat Cloud VPN.

Stateful workloads:

Gebruik op GKE StatefulSets met persistent volumes (regionale PD’s voor HA) en geordende, stabiele identiteiten; overweeg Filestore voor NFS-semantiek.
Gebruik waar mogelijk beheerde databases (Cloud SQL, AlloyDB, Spanner) voor duurzaamheid en schaalbaarheid; plan read replica’s en failover.

Beveiliging en compliance:

Overweeg Confidential VMs om data-in-use te beschermen met beperkte prestatie-overhead; evalueer dit ten opzichte van de workload-vereisten.
Gebruik CMEK waar sleutels door de klant beheerd moeten worden; dwing isolatie per omgeving af en gebruik aparte projecten voor dev/test/prod.

Kostenbeheersing:

Gebruik committed use en sustained use discounts voor compute met een constante belasting; preemptible/Spot voor fouttolerante batchtaken; automatisch schalen naar nul op serverless.
Optimaliseer de grootte van resources met aanbevelingen van Monitoring; verwijder ongebruikte services en stel quota in voor op logs gebaseerde metrics om onverwachte kosten te voorkomen.

Probleemoplossing voor latency:

Gebruik Cloud Trace om de microservice te identificeren die de meeste latency toevoegt; optimaliseer het codepad, de caching of de database-indexen van die service. Valideer verbeteringen met A/B canaries.

Praktijkscenario

FerroLine Logistics is van plan een J2EE-monoliet te moderniseren die zendingen volgt en klanten notificeert. De workload is piekerig tijdens regionale cut-off tijden, moet een beschikbaarheidsdoelstelling van 99,9% halen, en het team wil portabiliteit met minimale operationele last, terwijl event-driven features worden geïntroduceerd.

Stabiliseer en observeer het huidige systeem

Rationale: Breng vóór de wijzigingen het basisgedrag en de fouten in kaart om het risico op een rollback te verminderen. Implementeer de Ops Agent op bestaande VM’s voor Cloud Logging en Monitoring, en instrumenteer distributed tracing in request-paden met hoge latency. Exporteer logs en metrics naar BigQuery voor historische analyse en SLO-rapportage.

Kies een gefaseerde landing zone en platformmix

Rationale: Breng controle en snelheid in evenwicht. Migreer de monoliet als een container naar Cloud Run jobs voor batchcomponenten en naar Cloud Run services voor stateless HTTP API’s, waarbij min instances worden ingesteld voor latency-kritieke endpoints. Behoud de stateful Oracle DB in eerste instantie op Compute Engine, met een regionale interne HTTP(S) LB ervoor voor interne API’s, en plan een toekomstige overstap naar AlloyDB.

Externaliseer sessie- en configuratiestatus

Rationale: Vermijd problemen met instance-lokale sessies en maak veilige autoscaling mogelijk. Sla secrets op in Secret Manager met per-service accounts voor least-privilege toegang. Verplaats sessiestatus naar Memorystore en gedeelde bestanden naar Cloud Storage. Dit voorkomt dat gebruikers verouderde gegevens zien tijdens piekbelasting.

Stel identiteits- en registry-controles in

Rationale: Dwing least privilege en herkomst (provenance) af. Sla images op in Artifact Registry met vulnerability scanning ingeschakeld. Wijs een uniek runtime service account toe aan elke Cloud Run-service en GKE-workload (voor componenten die later worden opgesplitst), en ken alleen de vereiste rollen toe (bijv. Pub/Sub Publisher).

Implementeer CI/CD met veilige uitrolstrategieën

Rationale: Verminder ongeplande rollbacks. Bouw een pipeline die unit/integratietests uitvoert en naar staging implementeert. Gebruik Cloud Run traffic splitting om 5-10% van het verkeer als canary naar nieuwe revisies te sturen en een snelle rollback mogelijk te maken. Gebruik voor de VM-gebaseerde DB-wijzigingen blue-green schema migratiepatronen om applicatie- en database-implementaties te ontkoppelen.

Splits eerst de domeinen met veel wijzigingen op

Rationale: Incrementele waarde met een lager risico. Pas een strangler pattern toe: snijd de levering van notificaties uit als een microservice op GKE om HPA te gebruiken voor pieken en Pub/Sub voor ontkoppeling. Behoud de resterende monoliet als een modulaire monoliet op Cloud Run terwijl de interfaces stabiliseren.

Ontwerp autoscaling en load shedding

Rationale: Verwerk pieken zonder cascade-storingen. Configureer Cloud Run concurrency en min instances per endpoint; stel Cloud Armor rate limits in op de globale HTTP(S) LB om te beschermen tegen niet-geauthenticeerde pieken. Schakel voor GKE-services HPA in op basis van custom metrics (requests per seconde) en voorzie een kleine node-buffer via de cluster autoscaler.

Bereid stateful services en datapadpaden voor

Rationale: Garandeer duurzaamheid en prestaties. Gebruik voor GKE-notificatie retries een Bigtable-tabel met een sleutel gebaseerd op klantregio en tijdsbuckets om de tijdelijke afleverstatus op te slaan bij hoge schrijfsnelheden. Gebruik voor private, consistente connectiviteit met on-prem ERP tijdens de overgang Dedicated Interconnect met Cloud Router.

Voer veerkracht- en prestatietests uit

Rationale: Valideer SLO’s vóór de volledige overstap. Voer synthetische, gerandomiseerde gebruikersstromen uit om de autoscaling-lagen te activeren. Injecteer chaos door willekeurige Cloud Run-instances te beëindigen (waardoor het control plane ze opnieuw aanmaakt) en GKE-pods te verwijderen om PodDisruptionBudgets en readiness gates te verifiëren. Gebruik Trace om de grootste bijdrager aan tail latency te identificeren en te verhelpen.

Werk met kosten- en compliance-kaders

Rationale: Duurzaam in productie draaien. Stel budgetten en alerts per service in, schakel CMEK in voor gevoelige opslag waar vereist, en gebruik committed use discounts voor GKE-node pools en AlloyDB zodra de steady-state bekend is. Configureer beleid voor logretentie en BigQuery-views om auditgegevens veilig te delen met interne auditors.

Deze gefaseerde aanpak levert onmiddellijke stabiliteit en observeerbaarheid, introduceert veilige implementatiepraktijken, splitst de monoliet geleidelijk op langs natuurlijke servicegrenzen, en stemt platformkeuzes af op doelstellingen voor controle, latency, portabiliteit, schaalbaarheid en kosten.

← Organisatieontwerp · Alle domeinen · Dataopslag →

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