Google PCD: Performance, Skalierbarkeit und Resilienz-Engineering — 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

Das Engineering für Performance, Skalierbarkeit und Resilienz auf Google Cloud konzentriert sich auf die Aufrechterhaltung eines latenzarmen, kosteneffizienten Dienstes unter variabler Last, während Fehler toleriert werden, ohne die SLOs zu verletzen. Das Design muss die Signale für die automatische Skalierung auf die Eigenschaften des Workloads abstimmen, Daten und Rechenleistung so platzieren, dass die Tail-Latenz minimiert wird, und Überlaststeuerungen, Wiederholungsversuche (Retries) und Failover implementieren, um kaskadierende Ausfälle zu vermeiden. Dieser Abschnitt beschreibt die Muster, Steuerungsmechanismen und Kompromisse, die für Anwendungsentwickler auf den Compute-, Netzwerk- und Datenebenen von Bedeutung sind.

Skalierung und Lastverteilung

Horizontale vs. vertikale Skalierung

Horizontale Skalierung fügt Instanzen oder Pods hinzu, um Kapazität und Resilienz zu erhöhen. Bevorzugt für zustandslose (stateless) Dienste und wenn schnelle Elastizität erforderlich ist. Verwenden Sie Managed Instance Groups (MIGs), Cloud Run-Revisionen oder GKE-Deployments.
Vertikale Skalierung erhöht die Maschinengröße. Nützlich für Single-Threaded- oder speicherintensive Workloads oder um die Koordination zwischen den Knoten zu reduzieren, bietet aber nur begrenzten Spielraum und längere Neustartzeiten.
Gleichzeitigkeit (Concurrency): Passen Sie die Gleichzeitigkeit von Anfragen an CPU-gebundene vs. I/O-gebundene Profile an. Cloud Run unterstützt die Gleichzeitigkeit pro Revision; GKE-Pods können mehrere Anfragen bedienen, wenn Ihre Laufzeitumgebung nicht blockierend ist; für eine strikte Isolierung setzen Sie die Gleichzeitigkeit auf 1.

Signale für die automatische Skalierung und warme Kapazität

Das Autoscaling von MIGs unterstützt CPU-Auslastung, Load-Balancing-Auslastung und benutzerdefinierte Metriken über Cloud Monitoring. Bei sprunghaftem Datenverkehr (bursty traffic) sollte die Skalierung auf Anfragemetriken (rps, Warteschlangentiefe) anstatt auf die CPU basieren.
Der GKE Horizontal Pod Autoscaler (HPA) kann auf Basis von CPU, Speicher oder benutzerdefinierten/externen Metriken (z. B. Länge der Pub/Sub-Warteschlange) skalieren. Verwenden Sie den Vertical Pod Autoscaler (VPA) für das Right-Sizing, aber vermeiden Sie VPA-Live-Updates bei schnell skalierenden Frontends, um Churn zu verhindern.
Cloud Run skaliert auf Basis der gleichzeitigen Anfragelast und optional benutzerdefinierter Metriken. Vermeiden Sie Kaltstarts durch die Aufrechterhaltung einer warmen Kapazität: Konfigurieren Sie eine Mindestanzahl von Instanzen, halten Sie die Leerlauf-Gleichzeitigkeit niedrig und wärmen Sie bei Bedarf durch synthetische Health-Pings vor.
Prädiktives Autoscaling in MIGs und das Setzen von min replicas bei Deployments/Revisionen helfen, die Latenz bei der Bereitstellung während täglicher Lastspitzen zu verschleiern.

Load Balancing, globale Verkehrsverteilung, Systemdiagnosen (Health Checks) und Failover

Verwenden Sie den globalen externen Application Load Balancer für eine weltweite Anycast-VIP, HTTP/2 und HTTP/3 sowie eine Edge-Terminierung mit Cloud CDN. Backends können Instanzgruppen, zonale/regionale NEGs, serverlose NEGs (Cloud Run/Functions) oder GKE Ingress sein.
Systemdiagnosen leiten den Verkehr von fehlerhaften Backends weg. Stellen Sie sicher, dass Ihre Health-Endpunkte Abhängigkeiten engmaschig validieren (z. B. Prozess und kritische lokale Ressourcen), um zirkuläre Ausfälle bei nachgelagerten Störungen zu vermeiden.
Firewall-Allow-Listen müssen die Health Checker zulassen. Wenn Prüfungen an Port 80 fehlschlagen, lassen Sie die Bereiche von Google zu:

undefined

