# Workload-Architektur
Ausgangspunkt für eine zuverlässige Workload sind vorab getroffene Designentscheidungen für Software und Infrastruktur. Ihre Auswahl in puncto Architektur wirkt sich in allen sechs Well-Architected-Säulen auf das Verhalten der Workload aus. Zur Gewährleistung von Zuverlässigkeit sind bestimmte Muster zu befolgen.
In den folgenden Abschnitten werden bewährte Methoden erläutert, die für diese Muster eingehalten werden sollten, damit eine hohe Zuverlässigkeit erzielt wird.
**Topics**
+ [Entwerfen Ihrer Workload-Servicearchitektur](design-your-workload-service-architecture.md)
+ [Entwerfen von Interaktionen in einem verteilten System, um Ausfälle zu vermeiden](design-interactions-in-a-distributed-system-to-prevent-failures.md)
+ [Entwerfen von Interaktionen in einem verteilten System, um Ausfälle abzumildern oder zu verkraften](design-interactions-in-a-distributed-system-to-mitigate-or-withstand-failures.md)
# Entwerfen Ihrer Workload-Servicearchitektur
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.
Schnittstellen für serviceorientierte Architektur (SOA) verwenden gängige Kommunikationsstandards, sodass sie schnell in neue Workloads integriert werden können. SOA hat die Erstellung monolithischer Architekturen ersetzt, die aus voneinander abhängigen, unteilbaren Einheiten bestehen.
AWS hat schon immer SOA verwendet, aber jetzt setzen wir bei der Entwicklung unserer Systeme auf Microservices. Microservices bieten eine Vielzahl attraktiver Qualitäten. Der größte Nutzen für die Verfügbarkeit liegt jedoch darin, dass Microservices kleiner und einfacher sind. Mit Microservices können Sie die Verfügbarkeit verschiedener Services differenzieren und damit den Fokus von Investitionen auf die Microservices mit dem größten Verfügbarkeitsbedarf legen. Beispiel: Um Seiten mit Produktinformationen auf Amazon.com („Detailseiten“) bereitzustellen, werden Hunderte von Microservices aufgerufen, um einzelne Teile der Seite zu erstellen. Es gibt einige Services, die zur Verfügung stehen müssen, um Preis- und Produktdetails bereitzustellen, die große Mehrheit der Inhalte auf der Seite können jedoch einfach ausgeschlossen werden, wenn der Service nicht verfügbar ist. Selbst Elemente wie Fotos und Rezensionen sind im Prinzip nicht erforderlich, um eine Umgebung zu schaffen, in der ein Kunde ein Produkt kaufen kann.
**Topics**
+ [REL03-BP01 Wählen Sie, wie Sie Ihre Arbeitslast segmentieren möchten](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Entwickeln von Services, die sich auf bestimmte Geschäftsdomänen und Funktionen konzentrieren](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Stellen Sie Serviceverträge bereit per API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Wählen Sie, wie Sie Ihre Arbeitslast segmentieren möchten
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. Je nach Ihren Anwendungsanforderungen kann es sich dabei, wenn möglich, um eine Kombination aus einer serviceorientierten Architektur (SOA) und Microservices handeln. 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 Nutzung dieser bewährten Methode:**
+ 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, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
Wählen Sie Ihren Architekturtyp basierend auf der Segmentierung Ihres Workloads aus. Wählen Sie eine SOA oder eine Microservices-Architektur (oder in einigen seltenen Fällen eine monolithische Architektur). Selbst wenn Sie sich dafür entscheiden, mit einer Monolith-Architektur zu beginnen, müssen Sie sicherstellen, dass diese modular ist und sich letztendlich zu SOA Microservices weiterentwickeln kann, wenn Ihr Produkt mit der Benutzerakzeptanz skaliert. SOAund Microservices bieten jeweils eine geringere Segmentierung, was als moderne, skalierbare und zuverlässige Architektur bevorzugt wird. Allerdings müssen auch Kompromisse berücksichtigt werden, insbesondere bei der Implementierung einer Microservice-Architektur.
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/latest/reliability-pillar/images/monolith-soa-microservices-comparison.png)
## Implementierungsschritte
+ Ermitteln Sie die richtige Architektur für den Faktorwechsel oder die Entwicklung Ihrer Anwendung. SOAund Microservices bieten jeweils eine geringere Segmentierung, was als moderne, skalierbare und zuverlässige Architektur bevorzugt wird. SOAkann ein guter Kompromiss sein, um eine kleinere Segmentierung zu erreichen und gleichzeitig einige der Komplexitäten von Microservices zu vermeiden. Weitere Informationen finden Sie unter [Microservice Trade-Offs](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 unter Implementierung von Microservices auf. 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 unter [Seamlessly migrate on-premises legacy workloads using a strangler pattern](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ Für die Implementierung von Microservices ist möglicherweise ein Service Discovery-Mechanismus erforderlich, der es diesen verteilten Diensten ermöglicht, miteinander zu kommunizieren. [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 und den zuverlässigen Zugriff auf Dienste zu ermöglichen. [AWS Cloud Map](https://aws.amazon.com/cloud-map/)kann auch für die dynamische, DNS basierte Serviceerkennung verwendet werden.
+ Wenn Sie von einem Monolith zu Amazon MQ migrierenSOA, kann [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) Ihnen helfen, die Lücke als Service Bus bei der Neugestaltung älterer Anwendungen in der Cloud zu schließen.
+ 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 Refactoring-Prozesses sollten Sie sich dafür entscheiden, mit einem relationalen oder einem nicht-relationalen Datenbanktyp (Nein) fortzufahren. SQL [Weitere Informationen finden Sie unter Von bis Nein. SQL SQL](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äftsdomänen und Funktionen konzentrieren](rel_service_architecture_business_domains.md)
**Zugehörige Dokumente:**
+ [Amazon API Gateway: Konfiguration eines REST API mit Open API](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 (a central pattern in Domain-Driven Design)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementierung von Microservices auf AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Microservice Trade-Offs](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices - a definition of this new architectural term](https://www.martinfowler.com/articles/microservices.html)
+ [Microservices auf 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:**
+ [Exzellenz mit Microservices erreichen AWS](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Entwickeln von Services, die sich auf bestimmte Geschäftsdomänen und Funktionen konzentrieren
Eine serviceorientierte Architektur (SOA) definiert Services mit genau abgegrenzten Funktionen, die von Geschäftsanforderungen definiert werden. Microservices verwenden Domain-Modelle und begrenzten Kontext, um Servicegrenzen entlang der Grenzen des Geschäftskontextes zu ziehen. Die Konzentration auf Geschäftsdomänen und Funktionen hilft Teams dabei, unabhängige Zuverlässigkeitsanforderungen für ihre Services zu definieren. Begrenzte Kontexte isolieren und kapseln die Geschäftslogik, sodass Teams besser überlegen können, wie mit Fehlern umzugehen ist.
**Gewünschtes Ergebnis:** Ingenieure und geschäftliche Interessenvertreter definieren gemeinsam begrenzte Kontexte und verwenden sie, um Systeme als Services zu entwerfen, die bestimmte Geschäftsfunktionen erfüllen. Diese Teams verwenden etablierte Praktiken wie Event Storming, um Anforderungen zu definieren. Neue Anwendungen sind als Services mit klar definierten Grenzen und losen Verkopplungen definiert. Bestehende Monolithen werden in [begrenzte Kontexte](https://martinfowler.com/bliki/BoundedContext.html) zerlegt und Systemdesigns bewegen sich in Richtung SOA- oder Microservice-Architekturen Bei der Refaktorisierung von Monolithen kommen etablierte Ansätze wie Bubble-Kontexte und Monolith-Zerlegung zur Anwendung.
Domain-orientierte Services werden als ein oder mehrere Prozesse ausgeführt, die keinen gemeinsamen Zustand haben. Sie reagieren selbstständig auf Nachfrageschwankungen und behandeln Störszenarien anhand Domain-spezifischer Anforderungen.
**Typische Anti-Muster:**
+ Teams werden für bestimmte technische Bereiche wie UI und UX, Middleware oder Datenbank gebildet, anstatt für bestimmte Geschäftsdomänen.
+ Anwendungen erstrecken sich über die Zuständigkeiten der einzelnen Domains. Services, die sich über begrenzte Kontexte erstrecken, können schwieriger zu verwalten sein, erfordern einen größeren Testaufwand und erfordern die Teilnahme mehrerer Domain-Teams an Softwareupdates.
+ Domänenabhängigkeiten wie Domain-Entity-Bibliotheken werden von allen Services gemeinsam genutzt, sodass Änderungen für eine Servicedomäne Änderungen an anderen Service-Domänen erfordern.
+ Serviceverträge und Geschäftslogik formulieren Entitäten nicht in einer gemeinsamen und konsistenten Domain-Sprache, was zu Übersetzungsebenen führt, die Systeme komplizieren und den Debugging-Aufwand erhöhen.
**Vorteile der Nutzung dieser bewährten Methode:** Anwendungen sind als unabhängige Services konzipiert, die durch Geschäftsdomänen begrenzt sind und eine gemeinsame Geschäftssprache verwenden. Services sind unabhängig voneinander testbar und einsetzbar. Services erfüllen die Domain-spezifischen Resilienzanforderungen für die implementierte Domain.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
Domain-driven Design (DDD, domänengesteuertes Design) ist der grundlegende Ansatz für das Entwerfen und Entwickeln von Software rund um Geschäftsdomänen. Bei der Entwicklung von Services, die sich auf Geschäftsdomänen konzentrieren, ist es hilfreich, mit einem vorhandenen Framework zu arbeiten. Wenn Sie mit bestehenden monolithischen Anwendungen arbeiten, können Sie die Vorteile von Zerlegungsmustern nutzen, die etablierte Techniken zur Modernisierung von Anwendungen in Services bereitstellen.
![\[Flussdiagramm, das den Ansatz des Domain-gesteuerten Designs darstellt\]](http://docs.aws.amazon.com/de_de/wellarchitected/latest/reliability-pillar/images/domain-driven-decision.png)
## Implementierungsschritte
+ Teams können [Event-Storming-Workshops](https://serverlessland.com/event-driven-architecture/visuals/event-storming) veranstalten, um rasch Ereignisse, Befehle, Mengen und Domänen in einem unkomplizierten Notizformat zu sammeln.
+ Sobald Domain-Entitäten und -Funktionen in einem Domain-Kontext gebildet wurden, können Sie Ihre Domain mithilfe eines [begrenzten Kontexts](https://martinfowler.com/bliki/BoundedContext.html), weiter in kleinere Modelle unterteilt, wobei Entitäten mit ähnlichen Funktionen und Attributen in Gruppen sortiert werden. Wenn das Modell in Kontexte unterteilt ist, entsteht eine Vorlage für die Begrenzung von Microservices.
+ Für die Website Amazon.com können Entitäten beispielsweise Pakete, Zustellung, Zeitplan, Preise, Rabatte und Währung enthalten.
+ Paket, Zustellung und Zeitplan werden dem Versandkontext zugeordnet, während Preis, Rabatt und Währung dem Preiskontext zugeordnet sind.
+ Unter [Decomposing monoliths into microservices](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html) wird das Muster für das Refactoring von Microservices skizziert. Die Verwendung von Mustern für die Unterteilung nach Geschäftsfähigkeit, Subdomäne oder Transaktion passt gut zu Domain-gesteuerten Ansätzen.
+ Taktische Techniken wie der [Bubble-Kontext](https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) ermöglichen es Ihnen, DDD in bestehenden oder älteren Anwendungen einzuführen, ohne dass Sie im Voraus Änderungen vornehmen und sich voll und ganz auf DDD verlassen müssen. Bei einem Bubble-Kontext-Ansatz wird mithilfe von Service-Mapping und -koordination ein kleiner begrenzter Kontext oder eine [Ebene zur Korruptionsbekämpfung](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context) erstellt, die das neu definierte Domain-Modell vor äußeren Einflüssen schützt.
Nachdem die Teams eine Domain-Analyse durchgeführt und Entitäten und Serviceverträge definiert haben, können sie AWS-Services nutzen, um ihr Domain-gesteuertes Design als Cloud-basierte Services zu implementieren.
+ Beginnen Sie Ihre Entwicklung, indem Sie Tests definieren, die die Geschäftsregeln Ihrer Domain anwenden. Test-driven Development (TDD, Testgetriebene Entwicklung) und Behavior-driven Development (BDD, verhaltensgetriebene Entwicklung) helfen Teams dabei, die Services auf die Lösung von Geschäftsproblemen zu konzentrieren.
+ Wählen Sie [AWS-Services](https://aws.amazon.com/microservices/) die den Anforderungen Ihrer Geschäfts-Domain und Ihrer [Microservice-Architektur am besten entsprechen](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html):
+ [AWS Serverless](https://aws.amazon.com/serverless/) ermöglicht es Ihrem Team, sich auf eine bestimmte Domain-Logik zu konzentrieren, anstatt Server und Infrastruktur zu verwalten.
+ [Container in AWS](https://aws.amazon.com/containers/) vereinfachen die Verwaltung Ihrer Infrastruktur, sodass Sie sich auf Ihre Domain-Anforderungen konzentrieren können.
+ [Speziell entwickelte Datenbanken](https://aws.amazon.com/products/databases/) helfen Ihnen dabei, Ihre Domain-Anforderungen dem am besten geeigneten Datenbanktyp zuzuordnen.
+ [Hexagonale Architekturen auf AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html) skizzieren ein Framework zur Integration von Geschäftslogik in Services. Dabei wird rückwärts von der Geschäfts-Domain aus gearbeitet, um funktionale Anforderungen zu erfüllen und dann Integrationsadapter zu implementieren. Muster, die Schnittstellendetails von der Geschäftslogik mit AWS-Services trennen, helfen Teams, sich auf die Funktionalität der Domain zu konzentrieren und die Softwarequalität zu verbessern.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL03-BP01 Wählen Sie, wie Sie Ihre Arbeitslast segmentieren möchten](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP03 Stellen Sie Serviceverträge bereit per API](rel_service_architecture_api_contracts.md)
**Zugehörige Dokumente:**
+ [AWS Microservices](https://aws.amazon.com/microservices/)
+ [Implementieren von Microservices in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [How to break a Monolith into Microservices](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Getting Started with DDD when Surrounded by Legacy Systems](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [ Domain-Driven Design: Tackling Complexity in the Heart of Software ](https://www.amazon.com/gp/product/0321125215)
+ [ Building hexagonal architectures on AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html)
+ [ Decomposing monoliths into microservices ](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html)
+ [ Event Storming ](https://serverlessland.com/event-driven-architecture/visuals/event-storming)
+ [ Messages Between Bounded Contexts ](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context)
+ [ Microservices ](https://www.martinfowler.com/articles/microservices.html)
+ [ Testgetriebene Entwicklung ](https://en.wikipedia.org/wiki/Test-driven_development)
+ [ Verhaltensgetriebene Entwicklung ](https://en.wikipedia.org/wiki/Behavior-driven_development)
**Zugehörige Beispiele:**
+ [ Designing Cloud Native Microservices on AWS (from DDD/EventStormingWorkshop) ](https://github.com/aws-samples/designing-cloud-native-microservices-on-aws/tree/main)
**Zugehörige Tools:**
+ [AWS Cloud-Datenbanken ](https://aws.amazon.com/products/databases/)
+ [Serverless in AWS](https://aws.amazon.com/serverless/)
+ [ Container in AWS](https://aws.amazon.com/containers/)
# REL03-BP03 Stellen Sie Serviceverträge bereit per API
Dienstleistungsverträge sind dokumentierte Vereinbarungen zwischen API Herstellern und Verbrauchern, die in einer maschinenlesbaren API Definition definiert sind. Eine Strategie zur Versionierung von Verträgen ermöglicht es den Verbrauchern, die vorhandenen weiterhin zu verwenden API und ihre Anwendungen auf eine neuere zu migrieren, API sobald sie bereit sind. Die Bereitstellung durch den Produzenten kann jederzeit erfolgen, solange der Vertrag eingehalten wird. Serviceteams können den Technologie-Stack ihrer Wahl verwenden, um den API Vertrag zu erfüllen.
**Gewünschtes Ergebnis:** Anwendungen, die mit serviceorientierten Architekturen oder Microservice-Architekturen erstellt wurden, können unabhängig voneinander betrieben werden und verfügen gleichzeitig über eine integrierte Laufzeitabhängigkeit. Änderungen, die an einem API Verbraucher oder Hersteller vorgenommen werden, beeinträchtigen nicht die Stabilität des Gesamtsystems, wenn beide Seiten einen gemeinsamen Vertrag einhalten. API Komponenten, die über den Service kommunizieren, APIs können unabhängige funktionale Releases durchführen, Upgrades auf Laufzeitabhängigkeiten durchführen oder ein Failover zu einem Disaster Recovery (DR) -Standort durchführen, ohne sich gegenseitig zu beeinträchtigen. Darüber hinaus können spezialisierte Services unabhängig voneinander skaliert werden und können dabei den Ressourcenbedarf absorbieren, ohne dass andere Services ebenfalls skaliert werden müssen.
**Typische Anti-Muster:**
+ Ein Dienst wird APIs ohne stark typisierte Schemas erstellt. Dies führt dazuAPIs, dass sie nicht zum Generieren von API Bindungen und Nutzlasten verwendet werden können, die nicht programmgesteuert validiert werden können.
+ Es wird keine Versionierungsstrategie angewendet, die API Verbraucher dazu zwingt, Updates und Releases vorzunehmen, andernfalls scheitern sie, wenn sich die Serviceverträge weiterentwickeln.
+ Fehlermeldungen, die Details der zugrundeliegenden Service-Implementierung preisgeben, anstatt Integrationsfehler im Kontext und in der Sprache der Domain zu beschreiben.
+ Keine Nutzung von API Verträgen zur Entwicklung von Testfällen und API Scheinimplementierungen, um unabhängige Tests von Servicekomponenten zu ermöglichen.
**Vorteile der Einführung dieser bewährten Methode:** Verteilte Systeme, die aus Komponenten bestehen, die über API Serviceverträge miteinander kommunizieren, können die Zuverlässigkeit verbessern. Entwickler können potenzielle Probleme frühzeitig im Entwicklungsprozess catch, indem sie während der Kompilierung eine Typprüfung durchführen, um sicherzustellen, dass Anfragen und Antworten dem API Vertrag entsprechen und die erforderlichen Felder vorhanden sind. APIVerträge bieten eine klare, sich selbst dokumentierende Schnittstelle für eine bessere Interoperabilität zwischen verschiedenen Systemen APIs und Programmiersprachen und sorgen für eine bessere Interoperabilität.
**Risikostufe bei fehlender Befolgung dieser bewährten Methode:** Mittel
## Implementierungsleitfaden
Sobald Sie Geschäftsbereiche identifiziert und Ihre Workload-Segmentierung festgelegt haben, können Sie Ihren Service weiterentwickeln. APIs Definieren Sie zunächst maschinenlesbare Serviceverträge für APIs und implementieren Sie anschließend eine API Versionierungsstrategie. Wenn Sie bereit sindREST, Dienste über gängige Protokolle wie GraphQL oder asynchrone Ereignisse zu integrieren, können Sie AWS Dienste in Ihre Architektur integrieren, um Ihre Komponenten mit stark API typisierten Verträgen zu integrieren.
**AWS Dienste für Serviceverträge API**
Integrieren Sie AWS Services wie [Amazon API Gateway](https://aws.amazon.com/api-gateway/) und [Amazon EventBridge](https://aws.amazon.com/eventbridge/) in Ihre Architektur [AWS AppSync](https://aws.amazon.com/appsync/), um API Serviceverträge in Ihrer Anwendung zu verwenden. Amazon API Gateway unterstützt Sie bei der direkten Integration mit nativen AWS Diensten und anderen Webdiensten. APIGateway unterstützt die [APIOpen-Spezifikation](https://github.com/OAI/OpenAPI-Specification) und Versionierung. AWS AppSync ist ein verwalteter [GraphQL-Endpunkt](https://graphql.org/), den Sie konfigurieren, indem Sie ein GraphQL-Schema definieren, um eine Serviceschnittstelle für Abfragen, Mutationen und Abonnements zu definieren. Amazon EventBridge verwendet Ereignisschemas, um Ereignisse zu definieren und Codebindungen für Ihre Ereignisse zu generieren.
## Implementierungsschritte
+ Definieren Sie zunächst einen Vertrag für Ihren. API Ein Vertrag drückt die Fähigkeiten eines aus und API definiert stark typisierte Datenobjekte und Felder für die API Eingabe und Ausgabe.
+ Bei der Konfiguration APIs in API Gateway können Sie Open API Specifications für Ihre Endgeräte importieren und exportieren.
+ Der [Import einer offenen API Definition](https://docs.aws.amazon.com/apigateway/latest/developerguide/import-edge-optimized-api.html) vereinfacht die Erstellung Ihrer Definition API und kann als Codetools wie [AWS Serverless Application Model](https://aws.amazon.com/serverless/sam/)und [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/)in die AWS Infrastruktur integriert werden.
+ Das [Exportieren einer API Definition](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html) vereinfacht die Integration mit API Testtools und bietet dem Servicenutzer eine Integrationsspezifikation.
+ Sie können APIs GraphQL definieren und verwalten, AWS AppSync indem Sie [eine GraphQL-Schemadatei definieren](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html), um Ihre Vertragsschnittstelle zu generieren und die Interaktion mit komplexen REST Modellen, mehreren Datenbanktabellen oder älteren Diensten zu vereinfachen.
+ [AWS Amplify](https://aws.amazon.com/amplify/)Projekte, die integriert sind, AWS AppSync generieren stark typisierte JavaScript Abfragedateien zur Verwendung in Ihrer Anwendung sowie eine AWS AppSync GraphQL-Clientbibliothek für [Amazon DynamoDB-Tabellen](https://aws.amazon.com/dynamodb/).
+ Wenn Sie Serviceereignisse von Amazon nutzen EventBridge, entsprechen Ereignisse Schemas, die bereits in der Schemaregistrierung vorhanden sind oder die Sie mit der Open API Spec definieren. Mit einem in der Registrierung definierten Schema können Sie auch Client-Bindungen aus dem Schemavertrag generieren, um Ihren Code in Ereignisse zu integrieren.
+ Erweiterung oder Versionierung Ihrer. API Das Erweitern von API ist eine einfachere Option, wenn Felder hinzugefügt werden, die mit optionalen Feldern oder Standardwerten für Pflichtfelder konfiguriert werden können.
+ JSONbasierte Verträge für Protokolle wie REST GraphQL können sich gut für eine Vertragsverlängerung eignen.
+ XMLVerträge, die auf Protokollen basieren, SOAP sollten mit den Nutzern der Dienste getestet werden, um festzustellen, ob eine Vertragsverlängerung durchführbar ist.
+ Bei der Versionierung einer sollten Sie die Implementierung einer Proxy-Versionierung in Betracht ziehenAPI, bei der eine Fassade zur Unterstützung von Versionen verwendet wird, sodass die Logik in einer einzigen Codebasis verwaltet werden kann.
+ Mit API Gateway können Sie [Anfragen- und Antwortzuordnungen](https://docs.aws.amazon.com/apigateway/latest/developerguide/request-response-data-mappings.html#transforming-request-response-body) verwenden, um die Übernahme von Vertragsänderungen zu vereinfachen, indem Sie eine Fassade einrichten, um Standardwerte für neue Felder bereitzustellen oder entfernte Felder aus einer Anfrage oder Antwort zu entfernen. Mit diesem Ansatz kann der zugrunde liegende Service mit einer einzelnen Codebasis betrieben werden.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL03-BP01 Wählen Sie, wie Sie Ihre Arbeitslast segmentieren möchten](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Entwickeln von Services, die sich auf bestimmte Geschäftsdomänen und Funktionen konzentrieren](rel_service_architecture_business_domains.md)
+ [REL04-BP02 Lose gekoppelte Abhängigkeiten implementieren](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL05-BP03 Steuerung und Begrenzung von Wiederholungsaufrufen](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP05 Client-Timeouts festlegen](rel_mitigate_interaction_failure_client_timeouts.md)
**Zugehörige Dokumente:**
+ [Was ist eine API (Anwendungsprogrammierschnittstelle)?](https://aws.amazon.com/what-is/api/)
+ [Implementierung von Microservices auf AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [Microservice Trade-Offs](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [ Microservices - a definition of this new architectural term ](https://www.martinfowler.com/articles/microservices.html)
+ [Microservices auf AWS](https://aws.amazon.com/microservices/)
+ [Ich arbeite mit API Gateway-Erweiterungen für Open API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-swagger-extensions.html)
+ [APIOpen-Spezifikation](https://github.com/OAI/OpenAPI-Specification)
+ [ GraphQL: Schemata und Typen ](https://graphql.org/learn/schema/)
+ [ EventBridge Amazon-Codebindungen](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-schema-code-bindings.html)
**Zugehörige Beispiele:**
+ [Amazon API Gateway: Konfiguration eines REST API mit Open API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [CRUDAnwendung Amazon API Gateway to Amazon DynamoDB mithilfe von Open API](https://serverlessland.com/patterns/apigw-ddb-openapi-crud?ref=search)
+ [Moderne Anwendungsintegrationsmuster in einem serverlosen Zeitalter: API Gateway Service Integration](https://catalog.us-east-1.prod.workshops.aws/workshops/be7e1ee7-b91f-493d-93b0-8f7c5b002479/en-US/labs/asynchronous-request-response-poll/api-gateway-service-integration)
+ [Implementierung einer Header-basierten API Gateway-Versionierung mit Amazon CloudFront](https://aws.amazon.com/blogs/compute/implementing-header-based-api-gateway-versioning-with-amazon-cloudfront/)
+ [AWS AppSync: Building a client application ](https://docs.aws.amazon.com/appsync/latest/devguide/building-a-client-app.html#aws-appsync-building-a-client-app)
**Zugehörige Videos:**
+ [Verwenden von Open API in AWS SAM zur Verwaltung von Gateway API](https://www.youtube.com/watch?v=fet3bh0QA80)
**Zugehörige Tools:**
+ [APIAmazon-Gateway](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [Amazon EventBridge](https://aws.amazon.com/eventbridge/)
# Entwerfen von Interaktionen in einem verteilten System, um Ausfälle zu vermeiden
Verteilte Systeme sind auf Kommunikationsnetzwerke angewiesen, um Komponenten wie Server oder Services miteinander zu verbinden. Ihre Workload muss trotz Datenverlust oder Latenz in diesen Netzwerken zuverlässig funktionieren. Die Komponenten des verteilten Systems müssen so funktionieren, dass sie sich nicht negativ auf andere Komponenten oder die Workload auswirken. Diese bewährten Methoden verhindern Ausfälle und verbessern die mittlere Betriebsdauer zwischen Ausfällen (MTBF).
**Topics**
+ [REL04-BP01 Bestimmen Sie, von welcher Art von verteilten Systemen Sie abhängig sind](rel_prevent_interaction_failure_identify.md)
+ [REL04-BP02 Lose gekoppelte Abhängigkeiten implementieren](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL04-BP03 Arbeite ständig](rel_prevent_interaction_failure_constant_work.md)
+ [REL04-BP04 Festlegen von Mutationsoperationen als idempotent](rel_prevent_interaction_failure_idempotent.md)
# REL04-BP01 Bestimmen Sie, von welcher Art von verteilten Systemen Sie abhängig sind
Verteilte Systeme verwenden die synchrone, asynchrone oder Stapelverarbeitung. Synchrone Systeme müssen Anfragen so schnell wie möglich verarbeiten und miteinander kommunizieren, indem sie synchrone Anfrage- und Antwortaufrufe mithilfe von HTTP/S-, REST- oder RPC-Protokollen (Remote Procedure Call) durchführen. Asynchrone Systeme kommunizieren miteinander, indem sie Daten asynchron über einen Zwischenservice austauschen, ohne einzelne Systeme zu koppeln. Systeme mit Stapelverarbeitung empfangen eine große Menge an Eingabedaten, führen automatisierte Datenprozesse ohne menschliches Eingreifen aus und generieren Ausgabedaten.
**Gewünschtes Ergebnis**: Entwerfen Sie einen Workload, der effektiv mit synchronen, asynchronen und Batch-Abhängigkeiten interagiert.
**Typische Anti-Muster:**
+ Der Workload wartet auf unbestimmte Zeit auf eine Antwort von seinen Abhängigkeiten, was dazu führen kann, dass Workload-Clients das Zeitlimit überschreiten und nicht wissen, ob ihre Anfrage eingegangen ist.
+ Der Workload verwendet eine Kette von abhängigen Systemen, die sich gegenseitig synchron aufrufen. Der Erfolg der gesamten Kette hängt davon ab, dass jedes System verfügbar ist und Anfragen erfolgreich verarbeitet, was zu instabilem Verhalten und eingeschränkter Gesamtverfügbarkeit führen kann.
+ Der Workload kommuniziert asynchron mit seinen Abhängigkeiten und stützt sich auf das Konzept der garantierten einmaligen Zustellung von Nachrichten, obwohl es oft immer noch möglich ist, doppelte Nachrichten zu empfangen.
+ Der Workload verwendet keine geeigneten Tools zur Batchplanung und ermöglicht die gleichzeitige Ausführung desselben Batchjobs.
**Vorteile der Nutzung dieser bewährten Methode**: Es ist üblich, dass ein bestimmter Workload einen oder mehrere Kommunikationsstile der synchronen, asynchronen und Stapelverarbeitung implementiert. Diese bewährte Methode hilft Ihnen dabei, die verschiedenen Kompromisse zu identifizieren, die mit den einzelnen Kommunikationsstilen verbunden sind, damit Ihr Workload Störungen in allen Abhängigkeiten tolerieren kann.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
Die folgenden Abschnitte enthalten sowohl allgemeine als auch spezifische Implementierungshinweise für jede Art von Abhängigkeit.
**General guidance (Allgemeine Anleitung**
+ Stellen Sie sicher, dass die Leistungs- und Zuverlässigkeits-Servicelevel-Ziele (SLOs), die Ihre Abhängigkeiten bieten, den Leistungs- und Zuverlässigkeitsanforderungen Ihres Workloads entsprechen.
+ Verwenden Sie [AWS Observability Services](https://aws.amazon.com/cloudops/monitoring-and-observability), um [Reaktionszeiten und Fehlerraten zu überwachen](https://www.youtube.com/watch?v=or7uFFyHIX0), und so sicherzustellen, dass Ihre Abhängigkeit den von Ihrem Workload benötigten Service bietet.
+ Identifizieren Sie die potenziellen Herausforderungen, mit denen Ihr Workload bei der Kommunikation mit seinen Abhängigkeiten konfrontiert sein könnte. Verteilte Systeme [sind mit einer Vielzahl von Herausforderungen verbunden](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/), die die architektonische Komplexität, den Betriebsaufwand und die Kosten erhöhen können. Zu den häufigsten Herausforderungen gehören Latenz, Netzwerkunterbrechungen, Datenverlust, Skalierung und Verzögerungen bei der Datenreplikation.
+ Implementieren Sie eine robuste Fehlerbehandlung und [-protokollierung](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html), um Probleme zu beheben, wenn es in Ihrer Abhängigkeit zu Problemen kommt.
**Synchrone Abhängigkeit**
Bei synchroner Kommunikation sendet Ihr Workload eine Anfrage an seine Abhängigkeit und blockiert den Vorgang, der auf eine Antwort wartet. Wenn ihre Abhängigkeit die Anfrage erhält, versucht sie, sie so schnell wie möglich zu bearbeiten, und sendet eine Antwort zurück an den Workload. Eine große Herausforderung bei synchroner Kommunikation besteht darin, dass sie zu einer zeitlichen Kopplung führt, was erfordert, dass der Workload und dessen Abhängigkeiten gleichzeitig verfügbar sind. Beachten Sie die folgenden Hinweise, wenn der Workload synchron mit seinen Abhängigkeiten kommunizieren muss:
+ Der Workload sollte sich nicht auf mehrere synchrone Abhängigkeiten stützen, um eine einzelne Funktion auszuführen. Diese Kette von Abhängigkeiten erhöht die allgemeine Instabilität, da alle Abhängigkeiten im Pfad verfügbar sein müssen, damit die Anfrage erfolgreich abgeschlossen werden kann.
+ Wenn eine Abhängigkeit fehlerhaft oder nicht verfügbar ist, bestimmen Sie Ihre Strategie zur Fehlerbehandlung und versuchen Sie es erneut. Vermeiden Sie bimodales Verhalten. Bimodales Verhalten liegt vor, wenn sich der Workload im Normalmodus und im Fehlermodus unterschiedlich verhält. Weitere Informationen zu bimodalem Verhalten finden Sie unter [REL11-BP05 Verhindern von bimodalem Verhalten mithilfe statischer Stabilität](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html).
+ Denken Sie daran, dass es besser ist, schnell zu scheitern, als Ihren Workload warten zu lassen. Im [AWS Lambda Entwicklerleitfaden](https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html) wird beispielsweise beschrieben, wie Wiederholungen und Fehlschläge beim Aufrufen von Lambda-Funktionen behandelt werden.
+ Legen Sie Timeouts fest, wenn Ihr Workload seine Abhängigkeit aufruft. Dadurch wird vermieden, zu lange oder unbegrenzt auf eine Antwort zu warten. Eine hilfreiche Diskussion zu diesem Problem finden Sie unter [Tuning AWS Java SDK HTTP request settings for latency-aware Amazon DynamoDB applications](https://aws.amazon.com/blogs/database/tuning-aws-java-sdk-http-request-settings-for-latency-aware-amazon-dynamodb-applications/).
+ Reduzieren Sie die Anzahl der Aufrufe von Ihrem Workload an seine Abhängigkeit, um eine einzelne Anfrage zu erfüllen. Durch zahlreiche Aufrufe erhöht sich die Kopplung und Latenz.
**Asynchrone Abhängigkeit**
Um den Workload zeitlich von dessen Abhängigkeiten zu entkoppeln, sollte die Kommunikation asynchron erfolgen. Bei einem asynchronen Ansatz kann der Workload mit jeder anderen Verarbeitung fortfahren, ohne auf eine Antwort der Abhängigkeit oder Kette von Abhängigkeiten warten zu müssen.
Beachten Sie die folgenden Hinweise, wenn der Workload asynchron mit seiner Abhängigkeit kommunizieren muss:
+ Entscheiden Sie je nach Anwendungsfall und Anforderungen, ob Sie Messaging oder Ereignis-Streaming verwenden möchten. Beim [Messaging](https://aws.amazon.com/messaging/) kann der Workload mit seiner Abhängigkeit kommunizieren, indem er Nachrichten über einen Message Broker sendet und empfängt. Beim [Ereignis-Streaming](https://aws.amazon.com/streaming-data/) können der Workload und seine Abhängigkeiten einen Streaming-Dienst verwenden, um Ereignisse zu veröffentlichen und zu abonnieren, die als kontinuierliche Datenströme bereitgestellt werden und so schnell wie möglich verarbeitet werden müssen.
+ Messaging und Ereignis-Streaming behandeln Nachrichten unterschiedlich, sodass Sie basierend auf den folgenden Faktoren Abwägungsentscheidungen treffen müssen:
+ **Nachrichtenpriorität:** Message Broker können Nachrichten mit hoher Priorität vor normalen Nachrichten verarbeiten. Beim Ereignis-Streaming haben alle Nachrichten dieselbe Priorität.
+ **Nachrichtenverbrauch**: Message Broker stellen sicher, dass die Verbraucher die Nachricht erhalten. Ereignis-Streaming-Verbraucher müssen den Überblick über die zuletzt gelesene Nachricht behalten.
+ **Nachrichtenreihenfolge**: Beim Messaging ist der Empfang von Nachrichten in der genauen Reihenfolge, in der sie gesendet wurden, nicht garantiert, es sei denn, Sie verwenden einen FIFO-Ansatz (First-in-First-Out). Beim Ereignis-Streaming wird immer die Reihenfolge beibehalten, in der die Daten erzeugt wurden.
+ **Löschen von Nachrichten**: Beim Messaging muss der Verbraucher die Nachricht nach der Verarbeitung löschen. Der Ereignis-Streaming-Dienst hängt die Nachricht an einen Stream an und verbleibt dort, bis die Aufbewahrungsfrist der Nachricht abläuft. Diese Löschrichtlinie macht das Ereignis-Streaming für die Wiedergabe von Nachrichten geeignet.
+ Definieren Sie, wie Ihr Workload weiß, wann seine Abhängigkeit seine Arbeit beendet hat. Wenn der Workload beispielsweise [asynchron eine Lambda-Funktion](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html) aufruft, stellt Lambda das Ereignis in eine Warteschlange und gibt eine Erfolgsantwort ohne zusätzliche Informationen zurück. Nach Abschluss der Verarbeitung kann die Lambda-Funktion das [Ergebnis an ein Ziel senden](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html#invocation-async-destinations), das je nach Erfolg oder Misserfolg konfiguriert werden kann.
+ Entwickeln Sie Ihren Workload so, dass er doppelte Nachrichten verarbeiten kann, indem Sie Idempotenz nutzen. Idempotenz bedeutet, dass sich die Ergebnisse des Workloads nicht ändern, auch wenn der Workload mehrmals für dieselbe Nachricht generiert wird. Es ist wichtig, darauf hinzuweisen, dass [Messaging](https://aws.amazon.com/sqs/faqs/#FIFO_queues)- oder [Streaming](https://docs.aws.amazon.com/streams/latest/dev/kinesis-record-processor-duplicates.html)-Dienste eine Nachricht erneut übermitteln, wenn ein Netzwerkausfall auftritt oder wenn keine Bestätigung eingegangen ist.
+ Wenn Ihr Workload keine Antwort von seiner Abhängigkeit erhält, muss er die Anfrage erneut einreichen. Erwägen Sie, die Anzahl der Wiederholungsversuche zu begrenzen, um die CPU-, Arbeitsspeicher- und Netzwerkressourcen des Workloads für die Bearbeitung anderer Anfragen zu schonen. In der [AWS Lambda-Dokumentation](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html#invocation-async-errors) wird gezeigt, wie Fehler beim asynchronen Aufruf behandelt werden.
+ Nutzen Sie geeignete Beobachtbarkeits-, Debugging- und Tracing-Tools, um die asynchrone Kommunikation des Workloads mit seinen Abhängigkeiten zu verwalten und zu betreiben. Sie können [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) verwenden, um [Nachrichten-](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html) und [Ereignis-Streaming-Dienste](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html) zu überwachen. Sie können auch Ihren Workload mit [AWS X-Ray](https://aws.amazon.com/xray/) instrumentieren, um schnell [Erkenntnisse zur Problembehebung](https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html) zu gewinnen.
**Batch-Abhängigkeit**
Batch-Systeme nehmen Eingabedaten auf, initiieren eine Reihe von Aufgaben, um sie zu verarbeiten, und erzeugen einige Ausgabedaten, ohne dass manuelles Eingreifen erforderlich ist. Je nach Datengröße können Aufgaben in wenigen Minuten oder in einigen Fällen sogar in mehreren Tagen ausgeführt werden. Beachten Sie die folgenden Hinweise, wenn der Workload mit seiner Batch-Abhängigkeit kommuniziert:
+ Definieren Sie das Zeitfenster, in dem der Workload den Batchjob ausführen soll. Der Workload kann ein Wiederholungsmuster einrichten, um ein Batchsystem aufzurufen, beispielsweise jede Stunde oder am Ende eines jeden Monats.
+ Ermitteln Sie den Ort der Dateneingabe und der verarbeiteten Datenausgabe. Wählen Sie einen Speicherservice wie [Amazon Simple Storage Services (Amazon S3)](https://aws.amazon.com/s3/), [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) und [Amazon FSx for Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html), der es Ihrem Workload ermöglicht, Dateien in großem Umfang zu lesen und zu schreiben.
+ Wenn Ihr Workload mehrere Batchjobs aufrufen muss, können Sie [AWS Step Functions](https://aws.amazon.com/step-functions/?step-functions.sort-by=item.additionalFields.postDateTime&step-functions.sort-order=desc) nutzen, um die Orchestrierung von Batchjobs, die in AWS oder On-Premises ausgeführt werden, zu vereinfachen. in diesem [Beispielprojekt](https://github.com/aws-samples/aws-stepfunction-complex-orchestrator-app) wird die Orchestrierung von Batchjobs mithilfe von Step Functions, [AWS Batch](https://aws.amazon.com/batch/) und Lambda demonstriert.
+ Überwachen Sie Batchjobs, um nach Auffälligkeiten zu suchen, z. B. wenn die Ausführung eines Jobs länger dauert, als sie sollte. Sie könnten Tools wie [CloudWatch Container Insights](https://docs.aws.amazon.com/batch/latest/userguide/cloudwatch-container-insights.html) verwenden, um AWS Batch-Umgebungen und Jobs zu überwachen. In diesem Fall würde Ihr Workload den Beginn des nächsten Jobs unterbrechen und die zuständigen Mitarbeiter über die Ausnahme informieren.
## Ressourcen
**Zugehörige Dokumente:**
+ [AWS Cloud-Operationen: Überwachung und Beobachtbarkeit](https://aws.amazon.com/cloudops/monitoring-and-observability)
+ [Die Amazon Builders' Library: Herausforderungen für verteilte Systeme](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [REL11-BP05 Verhindern von bimodalem Verhalten mithilfe statischer Stabilität](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
+ [AWS Lambda-Entwicklerhandbuch: Fehlerbehandlung und automatische Wiederholungsversuche in AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html)
+ [Tuning AWS Java SDK HTTP request settings for latency-aware Amazon DynamoDB applications](https://aws.amazon.com/blogs/database/tuning-aws-java-sdk-http-request-settings-for-latency-aware-amazon-dynamodb-applications/)
+ [AWS-Messaging](https://aws.amazon.com/messaging/)
+ [Was sind Streaming-Daten?](https://aws.amazon.com/streaming-data/)
+ [AWS Lambda-Entwicklerhandbuch: Asynchroner Aufruf](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html)
+ [Amazon Simple Queue Service FAQ: FIFO-Warteschlangen](https://aws.amazon.com/sqs/faqs/#FIFO_queues)
+ [Amazon Kinesis Data Streams-Entwicklerhandbuch: Umgang mit doppelten Datensätzen](https://docs.aws.amazon.com/streams/latest/dev/kinesis-record-processor-duplicates.html)
+ [Amazon Simple Queue Service-Entwicklerhandbuch: Verfügbare CloudWatch-Metriken für Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html)
+ [Amazon Kinesis Data Streams-Entwicklerhandbuch: Überwachung des Amazon Kinesis Data Streams-Service mit Amazon CloudWatch](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html)
+ [AWS X-Ray-Entwicklerhandbuch: AWS X-Ray-Konzepte](https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html)
+ [AWS Beispiele auf GitHub: AWS Step functions Complex Orchestrator App](https://github.com/aws-samples/aws-stepfunction-complex-orchestrator-app)
+ [AWS Batch-Benutzerhandbuch: AWS Batch CloudWatch Container Insights](https://docs.aws.amazon.com/batch/latest/userguide/cloudwatch-container-insights.html)
**Zugehörige Videos:**
+ [AWS Summit SF 2022 - Full-stack observability and application monitoring with AWS (COP310)](https://www.youtube.com/watch?v=or7uFFyHIX0)
**Zugehörige Tools:**
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)
+ [Amazon FSx für Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [AWS Step Functions](https://aws.amazon.com/step-functions/?step-functions.sort-by=item.additionalFields.postDateTime&step-functions.sort-order=desc)
+ [AWS Batch](https://aws.amazon.com/batch/)
# REL04-BP02 Lose gekoppelte Abhängigkeiten implementieren
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 Entkopplung von Abhängigkeiten wie Warteschlangensystemen, Streaming-Systemen und Workflows trägt dazu bei, die Auswirkungen von Änderungen oder Ausfällen auf ein System zu minimieren. Durch diese Trennung wird das Verhalten einer Komponente von Auswirkungen auf andere, die von ihr abhängig sind, isoliert und so die Widerstandsfähigkeit und Agilität verbessert.
In eng gekoppelten Systemen können Änderungen an einer Komponente Änderungen an anderen Komponenten erforderlich machen, die von ihr abhängen, was die Leistung aller Komponenten beeinträchtigt. *Die lose* Verkopplung unterbricht diese Abhängigkeit, sodass abhängige Komponenten nur die versionierte und veröffentlichte Schnittstelle kennen müssen. Die Implementierung einer losen Verkopplung zwischen Abhängigkeiten isoliert einen Ausfall. So wird verhindert, dass er sich auf andere Komponenten auswirkt.
Die lose Verkoppelung ermöglicht Ihnen, einer Komponente zusätzlichen Code oder Features hinzuzufügen und gleichzeitig das Risiko für Komponenten zu minimieren, die von ihr abhängig sind. Sie ermöglicht auch eine granulare Ausfallsicherheit auf Komponentenebene, bei der Sie die zugrunde liegende Implementierung der Abhängigkeit aufskalieren oder sogar ändern können.
Um die Ausfallsicherheit durch lose Verkopplung 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 werden nicht durch direkte point-to-point Interaktion integriert, sondern normalerweise über eine dauerhafte Zwischenspeicherschicht, z. B. eine SQS Amazon-Warteschlange, eine Streaming-Datenplattform wie Amazon Kinesis oder AWS Step Functions.
![\[Diagramm zeigt Abhängigkeiten, etwa zwischen Warteschlangensystemen und Load Balancer, die lose gekoppelt sind\]](http://docs.aws.amazon.com/de_de/wellarchitected/latest/reliability-pillar/images/dependency-diagram.png)
SQSAmazon-Warteschlangen und AWS Step Functions sind nur zwei Möglichkeiten, eine Zwischenschicht für lose Kopplung hinzuzufügen. Eventgesteuerte Architekturen können auch AWS Cloud mithilfe von Amazon erstellt werden EventBridge, wodurch Kunden (Event-Produzenten) von den Diensten, auf die sie angewiesen sind (Event-Konsumenten), abstrahieren können. Amazon Simple Notification Service (AmazonSNS) ist eine effektive Lösung, wenn Sie Push-basiertes Messaging mit hohem Durchsatz benötigen. many-to-many Mithilfe von SNS Amazon-Themen können Ihre Publisher-Systeme Nachrichten zur parallel Verarbeitung an eine große Anzahl von Abonnenten-Endpunkten fächern.
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.
**Gewünschtes Ergebnis:** Wenn Sie lose gekoppelte Abhängigkeiten implementieren, können Sie die Fehlerfläche auf Komponentenebene minimieren, was die Diagnose und Lösung von Problemen erleichtert. Außerdem vereinfacht es die Entwicklungszyklen, da die Teams Änderungen auf modularer Ebene implementieren können, ohne die Leistung anderer Komponenten, die davon abhängen, zu beeinträchtigen. Dieser Ansatz ermöglicht eine Aufskalierung auf Komponentenebene auf Grundlage des Ressourcenbedarfs sowie der Auslastung einer Komponente und trägt so zur Kosteneffizienz bei.
**Typische Anti-Muster:**
+ Bereitstellen eines monolithischen Workloads.
+ Direkter Aufruf APIs zwischen Workload-Stufen, ohne dass ein Failover oder eine asynchrone Verarbeitung der Anfrage möglich ist.
+ Enge Verknüpfung mithilfe gemeinsam genutzter Daten. Lose gekoppelte Systeme sollten die gemeinsame Nutzung von Daten durch gemeinsam genutzte Datenbanken oder andere Formen der eng gekoppelten Datenspeicherung vermeiden, da dies wieder zu einer engen Verknüpfung führen und die Skalierbarkeit behindern kann.
+ Gegendruck wird ignoriert. Ihr Workload sollte in der Lage sein, die eingehenden Daten zu verlangsamen oder zu stoppen, wenn eine Komponente sie nicht mit der gleichen Geschwindigkeit verarbeiten kann.
**Vorteile der Nutzung dieser bewährten Methode:** Eine lose Verkoppelung hilft dabei, das Verhalten einer Komponente von anderen Komponenten zu isolieren, die von ihr abhängen, wodurch die Resilienz und Agilität erhöht werden. Fehler in einer Komponente sind von anderen isoliert.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
Implementieren lose gekoppelter Abhängigkeiten. Es gibt verschiedene Lösungen, mit denen Sie lose gekoppelte Anwendungen erstellen können. Dazu gehören Dienste für die Implementierung vollständig verwalteter Warteschlangen, automatisierter Workflows, die Reaktion auf Ereignisse und APIs vieles mehr, die dazu beitragen können, das Verhalten von Komponenten von anderen Komponenten zu isolieren und so die Widerstandsfähigkeit und Agilität zu erhöhen.
+ **Erstellen Sie ereignisgesteuerte Architekturen:** [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) hilft Ihnen beim Aufbau lose gekoppelter und verteilter ereignisgesteuerter Architekturen.
+ **Implementieren Sie Warteschlangen in verteilten Systemen:** Sie können [Amazon Simple Queue Service (AmazonSQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) verwenden, um verteilte Systeme zu integrieren und zu entkoppeln.
+ **Komponenten als Microservices containerisieren: [Microservices](https://aws.amazon.com/microservices/)** ermöglichen es Teams, Anwendungen zu erstellen, die aus kleinen unabhängigen Komponenten bestehen, die über klar definierte Kanäle kommunizieren. APIs [Amazon Elastic Container Service (AmazonECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) und [Amazon Elastic Kubernetes Service (AmazonEKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) können Ihnen helfen, schneller mit Containern zu beginnen.
+ **Verwalten Sie Workflows mit Step Functions:** Mit [Step Functions](https://aws.amazon.com/step-functions/getting-started/) können Sie mehrere AWS Services zu flexiblen Workflows koordinieren.
+ **Nutzen Sie die Messaging-Architekturen Publish-Subscribe (Pub/Sub):** [Amazon Simple Notification Service (AmazonSNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) ermöglicht die Nachrichtenzustellung von Verlagen an Abonnenten (auch bekannt als Produzenten und Verbraucher).
### Implementierungsschritte
+ Komponenten in einer ereignisgesteuerten Architektur werden durch Ereignisse ausgelöst. Ereignisse sind Aktionen, die in einem System stattfinden, z. B. wenn ein Benutzer einen Artikel in den Warenkorb legt. Wenn eine Aktion erfolgreich ist, wird ein Ereignis erzeugt, das die nächste Komponente des Systems auslöst.
+ [Entwicklung ereignisgesteuerter Anwendungen mit Amazon EventBridge](https://aws.amazon.com/blogs/compute/building-an-event-driven-application-with-amazon-eventbridge/)
+ [AWS re:Invent 2022 — Entwicklung ereignisgesteuerter Integrationen mit Amazon EventBridge](https://www.youtube.com/watch?v=W3Rh70jG-LM)
+ Verteilte Nachrichtensysteme haben drei Hauptbestandteile, die für eine warteschlangenbasierte Architektur implementiert werden müssen. Sie umfassen Komponenten des verteilten Systems, die Warteschlange, die für die Entkopplung verwendet wird (verteilt auf SQS Amazon-Servern), und die Nachrichten in der Warteschlange. Ein typisches System hat einen Produzenten, der die Nachricht in die Warteschlange einstellt, und einen Verbraucher, der die Nachricht aus der Warteschlange empfängt. Die Warteschlange speichert Nachrichten aus Redundanzgründen auf mehreren SQS Amazon-Servern.
+ [Grundlegende SQS Amazon-Architektur](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html)
+ [ Send Messages Between Distributed Applications with Amazon Simple Queue Service ](https://aws.amazon.com/getting-started/hands-on/send-messages-distributed-applications/)
+ Wenn Microservices gut genutzt werden, verbessern sie die Wartbarkeit und die Skalierbarkeit, da lose gekoppelte Komponenten von unabhängigen Teams verwaltet werden. Sie ermöglichen zudem die Isolierung von Verhaltensweisen auf eine einzelne Komponente im Falle von Änderungen.
+ [Implementierung von Microservices auf AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [Let’s Architect\$1 Architektur von Microservices mit Containern ](https://aws.amazon.com/blogs/architecture/lets-architect-architecting-microservices-with-containers/)
+ Mit können AWS Step Functions Sie unter anderem verteilte Anwendungen erstellen, Prozesse automatisieren und Microservices orchestrieren. Die Orchestrierung mehrerer Komponenten in einem automatisierten Workflow ermöglicht es Ihnen, Abhängigkeiten in Ihrer Anwendung zu entkoppeln.
+ [Erstellen Sie einen serverlosen Workflow mit und AWS Step FunctionsAWS Lambda](https://aws.amazon.com/tutorials/create-a-serverless-workflow-step-functions-lambda/)
+ [Erste Schritte mit AWS Step Functions](https://aws.amazon.com/step-functions/getting-started/)
## Ressourcen
**Zugehörige Dokumente:**
+ [AmazonEC2: 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)
+ [ Break up with your monolith ](https://pages.awscloud.com/break-up-your-monolith.html)
+ [Orchestrieren Sie warteschlangenbasierte Microservices mit und Amazon AWS Step Functions SQS](https://aws.amazon.com/tutorials/orchestrate-microservices-with-message-queues-on-step-functions/)
+ [Grundlegende SQS Amazon-Architektur](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html)
+ [ Warteschlangenbasierte Architektur ](https://docs.aws.amazon.com/wellarchitected/latest/high-performance-computing-lens/queue-based-architecture.html)
**Zugehörige Videos:**
+ [AWS New York Summit 2019: Einführung in ereignisgesteuerte Architekturen und Amazon (05) EventBridge MAD2](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Closed Loops and Opening Minds: Wie man die Kontrolle über große und kleine Systeme übernimmt ARC337 (beinhaltet lockere Kopplung, konstante Arbeit, statische Stabilität)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Umstellung auf ereignisgesteuerte Architekturen (08) SVS3](https://youtu.be/h46IquqjF3E)
+ [AWS re:Invent 2019: Skalierbare, serverlose, ereignisgesteuerte Anwendungen mit Amazon und Lambda SQS](https://www.youtube.com/watch?v=2rikdPIFc_Q)
+ [AWS re:Invent 2022 — Entwicklung ereignisgesteuerter Integrationen mit Amazon EventBridge](https://www.youtube.com/watch?v=W3Rh70jG-LM)
+ [AWS re:Invent 2017: Elastic Load Balancing im Detail und Best Practices](https://www.youtube.com/watch?v=9TwkMMogojY)
# REL04-BP03 Arbeite ständig
Bei größeren, schnellen Lastveränderungen können Systeme ausfallen. Wenn Ihr Workload beispielsweise eine Zustandsprüfung ausführt, die den Zustand vieler tausend Server überwacht, sollte er 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: Regelkreise schließen und neue Denkansätze eröffnen: Wie man die Kontrolle über große und kleine Systeme übernimmt ARC337 (beinhaltet ständige Arbeit)](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
**Zugehörige Dokumente:**
+ [AmazonEC2: 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/)
**Zugehörige Videos:**
+ [AWS New York Summit 2019: Einführung in ereignisgesteuerte Architekturen und Amazon (05) EventBridge MAD2](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close-Loops und offene Denkansätze: Wie man die Kontrolle über große und kleine Systeme übernimmt (beinhaltet ständige Arbeit) ARC337](https://youtu.be/O8xLxNje30M?t=2482)
+ [AWS re:Invent 2018: Close Loops und Opening Minds: So übernehmen Sie die Kontrolle über große und kleine Systeme ARC337 (beinhaltet lockere Kopplung, konstante Arbeit, statische Stabilität)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Umstellung auf ereignisgesteuerte Architekturen (08) SVS3](https://youtu.be/h46IquqjF3E)
# REL04-BP04 Festlegen von Mutationsoperationen als idempotent
Ein idempotenter Service garantiert, dass jede Anfrage genau einmal verarbeitet wird. Das bedeutet, dass das Senden mehrerer identischer Anfragen den gleichen Effekt hat wie das Senden einer einzelnen Anfrage. Dies vereinfacht es für einen 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, selbst wenn sich der zugrunde liegende Zustand des Systems geändert hat.
In einem verteilten System ist es relativ einfach, eine Aktion höchstens einmal (der Client führt nur eine Anforderung aus) oder mindestens einmal (Anforderung wird ausgeführt, bis der Client eine Erfolgsbenachrichtigung erhält) durchzuführen. Es ist jedoch schwieriger, zu gewährleisten, dass eine Aktion *genau einmal* ausgeführt wird, so dass 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 mutierende Anforderung erhalten, ohne dass doppelte Datensätze erstellt werden müssen oder andere Probleme entstehen.
**Gewünschtes Ergebnis:** Sie verfügen über einen konsistenten, gut dokumentierten und häufig verwendeten Ansatz zur Sicherstellung der Idempotenz für alle Komponenten und Services.
**Typische Anti-Muster:**
+ Sie wenden Idempotenz unterschiedslos an, auch wenn sie nicht benötigt wird.
+ Sie führen eine zu komplexe Logik für die Implementierung von Idempotenz ein.
+ Sie verwenden Zeitstempel als Schlüssel für Idempotenz. Dies kann zu Ungenauigkeiten führen, die auf eine Verschiebung der Uhrzeit oder darauf zurückzuführen sind, dass mehrere Clients dieselben Zeitstempel verwenden, um Änderungen vorzunehmen.
+ Sie speichern vollständige Nutzdaten für Idempotenz. Bei diesem Ansatz speichern Sie vollständige Nutzdaten für jede Anfrage und überschreiben sie bei jeder neuen Anfrage. Dies kann Leistung und Skalierbarkeit beeinträchtigen.
+ Sie generieren inkonsistente Service-Schlüssel. Ohne konsistente Schlüssel erkennen Services duplizierte Anfragen möglicherweise nicht, was zu unbeabsichtigten Ergebnissen führt.
**Vorteile der Nutzung dieser bewährten Methode:**
+ Höhere Skalierbarkeit: Das System kann Wiederholungsversuche und doppelte Anfragen verarbeiten, ohne eine zusätzliche Logik oder eine komplexe Statusverwaltung anwenden zu müssen.
+ Verbesserte Zuverlässigkeit: Mit Idempotenz können Services mehrere identische Anfragen konsistent verarbeiten, wodurch das Risiko unbeabsichtigter Nebenwirkungen oder duplizierter Datensätze reduziert wird. Dies ist besonders wichtig in verteilten Systemen, in denen Netzwerkausfälle und Wiederholungsversuche häufig sind.
+ Verbesserte Datenkonsistenz: Da dieselbe Anfrage zu derselben Antwort führt, trägt Idempotenz dazu bei, die Datenkonsistenz in verteilten Systemen aufrechtzuerhalten. Dies ist wichtig, um die Integrität von Transaktionen und Vorgängen aufrechtzuerhalten.
+ Fehlerbehandlung: Idempotenz-Tokens vereinfachen die Fehlerbehandlung. Wenn ein Client aufgrund eines Problems keine Antwort erhält, kann er die Anfrage problemlos erneut mit demselben Idempotenz-Token senden.
+ Betriebliche Transparenz: Idempotenz ermöglicht eine bessere Überwachung und Protokollierung. Services können Anfragen mit ihren Idempotenz-Tokens protokollieren, was das Nachverfolgen und Debuggen von Problemen erleichtert.
+ Vereinfachter API-Vertrag: Dies kann den Vertrag zwischen den client- und serverseitigen Systemen vereinfachen und Sorgen hinsichtlich einer fehlerhaften Datenverarbeitung verringern.
**Risikostufe bei fehlender Befolgung dieser bewährten Methode:** Mittel
## Implementierungsleitfaden
In einem verteilten System ist es einfach, eine Aktion höchstens einmal (der Client führt nur eine Anforderung aus) oder mindestens einmal (Anforderung wird so lange ausgeführt, bis der Erfolg bestätigt wird) durchzuführen. Es ist jedoch schwierig, die Aktion *genau einmal* ausführen zu lassen. Um dies zu erreichen, sollten Ihre Kunden für jede Anfrage ein Idempotenz-Token generieren und bereitstellen.
Durch die Verwendung von Idempotenz-Tokens kann ein Service zwischen neuen und wiederholten Anfragen unterscheiden. Wenn ein Service eine Anfrage mit einem Idempotenz-Token empfängt, prüft er, ob das Token bereits verwendet wurde. Wenn das Token bereits verwendet wurde, ruft der Service die gespeicherte Antwort ab und gibt sie zurück. Wenn das Token neu ist, verarbeitet der Service die Anfrage, speichert die Antwort zusammen mit dem Token und gibt dann die Antwort zurück. Dieser Mechanismus macht alle Antworten idempotent, was die Zuverlässigkeit und Konsistenz des verteilten Systems erhöht.
Idempotenz ist auch ein wichtiges Verhalten ereignisgesteuerter Architekturen. Diese Architekturen werden in der Regel durch eine Nachrichtenwarteschlange wie Amazon SQS, Amazon MQ, Amazon Kinesis Streams oder Amazon Managed Streaming for Apache Kafka (MSK) unterstützt. Unter bestimmten Umständen kann eine Nachricht, die nur einmal veröffentlicht wurde, versehentlich mehr als einmal zugestellt werden. Wenn ein Herausgeber Idempotenz-Token generiert und in Nachrichten einfügt, wird damit angefordert, dass die Verarbeitung doppelt empfangener Nachrichten nicht zu einer wiederholten Aktion für dieselbe Nachricht führt. Verbraucher sollten jedes erhaltene Token nachverfolgen und Nachrichten ignorieren, die duplizierte Token enthalten.
Services und Verbraucher sollten das empfangene Idempotenz-Token auch an alle nachgelagerten Services weitergeben, die sie aufrufen. Jeder nachgelagerte Service in der Verarbeitungskette ist ebenfalls dafür verantwortlich, sicherzustellen, dass Idempotenz implementiert wird, um den Nebeneffekt einer mehrfachen Verarbeitung einer Nachricht zu vermeiden.
### Implementierungsschritte
1. **Identifizieren idempotenter Operationen**
Ermitteln Sie, für welche Operationen Idempotenz erforderlich ist. Dazu gehören in der Regel die HTTP-Methoden POST, PUT und DELETE sowie Operationen zum Einfügen, Aktualisieren oder Löschen von Datenbanken. Operationen, bei denen der Status nicht verändert wird, z. B. schreibgeschützte Abfragen, erfordern normalerweise keine Idempotenz, es sei denn, es gibt Nebeneffekte.
1. **Verwenden eindeutiger Bezeichner**
Fügen Sie jeder idempotenten Operationsanforderung, die vom Absender gesendet wird, ein eindeutiges Token hinzu, entweder direkt in der Anfrage oder als Teil ihrer Metadaten (z. B. einen HTTP-Header). Auf diese Weise kann der Empfänger duplizierte Anforderungen oder Operationen erkennen und verarbeiten. Zu den üblicherweise für Token verwendeten Bezeichnern gehören [Universally Unique Identifiers (UUIDs)](https://datatracker.ietf.org/doc/html/rfc9562) und [K-Sortable Unique Identifiers (KSUIDs](https://github.com/segmentio/ksuid)).
1. **Verfolgen und Verwalten des Status**
Behalten Sie den Status jeder Operation oder Anforderung in Ihrem Workload bei. Dies kann erreicht werden, indem das Idempotenz-Token und der entsprechende Status (z. B. ausstehend, abgeschlossen oder fehlgeschlagen) in einer Datenbank, einem Cache oder einem anderen persistenten Speicher gespeichert werden. Diese Statusinformationen ermöglichen dem Workload die Identifizierung und Verarbeitung duplizierter Anforderungen oder Operationen.
Sorgen Sie für Konsistenz und Atomizität, indem Sie bei Bedarf geeignete Mechanismen zur Kontrolle der Gleichzeitigkeit verwenden, z. B. Sperren, Transaktionen oder optimistische Gleichzeitigkeitskontrollen. Dazu gehören das Aufzeichnen des idempotenten Tokens und das Ausführen aller Mutationsoperationen, die mit der Bearbeitung der Anfrage verbunden sind. Auf diese Weise wird verhindert, dass es zu Race-Bedingungen kommt, und sichergestellt, dass idempotente Operationen korrekt ausgeführt werden.
Entfernen Sie regelmäßig alte Idempotenz-Token aus dem Datenspeicher, um Speicherplatz und Leistung zu verwalten. Wenn Ihr Speichersystem es unterstützt, sollten Sie die Verwendung von Ablaufzeitstempeln für Daten in Betracht ziehen (häufig auch als Time to Live- oder TTL-Werte bezeichnet). Die Wahrscheinlichkeit einer Wiederverwendung von Idempotenz-Token nimmt mit der Zeit ab.
Zu den gängigen AWS-Speicheroptionen, die typischerweise zum Speichern von Idempotenz-Token und des zugehörigen Status verwendet werden, gehören:
+ **Amazon DynamoDB**: DynamoDB ist ein NoSQL-Datenbankservice, der eine Leistung mit niedriger Latenz und eine hohe Verfügbarkeit bietet und sich daher gut für die Speicherung von Daten im Zusammenhang mit Idempotenz eignet. Das Schlüssel-Wert- und Dokumentdatenmodell von DynamoDB ermöglicht das effiziente Speichern und Abrufen von Idempotenz-Token und der zugehörigen Statusinformationen. DynamoDB kann Idempotenz-Token auch automatisch ablaufen lassen, wenn Ihre Anwendung beim Einfügen einen TTL-Wert festlegt.
+ **Amazon ElastiCache**: ElastiCache kann Idempotenz-Token mit hohem Durchsatz, geringer Latenz und niedrigen Kosten speichern. Sowohl ElastiCache (Redis) als auch ElastiCache (Memcached) können Idempotenz-Token auch automatisch ablaufen lassen, wenn Ihre Anwendung beim Einfügen einen TTL-Wert festlegt.
+ **Amazon Relational Database Service (RDS):** Sie können Amazon RDS verwenden, um Idempotenz-Token und zugehörige Statusinformationen zu speichern, insbesondere, wenn Ihre Anwendung bereits eine relationale Datenbank für andere Zwecke verwendet.
+ **Amazon Simple Storage Service (S3):** Amazon S3 ist ein hoch skalierbarer und langlebiger Objektspeicherservice, der zum Speichern von Idempotenz-Token und der zugehörigen Metadaten verwendet werden kann. Die Versionsverwaltungsfunktionen von S3 können besonders nützlich sein, um den Status idempotenter Operationen aufrechtzuerhalten. Die Wahl des Speicherservices ist in der Regel von Faktoren wie der Menge der Daten im Zusammenhang mit Idempotenz, den erforderlichen Leistungsmerkmalen, der benötigten Speicherdauer und Verfügbarkeit sowie der Art und Weise abhängig, wie der Idempotenzmechanismus in die gesamte Workload-Architektur integriert ist.
1. **Implementieren von idempotenten Operationen**
Entwerfen Sie Ihre API- und Workload-Komponenten für Idempotenz. Integrieren Sie Idempotenzprüfungen in Ihre Workload-Komponenten. Überprüfen Sie vor der Verarbeitung einer Anforderung oder Ausführung einer Operation, ob der eindeutige Bezeichner bereits verarbeitet wurde. Wenn dies der Fall ist, geben Sie das vorherige Ergebnis zurück, anstatt die Operation erneut auszuführen. Wenn ein Client beispielsweise eine Anforderung zur Erstellung eines Benutzers sendet, überprüfen Sie, ob bereits ein Benutzer mit demselben eindeutigen Bezeichner vorhanden ist. Wenn der Benutzer vorhanden ist, sollten die vorhandenen Benutzerinformationen zurückgegeben werden, statt einen neuen Benutzer zu erstellen. Ebenso sollte ein Verbraucher Nachrichten ignorieren, die duplizierte Idempotenz-Token enthalten.
Erstellen Sie umfassende Testsuiten zur Validierung der Idempotenz von Anforderungen. Diese sollten ein breites Spektrum von Szenarien abdecken, z. B. erfolgreiche, fehlgeschlagene und doppelte Anforderungen.
Wenn Ihr Workload AWS Lambda-Funktionen nutzt, sollten Sie Powertools für AWS Lambda in Betracht ziehen. Powertools für AWS Lambda ist ein Entwickler-Toolkit zur Implementierung bewährter Serverless-Methoden und zur Steigerung der Entwicklungsgeschwindigkeit bei der Arbeit mit AWS Lambda-Funktionen. Insbesondere enthält der Kit ein Hilfsprogramm, mit dem Sie Ihre Lambda-Funktionen in idempotente Operationen konvertieren können, die sicher wiederholt werden können.
1. **Klare Kommunikation der Idempotenz**
Dokumentieren Sie Ihre API- und Workload-Komponenten, um die idempotente Natur der Operationen deutlich zu machen. Dies hilft Clients, das erwartete Verhalten zu verstehen und zu wissen, wie sie zuverlässig mit Ihrem Workload interagieren können.
1. **Überwachen und Prüfen**
Implementieren Sie Überwachungs- und Prüfmechanismen, um Probleme im Zusammenhang mit der Idempotenz von Antworten aufzudecken, z. B. unerwartete Antwortvarianten oder eine übermäßige Verarbeitung duplizierter Anforderungen. Dies kann Ihnen helfen, Probleme oder unerwartete Verhaltensweisen in Ihren Workloads zu erkennen und zu untersuchen.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL05-BP03 Steuern und Einschränken von Wiederholungsaufrufen](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_limit_retries.html)
+ [REL06-BP01 Überwachen aller Komponenten des Workloads (Generierung)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html)
+ [REL06-BP03 Senden von Benachrichtigungen (Verarbeitung und Benachrichtigung in Echtzeit)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_monitor.html)
+ [REL08-BP02 Integrieren von Funktionstests in die Bereitstellung](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_functional_testing.html)
**Zugehörige Dokumente:**
+ [Amazon Builders' Library: Sichere Wiederholungen mit idempotenten APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)
+ [Amazon Builders' Library: Herausforderungen bei verteilten Systemen](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Amazon Builders' Library: Zuverlässigkeit, stetige Ausführung und eine gute Tasse Kaffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [Amazon Elastic Container Service: Sicherstellen der Idempotenz](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/ECS_Idempotency.html)
+ [Wie mache ich meine Lambda-Funktion idempotent?](https://repost.aws/knowledge-center/lambda-function-idempotent)
+ [Sicherstellen der Idempotenz bei Amazon-EC2-API-Anforderungen](https://docs.aws.amazon.com/ec2/latest/devguide/ec2-api-idempotency.html)
**Zugehörige Videos:**
+ [Entwickeln verteilter Anwendungen mit ereignisgesteuerter Architektur – AWS Online Tech Talks](https://www.youtube.com/watch?v=gA2-eqDVSng&t=1668s)
+ [AWS re:Invent 2023 – Building next-generation applications with event-driven architecture](https://www.youtube.com/watch?v=KXR17uwLEC8)
+ [AWS re:Invent 2023 - Advanced integration patterns & trade-offs for loosely coupled systems](https://www.youtube.com/watch?v=FGKGdUiZKto)
+ [AWS re:Invent 2023 – Advanced event-driven patterns with Amazon EventBridge](https://www.youtube.com/watch?v=6X4lSPkn4ps)
+ [AWS re:Invent 2018 – Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes loose coupling, constant work, static stability)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019 – Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
**Zugehörige Tools:**
+ [Idempotenz mit AWS Lambda Powertools (Java)](https://docs.powertools.aws.dev/lambda/java/utilities/idempotency/)
+ [Idempotenz mit AWS Lambda Powertools (Python)](https://docs.powertools.aws.dev/lambda/python/latest/utilities/idempotency/)
+ [AWS Lambda Powertools – GitHub-Seite](https://github.com/aws-powertools/)
# Entwerfen von Interaktionen in einem verteilten System, um Ausfälle abzumildern oder zu verkraften
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. Die Komponenten des verteilten Systems müssen so funktionieren, dass sie sich nicht negativ auf andere Komponenten oder die Workload auswirken. Diese bewährten Methoden sorgen dafür, dass Workloads Belastungen oder Fehlern standhalten, sich schneller davon erholen und die Auswirkungen solcher Beeinträchtigungen abgeschwächt werden. Das Ergebnis ist eine verbesserte mittlere Reparaturzeit (MTTR).
Diese bewährten Methoden verhindern Ausfälle und verbessern die mittlere Betriebsdauer zwischen Ausfällen (MTBF).
**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 Steuerung und Begrenzung 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 Client-Timeouts festlegen](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 Systeme soweit möglich zustandslos machen](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 Nothebel einbauen](rel_mitigate_interaction_failure_emergency_levers.md)
# REL05-BP01 Implementieren einer ordnungsgemäßen Funktionsminderung, um harte Abhängigkeiten in weiche zu ändern
Anwendungskomponenten sollten weiterhin ihre Kernfunktion erfüllen, auch wenn Abhängigkeiten nicht mehr verfügbar sind. Sie liefern möglicherweise leicht veraltete Daten, alternative Daten oder sogar keine Daten. Dadurch wird sichergestellt, dass die Gesamtsystemfunktion nur minimal durch lokale Ausfälle beeinträchtigt wird, während gleichzeitig der zentrale Geschäftswert gewährleistet ist.
**Gewünschtes Ergebnis:** Wenn die Abhängigkeiten einer Komponente fehlerhaft sind, kann die Komponente selbst weiterhin funktionieren, wenn auch in eingeschränkter Weise. Komponentenausfälle sollten als normaler Geschäftsbetrieb betrachtet werden. Arbeitsabläufe sollten so konzipiert sein, dass solche Ausfälle nicht zu einem vollständigen Ausfall oder zumindest zu vorhersehbaren und wiederherstellbaren Zuständen führen.
**Typische Anti-Muster:**
+ Die erforderlichen Kerngeschäftsfunktionen wurden nicht identifiziert. Es wird nicht getestet, ob die Komponenten auch bei Abhängigkeitsfehlern funktionsfähig sind.
+ Es werden keine Daten zu Fehlern bereitgestellt oder wenn nur eine von mehreren Abhängigkeiten nicht verfügbar ist und Teilergebnisse dennoch zurückgegeben werden können.
+ Es entsteht ein inkonsistenter Zustand, wenn eine Transaktion teilweise fehlschlägt.
+ Es gibt keine alternative Möglichkeit, auf einen zentralen Parameterspeicher zuzugreifen.
+ Lokale Zustände werden aufgrund einer fehlgeschlagenen Aktualisierung ungültig oder geleert, ohne die Konsequenzen zu berücksichtigen.
**Vorteile der Nutzung dieser bewährten Methode:** Eine schrittweise Degradation verbessert die Verfügbarkeit des gesamten Systems und gewährleistet die Funktionsfähigkeit der wichtigsten Funktionen auch bei Ausfällen.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
Die Implementierung einer schrittweisen Degradation trägt dazu bei, die Auswirkungen von Abhängigkeitsfehlern auf die Komponentenfunktion zu minimieren. Im Idealfall erkennt eine Komponente Abhängigkeitsfehler und umgeht sie so, dass sich dies nur minimal auf andere Komponenten oder Kunden auswirkt.
Eine Architektur, die auf eine schrittweise Degradation ausgerichtet ist, bedeutet, potenzielle Ausfallmodi beim Entwurf von Abhängigkeiten zu berücksichtigen. Sorgen Sie für jeden Ausfallmodus für eine Möglichkeit, aufrufenden Komponenten oder Kunden die meisten oder zumindest die wichtigsten Funktionen der Komponente bereitzustellen. Diese Überlegungen können zu zusätzlichen Anforderungen werden, die getestet und verifiziert werden können. Im Idealfall ist eine Komponente in der Lage, ihre Kernfunktion auf akzeptable Weise auszuführen, selbst wenn eine oder mehrere Abhängigkeiten ausfallen.
Dies ist sowohl eine geschäftliche als auch eine technische Diskussion. Alle Geschäftsanforderungen sind wichtig und sollten nach Möglichkeit erfüllt werden. Es ist jedoch immer noch sinnvoll, sich zu fragen, was passieren soll, wenn nicht alle erfüllt werden können. Ein System kann so konzipiert werden, dass es verfügbar und konsistent ist. Doch was davon ist wichtiger, wenn auf eines davon verzichtet werden muss? Bei der Zahlungsabwicklung könnte dies die Konsistenz sein. Bei einer Echtzeitanwendung ist es eher die Verfügbarkeit. Bei einer kundenseitigen Website kann die Antwort von den Kundenerwartungen abhängen.
Was das bedeutet, hängt von den Anforderungen der Komponente ab und davon, was als ihre Kernfunktion angesehen werden sollte. Beispiel:
+ Eine E-Commerce-Website kann Daten aus verschiedenen Systemen wie personalisierte Empfehlungen, bestbewertete Produkte und den Status von Kundenbestellungen auf der Startseite anzeigen. Wenn ein Upstream-System ausfällt, ist es immer noch sinnvoll, alles andere anzuzeigen, anstatt einem Kunden eine Fehlerseite anzuzeigen.
+ Eine Komponente, die Batch-Schreibvorgänge durchführt, kann einen Stapel trotzdem weiterverarbeiten, wenn eine der einzelnen Operationen fehlschlägt. Es sollte einfach sein, einen Wiederholungsmechanismus zu implementieren. Geben Sie dazu Informationen dazu zurück, welche Operationen erfolgreich, welche fehlgeschlagen und warum sie fehlgeschlagen sind. Oder stellen Sie fehlgeschlagene Anfragen in eine Warteschlange für unzustellbare Nachrichten, um asynchrone Wiederholungsversuche zu implementieren. Informationen über fehlgeschlagene Operationen sollten ebenfalls protokolliert werden.
+ Ein System, das Transaktionen verarbeitet, muss überprüfen, ob entweder alle oder keine einzelnen Aktualisierungen ausgeführt werden. Bei verteilten Transaktionen kann das Saga-Muster verwendet werden, um vorherige Operationen rückgängig zu machen, falls ein späterer Vorgang derselben Transaktion fehlschlägt. Hier besteht die Kernfunktion darin, die Konsistenz aufrechtzuerhalten.
+ Zeitkritische Systeme sollten in der Lage sein, mit Abhängigkeiten umzugehen, die nicht rechtzeitig reagieren. In diesen Fällen kann das Unterbrechermuster verwendet werden. Wenn bei Antworten aus einer Abhängigkeit eine Zeitüberschreitung auftritt, kann das System in einen geschlossenen Zustand wechseln, in dem keine weiteren Aufrufe getätigt werden.
+ Eine Anwendung kann Parameter aus einem Parameterspeicher lesen. Es kann nützlich sein, Container-Images mit einem Satz von Standardparametern zu erstellen und diese zu verwenden, falls der Parameterspeicher nicht verfügbar ist.
Beachten Sie, dass die im Falle eines Komponentenausfalls eingeschlagenen Pfade getestet werden müssen und deutlich einfacher sein sollten als der primäre Pfad. Allgemein [sollten Fallback-Strategien vermieden werden](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/).
## Implementierungsschritte
Identifizieren Sie externe und interne Abhängigkeiten. Überlegen Sie, welche Arten von Fehlern bei ihnen auftreten können. Überlegen Sie, wie Sie die negativen Auswirkungen dieser Ausfälle auf vor- und nachgeschaltete Systeme und Kunden minimieren können.
Im Folgenden finden Sie eine Liste von Abhängigkeiten und wie Sie sie schrittweise degradieren können, wenn sie ausfallen:
1. **Teilweiser Ausfall von Abhängigkeiten:** Eine Komponente kann mehrere Anfragen an nachgelagerte Systeme stellen, entweder in Form mehrerer Anfragen an ein System oder in Form einer Anfrage an jeweils mehrere Systeme. Je nach Unternehmenskontext können unterschiedliche Vorgehensweisen angemessen sein (weitere Einzelheiten finden Sie in den vorherigen Beispielen in den Implementierungsleitfäden).
1. **Ein nachgelagertes System kann Anfragen aufgrund der hohen Auslastung nicht verarbeiten:** Wenn Anfragen an ein nachgelagertes System immer wieder fehlschlagen, ist es nicht sinnvoll, es erneut zu versuchen. Dies kann ein bereits überlastetes System zusätzlich belasten und die Wiederherstellung erschweren. Hier kann das Unterbrechermuster verwendet werden, das fehlgeschlagene Aufrufe an ein nachgelagertes System überwacht. Wenn eine große Anzahl von Aufrufen fehlschlägt, werden keine weiteren Anfragen mehr an das nachgelagerte System gesendet und nur gelegentlich Aufrufe durchgelassen, um zu testen, ob das nachgelagerte System wieder verfügbar ist.
1. **Ein Parameterspeicher ist nicht verfügbar**: Um einen Parameterspeicher umzuwandeln, können Soft Dependency Caching oder vernünftige Standardwerte verwendet werden, die in Container-Images oder Machine Images enthalten sind. Beachten Sie, dass diese Standardwerte auf dem neuesten Stand gehalten und in die Testsuiten aufgenommen werden müssen.
1. **Ein Überwachungsservice oder eine andere nicht funktionale Abhängigkeit ist nicht verfügbar:** Wenn eine Komponente zeitweise nicht in der Lage ist, Protokolle, Metriken oder Spuren an einen zentralen Überwachungsservice zu senden, ist es oft am besten, Geschäftsfunktionen weiterhin wie gewohnt auszuführen. Es ist oft nicht akzeptabel, Metriken über einen längeren Zeitraum stillschweigend nicht zu protokollieren oder weiterzuleiten. In einigen Anwendungsfällen können auch vollständige Auditeinträge erforderlich sein, um die Compliance-Anforderungen zu erfüllen.
1. **Eine primäre Instances einer relationalen Datenbank ist möglicherweise nicht verfügbar:** Amazon Relational Database Service kann, wie fast alle relationalen Datenbanken, nur eine primäre Writer-Instance haben. Dies führt zu einem einzigen Fehlerpunkt für Schreib-Workloads und erschwert die Skalierung. Dies kann teilweise gemildert werden, indem eine Multi-AZ-Konfiguration für hohe Verfügbarkeit oder Amazon Aurora Serverless für eine bessere Skalierung verwendet wird. Bei sehr hohen Verfügbarkeitsanforderungen kann es sinnvoll sein, sich überhaupt nicht auf den primären Writer zu verlassen. Für Abfragen, die nur lesen, können Lesereplikate verwendet werden, die Redundanz und die Möglichkeit bieten, nicht nur hoch-, sondern auch aufzuskalieren. Schreibvorgänge können gepuffert werden, zum Beispiel in einer Amazon Simple Queue Service-Warteschlange, sodass Schreibanfragen von Kunden auch dann akzeptiert werden können, wenn das primäre Gerät vorübergehend nicht verfügbar ist.
## Ressourcen
**Zugehörige Dokumente:**
+ [Amazon API Gateway: Throttle API Requests for Better Throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html) (Zusammenfassung des Unterbrechers aus dem Buch „Release It\$1“)
+ [Error Retries and Exponential 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/)
**Zugehörige Videos:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP02 Drosselung von Anfragen
Drosseln Sie Anfragen, um eine Ressourcenüberlastung aufgrund eines unerwarteten Nachfrageanstiegs zu verringern. Anfragen, die unter der Drosselungsrate liegen, werden verarbeitet, während Anfragen, die über dem definierten Limit liegen, abgelehnt werden. Es wird eine Meldung zurückgegeben, die besagt, dass die Anfrage gedrosselt wurde.
**Gewünschtes Ergebnis:** Stark ansteigendes Volumen, das entweder durch plötzliche Anstiege des Kundendatenverkehrs, Flooding-Angriffe oder Wiederholungsstürme verursacht wird, wird durch Anfragedrosselung abgeschwächt, sodass Workloads die normale Verarbeitung des unterstützten Anforderungsvolumens fortsetzen können.
**Typische Anti-Muster:**
+ API-Endpunktdrosselungen sind nicht implementiert oder werden auf Standardwerten belassen, ohne die erwarteten Volumina zu berücksichtigen.
+ API-Endpunkte werden nicht ausgelastet oder die Drosselungsgrenzwerte werden nicht getestet.
+ Anforderungsraten werden ohne Berücksichtigung der Größe oder Komplexität der Anfrage gedrosselt.
+ Es werden sowohl die maximalen Anforderungsraten als auch die maximale Anforderungsgröße getestet, aber nicht beides zusammen.
+ Ressourcen werden nicht mit denselben Limits bereitgestellt, die beim Testen festgelegt wurden.
+ Es wurden keine Nutzungspläne konfiguriert oder für A2A-API-Verbraucher in Betracht gezogen.
+ Für Warteschlangenverbraucher, die horizontal skalieren, sind keine Einstellungen für maximale Parallelität konfiguriert.
+ Eine Ratenbegrenzung pro IP-Adresse wurde nicht implementiert.
**Vorteile der Nutzung dieser bewährten Methode:** Workloads, die Drosselgrenzwerte festlegen, können normal arbeiten und akzeptierte Anfragen auch bei unerwarteten Volumenspitzen erfolgreich verarbeiten. Plötzliche oder anhaltende Spitzen von Anfragen an APIs und Warteschlangen werden gedrosselt und verbrauchen keine Ressourcen für die Anforderungsverarbeitung. Ratenbegrenzungen drosseln einzelne Anforderer, sodass ein hohes Datenverkehrsvolumen von einer einzelnen IP-Adresse oder einem API-Verbraucher keine Ressourcen verbraucht, die sich auf andere Verbraucher auswirken.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
Services sollten so konzipiert sein, dass sie eine bekannte Kapazität von Anfragen verarbeiten. Diese Kapazität kann durch Auslastungstests ermittelt werden. Wenn die Anzahl der Anfragen die Grenzwerte überschreitet, signalisiert die entsprechende Antwort, dass eine Anfrage gedrosselt wurde. Dies ermöglicht es dem Verbraucher, den Fehler zu beheben und es später erneut zu versuchen.
Wenn für Ihren Service eine Drosselungsimplementierung erforderlich ist, sollten Sie die Implementierung des Token-Bucket-Algorithmus in Betracht ziehen, bei dem ein Token für eine Anfrage zählt. Tokens werden mit einer Drosselrate pro Sekunde aufgefüllt und asynchron um ein Token pro Anfrage geleert.
![\[Diagramm, das den Token-Bucket-Algorithmus beschreibt.\]](http://docs.aws.amazon.com/de_de/wellarchitected/latest/reliability-pillar/images/token-bucket-algorithm.png)
[Amazon API Gateway](https://aws.amazon.com/api-gateway/) implementiert den Token-Bucket-Algorithmus entsprechend den Konto- und Regionslimits und kann pro Client mit Nutzungsplänen konfiguriert werden. Darüber hinaus können [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) und [Amazon Kinesis](https://aws.amazon.com/kinesis/) Anfragen zwischenspeichern, um die Anforderungsrate auszugleichen, und höhere Drosselungsraten für Anfragen ermöglichen, die bearbeitet werden können. Schließlich können Sie die Ratenbegrenzung mit [AWS WAF](https://aws.amazon.com/waf/) implementieren, um bestimmte API-Verbraucher zu drosseln, die ungewöhnlich hohe Lasten erzeugen.
## Implementierungsschritte
Sie können API Gateway mit Drosselungslimits für Ihre APIs konfigurieren und `429 Too Many Requests`-Fehler zurückgeben, wenn Grenzwerte überschritten werden. Sie können AWS WAF zusammen mit Ihren AWS AppSync- und API Gateway-Endpunkten verwenden, um die Ratenbegrenzung pro IP-Adresse zu aktivieren. Wenn Ihr System asynchrone Verarbeitung toleriert, können Sie außerdem Nachrichten in eine Warteschlange oder einen Stream stellen, um die Antworten an Service-Clients zu beschleunigen und so höhere Drosselungsraten zu erreichen.
Wenn Sie Amazon SQS als Ereignisquelle für AWS Lambda konfiguriert haben, können Sie mit asynchroner Verarbeitung [maximale Gleichzeitigkeit konfigurieren](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency), um zu verhindern, dass hohe Ereignisraten die für andere Services in Ihrem Workload oder Konto benötigten Kontingente für gleichzeitige Ausführungen auf Kontoebene verbrauchen.
API Gateway bietet zwar eine verwaltete Implementierung des Token-Buckets, aber in Fällen, in denen Sie API Gateway nicht verwenden können, können Sie sprachspezifische Open-Source-Implementierungen (siehe entsprechende Beispiele unter Ressourcen) des Token-Buckets für Ihre Services nutzen.
+ Verstehen und konfigurieren Sie [API Gateway-Drosselungslimits](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) auf Kontoebene pro Region, API pro Phase und API-Schlüssel pro Nutzungsplanebene.
+ Wenden Sie die [AWS WAF-Regeln zur Ratenbegrenzung](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/) auf API Gateway- und AWS AppSync-Endpunkte an, um sich vor Flooding zu schützen und schädliche IPs zu sperren Regeln zur Ratenbegrenzung können auch für AWS AppSync-API-Schlüssel für A2A-Verbraucher konfiguriert werden.
+ Überlegen Sie, ob Sie für AWS AppSync-APIs mehr Drosselungskontrolle als Ratenbegrenzung benötigen, und konfigurieren Sie in diesem Fall ein API Gateway vor Ihrem AWS AppSync-Endpunkt.
+ Wenn Amazon SQS-Warteschlangen als Auslöser für Lambda-Warteschlangenverbraucher eingerichtet werden, legen Sie die [maximale Gleichzeitigkeit](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) auf einen Wert fest, mit dem genug verarbeitet wird, um Ihre Service-Level-Ziele zu erreichen, aber keine Gleichzeitigkeitsbeschränkungen ausnutzt werden, die sich auf andere Lambda-Funktionen auswirken. Erwägen Sie, die reservierte Gleichzeitigkeit für andere Lambda-Funktionen in demselben Konto und derselben Region festzulegen, wenn Sie Warteschlangen mit Lambda verbrauchen.
+ Verwenden Sie API Gateway mit nativen Serviceintegrationen in Amazon SQS oder Kinesis, um Anfragen zwischenzuspeichern.
+ Wenn Sie API Gateway nicht verwenden können, nutzen Sie sprachspezifische Bibliotheken, um den Token-Bucket-Algorithmus für Ihren Workload zu implementieren. Sehen Sie sich den Abschnitt mit den Beispielen an und recherchieren Sie selbst, um eine geeignete Bibliothek zu finden.
+ Testen Sie Grenzwerte, die Sie festlegen oder deren Erhöhung Sie zulassen möchten, und dokumentieren Sie die getesteten Grenzwerte.
+ Erhöhen Sie die Grenzwerte nicht über das hinaus, was Sie beim Testen festgelegt haben. Wenn Sie einen Grenzwert erhöhen, stellen Sie sicher, dass die bereitgestellten Ressourcen bereits denen in Testszenarien entsprechen oder diese übertreffen, bevor Sie die Erhöhung anwenden.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL04-BP03 Arbeite ständig](rel_prevent_interaction_failure_constant_work.md)
+ [REL05-BP03 Steuerung und Begrenzung von Wiederholungsaufrufen](rel_mitigate_interaction_failure_limit_retries.md)
**Zugehörige Dokumente:**
+ [Amazon API Gateway: Throttle API Requests for Better Throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS WAF: Rate-based rule statement ](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html)
+ [ Introducing maximum concurrency of AWS Lambda when using Amazon SQS as an event source ](https://aws.amazon.com/blogs/compute/introducing-maximum-concurrency-of-aws-lambda-functions-when-using-amazon-sqs-as-an-event-source/)
+ [AWS Lambda: Maximum Concurrency ](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency)
**Zugehörige Beispiele:**
+ [ The three most important AWS WAF rate-based rules ](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/)
+ [ Java Bucket4j ](https://github.com/bucket4j/bucket4j)
+ [ Python-Token-Bucket ](https://pypi.org/project/token-bucket/)
+ [ Node-Token-Bucket ](https://www.npmjs.com/package/tokenbucket)
+ [ .NET System Threading Rate Limiting ](https://www.nuget.org/packages/System.Threading.RateLimiting)
**Zugehörige Videos:**
+ [ Implementing GraphQL API security best practices with AWS AppSync](https://www.youtube.com/watch?v=1ASMLeJ_15U)
**Zugehörige Tools:**
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon Kinesis ](https://aws.amazon.com/kinesis/)
+ [AWS WAF](https://aws.amazon.com/waf/)
+ [Virtueller Warteraum auf AWS](https://aws.amazon.com/solutions/implementations/virtual-waiting-room-on-aws/)
# REL05-BP03 Steuerung und Begrenzung von Wiederholungsaufrufen
Verwenden Sie das exponentielle Backoff, um Anfragen in zunehmend längeren Intervallen zwischen den einzelnen Wiederholungsversuchen zu wiederholen. Führen Sie Jitter zwischen den Wiederholungen ein, um die Wiederholungsintervalle zufällig zu bestimmen. Beschränken Sie die maximale Anzahl an Wiederholungen.
**Gewünschtes Ergebnis:** Zu den typischen Komponenten eines verteilten Softwaresystems gehören Server, Load Balancer, Datenbanken und Server. DNS Während des normalen Betriebs können diese Komponenten auf Anfragen mit temporären oder begrenzten Fehlern sowie mit Fehlern antworten, die unabhängig von Wiederholungsversuchen dauerhaft bleiben würden. Wenn Clients Anfragen an Services stellen, verbrauchen die Anfragen Ressourcen wie Speicher, Threads, Verbindungen, Ports oder andere begrenzte Ressourcen. Die Steuerung und Einschränkung von Wiederholungsversuchen ist eine Strategie zur Freigabe und Minimierung des Ressourcenverbrauchs, sodass beanspruchte Systemkomponenten nicht überlastet werden.
Wenn Client-Anfragen eine Zeitüberschreitung oder Fehlerantworten erhalten, sollten sie entscheiden, ob sie es erneut versuchen möchten oder nicht. Wenn sie es erneut versuchen, tun sie dies mit exponentiellem Backoff mit Jitter und einem maximalen Wiederholungswert. Dadurch werden Backend-Services und -Prozesse entlastet und erhalten Zeit, um sich selbst zu reparieren, was zu einer schnelleren Wiederherstellung und einer erfolgreichen Bearbeitung von Anfragen führt.
**Typische Anti-Muster:**
+ Wiederholungsversuche werden ohne exponentielles Backoff, Jitter und maximale Wiederholungswerte implementiert. Backoff und Jitter helfen dabei, künstliche Datenverkehrsspitzen zu vermeiden, die durch ungewollt koordinierte Wiederholungsversuche in regelmäßigen Intervallen entstehen.
+ Implementierung von Wiederholungsversuchen, ohne deren Auswirkungen zu testen oder davon auszugehen, dass Wiederholungsversuche bereits in Szenarien integriert sind, und SDK ohne Wiederholungsversuche zu testen.
+ Veröffentlichte Fehlercodes aus Abhängigkeiten werden nicht richtig interpretiert, was dazu führt, dass bei allen Fehlern eine Wiederholung versucht wird, auch dann, wenn die Ursache auf eine fehlende Berechtigung, einen Konfigurationsfehler oder ein anderes Problem hindeutet, das vorhersehbar nicht ohne manuelles Eingreifen behoben werden kann.
+ Beobachtbarkeits-Praktiken, einschließlich der Überwachung und Meldung von Warnmeldungen bei wiederholten Serviceausfällen, damit die zugrunde liegenden Probleme bekannt werden und behoben werden können, werden nicht beachtet.
+ Es werden benutzerdefinierte Wiederholungsmechanismen entwickelt, wenn integrierte Wiederholungsfunktionen oder Wiederholungsfunktionen von Drittanbietern ausreichen.
+ Es werden Wiederholungsversuche auf mehreren Ebenen eines Anwendungsstapels auf eine Weise ausgeführt, die Wiederholungsversuche verstärkt, was die Ressourcen durch einen Wiederholungssturm weiter verbraucht. Vergewissern Sie sich, dass Sie verstehen, wie sich diese Fehler auf Ihre Anwendung und die Abhängigkeiten auswirken, auf die Sie sich verlassen, und führen Sie dann Wiederholungsversuche nur auf einer Ebene durch.
+ Nicht idempotente Serviceaufrufe werden erneut versucht, was zu unerwarteten Nebeneffekten wie doppelten Ergebnissen führt.
**Vorteile der Nutzung dieser bewährten Methode:** Wiederholungsversuche helfen Clients dabei, die gewünschten Ergebnisse zu erzielen, wenn Anfragen fehlschlagen, verbrauchen aber auch mehr Zeit auf dem Server, um die gewünschten erfolgreichen Antworten zu erhalten. Wenn Fehler selten oder vorübergehend auftreten, funktionieren Wiederholungsversuche gut. Wenn Fehler durch Ressourcenüberlastung verursacht werden, können Wiederholungsversuche die Situation verschlimmern. Durch das Hinzufügen eines exponentiellen Backoffs mit Jitter zu den Client-Wiederholungsversuchen können Server sich erholen, wenn Ausfälle durch Ressourcenüberlastung verursacht werden. Jitter verhindert, dass Anfragen zu Datenverkehrsspitzen führen, und Backoff verringert die Lasteskalation, die durch das Hinzufügen von Wiederholungsversuchen zur normalen Anforderungslast verursacht wird. Schließlich ist es wichtig, eine maximale Anzahl von Wiederholungsversuchen oder die verstrichene Zeit zu konfigurieren, um zu vermeiden, dass Rückstände entstehen, die zu metastabilen Ausfällen führen.
**Risikostufe bei fehlender Befolgung dieser bewährten Methode:** 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.
Einige AWS SDKs implementieren standardmäßig Wiederholungsversuche und exponentielles Backoff. Verwenden Sie diese integrierten AWS Implementierungen, sofern dies für Ihren Workload relevant ist. Implementieren Sie eine ähnliche Logik in Ihrem Workload, wenn Sie Services aufrufen, die idempotent sind und bei denen Wiederholungsversuche die Verfügbarkeit Ihrer Clients verbessern. Legen Sie entsprechend Ihrem Anwendungsfall Zeitüberschreitungen fest und geben Sie an, wann Wiederholversuche gestoppt werden sollen. Erstellen Sie Testszenarien für diese Wiederholungsfälle und führen Sie sie aus.
## Implementierungsschritte
+ Ermitteln Sie die optimale Ebene in Ihrem Anwendungsstack, um Wiederholungsversuche für die Services zu implementieren, auf die sich Ihre Anwendung stützt.
+ Seien Sie sich bewusstSDKs, dass es für die Sprache Ihrer Wahl bewährte Wiederholungsstrategien mit exponentiellem Backoff und Jitter gibt, und ziehen Sie diese dem Schreiben Ihrer eigenen Wiederholungsimplementierungen vor.
+ Stellen Sie sicher, dass [Services idempotent sind](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/), bevor Sie Wiederholungen implementieren. Sobald Wiederholungsversuche implementiert wurden, stellen Sie sicher, dass sie sowohl getestet als auch regelmäßig in der Produktion ausgeführt werden.
+ Verwenden Sie beim Aufrufen des AWS Dienstes die Option und und APIs machen Sie sich mit den Konfigurationsoptionen für [AWS SDKs](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)Wiederholungen vertraut [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html). Finden Sie heraus, ob die Standardeinstellungen für Ihren Anwendungsfall geeignet sind, testen Sie sie und passen Sie sie nach Bedarf an.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL04-BP04 Festlegen von Mutationsoperationen als idempotent](rel_prevent_interaction_failure_idempotent.md)
+ [REL05-BP02 Drosselung von Anfragen](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP04 Schnelles Scheitern und Begrenzen von Warteschlangen](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Client-Timeouts festlegen](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL11-BP01 Überwachen aller Komponenten der Workload auf Fehler](rel_withstand_component_failures_monitoring_health.md)
**Zugehörige Dokumente:**
+ [Fehler bei Wiederholungen und exponentiellem 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/)
+ [ Exponential Backoff and Jitter ](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/)
+ [Machen Sie Wiederholungen mit idempotent sicher APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)
**Zugehörige Beispiele:**
+ [ Spring Retry ](https://github.com/spring-projects/spring-retry)
+ [ Resilience4j Retry ](https://resilience4j.readme.io/docs/retry)
**Zugehörige Videos:**
+ [Wiederholung, Backoff und Jitter: AWS re:Invent 2019: Einführung in die Amazon Builders' Library () DOP328](https://youtu.be/sKRdemSirDM?t=1884)
**Zugehörige Tools:**
+ [AWS SDKsund Tools: Verhalten bei Wiederholungen](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)
+ [AWS Command Line Interface: Wiederholungen AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html)
# REL05-BP04 Schnelles Scheitern und Begrenzen von Warteschlangen
Wenn ein Service nicht in der Lage ist, erfolgreich auf eine Anfrage zu antworten, sollte er schnell scheitern. Dies ermöglicht die Freigabe von mit einer Anfrage verbundenen Ressourcen und damit die Wiederherstellung eines Services, falls dieser nicht mehr über genügend Ressourcen verfügt. Schnelles Scheitern ist ein etabliertes Softwaredesignmuster, das genutzt werden kann, um hochzuverlässige Workloads in der Cloud aufzubauen. Warteschlangen sind ebenfalls ein etabliertes Integrationsmuster für Unternehmen. Sie sorgen für eine ausgeglichene Auslastung und ermöglichen es den Clients, Ressourcen freizugeben, wenn eine asynchrone Verarbeitung toleriert wird. Wenn ein Service unter normalen Bedingungen erfolgreich antworten kann, aber fehlschlägt, wenn die Anforderungsrate zu hoch ist, verwenden Sie eine Warteschlange, um Anfragen zwischenzuspeichern. Lassen Sie jedoch keine langen Warteschlangen zu. Sie können dazu führen, dass veraltete Anfragen verarbeitet werden, die ein Client bereits aufgegeben hat.
**Gewünschtes Ergebnis:** Wenn bei Systemen Ressourcenknappheit, Timeouts, Ausnahmen oder Grauausfälle auftreten, die Service-Level-Ziele unerreichbar machen, ermöglichen Strategien für schnelles scheitern eine schnellere Systemwiederherstellung. Systeme, die Traffic-Spitzen absorbieren müssen und asynchrone Verarbeitung ermöglichen, können die Zuverlässigkeit verbessern, indem sie es Clients ermöglichen, Anfragen schnell freizugeben, indem sie Warteschlangen verwenden, um Anfragen an Back-End-Services zu puffern. Beim Puffern von Anfragen in Warteschlangen werden Strategien zur Warteschlangenverwaltung implementiert, um nicht mehr aufzuholende Rückstände zu vermeiden.
**Typische Anti-Muster:**
+ Implementierung von Nachrichtenwarteschlangen, aber keine Konfiguration von Warteschlangen für unzustellbare Nachrichten (DLQ) oder Alarmen für volle DLQs, um zu erkennen, wenn ein System ausfällt.
+ Nichterfassung des Alters von Nachrichten in einer Warteschlange, einem Indikator für Latenz, um zu verstehen, wann Warteschlangenverbraucher mit der Verarbeitung nicht mehr hinterher kommen oder Fehler machen, was zu erneuten Versuchen führt.
+ Kein Löschen von aufgestauten Nachrichten aus einer Warteschlange, wenn es keinen Sinn macht, diese Nachrichten zu verarbeiten, da kein Geschäftsbedarf mehr besteht.
+ Die Konfiguration von First-in-First-Out (FIFO)-Warteschlangen, wenn Last-In-First-Out (LIFO)-Warteschlangen den Client-Anforderungen besser gerecht werden würden. Dies ist beispielsweise dann der Fall, wenn keine strenge Reihenfolge erforderlich ist und die Backlog-Verarbeitung alle neuen und zeitkritischen Anfragen verzögert, was dazu führt, dass alle Clients die Service-Levels nicht einhalten.
+ Bereitstellung interner Warteschlangen für Clients, anstatt APIs verfügbar zu machen, die den Arbeitseingang verwalten und Anfragen in internen Warteschlangen platzieren.
+ Wenn zu viele Arbeitsanforderungstypen in einer einzigen Warteschlange zusammengefasst werden, kann dies die Backlog-Bedingungen verschärfen, da der Ressourcenbedarf auf die verschiedenen Anforderungstypen verteilt wird.
+ Verarbeitung komplexer und einfacher Anfragen in derselben Warteschlange, obwohl unterschiedliche Überwachungs-, Timeout- und Ressourcenzuweisungen erforderlich sind.
+ Keine Validierung von Eingaben oder Nutzung von Aussagen, um Mechanismen für schnelles Scheitern in Software zu implementieren, die Ausnahmen an übergeordnete Komponenten weiterleiten, die Fehler problemlos verarbeiten können.
+ Keine Entfernung fehlerhafter Ressourcen aus der Anforderungsweiterleitung, insbesondere bei Ausfällen ohne erkennbare Ursache mit sowohl erfolgreicher als auch fehlgeschlagener Verarbeitung aufgrund von Abstürzen und Neustarts, zeitweise auftretenden Abhängigkeitsfehlern, verringerter Kapazität oder Verlust von Netzwerkpaketen.
**Vorteile der Nutzung dieser bewährten Methode:** Systeme, die schnelles Scheitern nutzen, lassen sich leichter debuggen und korrigieren und weisen häufig Probleme im Code und in der Konfiguration auf, bevor Releases für die Produktion veröffentlicht werden. Systeme, die effektive Warteschlangenstrategien beinhalten, sind widerstandsfähiger und zuverlässiger bei Traffic-Spitzen und zeitweiligen Systemstörungen.
**Risikostufe bei fehlender Befolgung dieser bewährten Methode:** Hoch
## Implementierungsleitfaden
Strategien für schnelles Scheitern können sowohl in Softwarelösungen als auch in der Infrastruktur konfiguriert werden. Warteschlangen scheitern nicht nur schnell, sondern sind auch eine einfache und dennoch leistungsstarke Architekturtechnik zur Entkopplung von Systemkomponenten für eine ausgeglichene Auslastung. [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) bietet Funktionen zur Überwachung von Ausfällen und zur Warnung bei Ausfällen. Sobald erkannt wird, dass ein System ausfällt, können Strategien zur Schadensbegrenzung umgesetzt werden, darunter auch der Wechsel weg von knapp werdenden Ressourcen. Wenn in Systemen Warteschlangen mit [Amazon SQS](https://aws.amazon.com/sqs/) und anderen Warteschlangentechnologien implementiert werden, um eine ausgeglichene Auslastung zu gewährleisten, muss berücksichtigt werden, wie Warteschlangenrückstände sowie Fehler beim Nachrichtenabruf verwaltet werden können.
## Implementierungsschritte
+ Implementieren Sie programmatische Aussagen oder spezifische Metriken in Ihrer Software und verwenden Sie diese, um explizit Alarme bei Systemproblemen auszulösen. Amazon CloudWatch hilft Ihnen bei der Erstellung von Metriken und Alarmen auf der Grundlage des Anwendungsprotokollmusters und der SDK-Instrumentierung.
+ Verwenden Sie CloudWatch-Metriken und Alarme, um knappe Ressourcen zu erkennen, die die Latenz bei der Verarbeitung erhöhen oder Anfragen wiederholt nicht bearbeiten können.
+ Nutzen Sie asynchrone Verarbeitung, indem Sie APIs entwerfen, die Anfragen annehmen und an interne Warteschlangen anhängen. Verwenden Sie dazu Amazon SQS und senden Sie dann eine Erfolgsmeldung an den Nachrichten-Client, sodass der Client Ressourcen freigeben und mit anderen Arbeiten fortfahren kann, während die Verbraucher der Backend-Warteschlangen Anfragen verarbeiten.
+ Messen und überwachen Sie die Latenz bei der Verarbeitung von Warteschlangen, indem Sie jedes Mal, wenn Sie eine Nachricht aus einer Warteschlange nehmen, eine CloudWatch-Metrik erstellen, indem Sie die aktuelle Uhrzeit mit dem Nachrichtenzeitstempel vergleichen.
+ Wenn Fehler eine erfolgreiche Nachrichtenverarbeitung verhindern oder der Datenverkehr so stark ansteigt, dass er im Rahmen der Service Level Agreements nicht verarbeitet werden kann, wird älterer oder überschüssiger Datenverkehr in eine Überlaufwarteschlange ausgelagert. So können vorrangig neuere Aufträge verarbeitet werden. Ältere Aufträge werden verarbeitet, sobald Kapazitäten frei werden. Diese Technik ist eine Annäherung an die LIFO-Verarbeitung und ermöglicht eine normale Systemverarbeitung für alle neuen Aufträge.
+ Verwenden Sie Warteschlangen für unzustellbare Nachrichten oder Redrive-Warteschlangen, um Nachrichten, die nicht verarbeitet werden können, aus dem Backlog an einen Ort zu verschieben, der später geprüft und verarbeitet werden kann.
+ Versuchen Sie es entweder erneut oder, sofern dies tolerierbar ist, löschen Sie alte Nachrichten, indem Sie die tatsächliche Zeit mit dem Nachrichtenzeitstempel vergleichen und Nachrichten verwerfen, die für den anfragenden Client nicht mehr relevant sind.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL04-BP02 Lose gekoppelte Abhängigkeiten implementieren](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL05-BP02 Drosselung von Anfragen](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Steuerung und Begrenzung von Wiederholungsaufrufen](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL06-BP02 Definieren und Berechnen von Metriken (Aggregierung)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP07 Überwachen der gesamten Nachverfolgung von Anfragen im System](rel_monitor_aws_resources_end_to_end.md)
**Zugehörige Dokumente:**
+ [ Vermeiden von nicht mehr aufzuholenden Rückständen ](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs/)
+ [Fail Fast](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [ How can I prevent an increasing backlog of messages in my Amazon SQS queue? ](https://repost.aws/knowledge-center/sqs-message-backlog)
+ [ Elastic Load Balancing: Zonal Shift ](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/zonal-shift.html)
+ [ Amazon Application Recovery Controller: Routing-Steuerung für Datenverkehr-Failover ](https://docs.aws.amazon.com/r53recovery/latest/dg/getting-started-routing-controls.html)
**Zugehörige Beispiele:**
+ [ Enterprise Integration Patterns: Dead Letter Channel ](https://www.enterpriseintegrationpatterns.com/patterns/messaging/DeadLetterChannel.html)
**Zugehörige Videos:**
+ [AWS re:Invent 2022 - Operating highly available Multi-AZ applications](https://www.youtube.com/watch?v=mwUV5skJJ0s)
**Zugehörige Tools:**
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon MQ ](https://aws.amazon.com/amazon-mq/)
+ [AWS IoT Core](https://aws.amazon.com/iot-core/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
# REL05-BP05 Client-Timeouts festlegen
Legen Sie angemessene Zeitüberschreitungen für Verbindungen und Anfragen fest, überprüfen Sie sie systematisch und verlassen Sie sich nicht auf Standardwerte, da sie nicht Workload-spezifisch sind.
**Gewünschtes Ergebnis:** Client-Zeitüberschreitungen sollten die Kosten für Client, Server und Workload berücksichtigen, die mit dem Warten auf Anfragen verbunden sind, deren Bearbeitung ungewöhnlich lange dauert. Da es nicht möglich ist, die genaue Ursache einer Zeitüberschreitung zu ermitteln, müssen Clients ihr Wissen über Services nutzen, um Erwartungen hinsichtlich wahrscheinlicher Ursachen und geeigneter Zeitüberschreitungen zu entwickeln.
Bei Client-Verbindungen kommt es aufgrund der konfigurierten Werte zu einer Zeitüberschreitung. Nach einer Zeitüberschreitung entscheidet der Client entweder, die Anfrage abzubrechen und es erneut zu versuchen oder er öffnet einen [Unterbrecher](https://martinfowler.com/bliki/CircuitBreaker.html). Durch diese Muster wird vermieden, dass Anfragen gestellt werden, die einen zugrunde liegenden Fehlerzustand verschlimmern könnten.
**Typische Anti-Muster:**
+ Systemzeitüberschreitungen oder standardmäßige Zeitüberschreitungen werden nicht beachtet.
+ Normale Abschlusszeit für Anfragen ist nicht bekannt.
+ Mögliche Ursachen, warum die Bearbeitung von Anfragen ungewöhnlich lange dauert, oder die Kosten für die Client-, Service- oder Workload-Leistung, die während des Wartens darauf, dass diese Anfragen abgeschlossen werden, anfallen, sind nicht bekannt.
+ Die Wahrscheinlichkeit, dass ein gestörtes Netzwerk dazu führt, dass eine Anfrage erst dann fehlschlägt, wenn die Zeitüberschreitung erreicht ist, und die Kosten für die Client- und Workload-Leistung, die entstehen, wenn keine kürzere Zeitüberschreitung gewählt wird, sind nicht bekannt.
+ Zeitüberschreitungsszenarien sowohl für Verbindungen als auch für Anfragen werden nicht getestet.
+ Zu hohe Zeitüberschreitungen können zu langen Wartezeiten führen und die Ressourcenauslastung erhöhen.
+ Zu niedrige Zeitüberschreitungen führen zu künstlichen Fehlschlägen.
+ Muster zur Behandlung von Zeitüberschreitungsfehlern bei Remote-Aufrufen wie Unterbrecher und Wiederholungsversuchen werden übersehen.
+ Die Überwachung der Fehlerraten bei Serviceaufrufen, der Service-Level-Ziele für die Latenz und der Latenzausreißer wird nicht in Betracht gezogen. Diese Metriken können Aufschluss über aggressive oder tolerante Zeitüberschreitungen geben.
**Vorteile der Nutzung dieser bewährten Methode:** Zeitüberschreitungen für Remote-Aufrufe sind konfiguriert und die Systeme sind so konzipiert, dass sie Zeitüberschreitungen ordnungsgemäß behandeln, sodass Ressourcen geschont werden, wenn Remote-Aufrufe ungewöhnlich langsam reagieren und Zeitüberschreitungsfehler von Service-Clients ordnungsgemäß behandelt werden.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
Legen Sie eine Zeitüberschreitung für Verbindungen sowie Anfragen für alle Serviceabhängigkeitsaufrufe und generell für prozessübergreifende Aufrufe fest. Viele Frameworks bieten integrierte Zeitüberschreitungsfunktionen. Seien Sie jedoch vorsichtig, da einige Standardwerte unendlich oder höher als für Ihre Serviceziele akzeptabel 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.
Beachten Sie bei der Festlegung von Zeitüberschreitungsstrategien Folgendes:
+ Die Bearbeitung von Anfragen kann aufgrund ihres Inhalts, Beeinträchtigungen eines Zieldienstes oder eines Ausfalls einer Netzwerkpartition länger als normal dauern.
+ Anfragen mit ungewöhnlich aufwändigem Inhalt könnten unnötige Server- und Client-Ressourcen verbrauchen. In diesem Fall können Ressourcen geschont werden, wenn für diese Anfragen eine Zeitüberschreitung konfiguriert wird und es nicht erneut versucht wird. Services sollten sich auch durch Drosselungen und serverseitige Zeitüberschreitungen vor ungewöhnlich aufwändigen Inhalten schützen.
+ Anfragen, die aufgrund einer Servicebeeinträchtigung ungewöhnlich lange dauern, können mit einer Zeitüberschreitung abgebrochen und erneut versucht werden. Die Servicekosten für die Anfrage und den erneuten Versuch sollten berücksichtigt werden. Wenn die Ursache jedoch eine lokale Beeinträchtigung ist, ist ein erneuter Versuch wahrscheinlich nicht teuer und reduziert den Ressourcenverbrauch des Clients. Die Zeitüberschreitung kann je nach Art der Beeinträchtigung auch Serverressourcen freisetzen.
+ Anfragen, deren Bearbeitung lange dauert, weil die Anfrage oder Antwort nicht vom Netzwerk zugestellt wurde, können mit einer Zeitüberschreitung abgebrochen und erneut versucht werden. Da die Anfrage oder Antwort nicht zugestellt wurde, würde sie unabhängig von der Länge der Zeitüberschreitung fehlschlagen. Durch eine Zeitüberschreitung werden in diesem Fall keine Serverressourcen, aber Client-Ressourcen freigegeben und die Workload-Leistung wird verbessert.
Nutzen Sie etablierte Entwurfsmuster wie Wiederholungsversuche und Schutzschalter, um Timeouts elegant zu handhaben und ausfallschnelle Ansätze zu unterstützen. [AWS SDKs](https://docs.aws.amazon.com/index.html#sdks)und [AWS CLI](https://aws.amazon.com/cli/)ermöglichen die Konfiguration von Verbindungs- und Anforderungs-Timeouts sowie von Wiederholungsversuchen mit exponentiellem Backoff und Jitter. [AWS Lambda](https://aws.amazon.com/lambda/)Funktionen unterstützen die Konfiguration von Timeouts. Damit können Sie Low-Code-Schutzschalter bauen [AWS Step Functions](https://aws.amazon.com/step-functions/), die die Vorteile der vorgefertigten Integrationen mit Diensten und nutzen. AWS SDKs [AWS App Mesh](https://aws.amazon.com/app-mesh/) Envoy bietet Funktionen für Zeitüberschreitungen und Unterbrecher an.
## Implementierungsschritte
+ Konfigurieren Sie Zeitüberschreitungen für Remote-Serviceaufrufe und nutzen Sie die integrierten sprachspezifischen Zeitüberschreitungsfunktionen oder Open-Source-Bibliotheken für Zeitüberschreitungen.
+ Wenn Ihr Workload Aufrufe mit einem tätigt AWS SDK, finden Sie in der Dokumentation Informationen zur sprachspezifischen Timeout-Konfiguration.
+ [ Python ](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html)
+ [ PHP ](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.DefaultsMode.Configuration.html)
+ [ .NET ](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [ Ruby ](https://docs.aws.amazon.com/sdk-for-ruby/v3/developer-guide/timeout-duration.html)
+ [ Java ](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
+ [ Go ](https://aws.github.io/aws-sdk-go-v2/docs/configuring-sdk/retries-timeouts/#timeouts)
+ [ Node.js ](https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/Config.html)
+ [ C\$1\$1 ](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/client-config.html)
+ Wenn Sie AWS SDKs AWS CLI Or-Befehle in Ihrem Workload verwenden, konfigurieren Sie Standard-Timeout-Werte, indem Sie die AWS [Konfigurationsstandardwerte](https://docs.aws.amazon.com/sdkref/latest/guide/feature-smart-config-defaults.html) für und festlegen. `connectTimeoutInMillis` `tlsNegotiationTimeoutInMillis`
+ Wenden Sie [Befehlszeilenoptionen](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html) `cli-read-timeout` an `cli-connect-timeout` und steuern Sie einmalige AWS CLI Befehle auf Dienste. AWS
+ Überwachen Sie Remote-Serviceanfragen auf Zeitüberschreitungen und richten Sie Alarme für anhaltende Fehler ein, sodass Sie proaktiv mit Fehlerszenarien umgehen können.
+ Implementieren Sie [CloudWatch Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) und [CloudWatch Anomalieerkennung](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) zu Anruffehlerraten, Service-Level-Zielen für Latenz und Latenzausreißer, um Einblicke in den Umgang mit übermäßig aggressiven oder toleranten Timeouts zu gewinnen.
+ Konfigurieren Sie Zeitüberschreitungen für [Lambda-Funktionen](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html#configuration-timeout-console).
+ APIGateway-Clients müssen bei der Behandlung von Timeouts ihre eigenen Wiederholungsversuche implementieren. APIGateway unterstützt ein [Integrations-Timeout von 50 Millisekunden bis 29 Sekunden für Downstream-Integrationen und versucht es nicht erneut, wenn die Integration ein Timeout](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html#api-gateway-execution-service-limits-table) anfordert.
+ Implementieren Sie das [Unterbrecher](https://martinfowler.com/bliki/CircuitBreaker.html)-Muster, um zu vermeiden, dass Remote-Aufrufe getätigt werden, wenn Zeitüberschreitungen auftreten. Öffnen Sie die Leitung, um fehlschlagende Aufrufe zu vermeiden, und schließen Sie die Leitung, wenn die Aufrufe normal reagieren.
+ Für containerbasierte Workloads können Sie die Funktionen von [App Mesh Envoy](https://docs.aws.amazon.com/app-mesh/latest/userguide/envoy.html) nutzen, um von den integrierten Zeitüberschreitungen und Unterbrechern zu profitieren.
+ Wird verwendet AWS Step Functions , um Low-Code-Schutzschalter für Remote-Serviceanrufe zu erstellen, insbesondere wenn AWS native SDKs und unterstützte Step Functions Functions-Integrationen aufgerufen werden, um Ihre Arbeitslast zu vereinfachen.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL05-BP03 Steuerung und Begrenzung von Wiederholungsaufrufen](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Schnelles Scheitern und Begrenzen von Warteschlangen](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL06-BP07 Überwachen der gesamten Nachverfolgung von Anfragen im System](rel_monitor_aws_resources_end_to_end.md)
**Zugehörige Dokumente:**
+ [AWS SDK: Wiederholungsversuche und Timeouts](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Die Amazon Builders' Library: Timeouts, Wiederholungen und Backoff mit Jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [Amazon API Gateway-Kontingente und wichtige Hinweise](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html)
+ [AWS Command Line Interface: Command line options ](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html)
+ [AWS SDK for Java 2.x: API Timeouts konfigurieren](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
+ [AWS Botocore verwendet das Konfigurationsobjekt und die Konfigurationsreferenz](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html#using-the-config-object)
+ [AWS SDK für .NET: Retries and Timeouts ](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [AWS Lambda: Configuring Lambda function options ](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html)
**Zugehörige Beispiele:**
+ [Verwenden des Circuit Breaker Patterns mit AWS Step Functions Amazon DynamoDB](https://aws.amazon.com/blogs/compute/using-the-circuit-breaker-pattern-with-aws-step-functions-and-amazon-dynamodb/)
+ [Martin Fowler: CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html?ref=wellarchitected)
**Zugehörige Tools:**
+ [AWS SDKs ](https://docs.aws.amazon.com/index.html#sdks)
+ [AWS Lambda](https://aws.amazon.com/lambda/)
+ [Amazon SQS](https://aws.amazon.com/sqs/)
+ [AWS Step Functions](https://aws.amazon.com/step-functions/)
+ [AWS Command Line Interface](https://aws.amazon.com/cli/)
# REL05-BP06 Systeme soweit möglich zustandslos machen
Systeme 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.
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 das System so konzipiert ist, dass es zustandslos ist, können Sie serverlose Rechendienste wie oder verwenden. AWS Lambda AWS Fargate
Neben dem Austausch von Servern besteht ein weiterer Vorteil statusfreier Anwendungen darin, dass sie horizontal skaliert werden können, da alle verfügbaren Rechenressourcen (wie EC2 Instanzen und AWS Lambda Funktionen) jede Anforderung bearbeiten können.
**Vorteile der Nutzung dieser bewährten Methode:** Systeme mit zustandslosem Design lassen sich besser an die horizontale Skalierung anpassen, sodass Kapazitäten je nach vorhandenem Datenverkehr und bestehender Nachfrage hinzugefügt oder entfernt werden können. Sie sind auch inhärent widerstandsfähig gegenüber Ausfällen und bieten Flexibilität und Agilität bei der Anwendungsentwicklung.
**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 widerstandsfähig gegenüber Ausfällen einzelner Knoten. Analysieren Sie die Komponenten Ihrer Anwendung, die ihren Status innerhalb der Architektur beibehalten. Auf diese Weise können Sie die potenziellen Auswirkungen der Umstellung auf ein zustandsloses Design bewerten. Eine zustandslose Architektur entkoppelt Benutzerdaten und entlädt die Sitzungsdaten. Dies bietet die Flexibilität, jede Komponente unabhängig zu skalieren, um unterschiedlichen Workload-Anforderungen gerecht zu werden und die Ressourcenauslastung zu optimieren.
### Implementierungsschritte
+ Identifizieren und analysieren Sie die zustandsbehafteten Komponenten in Ihrer Anwendung.
+ Entkoppeln Sie Daten, indem Sie Benutzerdaten von der Kernanwendungslogik trennen und verwalten.
+ [Amazon Cognito](https://aws.amazon.com/cognito/) kann Benutzerdaten mithilfe von Features wie [Identitätspools](https://docs.aws.amazon.com/cognito/latest/developerguide/getting-started-with-identity-pools.html), [Benutzerpools](https://docs.aws.amazon.com/cognito/latest/developerguide/getting-started-with-cognito-user-pools.html) und [Amazon Cognito Sync](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-sync.html) von Anwendungscode entkoppeln.
+ Sie können [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) verwenden, um Benutzerdaten zu entkoppeln, indem Sie Secrets an einem sicheren, zentralen Ort speichern. Das bedeutet, dass der Anwendungscode keine Secrets speichern muss, was seine Sicherheit erhöht.
+ Erwägen Sie die Verwendung von [Amazon S3](https://aws.amazon.com/s3/), um große, unstrukturierte Daten wie Bilder und Dokumente zu speichern. Ihre Anwendung kann diese Daten bei Bedarf abrufen, sodass sie nicht im Arbeitsspeicher gespeichert werden müssen.
+ Verwenden Sie [Amazon DynamoDB](https://aws.amazon.com/dynamodb/), um Informationen wie Benutzerprofile zu speichern. Ihre Anwendung kann diese Daten nahezu in Echtzeit abfragen.
+ Verlagern Sie Sitzungsdaten in eine Datenbank, einen Cache oder externe Dateien.
+ [Amazon ElastiCache](https://aws.amazon.com/elasticache/), Amazon DynamoDB, [Amazon Elastic File System](https://aws.amazon.com/efs/) (AmazonEFS) und [Amazon MemoryDB](https://aws.amazon.com/memorydb/) sind Beispiele für AWS Dienste, die Sie zum Auslagern von Sitzungsdaten verwenden können.
+ Entwerfen Sie eine zustandslose Architektur, nachdem Sie festgelegt haben, welche Zustands- und Benutzerdaten in Ihrer bevorzugten Speicherlösung abgelegt werden müssen.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL11-BP03 Automatisieren Sie die Heilung auf allen Ebenen](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_auto_healing_system.html)
**Zugehörige 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/)
+ [Bewährte Methoden für Stateless Web Tier auf AWS](https://docs.aws.amazon.com/whitepapers/latest/best-practices-wordpress/stateless-web-tier.html)
# REL05-BP07 Nothebel einbauen
Nothebel sind schnelle Prozesse, die die Auswirkungen auf die Verfügbarkeit Ihres Workloads mindern können.
Nothebel bewirken, dass das Verhalten von Komponenten oder Abhängigkeiten mithilfe bekannter und getesteter Mechanismen deaktiviert, gedrosselt oder geändert wird. Dadurch können Beeinträchtigungen des Workloads, die durch die Erschöpfung von Ressourcen aufgrund unerwarteter Nachfragesteigerungen verursacht werden, gemildert und die Auswirkungen von Ausfällen bei nicht kritischen Komponenten innerhalb Ihres Workloads reduziert werden.
**Gewünschtes Ergebnis:** Durch die Implementierung von Nothebeln können Sie bewährte Prozesse einrichten, um die Verfügbarkeit kritischer Komponenten in Ihrem Workload aufrechtzuerhalten. Der Workload sollte sich problemlos reduzieren lassen und auch während der Aktivierung eines Nothebels weiterhin seine geschäftskritischen Funktionen ausführen. Weitere Informationen zur graziösen Degradation finden Sie unter [REL05-BP01 Implementieren Sie eine graziöse Degradation, um entsprechende harte Abhängigkeiten in weiche Abhängigkeiten umzuwandeln](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html).
**Typische Anti-Muster:**
+ Der Ausfall von nicht kritischen Abhängigkeiten wirkt sich auf die Verfügbarkeit Ihres Kern-Workloads aus.
+ Das Verhalten kritischer Komponenten wird während der Beeinträchtigung unkritischer Komponenten nicht getestet oder überprüft.
+ Es sind keine klaren und deterministischen Kriterien für die Aktivierung oder Deaktivierung eines Nothebels definiert.
**Vorteile der Nutzung dieser bewährten Methode:** Die Implementierung von Nothebeln kann die Verfügbarkeit der kritischen Komponenten Ihres Workloads verbessern, indem Ihre Resolver mit bewährten Prozessen ausgestattet werden, um auf unerwartete Nachfragespitzen oder Ausfälle von nicht kritischen Abhängigkeiten zu reagieren.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel
## Implementierungsleitfaden
+ Ermitteln Sie die kritischen Komponenten in Ihrem Workload.
+ Entwerfen und gestalten Sie die kritischen Komponenten Ihres Workloads so, dass sie Ausfällen von nicht kritischen Komponenten standhalten.
+ Führen Sie Tests durch, um das Verhalten Ihrer kritischen Komponenten beim Ausfall von nicht kritischen Komponenten zu überprüfen.
+ Definieren und überwachen Sie relevante Metriken oder Auslöser für die Einleitung von Nothebeln.
+ Definieren Sie die Verfahren (manuell oder automatisiert), die Bestandteil des Nothebels sind.
### Implementierungsschritte
+ Ermitteln Sie die kritischen Komponenten in Ihrem Workload.
+ Jede technische Komponente Ihres Workloads sollte der entsprechenden Geschäftsfunktion zugeordnet und als kritisch oder nicht kritisch eingestuft werden. Beispiele für wichtige und unkritische Funktionen bei Amazon finden Sie unter [Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second](https://community.aws/posts/how-search-uses-chaos-engineering).
+ Hierbei handelt es sich sowohl um eine technische als auch um eine geschäftliche Entscheidung, die je nach Organisation und Workload unterschiedlich ausfallen kann.
+ Entwerfen und gestalten Sie die kritischen Komponenten Ihres Workloads so, dass sie Ausfällen von nicht kritischen Komponenten standhalten.
+ Berücksichtigen Sie bei der Abhängigkeitsanalyse alle potenziellen Fehlermodi und stellen Sie sicher, dass Ihre Notfallmechanismen die kritischen Funktionen an nachgelagerte Komponenten weitergeben.
+ Führen Sie Tests durch, um das Verhalten Ihrer kritischen Komponenten bei der Aktivierung Ihrer Nothebel zu überprüfen.
+ Vermeiden Sie bimodales Verhalten. Weitere Informationen finden Sie unter [REL11-BP05 Verwenden Sie statische](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html) Stabilität, um bimodales Verhalten zu verhindern.
+ Definieren und überwachen Sie relevante Metriken und lassen Sie gegebenenfalls einen Alarm auslösen, um einen Nothebel einzuleiten.
+ Die richtigen Metriken zur Überwachung zu finden, hängt von Ihrem Workload ab. Einige Beispielmetriken sind die Latenzzeit oder die Anzahl der fehlgeschlagenen Anfragen an eine Abhängigkeit.
+ Definieren Sie die manuellen oder automatisierten Verfahren, die Bestandteil des Nothebels sind.
+ Dazu können Mechanismen wie [Lastabwurf](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/), [Drosselung von Anfragen](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html) oder die Implementierung einer [ordnungsgemäßen Funktionsminderung](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html) gehören.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL05-BP01 Implementieren Sie eine schrittweise Degradation, um anwendbare harte Abhängigkeiten in weiche Abhängigkeiten umzuwandeln](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html)
+ [REL05-BP02 Drosseln Sie Anfragen](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html)
+ [REL11-BP05 Verwenden Sie statische Stabilität, um bimodales Verhalten zu verhindern](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
**Zugehörige Dokumente:**
+ [ Automating safe, hands-off deployments ](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+ [Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second](https://community.aws/posts/how-search-uses-chaos-engineering)
**Zugehörige Videos:**
+ [AWS re:Invent 2020: Zuverlässigkeit, Konsistenz und Vertrauen durch Unveränderlichkeit](https://www.youtube.com/watch?v=jUSYnRztttY)