Google PCD: Cloud-native Anwendungsarchitektur und Service-Auswahl — Lernleitfaden

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

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

Überblick

Die Cloud-native Anwendungsarchitektur auf Google Cloud konzentriert sich auf die Erstellung zustandsloser, resilienter Dienste, die horizontal skalieren, den Betriebsaufwand minimieren und gegebenenfalls Managed Services nutzen. Eine effektive Service-Auswahl erfordert das Verständnis der Abwägungen zwischen Kontrolle, Portabilität, Leistung, Kosten und Betriebsverantwortung. Dieser Abschnitt stellt Prinzipien und Muster vor, die Ihnen helfen, Anwendungen für globale Nutzer mit vorhersehbarer Zuverlässigkeit zu entwerfen, zu modernisieren und zu betreiben.

Cloud-native Prinzipien und Architekturentscheidungen

• Twelve-Factor-Prinzipien und zustandsloses Design

  • Codebasis, Abhängigkeiten und Build-Release-Run: Schreiben Sie exakte Abhängigkeiten fest, erstellen Sie unveränderliche Artefakte und trennen Sie den Build vom Release. Container-Images und Cloud Build-Pipelines erzwingen reproduzierbare Releases.
  • Konfiguration in der Umgebung: Externalisieren Sie die Konfiguration mithilfe von Umgebungsvariablen, Secret Manager, Kubernetes Secrets oder Instanzmetadaten für Compute Engine. Betten Sie keine Anmeldedaten oder bereitstellungsspezifischen Einstellungen in Images ein. Verwenden Sie für verwaltete Instanzgruppen von Compute Engine die Metadaten der Instanzvorlage für bereitstellungsspezifische Werte.
  • Unterstützende Dienste: Behandeln Sie Datenbanken, Warteschlangen und Caches als angehängte Ressourcen. Bevorzugen Sie Managed Services (Cloud SQL, Cloud Spanner, Firestore, Memorystore, Pub/Sub), um den Betriebsaufwand zu reduzieren.
  • Zustandslose Prozesse: Skalieren Sie durch Hinzufügen von Instanzen; speichern Sie Sitzungszustände extern (Memorystore for Redis, Firestore oder Spanner). Schreiben Sie Logs nach stdout/stderr oder in Log-Dateien, die vom Cloud Logging-Agenten erfasst werden.
  • Verwerfbarkeit: Schnelles Starten und Herunterfahren ermöglicht schnelle Skalierung und Rolling Updates. Behandeln Sie SIGTERM für ein ordnungsgemäßes Herunterfahren.
  • Logs als Ereignisströme: Geben Sie strukturierte Logs aus; verwenden Sie Cloud Logging für die Ingestion und Cloud Monitoring für Benachrichtigungen.

• Architektonische Abwägungen

  • Monolith
    • Vorteile: Vereinfachte Entwicklung/Tests, weniger Netzwerkgrenzen, einzelne Bereitstellungseinheit.
    • Nachteile: Langsamere unabhängige Auslieferung, Skalierungsbeschränkungen, enge Kopplung zwischen Domänen.
    • Fehlermodi: Ein einzelner Hot Path kann gemeinsame Ressourcen verbrauchen; Regressionen beeinträchtigen alle Funktionen.
  • Modularer Monolith
    • Vorteile: Klare interne Modulgrenzen, Refactoring-Pfad zu Services, einzelnes Deployable.
    • Nachteile: Immer noch durch monolithische Bereitstellung und Datenbank eingeschränkt.
    • Einsatz für Teams, die Domänengrenzen ausreifen, bevor sie Services extrahieren.
  • Microservices
    • Vorteile: Unabhängige Bereitstellbarkeit, gezielte Skalierung, Teamautonomie, Fehlerisolierung mit geeigneten Bulkheads (Schottwänden).
    • Nachteile: Komplexität verteilter Systeme, Konsistenz, Observability und Betriebs-Overhead.
    • Fehlermodi: Kaskadierende Ausfälle durch synchrone Aufrufe; Schema-Drift; geschwätzige Netzwerke.
  • Ereignisgesteuert
    • Vorteile: Lose Kopplung, asynchrone Resilienz, natürliche Pufferung, Auditierbarkeit über Logs/Streams.
    • Nachteile: Komplexität beim Debugging, Eventual Consistency, Reihenfolge und Exactly-Once-Semantik sind schwierig umzusetzen.
    • Pub/Sub bietet At-least-once-Zustellung; entwerfen Sie idempotente Consumer.
  • Serverless (Cloud Run, Cloud Functions, App Engine)
    • Vorteile: Minimaler Betriebsaufwand, Scale-to-Zero, Autoscaling pro Anfrage, integrierte Sicherheit und Telemetrie.
    • Nachteile: Begrenzungen bei Ausführungszeit und Gleichzeitigkeit, Kaltstarts, plattformspezifische Einschränkungen.
    • Einsatz für lastspitzenartige Workloads, Mobile-/Web-Backends und Ereignisverarbeitung.

