REL 10: Wie schützen Sie Ihre Workload mithilfe der Fehlerisolierung?

Fehlerisolierte Grenzen beschränken die Auswirkungen eines Ausfalls innerhalb eines Workloads auf eine begrenzte Anzahl von Komponenten. Komponenten außerhalb der Grenze sind vom Ausfall nicht betroffen. Wenn Sie mehrere fehlerisolierte Grenzen verwenden, können Sie die Auswirkungen auf Ihren Workload einschränken.

Ressourcen

AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)
Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)
AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)
AWS re:Invent 2019: Innovation and operation of the AWS global network infrastructure (NET339)
What is AWS Outposts?
Global Tables: Multi-Region Replication with DynamoDB
AWS Local Zones FAQ
AWS Global Infrastructure
The Amazon Builders' Library: Workload isolation using shuffle-sharding

Bewährte Methoden:

• Bereitstellen des Workloads an mehreren Standorten: Verteilen Sie die Workload-Daten und -Ressourcen über mehrere Availability Zones oder ggf. über mehrere AWS-Regionen. Die Standorte können so vielfältig wie nötig sein.

• Automatisierte Wiederherstellung für Komponenten, die auf einen einzelnen Standort beschränkt sind: Wenn Komponenten des Workloads nur in einer einzelnen Availability Zone oder einem On-Premise-Rechenzentrum ausgeführt werden können, müssen Sie die Funktion implementieren, um eine vollständige Neuerstellung des Workloads innerhalb festgelegter Wiederherstellungsziele durchzuführen.

• Verwenden von Bulkhead-Architekturen: Mit einem Bulkhead-Muster wird gewährleistet, dass sich ein Fehler auf eine kleine Teilmenge von Anfragen/Benutzern beschränkt, sodass nur eine geringe Anzahl von Anfragen beeinträchtigt sind und der Großteil fehlerfrei ausgeführt werden kann. Bulkheads für Daten werden in der Regel Partitionen oder Shards genannt, während Bulkheads für Services als Zellen bezeichnet werden.

Verbesserungsplan

Bereitstellen des Workloads an mehreren Standorten

Verwendung mehrerer Availability Zones und AWS-Regionen: Verteilen Sie die Workload-Daten und -Ressourcen über mehrere Availability Zones oder ggf. über mehrere AWS-Regionen. Die Standorte können so vielfältig wie nötig sein.

• Regionale Services werden von Haus aus in Availability Zones bereitgestellt.
  • Dies umfasst Amazon S3, Amazon DynamoDB und AWS Lambda (sofern nicht mit einer VPC verbunden)
• Stellen Sie Ihre Container-, Instance- und funktionsbasierten Workloads in mehreren Availability Zones bereit. Verwenden von Multi-AZ-Datenspeicher, einschließlich Cache: Nutzen Sie EC2 Auto Scaling, die ECS-Aufgabenplatzierung, ElastiCache-Cluster sowie bei Ausführung in Ihrer VPC AWS Lambda-Funktionen.
  • Wenn Sie Auto Scaling-Gruppen bereitstellen, verwenden Sie Subnetze in separaten Availability Zones.
    Example: Distributing instances across Availability Zones
    Amazon ECS task placement strategies
    Configuring an AWS Lambda function to access resources in an Amazon VPC
    Choosing Regions and Availability Zones
  • Verwenden Sie beim Bereitstellen von Auto Scaling-Gruppen Subnetze in separaten Availability Zones.
    Example: Distributing instances across Availability Zones
  • Legen Sie mithilfe von ECS-Aufgabenplatzierungsparametern DB-Subnetzgruppen fest.
    Amazon ECS task placement strategies
  • Nutzen Sie Subnetze in mehreren Availability Zones, wenn Sie eine in Ihrem VPC auszuführende Funktion konfigurieren.
    Configuring an AWS Lambda function to access resources in an Amazon VPC
  • Verwenden Sie mehrere Availability Zones mit ElastiCache-Clustern.
    Choosing Regions and Availability Zones

Wenn Ihr Workload für mehrere Regionen bereitgestellt werden muss, wählen Sie eine Strategie für mehrere Regionen aus.: Die meisten Zuverlässigkeitsanforderungen können innerhalb einer einzelnen AWS-Region mithilfe einer Multi Availability Zone-Strategie erfüllt werden. Verwenden Sie bei Bedarf eine Strategie für mehrere Regionen, um Ihre Geschäftsanforderungen zu erfüllen.
AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)

• Eine Sicherung in einer anderen AWS-Region kann eine weitere Ebene der Gewissheit bieten, dass Daten bei Bedarf verfügbar sind.
• Einige Workloads haben gesetzliche Anforderungen, die eine Multi-Region-Strategie erfordern

Auswerten von AWS Outposts für Ihre Workload: Wenn Ihre Workload eine niedrige Latenz für Ihr Rechenzentrum vor Ort erfordert oder lokale Datenverarbeitungsanforderungen hat. Führen Sie in diesem Fall die AWS-Infrastruktur und -Services lokal mit AWS Outposts aus.
What is AWS Outposts?

Bestimmen Sie, ob AWS Local Zones Ihnen beim Bereitstellen von Services für Ihre Benutzer hilft: o Wenn Sie Anforderungen mit geringer Latenz haben, prüfen Sie, ob sich AWS Local Zones in der Nähe Ihrer Benutzer befindet. Wenn ja, verwenden Sie es, um Workloads näher an diesen Benutzern bereitzustellen
AWS Local Zones FAQ

Automatisierte Wiederherstellung für Komponenten, die auf einen einzelnen Standort beschränkt sind

Implementieren der Selbstreparatur: Stellen Sie Ihre Instances oder Container nach Möglichkeit mit automatischer Skalierung bereit. Wenn dies nicht möglich ist, nutzen Sie für EC2-Instances die automatische Wiederherstellung oder implementieren Sie eine automatische Selbstreparatur basierend auf Amazon EC2- oder ECS-Container-Lebenszyklusereignissen.

• Verwenden Sie für Instances und Container-Workloads Auto Scaling-Gruppen, die weder eine IP-Adresse für eine einzelne Instance noch eine private oder elastische IP-Adresse oder Instance-Metadaten benötigen.
  What Is EC2 Auto Scaling?
  Service automatic scaling
  • Sie können die Benutzerdaten der Startkonfiguration nutzen, um die Selbstreparatur der meisten Workloads zu automatisieren.
• Nutzen Sie die automatische Wiederherstellung von EC2-Instances für Workloads, die eine IP-Adresse für eine einzelne Instance, eine private oder elastische IP-Adresse und Instance-Metadaten erfordern.
  Recover your instance.
  • Automatic Recovery sendet Benachrichtigungen zum Wiederherstellungsstatus an ein SNS-Thema, wenn der Instance-Fehler erkannt wird.
• Wenn eine automatische Skalierung oder EC2-Wiederherstellung nicht möglich ist, können Sie die Selbstreparatur mithilfe von EC2-Instance-Lebenszyklusereignissen oder ECS-Ereignissen automatisieren.
  EC2 Auto Scaling lifecycle hooks
  Amazon ECS events
  • Nutzen Sie die Ereignisse, um die automatische Reparatur der Komponente entsprechend der erforderlichen Prozesslogik zu starten.

Nutzen Sie die automatische Wiederherstellung von EC2-Instances für Workloads, die eine IP-Adresse für eine einzelne Instance, eine private oder elastische IP-Adresse und Instance-Metadaten erfordern.
Recover your instance.

• Automatic Recovery sendet Benachrichtigungen zum Wiederherstellungsstatus an ein SNS-Thema, wenn der Instance-Fehler erkannt wird.

Wenn eine automatische Skalierung oder EC2-Wiederherstellung nicht möglich ist, können Sie die Selbstreparatur mithilfe von EC2-Instance-Lebenszyklusereignissen oder ECS-Ereignissen automatisieren.
EC2 Auto Scaling lifecycle hooks
Amazon ECS events

• Nutzen Sie die Ereignisse, um die automatische Reparatur der Komponente entsprechend der erforderlichen Prozesslogik zu starten.

Verwenden von Bulkhead-Architekturen

Verwenden von Bulkhead-Architekturen: Mit einem Bulkhead-Muster wird gewährleistet, dass sich ein Fehler auf eine kleine Teilmenge von Anfragen/Benutzern beschränkt, sodass nur eine geringe Anzahl von Anfragen beeinträchtigt sind und der Großteil fehlerfrei ausgeführt werden kann. Bulkheads für Daten werden in der Regel Partitionen oder Shards genannt, während Bulkheads für Services als Zellen bezeichnet werden.
Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)
AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)

Auswerten der zellenbasierten Architektur für Ihre Workload: In einer zellenbasierten Architektur ist jede Zelle eine vollständige, unabhängige Instance des Service und hat eine feste maximale Größe. Mit zunehmender Last wachsen die Workloads, indem weitere Zellen hinzugefügt werden. Bei eingehendem Datenverkehr wird mit einem Partitionsschlüssel ermittelt, welche Zelle die Anfrage verarbeitet. Jeder Fehler beschränkt sich auf die Zelle, in der er auftritt, sodass die Anzahl der beeinträchtigten Anfragen begrenzt ist, da andere Zellen weiterhin fehlerfrei funktionieren. Es ist wichtig, den richtigen Partitionsschlüssel zu identifizieren, um zellenübergreifende Interaktionen zu minimieren und zu verhindern, dass bei jeder Anfrage komplexe Zuordnungsservices berücksichtigt werden müssen. Services, die komplexe Zuordnungen erfordern, führen nur zu einer Verlagerung des Problems auf die Zuordnungsservices, während Services, für die zellenübergreifende Interaktionen erforderlich sind, die Abhängigkeit von Zellen (und damit die angenommenen Verfügbarkeitsverbesserungen) reduzieren.

• Colm MacCarthaigh erläutert in seinem AWS-Blogbeitrag, wie Amazon Route 53 das Konzept des Shuffle Sharding nutzt, um Kundenanfragen in Shards zu isolieren.
  Shuffle Sharding: Massive and Magical Fault Isolation