Google PCA: Compute, Anwendungsplattformen und Workload-Architektur — Lernleitfaden

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

Teil des Google Professional Cloud Architect — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Dieser Themenbereich behandelt die Auswahl und das Design von Compute-Plattformen auf Google Cloud, das Paketieren und Bereitstellen von Anwendungen sowie den Betrieb von Workloads im Hinblick auf Zuverlässigkeit, Leistung, Sicherheit und Kosteneffizienz. Er umfasst virtuelle Maschinen, Kubernetes, serverlose Laufzeitumgebungen, Load Balancing, Rollout-Strategien, zustandsbehaftete und spezialisierte Compute-Ressourcen sowie Modernisierungsmuster, die technische Schulden reduzieren und gleichzeitig veränderten Anforderungen gerecht werden.

Compute Engine und VM-basierte Architekturen

Compute Engine bietet eine granulare Kontrolle über Betriebssysteme, Netzwerke und Maschinentypen. Wählen Sie Maschinenfamilien basierend auf den Eigenschaften des Workloads:

E2: kostenoptimiert für allgemeine Zwecke; gut für Entwicklung/Test, Anwendungen mit Lastspitzen.
N2/N2D: ausgewogenes Preis-Leistungs-Verhältnis für die meisten Produktions-Workloads; N2D verwendet AMD-CPUs mit starker Speicherbandbreite.
C2/C2D/C3: rechenoptimiert für CPU-gebundene Aufgaben (z. B. APIs mit hohen QPS, Batch-Verarbeitung).
M3: speicheroptimiert für große In-Memory-Datensätze (Caches, In-Memory-Analysen).
A3: GPU-optimiert (NVIDIA) für Training/Inferenz; GPUs können auch an andere Familien angehängt werden.
Confidential VMs (auf unterstützten CPUs) verschlüsseln Daten während der Nutzung mit minimalen Code-Änderungen.

Verwaltete Instanzgruppen (MIGs) sorgen für Elastizität und Ausfallsicherheit:

Verwenden Sie Instanzvorlagen (Instance Templates) für eine unveränderliche Konfiguration und MIGs, um horizontal über Zonen hinweg zu skalieren.
Autoscaling-Richtlinien: CPU-Auslastung, Load-Balancer-Auslastung, Cloud Monitoring-Messwerte oder Warteschlangentiefe über benutzerdefinierte Messwerte. Legen Sie eine minimale/maximale Anzahl an Replikaten und eine Cooldown-Phase fest, um instabiles Skalierungsverhalten bei Lastspitzen zu vermeiden.
Rollierende Updates und Canary-Deployments reduzieren das Risiko; halten Sie die Einstellungen für Surge (zusätzliche Instanzen) und Unavailable (nicht verfügbare Instanzen) bei zustandsbehafteten oder von Cold Starts stark betroffenen Diensten konservativ.

Load Balancing und Systemdiagnosen (Health Checks):

Der globale externe HTTP(S)-Load-Balancer beendet die TLS-Verschlüsselung, unterstützt URL-Mapping und ist das Standard-Frontend für Web-APIs; der interne HTTP(S)-LB wird für Ost-West-Traffic verwendet.
Systemdiagnosen müssen die Backends erreichen können. Eine häufige Fehlerursache sind blockierte Prüfanfragen (Probes), die zu ständigen Neustarts von Instanzen und Traffic-Verlusten führen. Erlauben Sie den Zugriff von den Quellbereichen der Systemdiagnose auf die Backend-Ports mithilfe von VPC-Firewallregeln und Ziel-Tags (Target Tags).

Beispiel, um HTTP-Systemdiagnosen für eine MIG zu erlauben:

gcloud compute firewall-rules create allow-lb-health-checks –network=my-net –direction=INGRESS –action=ALLOW –rules=tcp:80 –source-ranges=35.191.0.0/16,130.211.0.0/22 –target-tags=web-backend