Kommunikationsmuster und Service-Auswahl

• Synchrone vs. asynchrone Aufrufe

  • Synchron
    • Verwendung für Request/Response-APIs, die sofortige Ergebnisse erfordern.
    • Protokolle: gRPC (HTTP/2, Streaming, kompaktes Protobuf; exzellent für mobile Bandbreite und starke Contracts), HTTP/JSON (breite Kompatibilität; einfacheres Debugging).
    • Risiken: Enge Kopplung und Latenzverstärkung; verwenden Sie Timeouts, Wiederholungsversuche mit Jitter und Circuit Breaker.
  • Asynchron
    • Verwenden Sie Pub/Sub oder Cloud Tasks, wenn Arbeit aufgeschoben oder gebündelt werden kann.
    • Vorteile: Glättet Lastspitzen, isoliert Ausfälle, verbessert die vom Benutzer wahrgenommene Latenz durch spätere Fertigstellung.
    • Risiken: Erfordert Idempotenz und kompensierende Aktionen; Sichtbarkeit der laufenden Arbeit muss implementiert werden.

• Kriterien für die Service-Auswahl auf Google Cloud

  • Kontrolle und Portabilität
    • Compute Engine: Volle VM-Kontrolle und benutzerdefinierte Images; höherer Betriebsaufwand.
    • GKE: Portable Container und Service-Mesh-Optionen; robustes Autoscaling; geteilte Verantwortung.
    • Cloud Run: Hohe Portabilität für Container bei minimalem Betriebsaufwand; Scale-to-Zero; anfrageorientiert.
    • App Engine: Meinungsstarkes PaaS mit integriertem Routing und Skalierung; schnellster Weg für bestimmte Sprachen.
  • Skalierung und Latenz
    • Globales HTTP(S) Load Balancing mit Cloud CDN für Edge-Beschleunigung.
    • Datenspeicher:
      • Cloud Spanner: Globale Konsistenz, horizontale Skalierung, multiregionale Verfügbarkeit von 99,999 %.
      • Cloud SQL: Verwaltete relationale DB, regional, Lesereplikate einschließlich regionsübergreifender.
      • Firestore: Dokumenten-DB mit globaler Verfügbarkeit in Multi-Region, starke Konsistenz für einzelne Dokumente.
      • Cloud Bigtable: Niedrige Latenz, massive Skalierung für Wide-Column-Anwendungsfälle.
      • Memorystore: Cache mit niedriger Latenz für Hot Paths und Sitzungen.
  • Betriebsverantwortung
    • Bevorzugen Sie Managed Services für zentrale Belange (Verfügbarkeit, Patching, Backups, Upgrades).
    • Selbstverwaltung bietet Flexibilität, erhöht aber den Aufwand und die Angriffsfläche für Fehler (z. B. selbst gehostetes Kafka vs. Pub/Sub).
  • Datenbewegung und Integration
    • Verwenden Sie VPC-native Konnektivität, Private Service Connect und internes HTTP(S) Load Balancing für privaten Zugriff mit niedriger Latenz.
    • Service Discovery: Kubernetes-Service-Namen innerhalb eines Clusters; internes DNS von Compute Engine für VMs.

Beispiel für einen Kubernetes Service (Namenserkennung im Cluster): apiVersion: v1 kind: Service metadata: name: image-resize spec: selector: app: image-resize ports:

• port: 80 targetPort: 8080 type: ClusterIP

Globale und betriebliche Überlegungen

• Multi-regionale Muster für globale Benutzer

  • Globales Frontend: Globales externes HTTP(S)-Load-Balancing mit Anycast-IP und Cloud CDN für statische Inhalte verwenden. Negatives Caching und Validierung konfigurieren, um die Last auf den Ursprungsservern zu reduzieren.
  • Datenebene:
    • Für eine Datenbankverfügbarkeit von 99,999 % (fünf Neunen) und minimierte globale Leselatenz eine multi-regionale Cloud Spanner-Instanz (z. B. nam-asia-eur1) verwenden und ausreichend Knoten für Rechenleistung und Quorum bereitstellen (mindestens drei Knoten für die Produktion).
    • Bei leseintensiven Mustern ohne strikte globale Konsistenz eine regionale primäre Instanz mit regionsübergreifenden Lesereplikas in Betracht ziehen; eine höhere Schreiblatenz zwischen den Kontinenten akzeptieren.
  • Anwendungsebene:
    • Zustandslose Dienste in mehreren Regionen mit Autoscaling (GKE oder Cloud Run) bereitstellen. Backend-Dienste und Netzwerk-Endpunktgruppen pro Region verwenden.
    • Routing nach Latenz unter Berücksichtigung von Datenresidenz- und Compliance-Anforderungen.
  • Caches: Memorystore oder Edge-Caches nahe bei den Nutzern platzieren, um Lesetraffic abzufangen und die Ursprungsserver zu schützen.