Failover: Konfigurieren Sie primäre/Backup-Backend-Dienste oder Traffic-Richtlinien, die bei einem Ausfall der Systemdiagnose auf alternative Regionen umleiten. Für ein Failover auf DNS-Ebene verwenden Sie Cloud DNS-Richtlinien mit Systemdiagnosen für Nicht-HTTP-Endpunkte.

Latenz und Effizienz

Latenzbudgets

Weisen Sie ein End-to-End-Latenzbudget pro Schicht (Client, Edge, App, Daten) zu. Überwachen Sie p95/p99, nicht Durchschnittswerte. Verwenden Sie Cloud Trace, um dienstübergreifende Verursacher und Head-of-Line-Blocking zu finden. Wenden Sie Deadlines auf RPCs an, damit die Stornierung durch den Upstream Kapazitäten freigibt.

Nutzung von Caching und CDN

Schichten von Caches: Client-/Browser-Cache, CDN-Edge (Cloud CDN) und regionale/In-Memory-Caches (Memorystore oder prozessintern). Wählen Sie Cache-Schlüssel und Vary-Header sorgfältig aus. Setzen Sie TTLs basierend auf der Datenaktualität und dem Risiko veralteter Daten; ziehen Sie negatives Caching für 404s in Betracht, wenn dies sicher ist.
Stellen Sie statische Assets aus Cloud Storage hinter Cloud CDN bereit, um die Last am Ursprung (Origin) und die Tail-Latenz zu reduzieren. Verwenden Sie signierte URLs/Header für kontrollierten Zugriff.

Wiederverwendung von Verbindungen

Bevorzugen Sie HTTP/2 oder gRPC für Multiplexing und Header-Komprimierung. Aktivieren Sie Keep-Alives und Connection-Pooling, um den Handshake-Overhead zu reduzieren. Achten Sie auf die Erschöpfung von NAT-Ports; optimieren Sie die Connection-Pools und Idle-Timeouts des Clients und dimensionieren Sie gegebenenfalls die Cloud NAT-Ports pro VM.

Payload-Effizienz

Verwenden Sie binäre Kodierungen (z. B. Protobuf) und komprimieren Sie Text-Payloads (gzip/brotli) oberhalb eines Größenschwellenwerts. Entwerfen Sie Anfrage-/Antwortfelder sorgfältig; paginieren Sie, filtern Sie serverseitig und vermeiden Sie das Abrufen von zu vielen Daten (Over-Fetching). Verwenden Sie ETags und bedingte Anfragen (If-None-Match), um redundante Übertragungen zu vermeiden. Verwenden Sie für Cloud Storage Generations-Vorbedingungen und Range-Reads für Teilinhalte.

Muster für Überlastung und Resilienz

Ratenbegrenzung, Backpressure, Queues und Stapelverarbeitung

Erzwingen Sie Ratenbegrenzungen am Edge (Cloud Armor für IP-/geo-/dienstbasierte Ratenbegrenzung) und auf der API-Ebene (Apigee-Kontingente, Tokens pro API-Client). Implementieren Sie serverseitig Token-Bucket- oder Leaky-Bucket-Algorithmen für eine faire Aufteilung.
Backpressure: Überfordern Sie nachgelagerte Systeme nicht. Verwenden Sie Warteschlangen (Pub/Sub für At-least-once-Eventing; Cloud Tasks für Drosselungen pro Warteschlange und pro Ziel mit Zeitplanung und Wiederholungsversuchen). Leiten Sie 429 Too Many Requests oder 503 mit Retry-After weiter, um Clients zurückzudrängen.
Stapelverarbeitung (Batching) kann den Durchsatz erhöhen und den Overhead pro Aufruf reduzieren (z. B. Batch-Mutationen in Datenbanken oder Batch-Bestätigungen für Pub/Sub), wobei erhöhte Latenz gegen Effizienz getauscht wird. Passen Sie die Batch-Größe und die maximale Wartezeit an.

Überlastschutz

Wenden Sie Timeouts und Deadlines auf jeden RPC an. Verwenden Sie Circuit Breaker, um das Senden von Arbeit an ausfallende Abhängigkeiten zu stoppen und schnelle Fallbacks zu ermöglichen. Implementieren Sie Load Shedding basierend auf der Warteschlangentiefe, der CPU-Auslastung oder der Verletzung von Latenz-SLOs, um Kernfunktionalitäten zu schützen.

Resiliente Wiederholungsversuche, exponentielles Backoff, Jitter, Idempotenz und Duplikatbehandlung

