# Workload-Architektur
**Topics**
+ [ZUV 3 Wie entwerfen Sie Ihre Workload-Service-Architektur?](w2aac19b9b7b5.md)
+ [ZUV 4 Wie lassen sich Interaktionen in einem verteilten System so gestalten, dass Ausfälle vermieden werden?](w2aac19b9b7b7.md)
+ [ZUV 5 Wie lassen sich Interaktionen in einem verteilten System so gestalten, dass Ausfälle abgemildert oder bewältigt werden?](w2aac19b9b7b9.md)
# ZUV 3 Wie entwerfen Sie Ihre Workload-Service-Architektur?
Erstellen Sie hoch skalierbare und zuverlässige Workloads mithilfe einer serviceorientierten Architektur (SOA) oder einer Microservices-Architektur. Eine serviceorientierte Architektur (SOA) hat zum Ziel, Softwarekomponenten über Service-Schnittstellen wiederverwendbar zu machen. Die Microservices-Architektur geht noch weiter, um Komponenten kleiner und einfacher zu machen.
**Topics**
+ [REL03-BP01 Segmentierung Ihres Workloads](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Entwickeln von Services, die sich auf bestimmte Geschäftsbereiche und Funktionen konzentrieren](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Bereitstellen von Serviceverträgen pro API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Segmentierung Ihres Workloads
Die Workload-Segmentierung ist wichtig, wenn es um die Festlegung der Resilienzanforderungen Ihrer Anwendung geht. Eine monolithische Architektur sollte vermieden werden, wann immer möglich. Stattdessen sollten Sie sorgfältig überlegen, welche Anwendungskomponenten in Microservices aufgeteilt werden können. Abhängig von den Anforderungen Ihrer Anwendung könnte es sich im Endergebnis um eine Kombination aus einer serviceorientierten Architektur (SOA) und Microservices handeln, wenn dies möglich ist. Workloads, die zustandslos sein können, können eher als Microservices bereitgestellt werden.
**Gewünschtes Ergebnis:** Workloads sollten unterstützbar, skalierbar und so lose miteinander verbunden sein wie möglich.
Wiegen Sie bei Entscheidungen zur Segmentierung von Workloads die Vorteile und die Komplexitäten miteinander ab. Was für ein neues Produkt richtig ist, das gerade auf dem Markt eingeführt wird, unterscheidet sich von den Anforderungen eines Workloads, der von Anfang an skalierbar sein muss. Bei einem Faktorwechsel für einen vorhandenen Monolith müssen Sie berücksichtigen, wie gut dieser aufgeteilt und in zustandslose Anwendungen transformiert werden kann. Die Aufteilung von Services in kleinere Teile ermöglicht kleinen, klar definierten Teams, diese weiterzuentwickeln und zu verwalten. Kleinere Services können jedoch Komplexitäten wie eine möglicherweise erhöhte Latenz, ein komplexeres Debugging und einen erhöhten operativen Aufwand einführen.
**Typische Anti-Muster:**
+ Der [Microservice *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) ist eine Situation, in der die einzelnen Komponenten so stark voneinander abhängig werden, dass der Ausfall einer einzigen Komponente einen wesentlich größeren Ausfall bewirkt. Das bedeutet, dass die Komponenten so starr und anfällig wie ein Monolith sind.
**Vorteile der Einrichtung dieser Best Practice:**
+ Spezifischere Segmente führen zu einer größeren Agilität, zu organisatorischer Flexibilität und zu Skalierbarkeit.
+ Die Auswirkungen von Service-Unterbrechungen werden reduziert.
+ Die einzelnen Komponenten einer Anwendung besitzen möglicherweise unterschiedliche Anforderungen an die Verfügbarkeit, die von einer stärkeren Segmentierung besser unterstützt werden können.
+ Die Verantwortlichkeiten der Teams, die den Workload unterstützen, sind klar definiert.
**Risikostufe bei fehlender Befolgung dieser Best Practice:** Hoch
## Implementierungsleitfaden
Wählen Sie Ihren Architekturtyp basierend auf der Segmentierung Ihres Workloads aus. Wählen Sie eine serviceorientierte Architektur (SOA) oder eine Microservices-Architektur aus. (In seltenen Fällen ist möglicherweise auch eine monolithische Architektur geeignet.) Auch wenn Sie mit einer monolithischen Architektur beginnen möchten, müssen Sie sicherstellen, dass diese modular ist und zu einer SOA oder zu Microservices weiterentwickeln werden kann, wenn Ihr Produkt aufgrund der zunehmenden Einführung durch Benutzer skaliert wird. SOA und Microservices ermöglichen eine kleinteiligere Segmentierung, die als moderne skalierbare und zuverlässige Architektur bevorzugt wird. Es gibt jedoch auch Nachteile, die besonders bei der Bereitstellung einer Microservice-Architektur berücksichtigt werden sollten.
Aufgrund ihrer verteilten Computing-Architektur kann es schwieriger sein, die Latenzanforderungen von Benutzern zu erfüllen. Außerdem sind das Debugging und die Nachverfolgung von Benutzerinteraktionen komplexer. Zur Lösung dieses Problems können Sie AWS X-Ray verwenden. Ein weiterer Effekt ist die erhöhte operative Komplexität, da die Anzahl der von Ihnen verwalteten Anwendungen zunimmt. In der Folge müssen Sie eine größere Zahl voneinander unabhängiger Komponenten bereitstellen.
![\[Diagramm mit einem Vergleich von monolithischen, serviceorientierten und Microservice-Architekturen\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)
## Implementierungsschritte
+ Ermitteln Sie die richtige Architektur für den Faktorwechsel oder die Entwicklung Ihrer Anwendung. SOA und Microservices bieten eine jeweils kleinere Segmentierung, die als moderne skalierbare und zuverlässige Architektur bevorzugt wird. SOA kann ein guter Kompromiss für das Erreichen einer kleineren Segmentierung sein, während die Komplexität von Microservices zum Teil vermieden wird. Weitere Informationen finden Sie in [Kompromisse bei Microservices](https://martinfowler.com/articles/microservice-trade-offs.html).
+ Wenn Ihre Workload für sie zugänglich ist und Ihre Organisation sie unterstützen kann, sollten Sie eine Microservices-Architektur verwenden, um die beste Agilität und Zuverlässigkeit zu erzielen. Weitere Informationen finden Sie in [Implementieren von Microservices in AWS.](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Sie sollten das Muster mit der Bezeichnung [*Strangler Fig* („Würgefeige“) verwenden,](https://martinfowler.com/bliki/StranglerFigApplication.html) um einen Faktorwechsel für einen Monolithen durchzuführen, bei dem Sie diesen in kleinere Komponenten aufteilen. Dies umfasst die schrittweise Ersetzung spezifischer Anwendungskomponenten durch neue Anwendungen und Services. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) dient als Ausgangspunkt für den inkrementellen Faktorwechsel. Weitere Informationen finden Sie in [Nahtlose Integration ältere On-Premises-Workloads unter Anwendung eines Strangler-Fig-Musters](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ Die Implementierung von Microservices erfordert möglicherweise einen Mechanismus für die Entdeckung von Services, damit diese verteilten Services miteinander kommunizieren können. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) kann mit serviceorientierten Architekturen verwendet werden, um eine zuverlässige Erkennung von Services und den Zugriff auf sie zu unterstützen. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) kann für die dynamische, DNS-basierte Serviceerkennung verwendet werden.
+ Wenn Sie von einem Monolithen zur SOA migrieren, kann [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) helfen, als Service-Bus die Lücke zu überbrücken, wenn Sie ältere Anwendungen in der Cloud neu entwerfen.
+ Im Fall vorhandener Monolithen mit einer einzigen, geteilten Datenbank müssen Sie entscheiden, wie Sie die Daten neu in kleineren Segmenten organisieren. Dabei kann es sich um Geschäftsbereiche, Zugriffsmuster oder Datenstrukturen handeln. An diesem Punkt des Faktorwechsel-Prozesses sollten Sie entscheiden, ob Sie eine relationale oder eine nicht relationale (NoSQL) Datenbank verwenden. Weitere Informationen finden Sie in [Von SQL zu NoSQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**Aufwand für den Implementierungsplan:** Hoch
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL03-BP02 Entwickeln von Services, die sich auf bestimmte Geschäftsbereiche und Funktionen konzentrieren](rel_service_architecture_business_domains.md)
**Zugehörige Dokumente:**
+ [Amazon API Gateway: Konfigurieren einer REST-API mit OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Was ist eine serviceorientierte Architektur?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Bounded Context (Begrenzter Kontext) (ein zentrales Muster im domänengesteuerten Design)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementieren von Microservices in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Kompromisse bei Microservices](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices – eine Definition dieses neuen Architekturbegriffs](https://www.martinfowler.com/articles/microservices.html)
+ [Microservices in AWS](https://aws.amazon.com/microservices/)
+ [Was ist AWS App Mesh?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**Zugehörige Beispiele:**
+ [Workshop für die iterative App-Modernisierung](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**Zugehörige Videos:**
+ [Kompetenz mit Microservices in AWS](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Entwickeln von Services, die sich auf bestimmte Geschäftsbereiche und Funktionen konzentrieren
Eine serviceorientierte Architektur (SOA) entwickelt Services mit genau abgegrenzten Funktionen, die von Geschäftsanforderungen definiert werden. Microservices verwenden Domänenmodelle und begrenzten Kontext, um dies weiter einzuschränken, sodass jeder Service nur eine Aufgabe erledigt. Wenn Sie sich auf bestimmte Funktionen konzentrieren, können Sie die Zuverlässigkeitsanforderungen verschiedener Services differenzieren und Investitionen genauer ausrichten. Ein präzises Geschäftsproblem und ein kleines Team, das mit jedem Service verbunden ist, ermöglichen auch eine einfachere Skalierung der Organisation.
Beim Entwerfen einer Microservice-Architektur ist es hilfreich, das Domain-Driven Design (DDD) zu verwenden, um das Geschäftsproblem mithilfe von Entitäten zu modellieren. Für die Website Amazon.com können Entitäten beispielsweise Pakete, Zustellung, Zeitplan, Preise, Rabatte und Währung enthalten. Anschließend wird das Modell mit [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html)weiter in kleinere Modelle unterteilt, wobei Entities mit ähnlichen Funktionen und Attributen in Gruppen sortiert werden. Beim Beispiel des Amazon.com-Pakets wären Lieferung und Zeitplan Teil des Versandkontexts, während Preise, Rabatte und Währung Teil des Preiskontexts sind. Wenn das Modell in Kontexte unterteilt ist, entsteht eine Vorlage für die Begrenzung von Microservices.
![\[Modellvorlage für die Begrenzung von Microservices\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/building-services.png)
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Entwerfen Sie Ihre Workload basierend auf Ihren Unternehmensdomänen und deren jeweiliger Funktionalität. Wenn Sie sich auf bestimmte Funktionen konzentrieren, können Sie die Zuverlässigkeitsanforderungen verschiedener Services differenzieren und Investitionen genauer ausrichten. Ein präzises Geschäftsproblem und ein kleines Team, das mit jedem Service verbunden ist, ermöglichen auch eine einfachere Skalierung der Organisation.
+ Führen Sie eine Domänenanalyse durch, um Ihrer Workload ein domänengesteuertes Design (DDD) zuzuordnen. Anschließend können Sie einen Architekturtyp auswählen, der die Anforderungen Ihrer Workload erfüllt.
+ [How to break a Monolith into Microservices (Aufschlüsseln eines Monolithen in Microservices)](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Getting Started with DDD when Surrounded by Legacy Systems (Erste Schritte mit DDD, wenn die Umgebung aus Legacy-Systemen besteht)](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [„Domain-Driven Design: Tackling Complexity in the Heart of Software“ von Eric Evans („Domänengesteuertes Design: Bewältigung der Komplexität im Herzen der Software“)](https://www.amazon.com/gp/product/0321125215)
+ [Implementieren von Microservices in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Zerlegen Sie Ihre Services in kleinstmögliche funktionale Einheiten. Mit der Microservices-Architektur können Sie Ihre Workload in Komponenten mit minimaler Funktionalität aufteilen, um Skalierung und Agilität der Organisation zu ermöglichen.
+ Definieren Sie die API für die Workload und ihre Designziele, Limits und sonstigen Nutzungsanforderungen.
+ Definieren Sie die API.
+ Lassen Sie in der API-Definition Raum für Wachstum und weitere Parameter.
+ Definieren Sie die gewünschten Verfügbarkeiten.
+ Sie können für Ihre API mehrere Designziele für unterschiedliche Funktionen haben.
+ Limits festlegen
+ Definieren Sie mithilfe von Tests die Limits Ihrer Workload-Funktionen.
## Ressourcen
**Relevante Dokumente:**
+ [Amazon API Gateway: Konfigurieren einer REST-API mit OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Bounded Context (Begrenzter Kontext) (ein zentrales Muster im domänengesteuerten Design)](https://martinfowler.com/bliki/BoundedContext.html)
+ [„Domain-Driven Design: Tackling Complexity in the Heart of Software“ von Eric Evans („Domänengesteuertes Design: Bewältigung der Komplexität im Herzen der Software“)](https://www.amazon.com/gp/product/0321125215)
+ [Getting Started with DDD when Surrounded by Legacy Systems (Erste Schritte mit DDD, wenn die Umgebung aus Legacy-Systemen besteht)](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [How to break a Monolith into Microservices (Aufschlüsseln eines Monolithen in Microservices)](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Implementieren von Microservices in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Kompromisse bei Microservices](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices – eine Definition dieses neuen Architekturbegriffs](https://www.martinfowler.com/articles/microservices.html)
+ [Microservices in AWS](https://aws.amazon.com/microservices/)
# REL03-BP03 Bereitstellen von Serviceverträgen pro API
Serviceverträge sind dokumentierte Vereinbarungen zur Service-Integration zwischen Teams und enthalten eine maschinenlesbare API-Definition, Ratenlimits und Leistungserwartungen. Eine Versionsverwaltungs-Strategie ermöglicht es Ihren Clients, die vorhandene API weiter zu verwenden und ihre Anwendungen auf die neuere API zu migrieren, wenn sie bereit sind. Die Bereitstellung kann jederzeit erfolgen, solange der Vertrag nicht verletzt wird. Das Serviceanbieterteam kann den Technologie-Stack seiner Wahl verwenden, um den API-Vertrag zu erfüllen. Ebenso kann der Service-Verbraucher seine eigene Technologie verwenden.
Microservices nutzen das Konzept einer serviceorientierten Architektur (SOA) und erstellen Services mit minimalem Funktionsumfang. Jeder Service veröffentlicht eine API und Designziele, Limits und andere Überlegungen zur Nutzung des Services. Damit entsteht ein *Vertrag* mit aufrufenden Anwendungen. Dies bietet die folgenden drei Vorteile:
+ Der Service muss eine Lösung für ein konkretes Geschäftsproblem bieten und verfügt über ein kleines Team, das Eigentümer des Geschäftsproblems ist. Dieser Ansatz ermöglicht eine bessere unternehmerische Skalierung.
+ Das Team kann jederzeit Bereitstellungen durchführen, solange es seine API- und weitere vertragsbasierte Anforderungen erfüllt.
+ Das Team kann einen beliebigen Technologie-Stack verwenden, solange es seine API- und weitere vertragsbasierte Anforderungen erfüllt.
Amazon API Gateway ist ein vollständig verwalteter Service, der es Entwicklern erleichtert, APIs in jeder Größenordnung zu erstellen, zu veröffentlichen, zu warten, zu überwachen und zu sichern. API Gateway übernimmt alle Aufgaben, die mit der Annahme und Verarbeitung von mitunter Hunderttausenden gleichzeitigen API-Aufrufen verbunden sind. Hierzu zählen die Verwaltung des Datenverkehrs, die Autorisierung, die Zugriffskontrolle, die Überwachung sowie die API-Versionsverwaltung. Mit der OpenAPI-Spezifikation (OAS), früher als Swagger-Spezifikation bezeichnet, können Sie Ihren API-Vertrag definieren und in API Gateway importieren. Mit API Gateway können Sie die APIs versionieren und bereitstellen.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Niedrig
## Implementierungsleitfaden
+ Stellen Sie Serviceverträge pro API bereit. Serviceverträge sind dokumentierte Vereinbarungen zur Service-Integration zwischen Teams und enthalten eine maschinenlesbare API-Definition, Ratenlimits und Leistungserwartungen.
+ [Amazon API Gateway: Konfigurieren einer REST-API mit OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ Eine Versioning-Strategie ermöglicht es Clients, die vorhandene API weiter zu verwenden und ihre Anwendungen auf die neuere API zu migrieren, wenn sie bereit sind.
+ Amazon API Gateway ist ein vollständig verwalteter Service, der es Entwicklern leicht macht, APIs beliebiger Größe zu erstellen. Mit der OpenAPI-Spezifikation (OAS), früher als Swagger-Spezifikation bezeichnet, können Sie Ihren API-Vertrag definieren und in API Gateway importieren. Mit API Gateway können Sie die APIs versionieren und bereitstellen.
## Ressourcen
**Relevante Dokumente:**
+ [Amazon API Gateway: Konfigurieren einer REST-API mit OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Bounded Context (Begrenzter Kontext) (ein zentrales Muster im domänengesteuerten Design)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementieren von Microservices in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Kompromisse bei Microservices](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices – eine Definition dieses neuen Architekturbegriffs](https://www.martinfowler.com/articles/microservices.html)
+ [Microservices in AWS](https://aws.amazon.com/microservices/)
# ZUV 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).
**Topics**
+ [REL04-BP01 Bestimmen, welches verteilte System erforderlich ist](rel_prevent_interaction_failure_identify.md)
+ [REL04-BP02 Implementieren lose gekoppelter Abhängigkeiten](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL04-BP03 Konstante Ausführung](rel_prevent_interaction_failure_constant_work.md)
+ [REL04-BP04 Festlegen aller Reaktionen als idempotent](rel_prevent_interaction_failure_idempotent.md)
# REL04-BP01 Bestimmen, welches verteilte 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.
Die schwierigsten [Herausforderungen mit verteilten Systemen](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) gelten für die harten verteilten Echtzeitsysteme, die auch als Anfrage-/Antwortservices bezeichnet werden. Die Schwierigkeiten entstehen dadurch, dass Anfragen unvorhersehbar eingehen und schnelle Antworten ausgegeben werden müssen (z. B. weil der Kunde aktiv auf die Antwort wartet). Beispiele sind Frontend-Webserver, die Auftragspipeline, Kreditkartentransaktionen, jede AWS-API und Telefonie.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Bestimmen Sie, welches verteilte 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. Angesichts des zunehmenden Wachstums und Verteilungsgrads von Systemen werden theoretische Edge-Fälle zu regelmäßigen Ereignissen.
+ [Die Amazon Builders' Library: Herausforderungen bei verteilten Systemen](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ In Echtzeit verteilte Systeme 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.
## Ressourcen
**Relevante Dokumente:**
+ [Amazon EC2: Idempotenz sicherstellen](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Die Amazon Builders' Library: Herausforderungen bei verteilten Systemen](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Die Amazon Builders' Library: Zuverlässigkeit, stetige Ausführung und eine gute Tasse Kaffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [Was ist Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Was ist Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**Relevante Videos:**
+ [AWS New York Summit 2019: Einführung in ereignisgesteuerte Architekturen und Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Kreisläufe schließen & aufgeschlossen sein: Wie man die Kontrolle über Systeme übernimmt – große und kleine ARC337 (umfasst lose Verkoppelung, konstante Ausführung, statische Stabilität)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308) (Umstieg auf ereignisgesteuerte Architekturen)](https://youtu.be/h46IquqjF3E)
# REL04-BP02 Implementieren lose gekoppelter Abhängigkeiten
Abhängigkeiten etwa zwischen Warteschlangensystemen, Streaming-Systemen, Workflows und Load Balancern sind lose gekoppelt. Eine lose Verkoppelung hilft, das Verhalten einer Komponente von anderen Komponenten zu isolieren, die von ihr abhängig sind. Dies verbessert Resilienz und Agilität.
Wenn Änderungen an einer Komponente bewirken, dass andere abhängige Komponenten ebenfalls geändert werden, sind sie *eng* gekoppelt. *Die lose* Kopplung unterbricht diese Abhängigkeit, sodass abhängige Komponenten nur die versionierte und veröffentlichte Schnittstelle kennen müssen. Die Implementierung einer losen Kopplung zwischen Abhängigkeiten isoliert einen Ausfall. So wird verhindert, dass er sich auf andere Komponenten auswirkt.
Die lose Kopplung ermöglicht Ihnen, einer Komponente zusätzlichen Code oder Funktionen hinzuzufügen und gleichzeitig das Risiko für Komponenten zu minimieren, die von ihr abhängig sind. Außerdem wird die Skalierbarkeit verbessert, da Sie die zugrunde liegende Implementierung der Abhängigkeit aufskalieren oder sogar ändern können.
Um die Ausfallsicherheit durch lose Kopplung weiter zu verbessern, legen Sie Komponenten-Interaktionen nach Möglichkeit als asynchron fest. Dieses Modell eignet sich für jede Interaktion, bei der keine sofortige Antwort benötigt wird, sondern die Bestätigung ausreicht, dass eine Anfrage registriert wurde. Es umfasst eine Komponente, die Ereignisse generiert, und eine andere Komponente, die sie konsumiert. Die beiden Komponenten lassen sich nicht durch direkte Punkt-zu-Punkt-Interaktion integrieren, sondern in der Regel über eine temporäre, robuste Speicherschicht, z. B. eine SQS-Warteschlange oder eine Streaming-Datenplattform wie Amazon Kinesis oder AWS Step Functions.
![\[Diagramm: Abhängigkeiten etwa zwischen Warteschlangensystemen und Load Balancer sind lose gekoppelt\]](http://docs.aws.amazon.com/de_de/wellarchitected/2022-03-31/framework/images/loosely-coupled-dependencies.png)
Amazon SQS-Warteschlangen und Elastic Load Balancers sind nur zwei Möglichkeiten, um eine Zwischenschicht für lose Kopplung hinzuzufügen. Ereignisgesteuerte Architekturen können auch in der AWS Cloud mithilfe von Amazon EventBridge erstellt werden, was Clients (Ereignisproduzenten) von den Services abstrahieren kann, auf die sie sich verlassen (Ereignisverbraucher). Amazon Simple Notification Service (Amazon SNS) ist eine effektive Lösung, wenn Sie Push-basiertes M-zu-N-Messaging mit hohem Durchsatz benötigen. Mithilfe von Amazon SNS-Themen können Ihre Publisher-Systeme Nachrichten zur parallelen Verarbeitung an eine große Anzahl von Abonnenten-Endpunkten senden.
Warteschlangen bieten zwar mehrere Vorteile, doch Anfragen, die älter als ein Schwellenwert sind (oft Sekunden), sollten in den meisten harten Echtzeitsystemen als veraltet betrachtet (der Client hat aufgegeben und wartet nicht mehr auf eine Antwort) und nicht verarbeitet werden. Auf diese Weise können stattdessen neuere (und wahrscheinlich noch gültige Anfragen) verarbeitet werden.
**Gängige Antimuster:**
+ Bereitstellen eines Singletons im Rahmen einer Workload.
+ APIs werden zwischen Workload-Ebenen direkt aufgerufen, ohne Möglichkeit eines Failovers oder einer asynchronen Verarbeitung der Anfrage.
**Vorteile der Einführung dieser bewährten Methode:** Eine lose Verkoppelung hilft, das Verhalten einer Komponente von anderen Komponenten zu isolieren, die von ihr abhängig sind. Dies verbessert Resilienz und Agilität. Fehler in einer Komponente sind von anderen isoliert.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
+ Implementieren Sie lose gekoppelte Abhängigkeiten. Abhängigkeiten etwa zwischen Warteschlangensystemen, Streaming-Systemen, Workflows und Load Balancern sind lose gekoppelt. Eine lose Verkoppelung hilft, das Verhalten einer Komponente von anderen Komponenten zu isolieren, die von ihr abhängig sind. Dies verbessert Resilienz und Agilität.
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308) (Umstieg auf ereignisgesteuerte Architekturen)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Was ist Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Was ist Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ Mit Amazon EventBridge können Sie ereignisgesteuerte Architekturen entwickeln, die lose verkoppelt und verteilt sind.
+ [AWS New York Summit 2019: Einführung in ereignisgesteuerte Architekturen und Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ Wenn Änderungen für eine Komponente Änderungen für andere Komponenten auslöst, die von ihr abhängig sind, sind sie eng verkoppelt. 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 ist für Interaktionen geeignet, die keine sofortigen Reaktionen erfordern und für die die Bestätigung der Registrierung einer Anfrage ausreichend ist.
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304) (Skalierbare serverlose ereignisgesteuerte Anwendungen, die Amazon SQS und Lambda nutzen)](https://youtu.be/2rikdPIFc_Q)
## Ressourcen
**Relevante Dokumente:**
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308) (Umstieg auf ereignisgesteuerte Architekturen)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon EC2: Idempotenz sicherstellen](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Die Amazon Builders' Library: Herausforderungen für verteilte Systeme](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Die Amazon Builders' Library: Zuverlässigkeit, stetige Ausführung und eine gute Tasse Kaffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [Was ist Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Was ist Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**Relevante Videos:**
+ [AWS New York Summit 2019: Einführung in ereignisgesteuerte Architekturen und Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Kreisläufe schließen & aufgeschlossen sein: Wie man die Kontrolle über Systeme übernimmt – große und kleine ARC337 (umfasst lose Verkoppelung, konstante Ausführung, statische Stabilität)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308) (Umstieg auf ereignisgesteuerte Architekturen)](https://youtu.be/h46IquqjF3E)
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304) (Skalierbare serverlose ereignisgesteuerte Anwendungen, die Amazon SQS und Lambda nutzen)](https://youtu.be/2rikdPIFc_Q)
# REL04-BP03 Konstante Ausführung
Bei größeren, schnellen Lastveränderungen können Systeme ausfallen. Wenn Ihre Workload beispielsweise eine Zustandsprüfung ausführt, die den Zustand vieler tausend Server überwacht, sollte sie jedes Mal die gleiche Nutzlast senden (einen vollständigen Snapshot des aktuellen Status). Unabhängig davon, ob keine Server oder alle Server ausfallen, führt das System für die Zustandsprüfung die Aufgaben stetig und ohne große, schnelle Änderungen aus.
Wenn das Zustandsprüfungssystem beispielsweise 100 000 Server überwacht, ist die Last darauf angesichts der normalerweise geringen Serverausfallrate nominal. Wenn jedoch ein großes Ereignis die Hälfte dieser Server fehlerhaft macht, wäre das Zustandsprüfungssystem überfordert, wenn es versucht, Benachrichtigungssysteme zu aktualisieren und den Status an seine Clients zu kommunizieren. 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 konstant und große, schnelle Änderungen stellen keine Bedrohung für die Systemstabilität dar. Auf diese Weise führt Amazon Route 53 Zustandsprüfungen für Endpunkte (wie z. B. IP-Adressen) durch, um zu ermitteln, wie Endbenutzer an diese weitergeleitet werden.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Niedrig
## Implementierungsleitfaden
+ Führen Sie Aufgaben konstant aus, sodass auch bei großen, schnellen Lastveränderungen keine Fehler auf Systemen auftreten.
+ Implementieren Sie lose gekoppelte Abhängigkeiten. Abhängigkeiten etwa zwischen Warteschlangensystemen, Streaming-Systemen, Workflows und Load Balancern sind lose gekoppelt. Eine lose Verkoppelung hilft, das Verhalten einer Komponente von anderen Komponenten zu isolieren, die von ihr abhängig sind. Dies verbessert Resilienz und Agilität.
+ [Die Amazon Builders' Library: Zuverlässigkeit, stetige Ausführung und eine gute Tasse Kaffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS re:Invent 2018: Kreisläufe schließen & aufgeschlossen sein: Wie man die Kontrolle über große und kleine Systeme übernimmt ARC337 (umfasst konstante Ausführung)](https://youtu.be/O8xLxNje30M?t=2482)
+ Beispiel: Zustandsprüfungssystem, das 100.000 Server überwacht: Entwickeln Sie die Workloads so, dass die Nutzlastgrößen unabhängig von der Anzahl der Erfolge oder Ausfälle konstant bleiben.
## Ressourcen
**Ähnliche Dokumente:**
+ [Amazon EC2: Idempotenz sicherstellen](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Die Amazon Builders' Library: Herausforderungen für verteilte Systeme](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Die Amazon Builders' Library: Zuverlässigkeit, stetige Ausführung und eine gute Tasse Kaffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Ähnliche Videos:**
+ [AWS New York Summit 2019: Einführung in ereignisgesteuerte Architekturen und Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Kreisläufe schließen & aufgeschlossen sein: Wie man die Kontrolle über große und kleine Systeme übernimmt ARC337 (umfasst konstante Ausführung)](https://youtu.be/O8xLxNje30M?t=2482)
+ [AWS re:Invent 2018: Kreisläufe schließen & aufgeschlossen sein: Wie man die Kontrolle über Systeme übernimmt – große und kleine ARC337 (umfasst lose Verkoppelung, konstante Ausführung, statische Stabilität)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308) (Umstieg auf ereignisgesteuerte Architekturen)](https://youtu.be/h46IquqjF3E)
# REL04-BP04 Festlegen aller Reaktionen als idempotent
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.
In einem verteilten System ist es einfach, eine Aktion höchstens einmal (der Client stellt nur eine Anforderung) oder mindestens einmal (Anforderung so lange, bis der Client erfolgreich ist) durchzuführen. Es ist jedoch schwer zu gewährleisten, dass eine Aktion idempotent ist, was bedeutet, dass sie *genau* einmal ausgeführt wird, sodass das Erstellen mehrerer identischer Anfragen den gleichen Effekt hat wie das Erstellen einer einzelnen Anfrage. Durch die Verwendung von idempotenten Tokens in APIs können Services einmal oder mehrmals eine sich verändernde Anfrage erhalten, ohne dass doppelte Datensätze erstellt werden oder sonstige Probleme entstehen.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel
## Implementierungsleitfaden
+ Legen Sie alle Reaktionen als idempotent fest. 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: Idempotenz sicherstellen](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
## Ressourcen
**Ähnliche Dokumente:**
+ [Amazon EC2: Idempotenz sicherstellen](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Die Amazon Builders' Library: Herausforderungen bei verteilten Systemen](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Die Amazon Builders' Library: Zuverlässigkeit, stetige Ausführung und eine gute Tasse Kaffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Ähnliche Videos:**
+ [AWS New York Summit 2019: Einführung in ereignisgesteuerte Architekturen und Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Kreisläufe schließen & aufgeschlossen sein: Wie man die Kontrolle über Systeme übernimmt – große und kleine ARC337 (umfasst lose Verkoppelung, konstante Ausführung, statische Stabilität)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308) (Umstieg auf ereignisgesteuerte Architekturen)](https://youtu.be/h46IquqjF3E)
# 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