Amazon DOP-C02: Ereignisgesteuerte Architekturen und Automatisierung — Lernleitfaden
Teil des AWS DevOps Engineer Professional DOP-C02 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.
Überblick
Ereignisgesteuerte Architekturen entkoppeln Produzenten von Konsumenten, betonen asynchrone Kommunikation und machen Systeme resilient gegenüber Lastspitzen und Ausfällen. Die Kernprinzipien sind lose Kopplung über Ereignisse/Nachrichten, konsumentengesteuerte Skalierung, idempotente Handler sowie explizite Fehlerbehandlung und Beobachtbarkeit (Observability). AWS bietet Bausteine für langlebige Warteschlangen, Pub/Sub, Event-Busse, Stream-Verarbeitung, Orchestrierung und Betriebsautomatisierung. Die Beherrschung des Zusammenspiels von Amazon SQS, Amazon SNS, Amazon EventBridge, AWS Step Functions, Lambda Event Source Mappings, AWS Systems Manager Automation und OpsCenter sowie Kinesis Data Streams und Firehose ermöglicht es Ihnen, skalierbare, fehlertolerante und auditierbare Automatisierungs- und Datenpipelines zu erstellen.
Messaging und Ingestion: SQS, SNS, Kinesis und Firehose
Amazon SQS bietet langlebige, skalierbare Warteschlangen zur Entkopplung. Standard-Warteschlangen bieten eine At-least-once-Zustellung (mindestens einmal) und eine Best-Effort-Reihenfolge bei praktisch unbegrenztem Durchsatz; sie eignen sich für parallele Worker, die doppelte und nicht in der richtigen Reihenfolge eintreffende Nachrichten durch Idempotenzschlüssel und bedingte Schreibvorgänge tolerieren. FIFO-Warteschlangen erzwingen eine geordnete Zustellung pro Nachrichtengruppe und eine Exactly-once-Verarbeitungssemantik (genau einmal) mit Deduplizierung (innerhalb eines Fünf-Minuten-Fensters). Sie garantieren die Reihenfolge und einmalige Verarbeitung, gehen aber Kompromisse beim absoluten Durchsatz ein: Verwenden Sie mehrere Nachrichtengruppen zur Parallelisierung innerhalb von FIFO oder aktivieren Sie High-Throughput-FIFO für Tausende von Nachrichten pro Sekunde. Konfigurieren Sie das Visibility Timeout (Sichtbarkeitszeitlimit) pro Warteschlange oder pro Nachricht so, dass es die maximale Verarbeitungszeit überschreitet; bei Lambda-Konsumenten sollte das Visibility Timeout auf mindestens das Sechsfache des Funktionstimeouts gesetzt werden, um Wiederholungsversuche zu ermöglichen, bevor eine Nachricht wieder sichtbar wird. Verwenden Sie Long Polling, um leere Empfangsvorgänge (Empty Receives) zu reduzieren. Dead-Letter-Queues (DLQs) fangen „Poison Messages“ (fehlerhafte Nachrichten) auf, wenn eine Nachricht den maxReceiveCount überschreitet; später können Sie einen Redrive von der DLQ zur Quell-Warteschlange durchführen, um die Nachrichten nach einer Korrektur erneut zu verarbeiten. Überwachen Sie ApproximateAgeOfOldestMessage, um Rückstände (Backlogs) zu erkennen und Änderungen an der Gleichzeitigkeit/Autoscaling vorzunehmen.
Amazon SNS bietet verwaltetes Pub/Sub mit hohem Durchsatz. Publisher senden eine Nachricht einmal an ein Topic; SNS verteilt diese dann an mehrere Subscriptions (SQS, Lambda, HTTP/S, E-Mail, Mobilgeräte) (Fan-Out). Filterrichtlinien für Subscriptions (Subscription Filter Policies) verwenden Nachrichtenattribute, um nur relevante Benachrichtigungen an den jeweiligen Abonnenten weiterzuleiten, was die nachgelagerten Kosten und die Last reduziert; formulieren Sie Prädikate wie exakte Übereinstimmung (Exact Match), Präfix, numerische Bereiche, „Anything-but“ (alles außer) und „Exists“ (existiert). Verwenden Sie SNS für Fan-Out, entkoppelte Benachrichtigungen und Mobile Push. Aktivieren Sie Wiederholungsversuche und ziehen Sie pro Subscription eine DLQ für unzustellbare Nachrichten in Betracht. Für Anwendungsfälle, die einen geordneten Fan-Out erfordern, erzwingen SNS-FIFO-Topics mit FIFO-SQS-Subscriptions die Reihenfolge und Deduplizierung.
Kinesis Data Streams bietet geordnete Streams mit geringer Latenz und Parallelität auf Shard-Ebene für Echtzeitanalysen und Ereignisverarbeitung. Produzenten schreiben Datensätze (Records) mit Partitionsschlüsseln in Shards; Konsumenten (Lambda, KCL, Enhanced-Fan-Out-Konsumenten, Kinesis Data Analytics) lesen diese pro Shard in der richtigen Reihenfolge mit Checkpointing. Nutzen Sie On-Demand-Kapazität für unvorhersehbare Lasten oder provisionierte Shards mit Resharding für vorhersagbaren Durchsatz. Optimieren Sie die Partitionsschlüssel, um „Hot Shards“ auszugleichen, und überwachen Sie IteratorAge, um Verzögerungen bei den Konsumenten (Consumer Lag) festzustellen. Enhanced Fan-Out bietet einen dedizierten Durchsatz von 2 MB/s pro Konsumenten-Stream mit Push-Zustellung mit geringer Latenz über HTTP/2.
Kinesis Data Firehose ist ein vollständig verwalteter Lieferservice für die Ingestion (Datenerfassung) in Nahezu-Echtzeit in S3, Amazon OpenSearch Service, Splunk oder HTTP-Endpunkte, mit optionaler Lambda-Transformation, Pufferung (nach Größe/Zeit), Komprimierung und Verschlüsselung. Die Datenquellen können direkte PutRecord/PutRecordBatch-Aufrufe, Kinesis Data Streams oder Subscriptions von CloudWatch Logs/Events sein. Verwenden Sie Firehose, wenn Sie eine verwaltete Zustellung mit Transformation und Batch-Verarbeitung benötigen und keinen eigenen Konsumenten-Code erstellen und betreiben möchten. Dynamische Partitionierung (Dynamic Partitioning) ermöglicht es Ihnen, Datensätze anhand von Schlüsseln an S3-Präfixe weiterzuleiten, um eine effiziente nachgelagerte Verarbeitung zu gewährleisten.
Routing, Orchestrierung und Zeitplanung: EventBridge und Step Functions
Amazon EventBridge ist der zentrale Event-Bus für Routing, Governance und konto-/Event-Domain-übergreifende Integration. Verwenden Sie den Standard-Bus für AWS-Service-Events, benutzerdefinierte Busse zur Segmentierung von Domänen und zur Anwendung von Berechtigungen und Partner-Busse für SaaS-Integrationen. Regeln matchen Events über inhaltsbasierte Muster (content-based patterns) und leiten sie an über 200 AWS-Services als Ziele (Targets) weiter. Nutzen Sie Input-Transformer, um Payloads zu formen, und die Archiv/Replay-Funktion, um historische Events bei einer Wiederherstellung oder beim Onboarding neuer Consumer erneut zu verarbeiten. Ressourcenrichtlinien ermöglichen kontoübergreifendes Event-Routing, um die Governance in einem Plattform-Konto zu konsolidieren. EventBridge Pipes bieten Punkt-zu-Punkt-konfigurierbare Flüsse von Event-Quellen (SQS, Kinesis, DynamoDB Streams, selbstverwaltetes Apache Kafka auf Amazon MSK und andere) zu Zielen, mit integrierter Filterung, Batch-Verarbeitung, Transformation und Anreicherung durch Lambda oder Step Functions – ideal, wenn Sie keine vollständige Consumer-Anwendung verwalten möchten, aber eine leichtgewichtige Vermittlung benötigen. EventBridge Scheduler bietet einmalige und Cron-basierte Zeitpläne, um Ziele mit einer Ausführungsrolle, Zeitzonenunterstützung und optional flexiblen Zeitfenstern aufzurufen, um „Thundering Herds“ (Lastspitzen durch gleichzeitige Ausführungen) zu reduzieren.
AWS Step Functions orchestriert verteilte Workflows, die in der Amazon States Language definiert sind, mit Zuständen (States) für Task, Choice, Parallel, Map (einschließlich Distributed Map), Wait, Pass, Succeed/Fail und robusten Retry/Catch-Mustern. Tiefe Service-Integrationen eliminieren die Notwendigkeit von „Glue Code“, um AWS-APIs aufzurufen, einschließlich synchroner (.sync) und Callback-Muster mit Task-Tokens. Wählen Sie Standard-Workflows für langlebige, audit-intensive Orchestrierungen mit Exactly-Once-Zustandsübergängen, einer Dauer von bis zu einem Jahr und einer Preisgestaltung pro Zustandsübergang; der Ausführungsverlauf wird beibehalten, mit starker Sichtbarkeit und integrierten X-Ray-Traces. Wählen Sie Express-Workflows für kurzlebige Orchestrierungen mit hohem Durchsatz (Sekunden bis Minuten), bei denen Sie eine Preisgestaltung pro Anfrage + Dauer und At-Least-Once-Ausführungssemantik für massive Skalierung in Kauf nehmen können; verwenden Sie sie für die Anreicherung bei der Aufnahme von Streaming-Daten, Event-Router und Mikro-Orchestrierungen, bei denen Sie Tasks idempotent gestalten können. Wenden Sie Muster wie Saga mit kompensierenden Tasks und zentralisierter Fehlerbehandlung an; externalisieren Sie Wiederholungsversuche/Timeouts in der Zustandsmaschine, um den Task-Code zu vereinfachen.
Compute-Trigger und Gegendruck (Backpressure): Lambda Event Source Mappings
Lambda Event Source Mappings (ESMs) verbinden abfragebasierte (poll-based) Quellen mit Lambda und steuern Parallelität, Batch-Verarbeitung und Fehlerbehandlung.
SQS: Lambda skaliert horizontal, indem es die Warteschlange abfragt und Ihre Funktion mit Batches aufruft (bis zu 10 Nachrichten; maximales Batch-Fenster bis zu 300 Sekunden). Bei Standard-Warteschlangen ist die Skalierung aggressiv und richtet sich nach der Tiefe und dem Nachrichtendurchsatz; bei FIFO-Warteschlangen erhält Lambda die Reihenfolge pro Nachrichtengruppe aufrecht und verarbeitet einen Batch pro Gruppe auf einmal. Konfigurieren Sie die maximale Parallelität (maximum concurrency) auf dem ESM, um die Skalierung der Worker zu begrenzen und nachgelagerte Systeme zu schützen; kombinieren Sie dies mit reservierter/provisionierter Parallelität, um Kapazität zu garantieren. Verwenden Sie die partielle Batch-Antwort (partial batch response), um nur erfolgreiche Datensätze zu bestätigen und fehlgeschlagene erneut in die Warteschlange zu stellen, um die Wiederholung des gesamten Batches zu vermeiden. Setzen Sie das Visibility Timeout der Warteschlange so, dass es die Gesamtzeit der Wiederholungsversuche im schlimmsten Fall überschreitet. DLQs und Redrive Policies isolieren „Poison Messages“ (problematische Nachrichten).
Kinesis Data Streams: Standardmäßig eine gleichzeitige Lambda-Invocation pro Shard, um die Reihenfolge pro Shard sicherzustellen. Erhöhen Sie den ParallelizationFactor auf bis zu 10, um mehrere Batches pro Shard gleichzeitig zu verarbeiten, wenn die Reihenfolge über Teilsequenzen hinweg nicht zwingend erforderlich ist. Batch-Größe bis zu 10.000 Datensätze (6 MB) und maximales Batch-Fenster bis zu 5 Minuten ermöglichen es Ihnen, Kosten zu amortisieren und den Durchsatz zu erhöhen. Verwenden Sie „Bisect on Function Error“, um fehlerhafte Datensätze innerhalb eines Batches per Binärsuche zu finden, und „On-Failure Destinations“ oder ein maximales Alter/Anzahl von Wiederholungsversuchen für Datensätze, um nicht verarbeitbare Datensätze zu verwerfen oder weiterzuleiten. Überwachen Sie die IteratorAge, um Verzögerungen beim Consumer (Consumer Lag) zu erkennen und entsprechend die Shard-Anzahl zu erhöhen oder die Parallelisierung anzupassen.
DynamoDB Streams: Ähnlich wie Kinesis in der Semantik; Batch-Größe bis zu 1.000 Datensätze (6 MB) und ein Shard-pro-Partition-Key-Modell. Consumer erhalten geordnete Mutationen auf Elementebene (INSERT, MODIFY, REMOVE). Wenden Sie die gleiche Fehlerbehandlung (Bisect on Error, maximale Anzahl von Wiederholungsversuchen, Alter des Datensatzes) und Filterung an. Verwenden Sie einen Stream-Ansichtstyp (Stream View Type), der die von Ihrem Consumer benötigten Attribute enthält (NewImage, OldImage, NewAndOldImages oder KeysOnly), um die Payload-Größe zu optimieren.
Die Ereignisfilterung (Event Filtering) in ESMs reduziert Aufrufe, indem nicht relevante Ereignisse bereits am Poller verworfen werden. Verwenden Sie die Tumbling-Window-Aggregation bei Streams mit Lambda, um Datensätze über die Zeit für Mini-Batch-Verarbeitungsmuster zu aggregieren.
Automatisierung und Behebung von Betriebsabläufen: Systems Manager Automation und OpsCenter
AWS Systems Manager Automation stellt Runbooks (Dokumente vom Typ Automation) bereit, die in JSON/YAML geschrieben sind und Schritte wie aws:runCommand, aws:executeScript, aws:invokeLambda, aws:approve, aws:createStack und aws:executeAutomation enthalten. Automations akzeptieren Parameter, geben Ausgaben aus, werden mit einem Änderungsverlauf versioniert und mit einer dedizierten AutomationAssumeRole für das Prinzip der geringsten Rechte (Least Privilege) und konto- sowie regionsübergreifende Operationen ausgeführt. Steuern Sie die Gleichzeitigkeit und Fehlerschwellenwerte für ganze Flotten, fordern Sie Genehmigungen und Change-Calendar-Fenster an und integrieren Sie Benachrichtigungen über SNS. Rufen Sie Automations nach einem Zeitplan auf, über EventBridge-Regeln (für die Behebung von AWS-Health-, CloudWatch- oder API-Ereignissen in nahezu Echtzeit), über AWS-Config-Remediations zur Durchsetzung von Richtlinien (z. B. das Anwenden von Standard-Tags auf EBS-Volumes oder das Anhängen eines Standard-Instanzprofils an EC2-Instanzen) und über OpsCenter.
OpsCenter aggregiert betriebliche Probleme aus CloudWatch-Alarmen, AWS Config, Health-Ereignissen oder benutzerdefinierten Quellen in OpsItems. Jedes OpsItem erfasst Status, Priorität, Deduplizierung, zugehörige Ressourcen und Runbook-Links. Verknüpfen Sie Ein-Klick-Runbooks für Standardkorrekturen und ermöglichen Sie die automatische Behebung, indem Sie EventBridge- oder Config-Regeln so konfigurieren, dass sie eine bestimmte Automation starten, wenn ein OpsItem mit einer passenden Bedingung erstellt oder aktualisiert wird (z. B. eine Sicherheitsgruppe, die 0.0.0.0/0 für SSH zulässt, eine abweichende Patch-Compliance oder fehlgeschlagene Backups). Verwenden Sie den Systems Manager Explorer, um den Zustand der Flotte und offene OpsItems konto- und regionsübergreifend zu visualisieren. Diese Kombination – OpsItems als dauerhafte Datensätze und Automation-Runbooks als kodifizierte Korrekturen – ermöglicht prüfbare, konsistente Betriebsabläufe in großem Umfang.
← Hochverfügbarkeit · Alle Domänen · Speicher →
Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Bestehe deine Prüfung →