REL 4: Wie lassen sich Interaktionen in einem verteilten System so gestalten, dass Ausfälle vermieden werden?

Verteilte Systeme nutzen Kommunikationsnetzwerke, um Komponenten wie Server oder Services miteinander zu verbinden. Ihre Workload muss trotz Datenverlust oder höherer Latenz in diesen Netzwerken zuverlässig ausgeführt werden. Komponenten des verteilten Systems müssen so funktionieren, dass sie keine negativen Auswirkungen auf andere Komponenten oder die Workload haben. Diese bewährten Methoden verhindern Ausfälle und verbessern die mittlere Zeit zwischen Ausfällen (MTBF).

Ressourcen

AWS re:Invent 2019: Moving to event-driven architectures (SVS308)
AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes loose coupling, constant work, static stability)
AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)
What Is Amazon EventBridge?
What Is Amazon Simple Queue Service?
Amazon EC2: Ensuring Idempotency
The Amazon Builders' Library: Challenges with distributed systems

Bewährte Methoden:

• Bestimmen, welches verteiltes System erforderlich ist: Harte verteilte Echtzeitsysteme erfordern synchrone und schnelle Antworten, während bei weichen Echtzeitsystemen ein großzügigeres Zeitfenster von Minuten (oder mehr) für Antworten besteht. Offline-Systeme verarbeiten Antworten über Stapelverarbeitung oder asynchrone Verarbeitung. Harte verteilte Echtzeitsysteme haben die strengsten Zuverlässigkeitsanforderungen.

• Implementieren lose gekoppelter Abhängigkeiten: Abhängigkeiten etwa zwischen Warteschlangensystemen, Streaming-Systemen, Workflows und Load Balancern sind lose gekoppelt. Die lose Kopplung hilft, das Verhalten einer Komponente von anderen Komponenten zu isolieren, die von ihr abhängig sind, wodurch sich die Ausfallsicherheit und die Agilität erhöhen.

• Festlegen idempotenter Antworten: Ein idempotenter Service garantiert, dass jede Anfrage genau einmal abgeschlossen wird. Das bedeutet, dass das Senden mehrerer identischer Anfragen den gleichen Effekt hat wie das Senden einer einzelnen Anfrage. Ein idempotenter Service erleichtert es einem Client, Wiederholungen zu implementieren. So muss nicht befürchtet werden, dass eine Anfrage fälschlicherweise mehrfach verarbeitet wird. Zu diesem Zweck können Clients API-Anfragen mit einem Idempotenz-Token ausgeben. Das gleiche Token wird verwendet, wenn die Anfrage wiederholt wird. Eine idempotente Service-API gibt mithilfe des Tokens eine Antwort zurück, die identisch mit der Antwort ist, die beim ersten Abschluss der Anfrage zurückgegeben wurde.

• Beständige Arbeit: Bei größeren, schnellen Lastveränderungen können Systeme ausfallen. Beispielsweise sollte ein System, das den Zustand Tausender Server überwacht, jedes Mal dieselbe Nutzlast (einen vollständigen Snapshot des aktuellen Status) senden. Unabhängig davon, ob keine Server ausfallen oder alle – das System für die Zustandsprüfung erledigt seine Arbeit beständig und ohne große, schnelle Änderungen.

Verbesserungsplan

Bestimmen, welches verteiltes System erforderlich ist

Bestimmen, welches verteiltes System erforderlich ist: Zu den Herausforderungen verteilter Systeme gehörten die Latenz, die Skalierung, das Verständnis von Netzwerk-APIs, das Marshalling und Unmarshalling von Daten sowie die Komplexität von Algorithmen wie Paxos. Mit dem zunehmenden Wachstum und dem höheren Verteilungsgrad der Systeme werden Edge-Fälle, früher bloße Theorie, zu regelmäßigen Vorkommnissen.
The Amazon Builders' Library: Challenges with distributed systems

• Harte verteilte Echtzeitsysteme erfordern synchrone und schnelle Antworten.
• Bei weichen Echtzeitsystemen besteht ein großzügigeres Zeitfenster von Minuten (oder mehr) für Antworten.
• Offline-Systeme verarbeiten Antworten über Stapelverarbeitung oder asynchrone Verarbeitung.
• Harte verteilte Echtzeitsysteme haben die strengsten Zuverlässigkeitsanforderungen.

Implementieren lose gekoppelter Abhängigkeiten

Implementieren lose gekoppelter Abhängigkeiten: Abhängigkeiten etwa zwischen Warteschlangensystemen, Streaming-Systemen, Workflows und Load Balancern sind lose gekoppelt. Die lose Kopplung hilft, das Verhalten einer Komponente von anderen Komponenten zu isolieren, die von ihr abhängig sind, wodurch sich die Ausfallsicherheit und die Agilität erhöhen.
AWS re:Invent 2019: Moving to event-driven architectures (SVS308)
What Is Amazon EventBridge?
What Is Amazon Simple Queue Service?

• Mit Amazon EventBridge können Sie ereignisgesteuerte Architekturen entwickeln, die lose gekoppelt und verteilt sind.
  AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)
• Wenn Änderungen an einer Komponente bewirken, dass andere abhängige Komponenten ebenfalls geändert werden, sind sie eng gekoppelt. Die lose Kopplung hebt diese Abhängigkeit auf, sodass abhängige Komponenten nur die versionierte und veröffentlichte Schnittstelle kennen müssen.
• Gestalten Sie die Interaktionen zwischen Komponenten möglichst als asynchrone Interaktionen. Dieses Modell eignet sich für Interaktionen, bei denen keine sofortige Antwort benötigt wird, sondern die Bestätigung ausreicht, dass eine Anfrage registriert wurde.
  AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304)

Festlegen idempotenter Antworten

Festlegen idempotenter Antworten: Ein idempotenter Service garantiert, dass jede Anfrage genau einmal abgeschlossen wird. Das bedeutet, dass das Senden mehrerer identischer Anfragen den gleichen Effekt hat wie das Senden einer einzelnen Anfrage.

• Clients können API-Anfragen mit einem Idempotenz-Token ausgeben. Das gleiche Token wird bei einer Wiederholung der Anfrage verwendet. Eine idempotente Service-API gibt mithilfe des Tokens eine Antwort zurück, die identisch mit der Antwort ist, die beim ersten Abschluss der Anfrage zurückgegeben wurde.
  Amazon EC2: Ensuring Idempotency

Beständige Arbeit

Beständige Arbeit: Bei größeren, schnellen Lastveränderungen können Systeme ausfallen.
AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes constant work)

• Gestalten Sie die Workloads so, dass die Nutzlastgrößen unabhängig von der Anzahl der Erfolge oder Ausfälle konstant bleiben.
  • Wenn das Zustandsprüfungssystem beispielsweise 100 000 Server überwacht, ist die Last darauf angesichts der normalerweise geringen Serverausfallrate nominal. Wenn jedoch die Hälfte dieser Server durch ein großes Ereignis fehlerhaft wird, wäre das Zustandsprüfungssystem überfordert, wenn es versuchte, Benachrichtigungssysteme zu aktualisieren und die Clients über den Status zu informieren. Stattdessen sollte das Zustandsprüfungssystem jedes Mal den vollständigen Snapshot des aktuellen Status senden. 100 000 Server-Zustände, die jeweils durch ein Bit dargestellt werden, entsprächen nur eine Nutzlast von 12,5 KB. Unabhängig davon, ob keine oder alle Server ausfallen – das System für die Zustandsprüfung erledigt seine Arbeit beständig und große, schnelle Änderungen stellen keine Bedrohung für die Systemstabilität dar. Auf diese Weise ist die Steuerebene für Amazon Route 53-Zustandsprüfungen ausgelegt.