Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Entwerfen hochverfügbarer verteilter Systeme auf AWS
In den vorherigen Abschnitten ging es hauptsächlich um die theoretische Verfügbarkeit von Workloads und darum, was damit erreicht werden kann. Dies sind wichtige Konzepte, die Sie beim Aufbau verteilter Systeme berücksichtigen sollten. Sie helfen Ihnen bei der Auswahl von Abhängigkeiten und bei der Implementierung von Redundanz.
Wir haben uns auch mit dem Verhältnis von MTTDMTTR, und MTBF zur Verfügbarkeit befasst. In diesem Abschnitt werden praktische Anleitungen vorgestellt, die auf der vorherigen Theorie basieren. Kurz gesagt, der technische Arbeitsaufwand für Hochverfügbarkeit zielt darauf ab, die zu erhöhen MTBF und zu verringern MTTR sowie dieMTTD.
Die Beseitigung aller Fehler wäre zwar ideal, aber nicht realistisch. In großen verteilten Systemen mit tief verteilten Abhängigkeiten werden Fehler auftreten. „Alles schlägt ständig fehl“ (siehe Werner Vogels, Amazon.comCTO, [10 Lektionen aus 10 Jahren Amazon Web Services](https://www.allthingsdistributed.com/2016/03/10-lessons-from-10-years-of-aws.html).) und „Sie können keine Gesetze gegen Fehler erlassen [also] konzentrieren Sie sich auf schnelle Erkennung und Reaktion.“ (siehe Chris Pinkham, Gründungsmitglied des EC2 Amazon-Teams, [ARC335Designing for failure: Architecting resilient systems on](https://d1.awsstatic.com/events/reinvent/2019/REPEAT_1_Designing_for_failure_Architecting_resilient_systems_on_AWS_ARC335-R1.pdf)) AWS
Das bedeutet, dass Sie häufig keine Kontrolle darüber haben, ob es zu einem Ausfall kommt. Sie können kontrollieren, wie schnell Sie den Fehler erkennen und etwas dagegen unternehmen. Die Erhöhung der Verfügbarkeit MTBF ist zwar nach wie vor ein wichtiger Bestandteil der Hochverfügbarkeit, doch die wichtigsten Änderungen, auf die Kunden Einfluss haben, sind die Reduzierung MTTD undMTTR.
**Topics**
+ [Reduzieren MTTD](reducing-mttd.md)
+ [Reduzieren MTTR](reducing-mttr.md)
+ [Zunehmend MTBF](increasing-mtbf.md)
# Reduzieren MTTD
Um die Anzahl MTTD der Fehler zu reduzieren, muss der Fehler so schnell wie möglich entdeckt werden. Die Verkürzung hängt MTTD von der Beobachtbarkeit ab, d. h. davon, wie Sie Ihren Workload instrumentiert haben, um seinen Status zu verstehen. Kunden sollten ihre Kennzahlen zur *Kundenzufriedenheit* in den kritischen Subsystemen ihrer Workloads überwachen, um proaktiv zu erkennen, wann ein Problem auftritt (siehe [Anhang 1). Weitere Informationen zu diesen Kennzahlen finden MTTD Sie auch bei MTTR kritischen Kennzahlen](appendix-1-mttd-and-mttr-critical-metrics.md). ). Kunden können [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) verwenden, um *Kanarien* zu erstellen, die Ihr System APIs und Ihre Konsolen überwachen, um die Benutzererfahrung proaktiv zu messen. Es gibt eine Reihe anderer Zustandsprüfungsmechanismen, die verwendet werden können, um diese zu minimierenMTTD, z. B. [Elastic Load Balancing (ELB) -Zustandsprüfungen](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-add-elb-healthcheck.html), [Amazon Route 53-Zustandsprüfungen](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-types.html) und mehr. (Siehe [Amazon Builders' Library — Implementierung von Zustandsprüfungen](https://aws.amazon.com/builders-library/implementing-health-checks/).)
Ihre Überwachung muss auch in der Lage sein, Teilausfälle sowohl des Systems als Ganzes als auch Ihrer einzelnen Subsysteme zu erkennen. Ihre Verfügbarkeits-, Ausfall- und Latenzkennzahlen sollten die Dimensionalität Ihrer Fehlerisolationsgrenzen als [CloudWatch metrische](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension) Dimensionen verwenden. Stellen Sie sich zum Beispiel eine einzelne EC2 Instanz vor, die Teil einer zellenbasierten Architektur ist, in der use1-az1 AZ, in der Region us-east-1, die Teil des Updates des Workloads ist, das Teil seines API Steuerebenen-Subsystems ist. Wenn der Server seine Messobjekte überträgt, kann er seine Instanz-ID, AZ, Region, API Namen und Subsystemnamen als Dimensionen verwenden. Auf diese Weise können Sie die Daten beobachten und Alarme für jede dieser Dimensionen einrichten, um Fehler zu erkennen.
# Reduzieren MTTR
Nachdem ein Fehler entdeckt wurde, dient der Rest der MTTR Zeit der eigentlichen Reparatur oder Minderung der Auswirkungen. Um einen Fehler zu reparieren oder zu mindern, müssen Sie wissen, was falsch ist. Es gibt zwei Hauptgruppen von Kennzahlen, die in dieser Phase Aufschluss geben: 1/ Kennzahlen zur *Folgenabschätzung und 2/ Kennzahlen zur* *betrieblichen Health*. Die erste Gruppe gibt Aufschluss über das Ausmaß der Auswirkungen bei einem Ausfall. Dabei wird die Anzahl oder der Prozentsatz der betroffenen Kunden, Ressourcen oder Workloads gemessen. Die zweite Gruppe hilft bei der Identifizierung der *Gründe* für die Auswirkungen. Sobald das Warum erkannt wurde, können Bediener und die Automatisierung auf den Fehler reagieren und ihn beheben. Weitere Informationen zu diesen [Kennzahlen finden Sie in Anhang 1 — MTTD und in MTTR wichtigen](appendix-1-mttd-and-mttr-critical-metrics.md) Kennzahlen.
**Regel 9**
Beobachtbarkeit und Instrumentierung sind entscheidend für die Reduzierung von MTTD undMTTR.
## Umgehung von Ausfällen
Der schnellste Ansatz zur Minderung der Auswirkungen sind ausfallschnelle Subsysteme, die Ausfälle umgehen. Bei diesem Ansatz wird Redundanz verwendet, um das Problem zu reduzieren, MTTR indem die Arbeit eines ausgefallenen Subsystems schnell auf ein Ersatzsystem verlagert wird. Die Redundanz kann von Softwareprozessen über EC2 Instanzen bis hin zu mehreren Regionen AZs reichen.
Durch Ersatzsubsysteme kann die Geschwindigkeit auf nahezu MTTR Null reduziert werden. Die Wiederherstellungszeit ist nur das, was benötigt wird, um die Arbeit auf das Ersatzgerät umzuleiten. Dies geschieht häufig mit minimaler Latenz und ermöglicht es, die Arbeit innerhalb des definierten Zeitraums abzuschließenSLA, wobei die Verfügbarkeit des Systems erhalten bleibt. Dies führt MTTRs eher zu geringfügigen, vielleicht sogar unmerklichen Verzögerungen als zu längeren Zeiten der Nichtverfügbarkeit.
Wenn Ihr Service beispielsweise EC2 Instances hinter einem Application Load Balancer (ALB) verwendet, können Sie Integritätsprüfungen in einem Intervall von nur fünf Sekunden konfigurieren und nur zwei fehlgeschlagene Zustandsprüfungen benötigen, bevor ein Ziel als fehlerhaft markiert wird. Das bedeutet, dass Sie innerhalb von 10 Sekunden einen Fehler erkennen und das Senden von Datenverkehr an den fehlerhaften Host beenden können. In diesem Fall MTTR ist das praktisch dasselbe wie beim, MTTD da der Fehler, sobald er erkannt wird, auch behoben wird.
Genau das versuchen *Workloads mit hoher Verfügbarkeit* oder *kontinuierlicher Verfügbarkeit* zu erreichen. Wir möchten Ausfälle in der Arbeitslast schnell umgehen, indem wir ausgefallene Subsysteme schnell erkennen, sie als ausgefallen markieren, das Senden von Datenverkehr an sie beenden und stattdessen Datenverkehr an ein redundantes Subsystem weiterleiten.
Beachten Sie, dass Ihr Workload durch die Verwendung eines solchen Fail-Fast-Mechanismus sehr empfindlich auf vorübergehende Fehler reagiert. Stellen Sie im angegebenen Beispiel sicher, dass Ihre Load Balancer-Integritätsprüfungen nur *oberflächliche* Zustandsprüfungen oder [https://aws.amazon.com/builders-library/implementing-health-checks/](https://aws.amazon.com/builders-library/implementing-health-checks/) Integritätsprüfungen nur für die Instanz durchführen und keine Abhängigkeiten oder Workflows testen (oft als *tiefgreifende* Integritätsprüfungen bezeichnet). Dadurch wird verhindert, dass Instanzen bei vorübergehenden Fehlern, die sich auf die Arbeitslast auswirken, unnötig ausgetauscht werden.
Beobachtbarkeit und die Fähigkeit, Fehler in Subsystemen zu erkennen, sind entscheidend für die erfolgreiche Umgehung von Ausfällen. Sie müssen den Umfang der Auswirkungen kennen, damit die betroffenen Ressourcen als fehlerhaft oder ausgefallen markiert und außer Betrieb genommen werden können, sodass sie umgeleitet werden können. Wenn beispielsweise eine einzelne AZ teilweise beeinträchtigt wird, muss Ihre Instrumentierung in der Lage sein, zu erkennen, dass ein AZ-lokales Problem vorliegt, damit alle Ressourcen in dieser AZ umgeleitet werden können, bis sie wiederhergestellt sind.
Für die Umgehung von Ausfällen durch Routing sind je nach Umgebung möglicherweise auch zusätzliche Tools erforderlich. Stellen Sie sich anhand des vorherigen Beispiels mit EC2 Instances hinter einem vorALB, dass Instanzen in einer AZ möglicherweise die lokalen Zustandsprüfungen bestehen, aber eine isolierte Beeinträchtigung der AZ dazu führt, dass sie keine Verbindung zu ihrer Datenbank in einer anderen AZ herstellen können. In diesem Fall werden diese Instanzen durch die Integritätsprüfungen des Lastenausgleichs nicht außer Betrieb genommen. Ein anderer automatisierter Mechanismus wäre erforderlich, um [die AZ aus dem Load Balancer zu entfernen oder die](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-subnets.html) Instances dazu zu zwingen, ihre Integritätsprüfungen nicht zu bestehen. Dies hängt davon ab, ob es sich bei dem Umfang der Auswirkungen um eine AZ handelt. Für Workloads, die keinen Load Balancer verwenden, wäre eine ähnliche Methode erforderlich, um zu verhindern, dass Ressourcen in einer bestimmten AZ Arbeitseinheiten akzeptieren oder Kapazität aus der AZ ganz entfernen.
In einigen Fällen kann die Verlagerung von Arbeit auf ein redundantes Subsystem nicht automatisiert werden, z. B. der Failover von einer primären auf eine sekundäre Datenbank, bei der die Technologie keine eigene Wahl zum Marktführer vorsieht. Dies ist ein übliches Szenario für Architekturen mit [AWS mehreren](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/) Regionen. Da diese Arten von Failovers eine gewisse Ausfallzeit erfordern, nicht sofort rückgängig gemacht werden können und die Arbeitslast für einen gewissen Zeitraum ohne Redundanz bleibt, ist es wichtig, dass ein Mensch in den Entscheidungsprozess einbezogen wird.
Workloads, für die ein weniger striktes Konsistenzmodell verwendet werden kann, können kürzere Ergebnisse erzielen, MTTRs indem Failover-Automatisierung für mehrere Regionen verwendet wird, um Ausfälle zu umgehen. Funktionen wie die [regionsübergreifende Amazon S3 S3-Replikation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) oder [globale Amazon DynamoDB-Tabellen](https://aws.amazon.com/dynamodb/global-tables/) bieten Funktionen für mehrere Regionen durch letztlich konsistente Replikation. Darüber hinaus ist die Verwendung eines lockeren Konsistenzmodells von Vorteil, wenn wir das Theorem berücksichtigen. CAP Wenn der Workload bei Netzwerkausfällen, die sich auf die Konnektivität zu statusbehafteten Subsystemen auswirken, Verfügbarkeit der Konsistenz vorzieht, kann er dennoch fehlerfreie Antworten liefern — eine weitere Möglichkeit, Fehler zu umgehen.
Das Routing zur Umgehung von Ausfällen kann mit zwei verschiedenen Strategien implementiert werden. Die erste Strategie besteht in der Implementierung statischer Stabilität, indem im Voraus genügend Ressourcen bereitgestellt werden, um die gesamte Last des ausgefallenen Subsystems zu bewältigen. Dabei kann es sich um eine einzelne EC2 Instanz oder um eine gesamte Kapazität von AZ handeln. Der Versuch, während eines Fehlers neue Ressourcen bereitzustellen, erhöht die Abhängigkeit von einer Kontrollebene in Ihrem Wiederherstellungspfad MTTR und fügt eine Abhängigkeit von dieser hinzu. Dies ist jedoch mit zusätzlichen Kosten verbunden.
Die zweite Strategie besteht darin, einen Teil des Datenverkehrs vom ausgefallenen Teilsystem auf andere umzuleiten und [den überschüssigen Verkehr, der von der verbleibenden Kapazität nicht bewältigt werden kann, abzuleiten](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload). Während dieser Phase der Verschlechterung können Sie neue Ressourcen aufstocken, um die ausgefallene Kapazität zu ersetzen. Dieser Ansatz dauert länger MTTR und führt zu einer Abhängigkeit von einer Steuerungsebene, kostet aber weniger, wenn Reservekapazitäten im Standby-Modus vorhanden sind.
## Kehren Sie zu einem zweifelsfrei funktionierenden Zustand zurück
Ein weiterer gängiger Ansatz zur Risikominderung während einer Reparatur besteht darin, die Arbeitslast wieder in einen als funktionierend bekannten Zustand zu versetzen. Wenn eine kürzlich durchgeführte Änderung den Fehler verursacht haben könnte, ist das Zurücksetzen dieser Änderung eine Möglichkeit, zum vorherigen Zustand zurückzukehren.
In anderen Fällen könnten vorübergehende Bedingungen den Fehler verursacht haben. In diesem Fall könnte ein Neustart der Arbeitslast die Auswirkungen abschwächen. Lassen Sie uns diese beiden Szenarien untersuchen.
Während einer Bereitstellung MTTR hängt die Minimierung von MTTD und von Beobachtbarkeit und Automatisierung ab. Ihr Bereitstellungsprozess muss die Arbeitslast kontinuierlich auf erhöhte Fehlerraten, erhöhte Latenz oder Anomalien hin beobachten. Sobald diese erkannt wurden, sollte der Bereitstellungsprozess gestoppt werden.
Es gibt verschiedene [Bereitstellungsstrategien](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/deployment-strategies.html), z. B. direkte Bereitstellungen, blaue/grüne Bereitstellungen und fortlaufende Bereitstellungen. Jede dieser Methoden verwendet möglicherweise einen anderen Mechanismus, um zu einem zweifelsfrei funktionierenden Zustand zurückzukehren. Es kann automatisch zum vorherigen Status zurückkehren, den Verkehr wieder in die blaue Umgebung verlagern oder ein manuelles Eingreifen erfordern.
CloudFormation [bietet die Möglichkeit, im Rahmen seiner Stack-Erstellungs- und Aktualisierungsvorgänge ein automatisches Rollback](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-rollback-triggers.html) durchzuführen, was [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html#deployments-rollback-and-redeploy-automatic-rollbacks)auch der Fall ist. CodeDeploy unterstützt auch Blau/Grün- und fortlaufende Bereitstellungen.
Um diese Funktionen zu nutzen und Ihren Energieverbrauch zu minimieren, sollten Sie erwägenMTTR, Ihre gesamte Infrastruktur- und Codebereitstellung mithilfe dieser Services zu automatisieren. In Szenarien, in denen Sie diese Dienste nicht nutzen können, sollten Sie erwägen, das [Saga-Muster zu implementieren, um fehlgeschlagene](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-the-serverless-saga-pattern-by-using-aws-step-functions.html) AWS Step Functions Bereitstellungen rückgängig zu machen.
Wenn Sie einen *Neustart* in Betracht ziehen, gibt es verschiedene Ansätze. Diese reichen vom Neustart eines Servers, der längsten Aufgabe, bis zum Neustart eines Threads, der kürzesten Aufgabe. In der folgenden Tabelle sind einige der Methoden zum Neustarten und die ungefähren Zeiten bis zum Abschluss aufgeführt (repräsentativ für Größenunterschiede, diese sind nicht exakt).
| Mechanismus zur Behebung von Fehlern | Geschätzt MTTR |
| --- | --- |
| Starten und konfigurieren Sie einen neuen virtuellen Server | 15 Minuten |
| Stellen Sie die Software erneut bereit | 10 Minuten |
| Starten Sie den Server neu | 5 Minuten |
| Starten Sie den Container neu oder starten Sie ihn | 2 Sekunden |
| Rufen Sie eine neue serverlose Funktion auf | 100 ms |
| Prozess neu starten | 10 ms |
| Thread neu starten | 10 μs |
Wenn man sich die Tabelle ansieht, gibt es einige klare Vorteile MTTR bei der Verwendung von Containern und serverlosen Funktionen (wie [AWS Lambda](https://aws.amazon.com/lambda/)). Sie MTTR sind um Größenordnungen schneller als der Neustart einer virtuellen Maschine oder der Start einer neuen. Die Verwendung von Fehlerisolierung durch Softwaremodularität ist jedoch ebenfalls von Vorteil. Wenn Sie den Ausfall eines einzelnen Prozesses oder Threads eindämmen können, ist die Wiederherstellung nach diesem Fehler viel schneller als der Neustart eines Containers oder Servers.
Als allgemeine Methode zur Wiederherstellung können Sie von unten nach oben vorgehen: 1/Restart, 2/Reboot, 3/Reimage/ReDeploy, 4/Replace. Sobald Sie jedoch mit dem Neustartschritt begonnen haben, ist das Routing zur Umgehung von Fehlern in der Regel schneller (in der Regel dauert es höchstens 3-4 Minuten). Um die Auswirkungen nach einem Neustartversuch so schnell wie möglich abzumildern, umgehen Sie den Ausfall und setzen Sie dann im Hintergrund den Wiederherstellungsprozess fort, um die Kapazität Ihres Workloads wiederherzustellen.
**Regel 10**
Konzentrieren Sie sich auf die Minderung der Auswirkungen, nicht auf die Problemlösung. Gehen Sie den schnellsten Weg zurück zum Normalbetrieb.
## Diagnose eines Fehlers
Ein Teil des Reparaturprozesses nach der Erkennung ist der Diagnosezeitraum. In diesem Zeitraum versuchen die Bediener herauszufinden, was falsch ist. Dieser Prozess kann das Abfragen von Protokollen, das Überprüfen von Operational Health-Metriken oder das Anmelden bei Hosts zur Fehlerbehebung beinhalten. All diese Aktionen benötigen Zeit. Daher kann die Erstellung von Tools und Runbooks zur Beschleunigung dieser Aktionen auch dazu beitragen, diesen Aufwand zu reduzieren. MTTR
## Runbooks und Automatisierung
In ähnlicher Weise müssen Bediener, nachdem Sie festgestellt haben, was falsch ist und welche Maßnahmen zur Behebung der Arbeitslast ergriffen werden können, in der Regel einige Schritte ausführen, um das Problem zu lösen. Nach einem Ausfall kann die Arbeitslast beispielsweise am schnellsten repariert werden, indem sie neu gestartet wird, was mehrere, geordnete Schritte umfassen kann. Die Verwendung eines Runbooks, das diese Schritte entweder automatisiert oder einem Bediener spezifische Anweisungen gibt, beschleunigt den Vorgang und trägt dazu bei, das Risiko unbeabsichtigter Aktionen zu verringern.
# Zunehmend MTBF
Die letzte Komponente zur Verbesserung der Verfügbarkeit ist die Erhöhung derMTBF. Dies kann sowohl für die Software als auch für die AWS Dienste gelten, mit denen sie ausgeführt wird.
## Zunehmendes verteiltes System MTBF
Eine Möglichkeit zur Steigerung MTBF besteht darin, Fehler in der Software zu reduzieren. Dazu stehen verschiedene Möglichkeiten zur Verfügung. Kunden können Tools wie [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) verwenden, um häufig auftretende Fehler zu finden und zu beheben. Sie sollten außerdem umfassende Peer-Code-Reviews, Komponententests, Integrationstests, Regressionstests und Auslastungstests an Software durchführen, bevor sie in der Produktion eingesetzt wird. Wenn Sie den Umfang der Codeabdeckung in Tests erhöhen, können Sie sicherstellen, dass auch ungewöhnliche Codeausführungspfade getestet werden.
Die Implementierung kleinerer Änderungen kann auch dazu beitragen, unerwartete Ergebnisse zu vermeiden, indem die Komplexität von Änderungen reduziert wird. Jede Aktivität bietet die Möglichkeit, Fehler zu identifizieren und zu beheben, bevor sie überhaupt in Anspruch genommen werden können.
Ein weiterer Ansatz zur Vermeidung von Ausfällen sind [regelmäßige Tests](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html). Durch die Implementierung eines Chaos Engineering-Programms können Sie testen, wie Ihr Workload ausfällt, Wiederherstellungsverfahren validieren und Fehlerquellen finden und beheben, bevor sie in der Produktion auftreten. Kunden können den [AWS Fault Injection Simulator](https://aws.amazon.com/fis/) als Teil ihres Toolsets für Chaos-Engineering-Experimente verwenden.
Fehlertoleranz ist eine weitere Möglichkeit, Ausfälle in einem verteilten System zu verhindern. Fail-Fast-Module, Wiederholungsversuche mit exponentiellem Backoff und Jitter, Transaktionen und Idempotenz sind alles Techniken, um Workloads fehlertolerant zu machen.
Bei Transaktionen handelt es sich um eine Gruppe von Vorgängen, die den Eigenschaften entsprechen. ACID Diese sind:
+ **Atomarität** — Entweder werden alle Aktionen ausgeführt oder keine von ihnen wird ausgeführt.
+ **Konsistenz** — Bei jeder Transaktion wird der Workload in einem gültigen Zustand belassen.
+ **Isolation** — Bei gleichzeitig ausgeführten Transaktionen bleibt der Workload in demselben Zustand, als ob sie sequentiell ausgeführt worden wären.
+ **Dauerhaftigkeit** — Sobald eine Transaktion festgeschrieben ist, bleiben alle ihre Auswirkungen erhalten, auch wenn der Workload ausfällt.
Wiederholungen mit [exponentiellem Backoff und Jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) ermöglichen es Ihnen, vorübergehende Ausfälle zu überwinden, die durch Heisenbugs, Überlastung oder andere Bedingungen verursacht werden. Wenn Transaktionen idempotent sind, können sie ohne Nebenwirkungen mehrfach wiederholt werden.
Wenn wir die Auswirkungen eines Heisenbugs auf eine fehlertolerante Hardwarekonfiguration berücksichtigen, wären wir ziemlich unbesorgt, da die Wahrscheinlichkeit, dass der Heisenbug sowohl auf dem primären als auch auf dem redundanten Subsystem auftritt, verschwindend gering ist. [(Siehe Jim Gray, „Warum stoppen Computer und was kann dagegen getan werden?](https://pages.cs.wisc.edu/~remzi/Classes/739/Fall2018/Papers/gray85-easy.pdf) „, Juni 1985, Technischer Tandembericht 85.7.) In verteilten Systemen wollen wir mit unserer Software dieselben Ergebnisse erzielen.
Wenn ein Heisenbug ausgelöst wird, ist es unerlässlich, dass die Software die fehlerhafte Operation schnell erkennt und fehlschlägt, damit sie erneut versucht werden kann. Dies wird durch defensive Programmierung und Validierung von Eingaben, Zwischenergebnissen und Ausgaben erreicht. Darüber hinaus sind Prozesse isoliert und teilen sich keinen Status mit anderen Prozessen.
Dieser modulare Ansatz stellt sicher, dass der Umfang der Auswirkungen bei einem Ausfall begrenzt ist. Prozesse schlagen unabhängig voneinander fehl. Wenn ein Prozess fehlschlägt, sollte die Software „Prozesspaare“ verwenden, um die Arbeit erneut zu versuchen, was bedeutet, dass ein neuer Prozess die Arbeit eines fehlgeschlagenen Prozesses übernehmen kann. Um die Zuverlässigkeit und Integrität der Arbeitslast zu gewährleisten, sollte jeder Vorgang als Transaktion behandelt werden. ACID
Auf diese Weise kann ein Prozess fehlschlagen, ohne dass der Status der Arbeitslast dadurch beeinträchtigt wird, dass die Transaktion abgebrochen und alle vorgenommenen Änderungen rückgängig gemacht werden. Auf diese Weise kann der Wiederherstellungsprozess die Transaktion aus einem zweifelsfrei funktionierenden Zustand erneut versuchen und anschließend ordnungsgemäß neu starten. Auf diese Weise kann Software fehlertolerant gegenüber Heisenbugs sein.
Sie sollten jedoch nicht darauf abzielen, Software fehlertolerant gegenüber Bohrbugs zu machen. Diese Fehler müssen gefunden und behoben werden, bevor die Arbeitslast in die Produktion übergeht, da keine Redundanz jemals zu einem korrekten Ergebnis führen kann. (Siehe Jim Gray, „[Warum stoppen Computer und was kann dagegen getan werden](https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf)? „, Juni 1985, Technischer Tandembericht 85.7.)
Der letzte Weg zur Erhöhung MTBF besteht darin, den Umfang der Auswirkungen eines Fehlers zu verringern. Die Verwendung von [Fehlerisolierung](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) durch Modularisierung zur Erstellung von Fehlercontainern ist hierfür eine der wichtigsten Methoden, wie weiter oben unter *Fehlertoleranz und Fehlerisolierung* beschrieben. Die Reduzierung der Ausfallrate verbessert die Verfügbarkeit. AWS verwendet Techniken wie die Aufteilung von Diensten in Steuerungsebenen und Datenebenen, [Availability Zone Independence](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) (AZI), [regionale Isolierung](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/), [zellenbasierte Architekturen](https://www.youtube.com/watch?v=swQbA4zub20) und [Shuffle-Sharding](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding) zur Fehlerisolierung. Dies sind auch Muster, die auch von Kunden verwendet werden können. AWS
Schauen wir uns zum Beispiel ein Szenario an, in dem Kunden aufgrund eines Workloads in verschiedene Fehlercontainer der Infrastruktur aufgeteilt wurden, von denen höchstens 5% aller Kunden bedient wurden. Bei einem dieser Fehlercontainer tritt bei 10% der Anfragen ein Ereignis auf, das die Latenz über das Client-Timeout hinaus erhöht. Während dieses Ereignisses war der Service für 95% der Kunden zu 100% verfügbar. Bei den anderen 5% schien der Service zu 90% verfügbar zu sein. Dies führt zu einer Verfügbarkeit von 1 − (5% *o* *f* *c* *u* *s* *t* *o* *m* *e* *r* *s* × 10% *o* *f* *t* *h* *e* *i* *r r *r** *e *q* *u* *e** *s *t* *s**) = 99,5% anstatt dass 10% der Anfragen bei 100% der Kunden fehlschlagen (was zu einer Verfügbarkeit von 90% führt).
**Regel 11**
Die Fehlerisolierung verringert den Umfang der Auswirkungen und erhöht die MTBF Arbeitslast, da die Gesamtausfallrate reduziert wird.
## Zunehmende Abhängigkeit MTBF
Die erste Methode, um Ihre AWS Abhängigkeit zu erhöhen, MTBF ist die Verwendung von [Fehlerisolierung](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html). Viele AWS Dienste bieten ein gewisses Maß an Isolation in der AZ, was bedeutet, dass ein Ausfall in einer AZ keine Auswirkungen auf den Service in einer anderen AZ hat.
Die Verwendung redundanter EC2 Instanzen in mehreren Instanzen AZs erhöht die Verfügbarkeit des Subsystems. AZIbietet eine sparsame Kapazität innerhalb einer einzelnen Region, sodass Sie Ihre Verfügbarkeit für AZI Dienste erhöhen können.
Allerdings funktionieren nicht alle AWS Dienste auf AZ-Ebene. Viele andere bieten regionale Isolation. In diesem Fall, in dem die Verfügbarkeit des Regionaldienstes nicht die für Ihre Arbeitslast erforderliche Gesamtverfügbarkeit unterstützt, könnten Sie einen regionsübergreifenden Ansatz in Betracht ziehen. Jede Region bietet eine isolierte Instanziierung des Dienstes, was einem Sparing entspricht.
Es gibt verschiedene Dienste, die den Aufbau eines Dienstes für mehrere Regionen erleichtern. Beispielsweise:
+ [Globale Amazon Aurora Aurora-Datenbank](https://aws.amazon.com/rds/aurora/global-database/)
+ [Globale Amazon DynamoDB-Tabellen](https://aws.amazon.com/dynamodb/global-tables/)
+ [Amazon ElastiCache (RedisOSS) — Globaler Datenspeicher](https://aws.amazon.com/elasticache/redis/global-datastore/)
+ [AWS Globaler Beschleuniger](https://aws.amazon.com/global-accelerator/)
+ [Regionsübergreifende Amazon S3 S3-Replikation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [Amazon Route 53-Controller für die Anwendungswiederherstellung](https://aws.amazon.com/route53/application-recovery-controller/)
Dieses Dokument befasst sich nicht mit den Strategien für den Aufbau von Workloads in mehreren Regionen. Sie sollten jedoch die Verfügbarkeitsvorteile von Architekturen mit mehreren Regionen gegen die zusätzlichen Kosten, die Komplexität und die betrieblichen Abläufe abwägen, die erforderlich sind, um Ihre gewünschten Verfügbarkeitsziele zu erreichen.
Die nächste Methode zur Erhöhung der Abhängigkeit MTBF besteht darin, Ihren Workload so zu gestalten, dass er statisch stabil ist. Beispiel: Sie haben einen Workload, der Produktinformationen bereitstellt. Wenn Ihre Kunden eine Anfrage für ein Produkt stellen, sendet Ihr Service eine Anfrage an einen externen Metadatendienst, um Produktdetails abzurufen. Dann gibt Ihr Workload all diese Informationen an den Benutzer zurück.
Wenn der Metadatendienst jedoch nicht verfügbar ist, schlagen die Anfragen Ihrer Kunden fehl. Stattdessen können Sie die Metadaten asynchron lokal in Ihren Service abrufen oder per Push übertragen, um Anfragen zu beantworten. Dadurch entfällt der synchrone Aufruf des Metadatendienstes aus Ihrem kritischen Pfad.
Da Ihr Service auch dann noch verfügbar ist, wenn der Metadaten-Service nicht verfügbar ist, können Sie ihn bei Ihrer Verfügbarkeitsberechnung als Abhängigkeit entfernen. Dieses Beispiel basiert auf der Annahme, dass sich die Metadaten nicht häufig ändern und dass die Bereitstellung veralteter Metadaten besser ist als die fehlgeschlagene Anfrage. Ein anderes ähnliches Beispiel ist [serve-stale](https://www.rfc-editor.org/rfc/rfc8767), da es ermöglichtDNS, Daten über das TTL Ablaufdatum hinaus im Cache zu behalten und für Antworten zu verwenden, wenn eine aktualisierte Antwort nicht sofort verfügbar ist.
Die letzte Methode zur Erhöhung der Abhängigkeit MTBF besteht darin, den Umfang der Auswirkungen eines Fehlers zu verringern. Wie bereits erwähnt, handelt es sich bei einem Ausfall nicht um ein binäres Ereignis, sondern um verschiedene Ausfälle. Dies ist der Effekt der Modularisierung; Fehler beschränken sich nur auf die Anfragen oder Benutzer, die von diesem Container bedient werden.
Dies führt zu weniger Ausfällen während eines Ereignisses, was letztlich die Verfügbarkeit der gesamten Arbeitslast erhöht, da der Umfang der Auswirkungen begrenzt wird.
## Reduzierung häufiger Einflussquellen
1985 entdeckte Jim Gray im Rahmen einer Studie bei Tandem Computers, dass Misserfolge hauptsächlich auf zwei Faktoren zurückzuführen waren: Software und Betrieb. (Siehe Jim Gray, „[Warum stoppen Computer und was kann dagegen getan werden](https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf)? „, Juni 1985, Technischer Tandembericht 85.7.) Dies gilt auch nach 36 Jahren noch immer. Trotz technologischer Fortschritte gibt es keine einfache Lösung für diese Probleme, und die Hauptausfallquellen haben sich nicht geändert. Die Behebung von Softwarefehlern wurde zu Beginn dieses Abschnitts erörtert, weshalb der Schwerpunkt hier auf dem Betrieb und der Reduzierung der Fehlerhäufigkeit liegen wird.
### Stabilität im Vergleich zu Funktionen
Wenn wir uns in diesem Abschnitt die Grafik mit den Ausfallraten für Software und Hardware ansehen[Verfügbarkeit verteilter Systeme](distributed-system-availability.md), können wir feststellen, dass in jeder Softwareversion Fehler hinzukommen. Das bedeutet, dass jede Änderung der Arbeitslast ein erhöhtes Ausfallrisiko mit sich bringt. Bei diesen Änderungen handelt es sich in der Regel um Dinge wie neue Funktionen, was eine logische Folge darstellt. Workloads mit höherer Verfügbarkeit werden die Stabilität gegenüber neuen Funktionen begünstigen. Daher besteht eine der einfachsten Möglichkeiten zur Verbesserung der Verfügbarkeit darin, seltener bereitzustellen oder weniger Funktionen bereitzustellen. Workloads, die häufiger bereitgestellt werden, weisen naturgemäß eine geringere Verfügbarkeit auf als Workloads, bei denen dies nicht der Fall ist. Workloads, bei denen keine Funktionen hinzugefügt werden können, halten jedoch nicht mit der Kundennachfrage Schritt und können mit der Zeit an Nutzen verlieren.
Wie können wir also weiterhin innovativ sein und Funktionen sicher veröffentlichen? Die Antwort lautet Standardisierung. Was ist die richtige Art der Bereitstellung? Wie ordnet man Bereitstellungen an? Was sind die Standards für Tests? Wie lange wartest du zwischen den Stufen? Decken Ihre Komponententests den Softwarecode ausreichend ab? Diese Fragen werden durch Standardisierung beantwortet und Probleme vermieden, die beispielsweise dadurch entstehen, dass keine Lasttests durchgeführt werden, Bereitstellungsphasen übersprungen werden oder zu schnell auf zu vielen Hosts bereitgestellt werden.
Die Art und Weise, wie Sie Standardisierung implementieren, erfolgt durch Automatisierung. Es reduziert die Wahrscheinlichkeit menschlicher Fehler und ermöglicht Computern, das zu tun, worin sie gut sind, nämlich jedes Mal dasselbe immer und immer wieder auf die gleiche Weise zu tun. Die Art und Weise, wie man Standardisierung und Automatisierung zusammenhält, besteht darin, sich Ziele zu setzen. Ziele wie keine manuellen Änderungen, Hostzugriff nur über bedingte Autorisierungssysteme, das Schreiben von Lasttests für alle API und so weiter. Operative Exzellenz ist eine kulturelle Norm, die tiefgreifende Veränderungen erfordern kann. Die Festlegung und Verfolgung der Leistung anhand eines Ziels trägt dazu bei, einen kulturellen Wandel voranzutreiben, der weitreichende Auswirkungen auf die Verfügbarkeit von Workloads haben wird. Die [Säule AWS Well-Architected Operational Excellence](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html) bietet umfassende Best Practices für operative Exzellenz.
### Sicherheit für den Bediener
Der andere Hauptverursacher von betrieblichen Ereignissen, die zu Ausfällen führen, sind Menschen. Menschen machen Fehler. Sie verwenden möglicherweise die falschen Anmeldeinformationen, geben den falschen Befehl ein, drücken zu früh die Eingabetaste oder verpassen einen wichtigen Schritt. Manuelles Handeln führt immer wieder zu Fehlern, was wiederum zum Scheitern führt.
Eine der Hauptursachen für Bedienfehler sind verwirrende, wenig intuitive oder inkonsistente Benutzeroberflächen. Jim Gray stellte in seiner Studie von 1985 auch fest, dass „Benutzeroberflächen, die den Bediener nach Informationen fragen oder ihn auffordern, eine Funktion auszuführen, einfach, konsistent und fehlertolerant sein müssen“. (Siehe Jim Gray, „[Warum hören Computer auf und was kann dagegen getan werden](https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf)? „, Juni 1985, Technischer Tandembericht 85.7.) Diese Einsicht gilt auch heute noch. In den letzten drei Jahrzehnten gab es in der Branche zahlreiche Beispiele, bei denen eine verwirrende oder komplexe Benutzeroberfläche, fehlende Bestätigungen oder Anweisungen oder auch einfach nur eine unfreundliche menschliche Sprache dazu geführt haben, dass ein Bediener das Falsche getan hat.
**Regel 12**
Machen Sie es den Bedienern leicht, das Richtige zu tun.
### Vermeidung von Überlastung
Der letzte gemeinsame Einflussfaktor sind Ihre Kunden, die eigentlichen Nutzer Ihres Workloads. Erfolgreiche Workloads werden in der Regel häufig genutzt, aber manchmal übersteigt diese Nutzung die Skalierbarkeit des Workloads. Es gibt viele Dinge, die passieren können: Festplatten können voll werden, Thread-Pools könnten erschöpft sein, die Netzwerkbandbreite könnte ausgelastet sein oder es können Grenzwerte für Datenbankverbindungen erreicht werden.
Es gibt keine ausfallsichere Methode, um diese zu beseitigen, aber die proaktive Überwachung von Kapazität und Auslastung anhand von Operational Health Metriken gibt frühzeitig Warnmeldungen, wenn diese Ausfälle auftreten könnten. Techniken wie [Load-Shedding](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload), [Schutzschalter](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-interactions-in-a-distributed-system-to-mitigate-or-withstand-failures.html) und [Wiederholungsversuche mit exponentiellem Backoff und Jitter können dazu beitragen, die Auswirkungen zu minimieren und](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) die Erfolgsquote zu erhöhen, aber diese Situationen stellen immer noch einen Fehler dar. Automatisierte Skalierung auf der Grundlage von Operational Health-Metriken kann dazu beitragen, die Häufigkeit von Ausfällen aufgrund von Überlastung zu reduzieren, ist aber möglicherweise nicht in der Lage, schnell genug auf Nutzungsänderungen zu reagieren.
Wenn Sie die kontinuierlich verfügbare Kapazität für Kunden sicherstellen möchten, müssen Sie Kompromisse bei Verfügbarkeit und Kosten eingehen. Eine Möglichkeit, um sicherzustellen, dass Kapazitätsmangel nicht zu Nichtverfügbarkeit führt, besteht darin, jedem Kunden ein Kontingent zuzuweisen und sicherzustellen, dass die Kapazität Ihres Workloads so skaliert wird, dass 100% der zugewiesenen Kontingente bereitgestellt werden. Wenn Kunden ihr Kontingent überschreiten, werden sie gedrosselt. Das ist kein Fehler und wird nicht auf die Verfügbarkeit angerechnet. Sie müssen auch Ihren Kundenstamm genau verfolgen und die future Auslastung prognostizieren, um ausreichend Kapazität bereitzustellen. Auf diese Weise wird sichergestellt, dass Ihr Workload nicht aufgrund einer zu hohen Auslastung durch Ihre Kunden zu Ausfallszenarien gezwungen wird.
+ [Amazon Builders' Library — Verwendung von Load Shedding zur Vermeidung von Überlastung](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/)
+ [Amazon Builders' Library — Fairness in Mehrmandantensystemen](https://aws.amazon.com/builders-library/fairness-in-multi-tenant-systems)
Schauen wir uns zum Beispiel einen Workload an, der einen Speicherservice bereitstellt. Jeder Server im Workload kann 100 Downloads pro Sekunde unterstützen, Kunden erhalten ein Kontingent von 200 Downloads pro Sekunde und es gibt 500 Kunden. Um dieses Kundenvolumen unterstützen zu können, muss der Service Kapazität für 100.000 Downloads pro Sekunde bereitstellen, wofür 1.000 Server erforderlich sind. Wenn ein Kunde sein Kontingent überschreitet, wird er gedrosselt, sodass für jeden anderen Kunden ausreichend Kapazität zur Verfügung steht. Dies ist ein einfaches Beispiel für eine Möglichkeit, Überlastung zu vermeiden, ohne Arbeitseinheiten abzulehnen.