Überlegungen zum Lebenszyklus von VMs:

Verwenden Sie Start-Skripts oder Image-Metadaten für das Bootstrapping; speichern Sie die Laufzeitkonfiguration in Secret Manager und nicht fest integriert in Images.
Fügen Sie bei Preemptible/Spot VMs ein Shutdown-Skript hinzu, um bei einer Beendigungsbenachrichtigung die Arbeit ordnungsgemäß abzuschließen.
Patchen Sie über neue Images und rollierenden Austausch, um Konfigurationsdrift zu vermeiden.
Die Größenänderung von Persistent Disks erfolgt online: Erhöhen Sie die Festplattengröße und vergrößern Sie anschließend das Dateisystem (z. B. mit resize2fs bei ext4) mit minimaler Ausfallzeit.

Beispiel für die Größenänderung eines PD:

gcloud compute disks resize my-disk –size=500GB –zone=us-central1-a
sudo resize2fs /dev/sdb

Sichere Identität und Beobachtbarkeit (Observability):

Weisen Sie Instanzen Servicekonten mit den geringsten Berechtigungen zu; betten Sie keine statischen Anmeldedaten ein.
Installieren Sie den Ops Agent für Cloud Logging und Cloud Monitoring. Verwenden Sie Cloud Trace und Cloud Profiler, um Tail-Latenz und Hotspots zu reduzieren.
Exportieren Sie Audit- und Messdaten zur langfristigen Aufbewahrung und Analyse nach BigQuery oder Cloud Storage.

Batch-Verarbeitung und spezialisierte Compute-Ressourcen:

Verwenden Sie Cloud Batch oder MIGs mit Preemptible VMs für eine fehlertolerante Batch-Verarbeitung, um Kosten zu senken; implementieren Sie Checkpointing.
Hängen Sie GPUs/TPUs an, wo ML-Beschleunigung erforderlich ist. Verwenden Sie dedizierte Knotenpools oder Sole-Tenant-Knoten, um Compliance- oder Isolationsanforderungen zu erfüllen.
Confidential VMs schützen sensible Daten im Arbeitsspeicher; messen Sie den Overhead im Verhältnis zu den Anforderungen.

Überlegungen zum Zustand (State):

Halten Sie Anwendungsinstanzen zustandslos; lagern Sie Sitzungen in einen gemeinsam genutzten Speicher aus (z. B. Memorystore, Cloud SQL), um für den Benutzer sichtbare Anomalien bei der Skalierung zu vermeiden.
Verwenden Sie für an eine VM gebundenen Zustand regionale Persistent Disks oder replizierte Datenbanken; testen Sie die Failover-Pfade.

Kubernetes und Container-Plattformen (GKE)

GKE bietet eine verwaltete Steuerungsebene mit flexiblen Worker-Knoten-Pools:

Regionale Cluster replizieren die Steuerungsebene und die Knoten über Zonen hinweg, um eine hohe Verfügbarkeit zu gewährleisten; zonale Cluster konzentrieren Ressourcen für geringere Kosten und Latenzempfindlichkeit.
Verwenden Sie mehrere Knoten-Pools, um Workloads zu segmentieren (z. B. Allzweck, GPU, hoher Arbeitsspeicher, Spot). Wenden Sie Taints/Tolerations und Affinity/Anti-Affinity an, um die Platzierung zu steuern und Noisy-Neighbor-Effekte zu reduzieren.
Autoscaling-Ebenen: Der Cluster Autoscaler fügt Knoten hinzu oder entfernt sie; der Horizontal Pod Autoscaler (HPA) skaliert Replikate basierend auf CPU- oder benutzerdefinierten Metriken; der Vertical Pod Autoscaler (VPA) passt die Größe der Anfragen an. Kombinieren Sie HPA mit dem Cluster Autoscaler für Elastizität.

Workload-Scheduling und Services:

Passen Sie die CPU-/Arbeitsspeicher-Requests/Limits richtig an, um das Risiko von Evictions zu minimieren und die Effizienz des Bin-Packing zu maximieren.
Verwenden Sie PodDisruptionBudgets, um die Verfügbarkeit während Upgrades aufrechtzuerhalten.
Service-Typen: ClusterIP (innerhalb des Clusters), NodePort/LoadBalancer (Nord-Süd) und Ingress für HTTP(S)-Routing mit dem globalen LB. Für Canary-Deployments leiten Sie den Traffic über separate Service-/Ingress-Backends oder ein Service Mesh.

Upgrades und Resilienz:

Verwenden Sie Surge-Upgrades und maxUnavailable, um die Wechselrate (Churn) zu steuern; pinnen Sie kritische Workloads an mehrere Zonen und Pools.
Legen Sie Wartungsfenster/-ausschlüsse für geschäftskritische Zeiträume fest.
Validieren Sie mit einer Vorproduktionsumgebung und Canary-Knoten-Pools vor einem breiten Rollout.

Images und Sicherheit:

Speichern Sie Container-Images in Artifact Registry; aktivieren Sie Schwachstellenscans und richten Sie Binary Authorization oder Attestierungen für die Herkunftssicherung ein.
Verwenden Sie Workload Identity, um GSA auf KSA abzubilden, für einen anmeldeinformationslosen Zugriff mit den geringsten Rechten (Least Privilege) auf Google-APIs.
Rufen Sie die Laufzeitkonfiguration über den CSI-Treiber aus dem Secret Manager ab; vermeiden Sie Kubernetes Secrets für hochsensible Werte, es sei denn, sie sind mit CMEK verschlüsselt und RBAC ist streng konfiguriert.

Rollouts und Rollback:

Bevorzugen Sie Rolling Updates von Deployments mit kleinen Schritten und Health Probes; für Systeme mit geringer Toleranz verwenden Sie Blue-Green über zwei Deployments hinter einem einzigen Service und schalten die Labels/Selektoren um.
Definieren Sie immer Readiness- und Liveness-Probes; falsch konfigurierte Probes verursachen kaskadierende Neustarts oder Blackholes während Rollouts.

Serverless- und ereignisgesteuerte Plattformen

Google Cloud Serverless abstrahiert die Infrastruktur und bietet gleichzeitig starke Kontrollen über Skalierung, Sicherheit und Kosten:

Cloud Run: Container-nativ, durch HTTP-Anfragen oder Eventarc ausgelöst. Skaliert auf null; konfigurierbare Gleichzeitigkeit; Traffic-Aufteilung nach Revision für Canary-Deployments und Rollbacks. Legen Sie eine Mindestanzahl von Instanzen fest, um Kaltstarts für latenzempfindliche Endpunkte zu reduzieren. Integrieren Sie es über den Serverless VPC Access in eine VPC für privaten Egress-Traffic.
App Engine: Ein Opinionated PaaS. Standard bietet schnelle Skalierung und sprachspezifische Gleichzeitigkeitsbeschränkungen pro Anfrage; Flexible führt Container auf VMs mit mehr Kontrolle aus. Vermeiden Sie instanzlokalen Sitzungsstatus; lagern Sie ihn in einen gemeinsam genutzten Speicher aus, um veraltete oder doppelte Benutzererfahrungen unter Last zu vermeiden.
Cloud Functions: Granularität auf Funktionsebene für ereignisgesteuerte Logik. Verwenden Sie Pub/Sub-, Cloud Storage- oder Eventarc-Trigger für leichtgewichtige Mikro-Operationen; halten Sie Funktionen idempotent und zustandslos. Für kombinierte Batch-/Stream-Pipelines ohne vorhandenen Code bietet Dataflow eine vereinheitlichte Verarbeitung mit Autoscaling.

Abwägungen bei der Plattformauswahl:

Operative Kontrolle: Compute Engine > GKE > Cloud Run/App Engine > Cloud Functions.
Portabilität: Containerbasiert (GKE/Cloud Run/App Engine Flex) > VM-Images > Functions und App Engine Standard.
Latenz: Cloud Run mit Mindestanzahl von Instanzen oder GKE für geringe Tail-Latenz; vermeiden Sie Kaltstarts für interaktive Workloads.
Skalierung: Cloud Functions/Run skalieren am schnellsten; GKE HPA plus Cluster Autoscaler; MIGs erfordern Aufwärmphasen und Health Checks.
Kosten: Serverless Pay-per-Use für Workloads mit Lastspitzen oder geringer Grundlast; GKE/VMs mit Committed Use Discounts für Dienste mit konstanter, hoher Durchsatzrate; Preemptible/Spot für Batch-Verarbeitung.

Identität und Konfiguration:

Jeder Dienst sollte ein dediziertes Service-Konto mit den geringsten Rechten (Least Privilege) verwenden. Legen Sie für Cloud Run und Functions das Laufzeit-Service-Konto explizit fest.
Speichern Sie Secrets im Secret Manager und binden Sie den Zugriff über IAM; injizieren Sie sie über Umgebungsvariablen oder Volume Mounts.

Architekturmuster, Bereitstellung und Betrieb

Dekomposition und Grenzen von Services:

Monolith: einfachste Bereitstellung und Transaktionen, schränkt aber unabhängige Skalierung und Blast-Radius-Kontrolle ein; kann Performance-Probleme tief in Aufrufketten verschleiern.
Modularer Monolith: klare interne Module, gemeinsamer Prozess; ein guter Zwischenschritt – erzwingt Schnittstellen ohne die Nachteile der Verteilung.
Microservices: unabhängige Bereitstellbarkeit und Skalierung; führt Netzwerklatenz, verteilte Transaktionen und Konsistenzherausforderungen ein. Definieren Sie klare Bounded Contexts und Datenverantwortlichkeiten; vermeiden Sie gemeinsam genutzte Datenbanken, um Kopplung zu verhindern.

Modernisierungsmuster:

Strangler-Fig-Muster: Leiten Sie schrittweise einen Teil des Traffics an neue Komponenten weiter und nehmen Sie Legacy-Endpunkte nach und nach außer Betrieb.
Lift and Shift: Zuerst containerisieren oder per VM migrieren, um zu stabilisieren, dann refaktorisieren.
Anti-Corruption Layer/Fassade: Isolieren Sie Legacy-Verträge, während neue Services erstellt werden.
Priorisieren Sie zuerst Domänen mit hoher Änderungsrate und hoher Reibung, um den Geschäftswert zu maximieren und das Risiko zu reduzieren.

Bereitstellung und Rollouts:

CI/CD mit automatisierten Tests und gestaffelten Umgebungen reduziert Rollbacks. Fügen Sie Canary-Analysen, Fehlerbudgets und progressive Bereitstellung hinzu.
Blue-Green minimiert Ausfallzeiten und vereinfacht Rollbacks auf Kosten doppelter Kapazität.
Traffic Splitting: Cloud Run/App Engine unterstützen prozentbasiertes Routing über Revisionen/Versionen; testen Sie unter realem Traffic mit engen SLO-Fehlerbudgets.

Load Balancing und Zustand:

Verwenden Sie globales L7 für HTTP und TCP-Proxy für Nicht-HTTP-Protokolle; interne LBs für private Services. Konfigurieren Sie Session-Affinität nur bei Bedarf und externalisieren Sie den Session-Zustand.
Health Checks sollten die Verfügbarkeit der App widerspiegeln (z. B. den Zustand von Abhängigkeiten); ein einfaches 200 OK, das einen Datastore-Ausfall verschleiert, kann zu einer fehlerhaften Traffic-Steuerung führen.

Observability und Governance:

Instrumentieren Sie Traces für die End-to-End-Latenzzuordnung über Services hinweg; aktivieren Sie die Protokollierung von Request-IDs, um Logs und Traces zu korrelieren.
Exportieren Sie Logs/Metriken/Audit-Trails nach BigQuery oder Cloud Storage für Aufbewahrungs- und Audit-Anforderungen; sichern Sie den Zugriff über Views und IAM.
Installieren Sie für VM-Logs den Ops Agent; definieren Sie Aufbewahrungsfristen und Sinks, um Kosten und Compliance zu steuern.

Sichere Software-Lieferkette:

Verwenden Sie Artifact Registry mit Scanning; halten Sie Images minimal. Optimieren Sie Dockerfiles: Bevorzugen Sie Slim-Basis-Images, installieren Sie zuerst Abhängigkeiten und kopieren Sie dann den Quellcode, um den Build-Cache zu nutzen.

Netzwerk und Segmentierung:

Erzwingen Sie einen mehrstufigen Zugriff über VPC-Firewall-Tags und -Regeln, um nur erwartete Datenflüsse zu erlauben (z. B. Web → API → DB). Verweigern Sie den direkten Zugriff von Web → DB.

Kapazität, Leistung und spezialisierte Rechenleistung

Design für variable Last:

GCE: MIGs auf Basis von Frühindikatoren (z. B. Warteschlangenlänge) automatisch skalieren, um einer CPU-Sättigung zuvorzukommen; Ratenbegrenzung für Anfragen und Backpressure hinzufügen, um nachgelagerte Systeme zu schützen.
GKE: HPA auf Basis von Anfragen pro Sekunde oder benutzerdefinierten Metriken mit dem Cluster Autoscaler kombinieren; einen kleinen Puffer bereitstellen, um Skalierungsverzögerungen zu vermeiden.
Serverless: Concurrency und Mindestinstanzen anpassen, um Kosten und Latenz auszugleichen; regionale Bereitstellung für benutzernahe Latenz nutzen.

Resilienz und Tests:

Synthetische Last ausführen, um Autoscaling und SLOs zu validieren; Chaos-Testing (z. B. zufälliges Beenden von Instanzen/Pods) einbeziehen, um sicherzustellen, dass das System die Verfügbarkeit bei Ausfällen und Upgrades aufrechterhält.
PodDisruptionBudgets und Hooks für eine ordnungsgemäße Beendigung (graceful termination) konfigurieren, um Verbindungen vor dem Herunterfahren von Pods/VMs zu „drainen“.

Leistung und Speicherauswahl:

Die Ingestion von Zeitreihen- und Clickstream-Daten mit hohem Durchsatz und niedriger Latenz passt gut zu Bigtable; entwerfen Sie breite Zeilen und nach Zeitfenstern gruppierte Schlüssel (time-bucketed keys), um Hotspots zu vermeiden.
Für Spark/Hadoop mit minimalen betrieblichen Änderungen Dataproc verwenden; Cluster mit Autoscaling richtig dimensionieren.
Für kombinierte stündliche Batch- und Streaming-Verarbeitung ohne vorhandenen Code Dataflow mit Autoscaling und Windowing verwenden, um Pipelines zu vereinheitlichen.

Datenverschiebung und Konnektivität:

Für dauerhafte, private Replikation mit hoher Bandbreite (z. B. Multi-Terabyte-Datenbanken) Dedicated Interconnect in Betracht ziehen; VLAN-Anhänge und Cloud Router für dynamisches Routing verwenden. Für Ad-hoc-Anforderungen oder geringeren Durchsatz genügt Cloud VPN.

Zustandsbehaftete Workloads:

Auf GKE StatefulSets mit Persistent Volumes (regionale PDs für HA) und geordneten, stabilen Identitäten verwenden; Filestore für NFS-Semantik in Betracht ziehen.
Verwaltete Datenbanken (Cloud SQL, AlloyDB, Spanner) für Langlebigkeit und Skalierung verwenden, wo immer möglich; Lesereplikas und Failover planen.