• Verwaltet vs. selbstverwaltet

  • Cloud Monitoring für Metriken, Cloud Logging für Logs, Cloud Trace/Profiler für Latenz- und CPU-/Speicher-Hotspots verwenden. Alarmierungsrichtlinien für SLO-Burn-Rates und Uptime-Checks für die externe Verfügbarkeit erstellen.
  • Wenn eine bestehende Observability-Plattform das „System of Record“ bleiben muss, zuerst mit Cloud Logging für Warnungen mit geringer Latenz erfassen und dann über Senken (Sinks) an die externe Plattform exportieren.

• Modernisierung und inkrementelle Migration

  • Strangler-Pattern: Dem Monolithen ein Gateway vorschalten; bestimmte Endpunkte an neue Dienste weiterleiten. Funktionalitäten schrittweise ersetzen.
  • Branch by Abstraction: Eine Schnittstelle um eine Abhängigkeit herum einführen und die Implementierung dahinter austauschen (z. B. Datenbank oder Speicher).
  • Anti-Corruption-Layer: Zwischen veralteten Datenmodellen und neuen Bounded Contexts übersetzen.
  • Datenmigration: Dual Writes mit Verifizierung oder Event Sourcing zum Auffüllen (Backfill) verwenden; Umstellungen (Cutovers) mit Backpressure-Kontrollen planen.
  • Phasenweise Bereitstellung: Features in Etappen ersetzen, um das Geschäftsrisiko zu minimieren; SLOs kontinuierlich messen.

• Design-Reviews und Abwägungen

  • Sicherheit: Bedrohungsmodell, IAM-Prinzip der geringsten Rechte (Least Privilege), Servicekonten anstelle von eingebetteten Schlüsseln (Application Default Credentials auf GCE/GKE/Cloud Run verwenden), CMEK, wo erforderlich, private Konnektivität, WAF und Ratenbegrenzungen, Schwachstellen- und Websicherheits-Scans.
  • Zuverlässigkeit: SLOs und Fehlerbudgets definieren, multi-regionale Failover-Pläne, Kapazitätsreserven (Headroom), Chaos-Drills, Abhängigkeitskarten.
  • Leistung: Analyse der Tail-Latenz, Lasttests am Edge und am Ursprungsserver, Wiederverwendung von Verbindungen (HTTP/2, gRPC), Komprimierung, Caching-Strategie.
  • Kosten: Ressourcen richtig dimensionieren (Right-Sizing), Autoscaling-Richtlinien, Rabatte für zugesicherte Nutzung (Committed Use Discounts), Skalierung auf Null für stoßweise Workloads, Egress- und CDN-Offload.
  • Betrieb: Runbooks, Rollbacks, progressive Bereitstellung (Canary, Blue/Green), Policy as Code, Backups und DR-Tests, Integration der Reaktion auf Vorfälle (Incident Response).

Praktisches Problemszenario

Nimbus Retail startet eine globale E-Commerce-Plattform mit personalisierten Bildern, strengen Latenzzielen von unter 200 ms bei p95 weltweit und einer Verfügbarkeitsanforderung von 99,999 % für die Bestelldatenbank. Außerdem müssen sie ihr bestehendes SIEM beibehalten und gleichzeitig die Geschwindigkeit der Alarmierung verbessern.

1. Eine globale, hochverfügbare Datenbank mit Cloud Spanner einrichten

• Aktion: Eine multi-regionale Spanner-Instanz in nam-asia-eur1 mit mindestens drei Knoten erstellen und Tabellen für eine bessere Lokalität in geeignete verschachtelte (interleaved) Schemata aufteilen.
• Begründung: Multi-regionales Spanner bietet eine Verfügbarkeit von fünf Neunen und eine niedrige Leselatenz durch Replikate auf drei Kontinenten; drei oder mehr Knoten gewährleisten ausreichend Rechen- und Replikat-Quorum-Kapazität.

Beispiel:

undefined

2. Globales Deployment von Frontend und API

• Aktion: Globales externes HTTP(S) Load Balancing mit Cloud CDN für statische Assets und dynamisches Routing zu regionalen Backends (GKE-Dienste in us-central1, europe-west1, asia-east1) verwenden.
• Begründung: Anycast-VIP minimiert die RTT; CDN speichert Bilder zwischen (cacht) und nahe bei den Nutzern; Backend-Dienste verteilen Anfragen an die nächstgelegene fehlerfreie Region.

