Architekturmuster für Anwendungen auf AWS

Bereitstellen von Anwendungen auf AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Lern deinen Instructor kennen

Kursleiter Dunieski Otano, ein AWS Solutions Architect mit rund zehn Jahren Cloud-Erfahrung

Warum die richtige Architektur zählt

Entscheidungsdiagramm im hellen Design: Ein Architektur-Knoten verzweigt in drei Faktoren – Kopplung, Zustand und Kommunikation – über einem kleinen Waagensymbol für Trade-offs

Architektur ist eine Summe von Trade-offs, nicht die eine richtige Antwort
- Drei Fragen lenken jede Wahl:
  - Wie eng sind Komponenten gekoppelt?
  - Wo liegt der Zustand?
  - Ist Kommunikation synchron oder asynchron?
- Wähle das Muster zur Workload, nicht nach Mode

Die Freitagnacht-Kaskade

Eine langsame Payment-API friert den gesamten Checkout ein
Jeder Service wartete synchron darauf
Die Lösung ist Architektur, nicht nur eine schnellere API

Gegenüberstellung: Eng gekoppelte, blockierende Services versus per Nachrichtenwarteschlange entkoppelte Services

Warum Architektur die Auslieferung prägt

Diagramm: Fragile, eng gekoppelte Architektur mit Ausfallkaskade vs. robustes Design mit Puffer-Warteschlange, sodass andere Services weiter bedienen

Das gewählte Muster bestimmt, wie die App skaliert und ausfällt
- Enge Kopplung bricht unter Last
Das passende Muster macht Deployments berechenbar
- Gleicher Code, sehr unterschiedliches Produktivverhalten

Die zentralen Architekturmuster

Monolithisch: eine deploybare Einheit, einfacher Start
Microservices: unabhängige Services, getrennt deployt
Ereignisgetrieben: Komponenten reagieren auf Events, nicht direkte Aufrufe
- Fanout ist ein Untermuster: ein Event erreicht viele Konsumenten

Drei Architekturmuster nebeneinander: monolithisch als ein Block, Microservices als unabhängige deploybare Services und ereignisgetrieben mit Event-Bus; Fanout als beschriftetes Untermuster mit einem Event an viele Konsumenten

Stateful vs. Stateless

Zustandslos: keine Clientdaten zwischen Requests
- Jede Instanz kann jeden Request bedienen
Zustandsbehaftet: Instanz merkt sich frühere Interaktionen
Zustandslosigkeit ermöglicht horizontale Skalierung
- Gemeinsamen Zustand in DynamoDB oder ElastiCache auslagern

Links eine zustandslose Funktionsinstanz, die jeden Request annehmen kann; rechts eine zustandsbehaftete Instanz, an eine Sitzung gebunden

Enge vs. lose Kopplung

Enge Kopplung mit blockierendem Aufrufer bei langsamem Callee vs. lose Kopplung mit SQS-Warteschlange als Puffer, damit der Producer weiterläuft

Enge Kopplung: der Aufrufer wartet auf die Antwort des Callee
Ein langsamer Service blockiert die ganze Kette
Lose Kopplung: eine Amazon SQS-Warteschlange sitzt dazwischen
Der Producer arbeitet weiter, selbst wenn der Consumer down ist

Synchron vs. asynchron

Synchron: Aufrufer blockiert und wartet auf das Ergebnis
Verwende es, wenn die Antwort sofort gebraucht wird
Asynchron: Aufrufer gibt Arbeit ab und kehrt zurück
Für langsame, schubweise oder nicht dringende Aufgaben

Links synchroner Aufruf: Aufrufer blockiert bis zur Antwort; rechts asynchrone Übergabe mit sofortiger Rückkehr und Hintergrundverarbeitung

Resilienz-Muster für Third-Party-Aufrufe

Retry mit exponentiellem Backoff: zwischen Versuchen länger warten
Circuit Breaker: fehlerhaften Service vorübergehend nicht aufrufen
Dead-Letter-Queue: Nachrichten parken, die immer wieder scheitern
Kombiniere sie; pauschale Retries verschlimmern Ausfälle

Drei Resilienz-Muster: Retry-Kurve mit exponentiellem Backoff, Circuit Breaker stoppt Aufrufe an fehlernden Service, und Dead-Letter-Queue sammelt Nachrichten nach erschöpften Retries

Lass uns üben!

Bereitstellen von Anwendungen auf AWS