Sicherheit und Compliance:

Confidential VMs in Betracht ziehen, um Daten während der Verarbeitung (Data-in-Use) mit begrenztem Performance-Overhead zu schützen; gegen die Workload-Anforderungen abwägen.
CMEK verwenden, wenn Schlüssel vom Kunden kontrolliert werden müssen; Isolierung pro Umgebung durchsetzen und separate Projekte für Dev/Test/Prod verwenden.

Kostenkontrollen:

Rabatte für zugesicherte Nutzung (committed use) und für kontinuierliche Nutzung (sustained use) für Rechenleistung im stabilen Zustand nutzen; Preemptible/Spot für fehlertolerante Batch-Jobs; Autoscaling bis auf null bei Serverless.
Ressourcen mit Empfehlungen aus Monitoring richtig dimensionieren; ungenutzte Dienste entfernen und Kontingente für logbasierte Metriken festlegen, um Kostenüberraschungen zu vermeiden.

Fehlerbehebung bei Latenz:

Cloud Trace verwenden, um den Microservice zu identifizieren, der die meiste Latenz verursacht; den Codepfad, das Caching oder die Datenbankindizes dieses Dienstes optimieren. Verbesserungen mit A/B-Canaries validieren.

Praktisches Problemszenario

FerroLine Logistics plant die Modernisierung eines J2EE-Monolithen, der die Sendungsverfolgung und Kundenbenachrichtigungen abwickelt. Die Workload ist während regionaler Annahmeschlüsse stoßweise (bursty), muss ein Verfügbarkeitsziel von 99,9 % erreichen, und das Team wünscht sich Portabilität mit minimalem Betriebsaufwand bei gleichzeitiger Einführung ereignisgesteuerter Funktionen.

Stabilisierung und Beobachtung des aktuellen Systems

Begründung: Vor Änderungen das Grundverhalten und Fehler als Baseline erfassen, um das Rollback-Risiko zu reduzieren. Den Ops Agent auf bestehenden VMs für Cloud Logging und Monitoring bereitstellen und Distributed Tracing in Anfragepfaden mit hoher Latenz instrumentieren. Logs und Metriken zur historischen Analyse und für das SLO-Reporting nach BigQuery exportieren.

Auswahl einer gestuften Landing Zone und eines Plattform-Mix

Begründung: Eine Balance zwischen Kontrolle und Geschwindigkeit finden. Den Monolithen als Container zu Cloud Run-Jobs für Batch-Komponenten und Cloud Run-Diensten für zustandslose HTTP-APIs migrieren, wobei für latenzkritische Endpunkte Mindestinstanzen festgelegt werden. Die zustandsbehaftete Oracle-DB zunächst auf Compute Engine belassen, die von einem regionalen internen HTTP(S) LB für interne APIs bedient wird, und einen zukünftigen Wechsel zu AlloyDB planen.

Externalisierung des Sitzungs- und Konfigurationszustands

Begründung: Probleme mit instanzlokalen Sitzungen vermeiden und sicheres Autoscaling ermöglichen. Geheimnisse im Secret Manager mit dienstspezifischen Service Accounts für den Zugriff nach dem Prinzip der geringsten Rechte (Least Privilege) speichern. Den Sitzungszustand nach Memorystore und gemeinsam genutzte Dateien nach Cloud Storage verschieben. Dies verhindert, dass Benutzer unter Spitzenlast veraltete Daten sehen.

Etablierung von Identitäts- und Registry-Kontrollen

Begründung: Das Prinzip der geringsten Rechte und die Nachverfolgbarkeit der Herkunft (Provenance) durchsetzen. Images in Artifact Registry mit aktivierten Schwachstellenscans speichern. Jedem Cloud Run-Dienst und jeder GKE-Workload (für später zerlegte Komponenten) ein eindeutiges Runtime Service Account zuweisen und nur die erforderlichen Rollen (z. B. Pub/Sub Publisher) gewähren.

