# 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/)