Dieser Inhalt ist veraltet. Diese Version des Well-Architected Framework finden Sie jetzt unter: https://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/reliability.html

REL 5: Wie lassen sich Interaktionen in einem verteilten System so gestalten, dass Ausfälle abgemildert oder bewältigt 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. Mit den folgenden bewährten Methoden können Workloads Belastungen oder Ausfällen standhalten, schneller wiederhergestellt werden und die Auswirkungen solcher Beeinträchtigungen verringern. Das Ergebnis ist eine verbesserte mittlere Reparaturzeit (MTTR).

Ressourcen

Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)
Error Retries and Exponential Backoff in AWS
Amazon API Gateway: Throttle API Requests for Better Throughput
The Amazon Builders' Library: Timeouts, retries, and backoff with jitter
The Amazon Builders' Library: Avoiding fallback in distributed systems
The Amazon Builders' Library: Avoiding insurmountable queue backlogs
The Amazon Builders' Library: Caching challenges and strategies
Well-Architected lab: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability
CircuitBreaker (summarizes Circuit Breaker from “Release It!” book)
Michael Nygard “Release It! Design and Deploy Production-Ready Software”

Bewährte Methoden:

Verbesserungsplan

Implementieren einer ordnungsgemäßen Funktionsminderung, um harte Abhängigkeiten in weiche zu ändern

  • Implementieren einer ordnungsgemäßen Funktionsminderung, um harte Abhängigkeiten in weiche zu ändern: Wenn die Abhängigkeiten einer Komponente fehlerhaft sind, kann die Komponente selbst weiterhin funktionieren, wenn auch in eingeschränkter Weise. Wenn beispielsweise ein Abhängigkeitsaufruf fehlschlägt, erfolgt ein Failover auf eine vordefinierte statische Antwort.

    • Drosseln von Anfragen

  • Drosseln von Anfragen: Hierbei handelt es sich um ein Abmilderungsmuster, mit dem auf einen unerwarteten Anstieg der Nachfrage reagiert werden kann. Einige Anfragen werden berücksichtigt, doch solche, die über ein definiertes Limit hinausgehen, werden abgelehnt. Zudem wird eine entsprechende Meldung über deren Drosselung zurückgegeben. Dabei wird erwartet, dass Clients die Anfragen abbrechen oder es mit einer langsameren Rate erneut versuchen.

    • Steuern und Einschränken von Wiederholungsaufrufen

  • Steuern und Einschränken von Wiederholungsaufrufen: Verwenden Sie ein exponentielles Backoff, um Aufrufe nach zunehmend längeren Intervallen zu wiederholen. Führen Sie Jitter ein, um die Wiederholungsintervalle zufällig festzulegen, und begrenzen Sie die Höchstzahl von Wiederholungen.
    Error Retries and Exponential Backoff in AWS

    • Verwenden von Fail-Fast und Begrenzen von Warteschlangen

  • Verwenden von Fail-Fast und Begrenzen von Warteschlangen: Wenn eine Workload auf eine Anfrage nicht erfolgreich antworten kann, sollte sie per Fail-Fast beendet werden. So können Ressourcen freigegeben werden, die einer Anfrage zugeordnet sind, und der Service kann entlastet werden, wenn die Ressourcen zur Neige gehen. Wenn die Workload erfolgreich antworten kann, aber die Rate der Anfragen zu hoch ist, sollten Sie die Anfragen mithilfe einer Warteschlange puffern. Lassen Sie jedoch keine langen Warteschlangen zu. Sie können dazu führen, dass veraltete Anfragen verarbeitet werden, die der Client bereits aufgegeben hat.

    • Festlegen von Client-Zeitbeschränkungen

  • Legen Sie eine Zeitbeschränkung für Verbindungen, für Remote-Aufrufe und generell für prozessübergreifende Aufrufe fest.: Viele Frameworks bieten integrierte Zeitbeschränkungsfunktionen, deren Standardwerte jedoch oft unendlich oder zu hoch sind. Ein zu hoher Wert reduziert die Nützlichkeit der Zeitbeschränkung, da Ressourcen weiterhin verbraucht werden, während der Client auf das Einsetzen der Zeitbeschränkung wartet. Ein zu niedriger Wert kann zu erhöhtem Datenverkehr im Backend und zu erhöhter Latenz führen, da zu viele Anfragen wiederholt werden. In einigen Fällen kann dies zu vollständigen Ausfällen führen, da alle Anfragen wiederholt werden.
    AWS SDK: Retries and Timeouts

    • Einstellen der Zustandslosigkeit für Services

  • Erstellen zustandsloser Anwendungen: Zustandslose Anwendungen ermöglichen eine horizontale Skalierung und sind gegenüber dem Ausfall eines einzelnen Knotens tolerant.

    • Implementieren von Nothebeln

  • Implementieren von Nothebeln: Hierbei handelt es sich um schnelle Prozesse, die die Auswirkungen auf die Verfügbarkeit Ihrer Workload mindern können. Sie können ausgeführt werden, wenn keine Ursache vorliegt. Ein idealer Nothebel reduziert die kognitive Belastung der Resolver auf null, indem er vollständig deterministische Aktivierungs- und Deaktivierungskriterien bereitstellt. Mit Hebeln lässt sich zum Beispiel der gesamte Roboterdatenverkehr blockieren oder eine statische Antwort bereitstellen. Hebel müssen oft manuell ausgeführt werden, können aber auch automatisiert werden.