Wiederholungsversuche nur dann durchführen, wenn es sicher ist: bei Netzwerk-Timeouts, 5xx-Fehlern oder dokumentierten wiederholbaren Codes (z. B. Cloud Storage 429/5xx). Führen Sie niemals Wiederholungsversuche bei 4xx-Fehlern wie 400/401/403 durch, es sei denn, dies ist ausdrücklich angegeben.
Verwenden Sie „truncated exponential backoff“ mit Jitter, um synchronisierte Wiederholungsversuche zu vermeiden. Bevorzugen Sie „full jitter“. Beispiel:

undefined

Stellen Sie Idempotenz sicher. Verwenden Sie Idempotenz-Schlüssel (z. B. eine eindeutige Operations-ID) und Upserts/bedingte Schreibvorgänge, um Duplikate zu tolerieren. Führen Sie bei Pub/Sub eine Deduplizierung mithilfe der messageId oder von Anwendungsschlüsseln durch; gestalten Sie Handler so, dass sie für eine At-least-once-Zustellung sicher sind. Verwenden Sie bei Schreibvorgängen in Cloud Storage generation-match-Preconditions, um Überschreibungen zu vermeiden.

Hochfahren von ruhenden Ressourcen

Einige Dienste erzwingen adaptive Limits. Fahren Sie bei Cloud Storage die Anfrageraten für zuvor inaktive Buckets schrittweise hoch, um vorübergehende 429/5xx-Fehler bei plötzlichen Spitzen zu reduzieren. Drosseln Sie die Producer und wärmen Sie die Buckets mit kontrolliertem Traffic auf, bevor die volle Last anliegt.

Hochverfügbarkeit, Daten, DR und Tests

Multizonal, regional, multiregional; Aktiv-Aktiv vs. Aktiv-Passiv

Über Fehlerdomänen hinweg bereitstellen. Verwenden Sie regionale MIGs oder regionale GKE-Cluster für Zonenfehlertoleranz. Für globale Dienste mehrere Regionen mit dem globalen Load Balancer verwenden.
Aktiv-Aktiv reduziert RTO und Latenz, erfordert aber konfliktfreie Daten und ein sorgfältiges Konsistenzmanagement. Aktiv-Passiv vereinfacht die Schreibsemantik, führt aber zu einer höheren RTO und potenziell kalter Kapazität.

RTO, RPO, Backup, Wiederherstellung und Disaster-Recovery-Tests

Definieren Sie RTO (Zeit bis zur Wiederherstellung des Dienstes) und RPO (tolerierbarer Datenverlust) pro Workload. Ordnen Sie dies den Plattformfähigkeiten zu:
- Cloud Spanner: multiregional mit einer Verfügbarkeit von fünf Neunen und synchroner Replikation für eine RPO von nahezu null.
- Cloud SQL: Hochverfügbarkeit innerhalb einer Region; verwenden Sie regionsübergreifende Replikate für DR, aktivieren Sie PITR und validieren Sie Failover/Failback-Runbooks.
- Firestore und Bigtable bieten regionale und multiregionale Optionen; wählen Sie diese entsprechend den RTO/RPO-Anforderungen.
- Cloud Storage Dual- oder Multi-Region-Buckets bieten Geo-Redundanz; überprüfen Sie die Wiederherstellungsverfahren und die Neuausstellung von Signed URLs.
Testen Sie DR: Führen Sie regelmäßig Failover-Übungen durch. Validieren Sie Backups durch Wiederherstellung in einer isolierten Umgebung, proben Sie das DNS-/Traffic-Failover und messen Sie die tatsächliche RTO/RPO.

Datenbank- und Speicherleistung, Indexdesign, Hot Keys und Konkurrenzsituationen