Implementierung von CI/CD mit sicheren Rollout-Strategien

Begründung: Ungeplante Rollbacks reduzieren. Eine Pipeline erstellen, die Unit-/Integrationstests ausführt und in der Staging-Umgebung bereitstellt. Cloud Run Traffic Splitting verwenden, um 5–10 % des Traffics als Canary auf neue Revisionen zu leiten und ein schnelles Rollback zu ermöglichen. Für die VM-basierten DB-Änderungen Blue-Green-Schemamigrationsmuster verwenden, um Anwendungs- und Datenbank-Deployments zu entkoppeln.

Zuerst Domänen mit hoher Änderungsrate zerlegen

Begründung: Inkrementeller Wert bei geringerem Risiko. Ein Strangler-Pattern anwenden: Die Zustellung von Benachrichtigungen als Microservice auf GKE ausgliedern, um HPA für Lastspitzen und Pub/Sub zur Entkopplung zu nutzen. Den verbleibenden Monolithen als modularen Monolithen auf Cloud Run belassen, während sich die Schnittstellen stabilisieren.

Design von Autoscaling und Load Shedding

Begründung: Lastspitzen ohne kaskadierende Ausfälle bewältigen. Cloud Run Concurrency und Mindestinstanzen pro Endpunkt konfigurieren; Cloud Armor-Ratenbegrenzungen am globalen HTTP(S) LB festlegen, um vor unauthentifizierten Lastspitzen zu schützen. Für GKE-Dienste HPA für benutzerdefinierte Metriken (Anfragen pro Sekunde) aktivieren und einen kleinen Knotenpuffer über den Cluster Autoscaler bereitstellen.

Vorbereitung von zustandsbehafteten Diensten und Datenpfaden

Begründung: Langlebigkeit und Leistung sicherstellen. Für Wiederholungsversuche bei Benachrichtigungen in GKE eine Bigtable-Tabelle verwenden, die nach Kunde-Region und Zeitfenstern geschlüsselt ist, um den transienten Zustellungsstatus bei hohen Schreibraten zu speichern. Für eine private, konsistente Konnektivität zum On-Prem-ERP während der Umstellung Dedicated Interconnect mit Cloud Router verwenden.

Durchführung von Resilienz- und Leistungstests

Begründung: SLOs vor der vollständigen Umstellung validieren. Synthetische, randomisierte Benutzerabläufe ausführen, um die Autoscaling-Schichten auszulösen. Chaos injizieren, indem zufällige Cloud Run-Instanzen beendet (damit die Steuerungsebene sie neu erstellt) und GKE-Pods entfernt werden, um PodDisruptionBudgets und Readiness Gates zu überprüfen. Trace verwenden, um den größten Beitrag zur Tail-Latenz zu identifizieren und zu beheben.

Betrieb mit Kosten- und Compliance-Leitplanken

Begründung: Nachhaltiger Betrieb in der Produktion. Budgets und Warnungen pro Dienst einrichten, CMEK für sensible Speicher bei Bedarf aktivieren und Rabatte für zugesicherte Nutzung (committed use discounts) für GKE-Knotenpools und AlloyDB nutzen, sobald der stabile Zustand (Steady-State) bekannt ist. Aufbewahrungsrichtlinien für Logs und BigQuery-Views konfigurieren, um Audit-Daten sicher mit internen Prüfern zu teilen.

Dieser phasenweise Ansatz liefert sofortige Stabilität und Beobachtbarkeit, führt sichere Bereitstellungspraktiken ein, zerlegt den Monolithen schrittweise entlang natürlicher Service-Grenzen und stimmt die Plattformauswahl auf die Ziele in Bezug auf Kontrolle, Latenz, Portabilität, Skalierung und Kosten ab.

← Organisationsdesign · Alle Domänen · Datenspeicherung →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →