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.

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 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. 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 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:

Wiederholungen mit exponentiellem Backoff und 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? „, 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? „, 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 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 (AZI), regionale Isolierung, zellenbasierte Architekturen und 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).

Zunehmende Abhängigkeit MTBF

Die erste Methode, um Ihre AWS Abhängigkeit zu erhöhen, MTBF ist die Verwendung von Fehlerisolierung. 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:

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, 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? „, 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 ansehenVerfügbarkeit verteilter Systeme, 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 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? „, 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.

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, Schutzschalter und Wiederholungsversuche mit exponentiellem Backoff und Jitter können dazu beitragen, die Auswirkungen zu minimieren und 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.

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.