Cloud Spanner: Vermeiden Sie monoton ansteigende Primärschlüssel, die zu Hotspots führen. Verwenden Sie Interleaved Tables für Lokalität, sekundäre Indizes für Lesemuster und Bounded Transactions, um Sperrkonflikte zu reduzieren. Dimensionieren Sie Knoten für QPS und Speicher; halten Sie mindestens drei Knoten für das Produktionsquorum und Leistungsreserven bereit.
Cloud SQL: Analysieren Sie Abfragen, fügen Sie Covering Indexes hinzu, vermeiden Sie lange Transaktionen und verwenden Sie Connection Pools. Passen Sie die Einstellungen von InnoDB oder Postgres mit Bedacht an; skalieren Sie Lesereplikate für leselastige Workloads.
Bigtable: Entwerfen Sie Zeilenschlüssel (Row Keys) so, dass die Last gleichmäßig verteilt wird (Salting oder Feldumkehr). Verwenden Sie Multi-Cluster-Routing für Hochverfügbarkeit über Regionen hinweg, falls verfügbar.
Firestore: Verwenden Sie Composite Indexes für Abfragen über mehrere Felder; achten Sie auf Hotspotting, wenn viele Schreibvorgänge auf denselben Dokumentenpfad abzielen.
Cloud Storage: Starke Read-after-Write-Konsistenz für neue Objekte; verwenden Sie parallele Uploads und Chunking für den Durchsatz. Fahren Sie den Traffic auf inaktiven Buckets langsam hoch; bevorzugen Sie den CDN-Edge für häufige Lesezugriffe (Hot Reads). Wenn viele VMs denselben großen, schreibgeschützten Datensatz benötigen, hängen Sie eine Persistent Disk im schreibgeschützten Modus an mehrere Instanzen an, um schnellen lokalen Zugriff zu geringen Kosten zu ermöglichen.

Lasttests, Chaos-Experimente, Fault Injection und Kapazitätsplanung

Lasttests: Simulieren Sie realistische Traffic-Muster und Datenverteilungen. Wärmen Sie Caches und Autoscaler auf; testen Sie die p95/p99-Latenz unter Last und während Skalierungsereignissen. Spiegeln Sie einen kleinen Teil des Live-Traffics auf Schatten-Stacks, um das Verhalten bei Produktionskomplexität zu validieren.
Chaos und Fault Injection: Beenden Sie Pods/VMs, sperren Sie eine Zone (Cordon), injizieren Sie Latenz/Fehler auf der Service-Mesh-Ebene (z. B. Envoy/Istio), um den Explosionsradius (Blast Radius) und die Resilienz zu beobachten. Überprüfen Sie, ob Circuit Breaker und Wiederholungsversuche wie beabsichtigt funktionieren.
Kapazitätsplanung: Erstellen Sie Prognosen auf der Grundlage historischer Nachfrage und geplanter Ereignisse. Halten Sie Leistungsreserven für N+1-Ausfälle und Rebalancing vor. Stimmen Sie die Cooldown-Phasen und maximalen Raten des Autoscalers auf erwartete Spitzen ab; stellen Sie Kapazität während vorhersehbarer Spitzen vorab bereit.

Verfügbarkeitsabwägungen zwischen Managed Services und benutzerdefinierten Architekturen

Compute: Cloud Run bietet schnelle Skalierung auf null und geringen Betriebsaufwand, hat aber Kaltstarts und Einschränkungen bei der Gleichzeitigkeit von Anfragen. GKE bietet feingranulare Kontrolle und Portabilität bei höheren Betriebskosten. Compute Engine VMs bieten maximale Kontrolle bei höchstem Betriebsaufwand.
Daten: Cloud Spanner bietet globale Konsistenz und hohe Verfügbarkeit zu höheren Kosten und mit strengeren Schema-Anforderungen. Cloud SQL eignet sich für traditionelle RDBMS mit einfacherem Betrieb, aber begrenzter HA/Skalierbarkeit. Bigtable zeichnet sich durch Key-Value/Zeitreihen mit niedriger Latenz und massiver Skalierung aus. Firestore bietet flexible Schemata mit starker Konsistenz und globalen Optionen.
Netzwerk: Globale Load Balancer und Cloud CDN sind hochverfügbar und werden an der Google-Edge betrieben; selbstgebaute (DIY) Proxys bieten Anpassungsmöglichkeiten, schaffen aber Betriebs- und Ausfallrisiken.
Bevorzugen Sie Managed Services für eine höhere Grundverfügbarkeit und DDoS-Resistenz, aber berücksichtigen Sie Quotas, Kaltstarts und dienstspezifische Semantiken in Ihrem Design.

Praktisches Problemszenario

NimbusMart, ein globales E-Commerce-Unternehmen, benötigt eine Produktkatalog-API mit niedriger Latenz, einer Verfügbarkeit von fünf Neunen und minimierter Leselatenz für Benutzer in Nordamerika, Europa und im asiatisch-pazifischen Raum. Schreibvorgänge müssen global konsistent sein. Der Traffic ist während Flash Sales sprunghaft, und zu früheren Vorfällen gehören kaskadierende Wiederholungsversuche und eine Überlastung des Ursprungsservers (Origin).

Ansatz:

Stellen Sie eine multiregionale Cloud Spanner-Instanz mit der Konfiguration nam-asia-eur1 und mindestens drei Knoten bereit.

Begründung: Bietet global konsistente Lese-/Schreibvorgänge mit einer Verfügbarkeit von fünf Neunen und platziert Replikate in der Nähe der Benutzer, um die Leselatenz zu reduzieren. Ein Minimum von drei Knoten sorgt für Quorum-Robustheit und Leistungsreserven für das Rebalancing.

Implementieren Sie eine zustandslose (stateless) API-Schicht in mehreren Regionen hinter dem globalen externen Application Load Balancer.

Begründung: Anycast-VIP und globales Routing reduzieren den Verbindungsaufbau und leiten Benutzer zur nächstgelegenen fehlerfreien Region. Zustandslose Dienste erleichtern die horizontale Skalierung und das Failover.

Konfigurieren Sie Health Checks und Firewall-Regeln für die Erreichbarkeit des Load Balancers.

Begründung: Health Checks verhindern das Routing zu fehlerhaften Backends. Erlauben Sie die IP-Bereiche der Google Health Checks, damit die Prüfungen erfolgreich sind: 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

Implementieren Sie Autoscaling auf Basis von Anfragemetriken mit warmer Kapazität.

Begründung: Skalieren Sie MIGs oder GKE HPA basierend auf QPS/Latenz anstatt auf CPU, um auf den Traffic von Flash Sales zu reagieren. Halten Sie eine Mindestanzahl von Replikaten pro Region aufrecht, um Kaltstarts zu vermeiden und prädiktives Autoscaling vor bekannten Ereignissen zu ermöglichen.

Fügen Sie Cloud CDN für statische Produktmedien hinzu, die in Cloud Storage gespeichert sind.

Begründung: Edge-Caching entlastet den Ursprungsserver, reduziert die Tail-Latenz und mildert die Verstärkung von Lastspitzen (Burst Amplification) auf der Anwendungs- und Speicherebene. Verwenden Sie Signed URLs und geeignete Cache-Schlüssel/TTLs.

Erzwingen Sie Überlastschutz und Ratenbegrenzung (Rate Limiting) am Edge und im Dienst.

Begründung: Konfigurieren Sie Cloud Armor-Ratenbegrenzungen, um missbräuchliche Spitzen abzufangen. Verwenden Sie im Dienst Token-Bucket-Limits pro Client und verwerfen Sie Anfragen mit niedriger Priorität, wenn die Latenz-SLOs gefährdet sind. Wenden Sie Deadlines auf jeden nachgelagerten Aufruf an.

Verwenden Sie resiliente Wiederholungsversuche mit Truncated Exponential Backoff und Full Jitter; stellen Sie Idempotenz mit Operations-IDs sicher.

Begründung: Verhindern Sie “Thundering Herds” und doppelte Schreibvorgänge bei Teilausfällen. Idempotenzschlüssel gewährleisten sichere Wiederholungen; verwenden Sie für Speichervorgänge bedingte Vorbedingungen (Conditional Preconditions).

Führen Sie eine Schreib-Warteschlange (Write Queue) zur Glättung von Lastspitzen und für Asynchronität ein, wo dies akzeptabel ist.

Begründung: Pub/Sub puffert plötzliche Spitzen nicht kritischer Schreibvorgänge (z. B. Analyse-Events), entkoppelt die Producer von Spanner und schützt die primären Schreibpfade vor Überlastung.

Definieren Sie SLOs und Latenzbudgets; instrumentieren Sie Tracing und Dashboards.

Begründung: Budgets pro Schicht (Tier) leiten die Optimierung. Cloud Monitoring SLOs mit Fehlerbudgets (Error Budgets) und Cloud Trace decken regionsübergreifende und datenschichtbezogene Beiträge zur p99-Latenz auf.

Erstellen Sie DR-Runbooks und testen Sie das Failover.

Begründung: Üben Sie mit multiregionalem Spanner und multiregionalem Compute die Evakuierung von Regionen. Überprüfen Sie die RTO mit Zeitplänen für das Ableiten (Drain) und Hochfahren (Ramp-up) des Traffics und validieren Sie, dass Autoscaler und CDN sich während des Failovers korrekt verhalten.

Dieses Design erfüllt die Ziele der globalen Verfügbarkeit und niedrigen Latenz, indem es die Compute- und Daten-Topologie aufeinander abstimmt, Überlastschutzmechanismen erzwingt und Managed Services nutzt, die nachweislich Skalierbarkeit und Resilienz bieten.

← Observability · Alle Domänen · Testen →

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