3. Zustandslose Dienste auf GKE mit In-Cluster-Discovery

• Aktion: Bildgrößenänderungs- und API-Dienste auf GKE mit horizontalem Pod-Autoscaling und ClusterIP-Services für namensbasierten Zugriff innerhalb des Clusters bereitstellen; öffentliche Endpunkte über einen Ingress verfügbar machen.
• Begründung: Zustandslose Pods ermöglichen elastische Skalierung; der Kubernetes Service abstrahiert Pod-IPs und bietet stabiles DNS, was die Kopplung von Clients reduziert.

4. Ereignisgesteuerte Bildverarbeitung

• Aktion: Bildverarbeitungsaufgaben in Pub/Sub veröffentlichen; Cloud Run-Dienste ausführen, die per Push abonniert sind, um in Cloud Storage gespeicherte Objekte zu verarbeiten. Truncated Exponential Backoff mit Jitter bei GCS 429/5xx-Fehlern implementieren.
• Begründung: Pub/Sub puffert Lastspitzen und isoliert Ausfälle; Cloud Run skaliert pro Nachricht; Backoff reduziert die Fehlerverstärkung und hilft, dass sich die Buckets allmählich aufwärmen.

5. Observability und schnelle Alarmierung

• Aktion: Cloud Logging und Cloud Monitoring verwenden, um Logs und Metriken zu erfassen, Uptime-Checks für APIs zu definieren und Alarmierungsrichtlinien für Fehlerraten und Latenz zu erstellen. Eine Log-Senke (Sink) konfigurieren, um in das bestehende SIEM zu exportieren.
• Begründung: Native Telemetrie bietet Warnungen mit geringer Latenz und verwaltete Uptime-Checks; der Export erhält das zentralisierte SIEM, ohne die Geschwindigkeit der Alarmierung zu beeinträchtigen.

6. Externalisierte Konfiguration und Secrets

• Aktion: Nicht geheime Konfigurationen in ConfigMaps speichern; Secrets und API-Schlüssel im Secret Manager mit Workload Identity für GKE. Für alle auf Compute Engine basierenden Jobs Instanz-Metadaten für deploymentspezifische Werte verwenden.
• Begründung: Externalisierte Konfiguration ermöglicht unveränderliche Images und umgebungsspezifische Einstellungen; vermeidet das Einbetten von Secrets; Metadaten unterstützen VM-Varianten ohne Codeänderungen.

7. Fehlerisolierung und gestaffelter Funktionsabbau (Graceful Degradation)

• Aktion: Bulkheads mit separaten Knotenpools für Best-Effort-Personalisierungs-Workloads anwenden; Request-Budgets und Circuit Breaker für Personalisierungsdienste durchsetzen. In der Benutzeroberfläche nicht kritische Widgets bei Timeouts von Abhängigkeiten weglassen.
• Begründung: Die Isolierung der Kapazität verhindert, dass Best-Effort-Funktionen den Checkout-Prozess beeinträchtigen (Starvation); Circuit Breaker begrenzen den Explosionsradius (Blast Radius); Graceful Degradation erhält die Kernprozesse (Core Journeys).

8. API-Verträge und Kompatibilität

• Aktion: gRPC-Verträge für mobile Clients (v1) mit HTTP/JSON-Transkodierung für das Web definieren; additive Änderungen übernehmen und während des mobilen Rollouts mindestens zwei Versionen beibehalten.
• Begründung: gRPC reduziert die Bandbreite und bietet starke Typisierung; Transkodierung erleichtert die Browser- und Partnerintegration; Versionierung erhält die Abwärtskompatibilität.

9. Sicherheit und Identität

• Aktion: Pro Dienst Google-Servicekonten mit dem IAM-Prinzip der geringsten Rechte (Least Privilege) verwenden; auf Application Default Credentials verlassen. Cloud Armor für den Schutz am Edge aktivieren und überall TLS erzwingen.
• Begründung: Workload Identity beseitigt Risiken bei der Schlüsselverwaltung; WAF und Ratenbegrenzungen mindern Missbrauch; Verschlüsselung während der Übertragung (in transit) ist Standard und obligatorisch.

10. Continuous Delivery und Release-Sicherheit

• Aktion: Canary-Releases mit prozentualer Aufteilung des Traffics am Load Balancer und automatischem Rollback bei SLO-Burn-Alerts implementieren. Blue/Green-Umgebungen pro Region vorhalten.
• Begründung: Progressive Bereitstellung begrenzt das Risiko; regionales Blue/Green beschleunigt das Rollback und ermöglicht sichere Schemamigrationen, die auf versionierte APIs abgestimmt sind.

Alle Domänen · Compute →

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

Google durchsuchen →