# ZUV 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).
**Topics**
+ [REL05-BP01 Implementieren einer ordnungsgemäßen Funktionsminderung, um harte Abhängigkeiten in weiche zu ändern](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 Drosselung von Anfragen](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Steuern und Einschränken von Wiederholungsaufrufen](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Schnelles Scheitern und Begrenzen von Warteschlangen](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Festlegen von Client-Zeitüberschreitungen](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 Erstellen zustandsloser Anwendungen](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 Implementieren von Nothebeln](rel_mitigate_interaction_failure_emergency_levers.md)
# REL05-BP01 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.
Ziehen Sie einen Service B in Betracht, der von Service A aufgerufen wird und wiederum Service C aufruft.
![\[Diagramm: Service C schlägt fehl, wenn er von Service B aufgerufen wird. Service B gibt eine schlechtere Antwort an Service A zurück.\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/graceful-degradation.png)
Wenn Service B Service C aufruft, hat er eine Fehlermeldung oder eine Zeitüberschreitung von ihm erhalten. Service B gibt ohne Antwort von Service C (und den darin enthaltenen Daten) stattdessen zurück, was möglich ist. Dies kann der letzte zwischengespeicherte Wert sein oder Service B kann eine vordefinierte statische Antwort für den Wert ersetzen, den er von Service C erhalten hätte. Er kann dann eine verminderte Antwort an seinen Aufrufer, Service A zurückgeben. Ohne diese statische Antwort würde der Fehler in Service C durch Service B zu Service A kaskadieren, was zu einem Verlust der Verfügbarkeit führt.
Gemäß dem multiplikativen Faktor in der Verfügbarkeitsgleichung für harte Abhängigkeiten (siehe [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122)) wirkt sich jeder Rückgang der Verfügbarkeit von C erheblich auf die effektive Verfügbarkeit von B aus. Durch die Rückgabe des statischen Antwortservice B wird der Fehler in C verringert und lässt die Verfügbarkeit von Service C wie eine hundertprozentige Verfügbarkeit aussehen (vorausgesetzt, dass er die statische Antwort unter Fehlerbedingungen zuverlässig zurückgibt). Beachten Sie, dass die statische Antwort eine einfache Alternative zur Rückgabe eines Fehlers darstellt und kein Versuch ist, die Antwort mit anderen Mitteln neu zu berechnen. Solche Versuche mit einem völlig anderen Mechanismus, um dasselbe Ergebnis zu erzielen, werden als Fallback-Verhalten bezeichnet und sind ein zu vermeidendes Antimuster.
Ein weiteres Beispiel für eine ordnungsgemäße Verschlechterung ist der *Schaltkreisunterbrecher*. Wiederholungsstrategien sollten verwendet werden, wenn der Fehler vorübergehend ist. Wenn dies nicht der Fall ist und der Vorgang wahrscheinlich fehlschlägt, verhindert der Unterbrecher, dass der Client eine Anfrage ausführt, die wahrscheinlich fehlschlägt. Wenn die Anfragen normal verarbeitet werden, wird der Unterbrecher geschlossen, und die Anfragen laufen durch. Wenn das Remote-System Fehler zurückgibt oder eine hohe Latenz aufweist, wird der Unterbrecher geöffnet und die Abhängigkeit wird ignoriert oder die Ergebnisse werden durch einfachere aber weniger umfassende Antworten ersetzt (was einfach ein Antwort-Cache sein kann). Das System versucht regelmäßig, die Abhängigkeit aufzurufen, um zu ermitteln, ob sie wiederhergestellt wurde. In diesem Fall wird der Unterbrecher geschlossen.
![\[Diagramm: Schutzschalter im offenen und geschlossenen Zustand\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/circuit-breaker.png)
Zusätzlich zu den im Diagramm gezeigten Zuständen "Geschlossen" und "Offen" kann der Unterbrecher nach einem konfigurierbaren Zeitraum im offenen Zustand in "Halboffen" übergehen. In diesem Zustand versucht er in regelmäßigen Abständen, den Service mit einer viel geringeren Rate als normal aufzurufen. Auf diese Weise wird der Zustand des Service überprüft. Nach einigen Erfolgen im halb geöffneten Zustand wechselt der Unterbrecher zu "closed" und die Anfragen werden normal fortgesetzt.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Implementieren Sie eine ordnungsgemäße 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.
+ Durch Rückgabe einer statischen Antwort grenzt die Workload Fehler in ihren Abhängigkeiten ein.
+ [Well-Architected Lab: Level 300: Implementieren von Zustandsprüfungen und Verwalten von Abhängigkeiten zur Verbesserung der Zuverlässigkeit](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
+ Erkennen Sie, wann eine Wiederholungsoperation wahrscheinlich fehlschlägt, und verhindern Sie mit dem Unterbrecher die Wiederholung fehlgeschlagener Aufrufe durch den Client.
+ [CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html)
## Ressourcen
**Relevante Dokumente:**
+ [Amazon API Gateway: Drosselung von API-Anfragen für höheren Durchsatz](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [CircuitBreaker (Zusammenfassung des Circuit Breaker aus dem Buch „Release It\$1“)](https://martinfowler.com/bliki/CircuitBreaker.html)
+ [Fehlerwiederholungen und exponentielles Backoff in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Michael Nygard, „Release It\$1“ Design and Deploy Production-Ready Software“](https://pragprog.com/titles/mnee2/release-it-second-edition/)
+ [Die Amazon Builders' Library: Vermeiden von Fallback in verteilten Systemen](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Die Amazon Builders' Library: Vermeiden von nicht mehr aufholbaren Warteschlangen-Rückständen](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Die Amazon Builders' Library: Herausforderungen und Strategien für das Caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Die Amazon Builders' Library: Timeouts, Wiederholungen und Backoff mit Jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Relevante Videos:**
+ [Wiederholung, Backoff und Jitter: AWS re:Invent 2019: Einführung in die Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
**Ähnliche Beispiele:**
+ [Well-Architected Lab: Level 300: Implementieren von Zustandsprüfungen und Verwalten von Abhängigkeiten zur Verbesserung der Zuverlässigkeit](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL05-BP02 Drosselung von Anfragen
Die Drosselung von Anfragen ist ein Abschwächungsmuster, um auf einen unerwarteten Anstieg der Nachfrage zu reagieren. 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.
Ihre Services sollten so konzipiert werden, dass jeder Knoten und jede Zelle eine bekannte Anzahl von Anfragen verarbeiten kann. Diese Kapazität kann mit Lasttests erreicht werden. Anschließend müssen Sie die Eingangsrate von Anfragen verfolgen, und wenn die vorübergehende Eingangsrate dieses Limit überschreitet, muss aus der entsprechenden Antwort hervorgehen, dass die Anfrage gedrosselt wurde. Damit kann der Benutzer es bei einem anderen Knoten oder einer anderen Zelle, der/die ggf. über Kapazität verfügt, erneut versuchen. Amazon API Gateway bietet Methoden zum Drosseln von Anfragen. Amazon SQS und Amazon Kinesis können Anfragen puffern, die Anfragerate glätten und die Notwendigkeit einer Drosselung für asynchrone Anfragen verringern.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Drosseln Sie 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.
+ Nutzen Sie Amazon API Gateway
+ [Drosseln Sie API-Anfragen, um einen höheren Durchsatz zu erzielen.](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
## Ressourcen
**Relevante Dokumente:**
+ [Amazon API Gateway: Drosselung von API-Anfragen für höheren Durchsatz](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Fehlerwiederholungen und exponentielles Backoff in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Die Amazon Builders' Library: Vermeiden von Fallback in verteilten Systemen](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Die Amazon Builders' Library: Vermeiden von nicht mehr aufholbaren Warteschlangen-Rückständen](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Die Amazon Builders' Library: Timeouts, Wiederholungen und Backoff mit Jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [Drosseln Sie API-Anfragen, um einen höheren Durchsatz zu erzielen.](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
**Relevante Videos:**
+ [Wiederholung, Backoff und Jitter: AWS re:Invent 2019: Einführung in die Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP03 Steuern und Einschränken von Wiederholungsaufrufen
Verwenden Sie ein exponentielles Backoff, um Aufrufe nach zunehmend längeren Intervallen zu wiederholen. Nutzen Sie Jitter, um die Wiederholungsintervalle zu randomisieren, und legen Sie ein Limit für die Zahl der Wiederholungen fest.
Typische Komponenten in einem verteilten Softwaresystem sind Server, Load Balancer, Datenbanken und DNS-Server. Im Betrieb und bei Ausfällen kann jede dieser Komponenten mit dem Generieren von Fehlern beginnen. Die Standardmethode für den Umgang mit Fehlern besteht darin, Wiederholungen auf Clientseite zu implementieren. Diese Methode erhöht die Zuverlässigkeit und Verfügbarkeit der Anwendung. In großem Umfang – und wenn Clients versuchen, den fehlgeschlagenen Vorgang zu wiederholen, sobald ein Fehler auftritt – kann das Netzwerk schnell mit neuen und nicht mehr aktiven Anfragen überfordert werden, wobei jede Anfrage um die Netzwerkbandbreite konkurriert. Dies kann zu einer *Wiederholungsflut* führen, die die Verfügbarkeit des Service reduziert. Dieses Muster setzt sich möglicherweise fort, bis ein vollständiger Systemausfall auftritt.
Um solche Szenarien zu vermeiden, sollten Backoff-Algorithmen wie das gängige *exponentielle Backoff* verwendet werden. Algorithmen für exponentielles Backoff verringern schrittweise die Rate, mit der Wiederholungen durchgeführt werden, und verhindern dadurch Netzwerküberlastungen.
Viele SDKs und Softwarebibliotheken, auch die von AWS, implementieren eine Version dieser Algorithmen. Sie sollten jedoch **nie davon ausgehen, dass ein Backoff-Algorithmus vorhanden ist. Dies muss stets im Voraus getestet und überprüft werden.**
Ein einfaches Backoff alleine reicht nicht aus, da in verteilten Systemen alle Clients gleichzeitig einen Backoff durchführen und Anhäufungen von Wiederholungsaufrufen erstellen können. Marc Brooker erklärt in seinem Blogbeitrag [Exponentielles Backoff und Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-italics%0djitter/), wie die Funktion „wait()“ im exponentiellen Backoff geändert werden kann, um Wiederholungsaufruf-Cluster zu verhindern. Die Lösung besteht darin, *Jitter* der Funktion „wait()“ hinzuzufügen. Um einen zu langen Wiederholungsversuch zu vermeiden, sollten Implementierungen das Backoff auf einen maximalen Wert begrenzen.
Schließlich ist es wichtig, eine *maximale Anzahl von Wiederholungen* oder die verstrichene Zeit zu konfigurieren, nach der Wiederholversuche einfach fehlschlagen. AWS SDKs implementieren dies als konfigurierbaren Standard. Für Services, die sich weiter unten im Stack befinden, kann ein maximales Wiederholungslimit von null oder eins das Risiko begrenzen und ist dennoch wirksam, da Wiederholungen an Services delegiert werden, die sich höher im Stack befinden.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Steuern und begrenzen Sie Wiederholungsaufrufe. Verwenden Sie ein exponentielles Backoff, um Aufrufe nach zunehmend längeren Intervallen zu wiederholen. Nutzen Sie Jitter, um die Wiederholungsintervalle zu randomisieren, und legen Sie ein Limit für die Zahl der Wiederholungen fest.
+ [Fehlerwiederholungen und exponentielles Backoff in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ Mit Amazon SKDs werden Wiederholungen und exponentielles Backoff standardmäßig implementiert. Implementieren Sie in die Abhängigkeitsebene zum Aufrufen Ihrer eigenen abhängigen Services eine ähnliche Logik. Legen Sie entsprechend Ihrem Anwendungsfall Zeitüberschreitungen fest und geben Sie an, wann Wiederholversuche gestoppt werden sollen.
## Ressourcen
**Relevante Dokumente:**
+ [Amazon API Gateway: Drosselung von API-Anfragen für höheren Durchsatz](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Fehlerwiederholungen und exponentielles Backoff in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Die Amazon Builders' Library: Vermeiden von Fallback in verteilten Systemen](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Die Amazon Builders' Library: Vermeiden von nicht mehr aufholbaren Warteschlangen-Rückständen](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Die Amazon Builders' Library: Herausforderungen und Strategien für das Caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Die Amazon Builders' Library: Timeouts, Wiederholungen und Backoff mit Jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Relevante Videos:**
+ [Wiederholung, Backoff und Jitter: AWS re:Invent 2019: Einführung in die Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP04 Schnelles Scheitern 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.
Diese bewährte Methode gilt für den Server oder den Empfänger der Anfrage.
Beachten Sie, dass Warteschlangen auf mehreren Ebenen eines Systems erstellt werden können und die Möglichkeit einer schnellen Wiederherstellung möglicherweise erheblich beeinträchtigt wird, da ältere veraltete Anfragen (die keine Antwort mehr benötigen) vor neueren Anfragen verarbeitet werden. Machen Sie sich mit den Orten vertraut, an denen Warteschlangen vorhanden sind. Sie verbergen sich häufig in Workflows oder in Daten, die in einer Datenbank aufgezeichnet werden.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Implementieren Sie schnelles Scheitern und begrenzen Sie Warteschlangen. Wenn eine Workload auf eine Anfrage nicht erfolgreich antworten kann, sollte sie per schnellem Scheitern 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.
+ Implementieren Sie schnelles Scheitern bei hoher Belastung eines Service.
+ [Schnell scheitern](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ Begrenzen Sie Warteschlagen. Wenn in einem warteschlangenbasierten System die Verarbeitung gestoppt wird, aber weiterhin Nachrichten eintreffen, kann ein großer Rückstand an unverarbeiteten Nachrichten entstehen, was die Verarbeitungszeit erhöht. Die Verarbeitung kann so spät abgeschlossen werden, dass die Ergebnisse nicht mehr nützlich sind. Dies führt zur Beeinträchtigung der Verfügbarkeit, die mit der Warteschlange eigentlich aufrecht erhalten werden sollte.
+ [Die Amazon Builders' Library: Vermeiden von nicht mehr aufzuholenden Rückständen](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
## Ressourcen
**Ähnliche Dokumente:**
+ [Fehlerwiederholungen und exponentielles Backoff in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Schnell scheitern](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [Die Amazon Builders' Library: Vermeiden von Fallback in verteilten Systemen](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Die Amazon Builders' Library: Vermeiden von nicht mehr aufholbaren Warteschlangen-Rückständen](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Die Amazon Builders' Library: Herausforderungen und Strategien für das Caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Die Amazon Builders' Library: Timeouts, Wiederholungen und Backoff mit Jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Ähnliche Videos:**
+ [Wiederholung, Backoff und Jitter: AWS re:Invent 2019: Einführung in die Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP05 Festlegen von Client-Zeitüberschreitungen
Legen Sie Zeitbeschränkungen entsprechend fest, überprüfen Sie sie systematisch und verlassen Sie sich nicht auf Standardwerte, da diese in der Regel zu hoch eingestellt sind.
Diese bewährte Methode gilt für den Client oder den Absender der Anfrage.
Legen Sie sowohl eine Zeitbeschränkung für Verbindungen als auch eine für Anforderungen für jeden Remote-Aufruf und in der Regel für jeden Prozess-übergreifenden Aufruf 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.
Weitere Informationen dazu, wie Amazon Zeitüberschreitungen, Wiederholungen und Backoff mit Jitter verwendet, finden Sie in der [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card).
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Legen Sie sowohl eine Zeitbeschränkung für Verbindungen als auch eine für Anforderungen für jeden Remote-Aufruf und in der Regel für jeden Prozess-übergreifenden Aufruf 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: Wiederholungen und Zeitüberschreitungen](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
## Ressourcen
**Relevante Dokumente:**
+ [AWS SDK: Wiederholungen und Zeitüberschreitungen](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Amazon API Gateway: Drosselung von API-Anfragen für höheren Durchsatz](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Fehlerwiederholungen und exponentielles Backoff in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Die Amazon Builders' Library: Timeouts, Wiederholungen und Backoff mit Jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Relevante Videos:**
+ [Wiederholung, Backoff und Jitter: AWS re:Invent 2019: Einführung in die Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP06 Erstellen zustandsloser Anwendungen
Services sollten entweder keinen Zustand erfordern oder ihn so auslagern, dass zwischen verschiedenen Client-Anfragen keine Abhängigkeit von lokal gespeicherten Daten auf der Festplatte und im Arbeitsspeicher besteht. Auf diese Weise können Server nach Belieben ersetzt werden, ohne dass dies Auswirkungen auf die Verfügbarkeit hat. Amazon ElastiCache oder Amazon DynamoDB sind gute Ziele für den ausgelagerte Zustand.
![\[In dieser zustandslosen Webanwendung wird der Sitzungsstatus in Amazon ElastiCache ausgelagert.\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/stateless-webapp.png)
Wenn Benutzer oder Services mit einer Anwendung interagieren, führen sie häufig eine Reihe von Interaktionen aus, die eine Sitzung bilden. Bei einer Sitzung handelt es sich um eindeutige Daten für Benutzer, die zwischen Anfragen bestehen bleiben, während sie die Anwendung verwenden. Eine zustandslose Anwendung ist eine Anwendung, die keine Informationen zu früheren Interaktionen benötigt und keine Sitzungsinformationen speichert.
Sobald eine Anwendung als zustandslos entwickelt wurde, können Sie serverlose Compute-Services wie AWS Lambda oder AWS Fargate verwenden.
Neben dem Serverersatz besteht ein weiterer Vorteil zustandsloser Anwendungen darin, dass sie horizontal skaliert werden können, da alle verfügbaren Compute-Ressourcen (z. B. EC2-Instances und AWS Lambda-Funktionen) jede Anfrage bearbeiten können.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel
## Implementierungsleitfaden
+ Erstellen Sie zustandslose Anwendungen. Zustandslose Anwendungen ermöglichen eine horizontale Skalierung und sind gegenüber dem Ausfall eines einzelnen Knotens tolerant.
+ Entfernen Sie Zustände, die tatsächlich in Anfrageparametern gespeichert werden können.
+ Nachdem Sie untersucht haben, ob der Zustand erforderlich ist, verschieben Sie die gesamte Zustandsverfolgung in einen ausfallsicheren Multizonen-Cache oder Datenspeicher wie Amazon ElastiCache, Amazon RDS, Amazon DynamoDB oder in die verteilte Datenlösung eines Drittanbieters. Speichern Sie nicht verlagerbare Zustände in ausfallsicheren Datenspeichern.
+ Manche Daten (wie Cookies) können in Headern oder Abfrageparametern übergeben werden.
+ Entfernen Sie Zustände, die sich schnell in Anfragen übergeben lassen.
+ Einige Daten sind möglicherweise nicht für jede Anfrage erforderlich, sondern können bei Bedarf abgerufen werden.
+ Entfernen Sie asynchron abrufbare Daten.
+ Wählen Sie einen Datenspeicher, der die Anforderungen eines erforderlichen Zustands erfüllt.
+ Ziehen Sie für nichtrelationale Daten eine NoSQL-Datenbank in Erwägung.
## Ressourcen
**Ähnliche Dokumente:**
+ [Die Amazon Builders' Library: Vermeiden von Fallback in verteilten Systemen](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Die Amazon Builders' Library: Vermeiden von nicht mehr aufholbaren Warteschlangen-Rückständen](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Die Amazon Builders' Library: Herausforderungen und Strategien für das Caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
# REL05-BP07 Implementieren von Nothebeln
Nothebel sind schnelle Prozesse, die die Auswirkungen auf die Verfügbarkeit Ihrer Workload mindern können.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel
## Implementierungsleitfaden
+ 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. Hebel müssen oft manuell ausgeführt werden, können aber auch automatisiert werden.
+ Beispiele für Nothebel:
+ Blockieren des gesamten Roboterdatenverkehrs
+ Anbieten von statischen Seiten anstelle von dynamischen Seiten
+ Reduzieren der Häufigkeit von Aufrufen für eine Abhängigkeit
+ Drosselung der Aufrufe von Abhängigkeiten
+ Tipps zur Implementierung und Verwendung von Nothebeln
+ Wenn die Hebel aktiviert sind, sollten Sie WENIGER machen, nicht mehr.
+ Halten Sie die Dinge einfach, vermeiden Sie bimodales Verhalten.
+ Testen Sie die Hebel regelmäßig.
+ Nachfolgend finden Sie Beispiele für Aktionen, die KEINE Nothebel sind:
+ Kapazität hinzufügen
+ Servicebesitzer von Clients anrufen, die von Ihrem Service abhängig sind, und sie bitten, Aufrufe zu reduzieren
+ Code ändern und freigeben