REL10-BP04 Verwenden von Bulkhead-Architekturen, um den Umfang von Beeinträchtigungen zu begrenzen
Implementieren Sie Bulkhead-Architekturen (zellenbasierte Architekturen), um die Auswirkungen von Fehlern innerhalb einer Workload auf eine begrenzte Anzahl von Komponenten zu beschränken.
Gewünschtes Ergebnis: Eine zellenbasierte Architektur verwendet mehrere isolierte Instances einer Workload, wobei jede Instance als Zelle bezeichnet wird. Jede Zelle ist unabhängig. Sie teilt ihren Status nicht mit anderen Zellen und bearbeitet eine Teilmenge der gesamten Workload-Anfragen. Dadurch werden die möglichen Auswirkungen eines Fehlers, z. B. eines fehlerhaften Software-Updates, auf eine einzelne Zelle und die von ihr verarbeiteten Anfragen reduziert. Wenn in einer Workload 10 Zellen für die Beantwortung von 100 Anfragen verwendet werden, sind bei einem Fehler 90 % der gesamten Anfragen nicht davon betroffen.
Typische Anti-Muster:
-
Es wird ein unbegrenztes Wachstum der Zellen zugelassen.
-
Code-Updates oder Bereitstellungen werden auf alle Zellen gleichzeitig angewandt.
-
Status oder Komponenten werden von den Zellen geteilt (mit Ausnahme der Router-Schicht).
-
Es werden komplexe Geschäfts- oder Routing-Logiken in die Routing-Schicht eingefügt.
-
Es gibt keine Minimierung der zellenübergreifenden Interaktionen.
Vorteile der Nutzung dieser bewährten Methode: Bei zellenbasierten Architekturen sind viele gängige Fehlertypen in der Zelle selbst enthalten, was eine zusätzliche Fehlerisolierung ermöglicht. Diese Fehlergrenzen können die Widerstandsfähigkeit gegenüber Fehlertypen erhöhen, die sonst schwer einzudämmen sind, wie z. B. erfolglose Codebereitstellungen oder Anfragen, die beschädigt sind oder einen bestimmten Fehlermodus aufrufen (auch bekannt als Poison-Pill–Anfragen).
Risikostufe, wenn diese bewährte Methode nicht eingeführt wird: Hoch
Implementierungsleitfaden
Auf einem Schiff sorgen Schotten dafür, dass eine Beschädigung des Rumpfes auf einen Teil des Schiffes beschränkt bleibt. In komplexen Systemen wird dieses Muster oft kopiert, um eine Fehlerisolierung zu ermöglichen. Fehlerisolierte Grenzen beschränken die Auswirkungen eines Fehlers innerhalb einer Workload auf eine begrenzte Anzahl von Komponenten. Komponenten außerhalb der Grenze sind von dem Ausfall nicht betroffen. Durch die Verwendung mehrerer fehlerisolierter Grenzen können Sie die Auswirkungen auf Ihre Workload einschränken. Bei AWS können Kunden mehrere Availability Zones und Regionen verwenden, um eine Fehlerisolierung zu gewährleisten. Das Konzept der Fehlerisolierung lässt sich jedoch auch auf die Architektur Ihrer Workload ausweiten.
Die gesamte Workload wird durch einen Partitionsschlüssel in Zellen unterteilt. Dieser Schlüssel muss mit der Struktur des Service übereinstimmen oder mit der natürlichen Art und Weise, wie die Workload eines Service mit minimalen zellenübergreifenden Interaktionen unterteilt werden kann. Beispiele für Partitionsschlüssel sind die ID des Kunden, die ID der Ressource oder jeder andere Parameter, der in den meisten API-Aufrufen leicht zugänglich ist. Eine Schicht für das Routing von Zellen verteilt Anfragen auf der Grundlage des Partitionsschlüssels an einzelne Zellen und präsentiert den Kunden einen einzigen Endpunkt.
Implementierungsschritte
Bei der Entwicklung einer zellenbasierten Architektur sind mehrere Designüberlegungen zu berücksichtigen:
-
Partitionsschlüssel: Bei der Auswahl des Partitionsschlüssels sollten besondere Überlegungen angestellt werden.
-
Er sollte mit der Struktur des Service übereinstimmen oder mit der natürlichen Art und Weise, wie die Workload eines Service mit minimalen zellenübergreifenden Interaktionen unterteilt werden kann. Beispiele sind
customer ID
oderresource ID
. -
Der Partitionsschlüssel muss in allen Anfragen verfügbar sein – entweder direkt oder in einer Weise, die sich durch andere Parameter leicht deterministisch ableiten lässt.
-
-
Persistente Zellenzuordnung: Upstream-Services sollten während des gesamten Lebenszyklus ihrer Ressourcen nur mit einer einzelnen Zelle interagieren.
-
Je nach Workload kann eine Strategie zur Migration von Zellen erforderlich sein, um Daten von einer Zelle in eine andere zu migrieren. Ein mögliches Szenario, in dem eine Migration von Zellen erforderlich sein kann, ist, wenn ein bestimmter Benutzer oder eine bestimmte Ressource in Ihrer Workload zu groß wird und eine eigene Zelle benötigt.
-
Zellen sollten keinen Status und keine Komponenten gemeinsam nutzen.
-
Folglich sollten zellenübergreifende Interaktionen vermieden oder auf ein Minimum beschränkt werden, da diese Interaktionen Abhängigkeiten zwischen den Zellen schaffen und somit die Möglichkeiten zur Fehlerisolierung verringern.
-
-
Router-Schicht: Die Router-Schicht ist eine Komponente, die von Zellen gemeinsam genutzt wird, sodass nicht dieselbe Segmentierungsstrategie verfolgt werden kann wie bei Zellen.
-
Es wird empfohlen, dass die Routing-Schicht Anfragen auf einzelne Zellen verteilt, indem sie einen effizienten Algorithmus für die Zuordnung von Partitionen einsetzt – z. B. als die Kombination von kryptographischen Hash-Funktionen und einer modularen Arithmetik.
-
Um Auswirkungen auf mehrere Zellen zu vermeiden, muss die Routing-Schicht so einfach und horizontal skalierbar wie möglich bleiben, was den Verzicht auf eine komplexe Geschäftslogik innerhalb dieser Schicht erforderlich macht. Dies hat den zusätzlichen Nutzen, dass das erwartete Verhalten jederzeit leicht nachvollziehbar ist, was eine gründliche Testbarkeit ermöglicht. Wie Colm MacCárthaigh in Zuverlässigkeit, stetige Ausführung und eine gute Tasse Kaffee
erklärt, sorgen einfache Designs und Muster mit konstanter Ausführung für zuverlässige Systeme und verringern die Widerstandsfähigkeit gegen Fragilität.
-
-
Zellgröße: Für Zellen sollte eine maximale Größe festgelegt sein, die sie nicht überschreiten dürfen.
-
Die maximale Größe sollte durch gründliche Tests ermittelt werden – bis Sollbruchstellen erreicht und sichere operative Margen etabliert sind. Weitere Details zur Implementierung von Testverfahren finden Sie unter REL07-BP04 Durchführen von Lasttests für den Workload.
-
Die gesamte Workload sollte durch Hinzufügen zusätzlicher Zellen wachsen, sodass die Workload mit der steigenden Nachfrage skalieren kann.
-
-
Multi-AZ- oder multiregionale Strategien: Zum Schutz vor unterschiedlichen Ausfall-Domains sollten mehrere Resilienzebenen genutzt werden.
-
Für die Ausfallsicherheit sollten Sie einen Ansatz wählen, bei dem verschiedene Verteidigungsebenen aufgebaut werden. Eine Ebene schützt vor kleineren, häufiger auftretenden Unterbrechungen, indem eine hochverfügbare Architektur mit mehreren AZs erstellt wird. Eine weitere Verteidigungsebene schützt vor seltenen Ereignissen wie Naturkatastrophen mit großer Reichweite und Unterbrechungen auf Regionsebene. Für diese zweite Ebene muss die Architektur Ihrer Anwendung mehrere AWS-Regionen umfassen. Wenn Sie eine Multi-Region-Strategie für Ihre Workload implementieren, ist sie vor weitreichenden Naturkatastrophen, die einen großen geografischen Bereich in einem Land betreffen, oder technischen Fehlern in einer ganzen Region geschützt. Beachten Sie dabei, dass das Implementieren einer Multi-Region-Architektur äußerst komplex sein kann und bei den meisten Workloads nicht erforderlich ist. Weitere Details erhalten Sie unter REL10-BP02 Auswählen der geeigneten Standorte für Ihre Multi-Standort-Bereitstellung.
-
-
Codebereitstellung: Eine Strategie zur gestaffelten Codebereitstellung sollte der gleichzeitigen Bereitstellung von Codeänderungen in allen Zellen vorgezogen werden.
-
Auf diese Weise werden mögliche Fehler in mehreren Zellen aufgrund einer fehlerhaften Bereitstellung oder menschlichen Versagens minimiert. Weitere Informationen finden Sie unter Automatisierung sicherer, vollautomatischer Bereitstellungen
.
-
Ressourcen
Zugehörige bewährte Methoden:
Zugehörige Dokumente:
Zugehörige Videos:
Zugehörige Beispiele: