In der heutigen Cloud-Welt sind Verfügbarkeit und Skalierbarkeit entscheidend für den Erfolg von Anwendungen. Bei der Gestaltung von Cloud-Infrastrukturen auf AWS müssen Unternehmen sorgfältig abwägen, wie sie ihre Architektur planen, um sowohl Verfügbarkeit als auch Redundanz zu gewährleisten. Eine zentrale Entscheidung dabei ist, ob man sich für eine Architektur innerhalb einer einzelnen Availability Zone (Single-AZ) oder für eine Multi-AZ-Architektur entscheiden sollte.

Ein Single-AZ-Ansatz stellt eine einfache Lösung dar, bei der alle Komponenten einer Anwendung in einer einzigen Availability Zone (AZ) innerhalb einer Region platziert werden. Diese Architektur ist in vielen Fällen ausreichend, insbesondere für kleinere Anwendungen oder Szenarien, in denen eine einfache Fehlerbehandlung und schnelle Bereitstellung von Ressourcen erforderlich sind. Zu den üblichen Komponenten, die in einer Single-AZ-Architektur verwendet werden, gehören beispielsweise Amazon Elastic File System (EFS) und Amazon FSx, die als Dateispeicher dienen und eine hohe Verfügbarkeit durch automatische Datei-Replikation bieten.

Für Datenbanken, etwa Amazon RDS oder Amazon Aurora, sind automatische Backups, Punkt-in-der-Zeit-Wiederherstellung und hohe Verfügbarkeit Standardfunktionen. Amazon RDS stellt zudem eine verwaltete Datenbanklösung dar, die in einer einzigen AZ betrieben werden kann. Aurora, kompatibel mit MySQL und PostgreSQL, bietet zusätzliche Funktionen wie Multi-Master-Replikation und crash-sichere Backups. Im Fall von RDS und Aurora können Replikate als Read-Only-Datenbanken fungieren und im Falle eines Ausfalls der primären Datenbank befördert werden, sodass die Anwendung nahtlos weiterläuft.

Trotz dieser Vorteile hat die Single-AZ-Architektur jedoch eine grundlegende Einschränkung: Sie ist anfällig für Ausfälle auf der Ebene der Availability Zone. Diese Ausfälle können durch geplante Wartungsarbeiten, unvorhergesehene Ausfälle oder sogar Naturkatastrophen verursacht werden, was zu einer vollständigen Unverfügbarkeit der Anwendung führt. Daher wird oft empfohlen, eine Multi-AZ-Architektur zu implementieren, um die Ausfallsicherheit und Verfügbarkeit zu erhöhen.

Eine Multi-AZ-Architektur verteilt die Infrastruktur auf mehrere Availability Zones innerhalb einer Region, um sicherzustellen, dass eine Anwendung auch dann verfügbar bleibt, wenn eine der AZs ausfällt. Diese Architektur verbessert nicht nur die Verfügbarkeit, sondern auch die Resilienz der gesamten Infrastruktur. In einer typischen Multi-AZ-Architektur werden Web- und Anwendungsserver über verschiedene AZs verteilt, sodass immer mindestens ein Server verfügbar ist, auch wenn eine AZ betroffen ist. Für den Datenspeicher werden Lösungen wie EFS oder Amazon FSx verwendet, die Daten zwischen verschiedenen AZs replizieren, sodass auf die Daten jederzeit zugegriffen werden kann, unabhängig davon, welche AZ betroffen ist.

Für Datenbanken empfiehlt es sich, Multi-AZ-Optionen wie bei Amazon RDS oder Amazon Aurora zu nutzen. Diese stellen sicher, dass bei einem Ausfall der primären Instanz automatisch eine Replikatinstanz als primäre Instanz übernommen wird. Bei Aurora kann zudem eine Read-Replica eingerichtet werden, die im Falle eines Ausfalls der primären Instanz ebenfalls automatisch die Rolle des Schreib-Datenbankservers übernimmt. In Amazon RDS müssen Administratoren zwar das Failover manuell durchführen, doch auch hier bleibt die Datenbank im Falle eines Ausfalls durch die Replikation verfügbar.

Die Vorteile von Multi-AZ liegen auf der Hand: Sie bieten eine deutlich höhere Ausfallsicherheit und gewährleisten, dass Anwendungen auch dann verfügbar bleiben, wenn es zu Problemen in einer der AZs kommt. Doch es gibt auch Einschränkungen. Zwar ist die Verfügbarkeit auf der Ebene der Availability Zones gegeben, jedoch kann es in seltenen Fällen zu einem Ausfall in einer ganzen Region kommen, etwa bei einem großflächigen Netzwerkausfall oder einer Naturkatastrophe. In solchen Fällen ist eine Multi-Region-Architektur erforderlich, bei der Anwendungen und Daten in mehreren Regionen weltweit verteilt werden, um die Verfügbarkeit und Resilienz zu maximieren.

Ein weiteres, oft übersehenes Detail bei der Planung von Multi-AZ-Architekturen ist die Netzwerkstruktur. Um sicherzustellen, dass der Datenverkehr innerhalb einer Region optimiert wird, sollte der Virtual Private Cloud (VPC) in mehrere Subnetze in verschiedenen AZs unterteilt werden. Verbindungen innerhalb desselben Subnetzes sind bevorzugt, da sie niedrige Latenzen und keine zusätzlichen Netzwerkkosten verursachen. Dies trägt zur Effizienz der gesamten Infrastruktur bei.

In der Praxis bedeutet dies, dass Unternehmen in eine gut durchdachte Architektur investieren müssen, die nicht nur die Komponenten wie Web-Server, App-Server und Datenbanken umfasst, sondern auch alle Aspekte der Kommunikation und Datenverfügbarkeit über mehrere AZs hinweg. Dies ist besonders wichtig für unternehmenskritische Anwendungen, bei denen jede Minute Ausfallzeit direkte finanzielle oder betriebliche Auswirkungen haben kann.

Die Wahl der richtigen Architektur hängt letztlich von den spezifischen Anforderungen und der Komplexität der Anwendung ab. Für einfache Anwendungen kann eine Single-AZ-Architektur ausreichend sein, aber sobald Skalierbarkeit, hohe Verfügbarkeit und Redundanz entscheidend werden, ist eine Multi-AZ-Architektur der bevorzugte Weg. In besonders komplexen Szenarien oder bei globalen Anwendungen kann sogar eine Multi-Region-Architektur erforderlich sein, um maximale Ausfallsicherheit und Performance zu gewährleisten.

Wie man Chaos-Engineering-Fehler in AWS-Infrastrukturen simuliert: Einblicke in die Implementierung und die Validierung von Hypothesen

Im Bereich des Chaos Engineering ist es entscheidend, systematisch Fehler in die Infrastruktur einzuführen, um die Belastbarkeit und das Verhalten eines Systems unter unerwarteten Bedingungen zu testen. Die Fähigkeit, diese Fehler gezielt zu simulieren, ermöglicht es, Schwachstellen zu identifizieren und die Resilienz des Systems zu optimieren. Ein gutes Beispiel für eine solche Implementierung ist die Verwendung von AWS Fault Injection Simulator (FIS), mit dem Unternehmen ihre Cloud-Infrastrukturen auf Schwächen und Fehleranfälligkeit testen können. Im Folgenden wird erklärt, wie man gezielt AWS-Ressourcen durch verschiedene Fehlerszenarien ansprechen und simulieren kann, und warum es für Chaos Engineers wichtig ist, die Hypothesen zu validieren, die zu Beginn eines Experiments aufgestellt wurden.

Ein grundlegendes Beispiel für die Simulation von Fehlern in AWS ist das Stoppen einer EC2-Instanz. In einem Experiment kann dies wie folgt konzipiert werden:

json
{
  "description": "EC2 Instance Failure Injection",
  "stopConditions": [


    { "source": "None" }


  ],
  "targets": {
    "aws:ec2:instance": {
      "resourceIds": [ "i-0123456789abcdef" ]
    }
  },
  "actions": {
    "aws:ec2:stop-instances": {


      "instanceIds": [ "i-0123456789abcdef" ],


      "startAfter": 0
    }
  },
  "roleName": "FIS-Role"
}

In diesem Beispiel wird die EC2-Instanz mit der ID i-0123456789abcdef gestoppt, sobald das Experiment startet. Dies simuliert einen Ausfall der Instanz. Die FIS-Rolle (FIS-Role) sorgt dafür, dass das Experiment mit den richtigen Berechtigungen ausgeführt wird.

Neben der EC2-Instanz können auch andere AWS-Ressourcen betroffen sein, etwa EBS-Volumes, Datenbanken oder Netzwerkverbindungen. Beispiele für solche Experimente umfassen die Fehlerbehebung bei einem EBS-Volume-Ausfall oder Netzwerkverzögerungen:

json
{
  "description": "EBS Volume Failure Injection",
  "stopConditions": [ { "source": "None" } ],
  "targets": {
    "aws:ebs:volume": { 


      "resourceNames": [ "YOUR_EBS_VOLUME_ID" ] 


    }
  },
  "actions": {
    "aws:ebs:volume-failure": {
      "failureMode": "VolumeUnavailable",
      "duration": 900
    }
  },
  "roleName": "FIS-Role"
}

Ähnlich kann auch die Simulation von Netzwerkverzögerungen oder Paketverlusten im Rahmen von Chaos-Engineering-Tests durchgeführt werden. Diese Experimente helfen, die Robustheit des Systems gegenüber realen Netzwerkproblemen zu überprüfen. Ein Beispiel für Netzwerkverzögerung und Paketverlust:

json
{


  "description": "Network Latency and Packet Loss Injection",
  "stopConditions": [ { "source": "None" } ],
  "targets": {
    "awscloud:ec2:resource-pool": {
      "resourceArns": [ "YOUR_RESOURCE_ARN_1", "YOUR_RESOURCE_ARN_2" ]
    }
  },
  "actions": {
    "awscloud:ec2:network-latency": {
      "latencyDuration": 1000,
      "resourceNames": [ "YOUR_RESOURCE_NAME_1", "YOUR_RESOURCE_NAME_2" ]
    },
    "awscloud:ec2:packet-loss": {
      "packetLossPercentage": 10,
      "resourceNames": [ "YOUR_RESOURCE_NAME_1", "YOUR_RESOURCE_NAME_2" ]
    }
  },
  "roleName": "FIS-Role"
}

Ein weiteres Beispiel umfasst das Einführen von Fehlern bei der API-Gateway-Verfügbarkeit. Diese Art von Tests simuliert, wie das System auf Ausfälle von APIs reagiert, was insbesondere für Services, die stark von HTTP-Anfragen abhängen, von großer Bedeutung ist:

json
{
  "description": "API Gateway Failure Injection",
  "stopConditions": [ { "source": "None" } ],
  "targets": {
    "aws:apigateway:api": {


      "resourceNames": [ "YOUR_API_GATEWAY_API_ID" ]


    }
  },
  "actions": {
    "aws:apigateway:failure": {
      "failureMode": "HttpStatusCodeFailure",
      "httpStatusCode": 500,
      "failurePercentage": 25,
      "duration": 600
    }
  },
  "roleName": "FIS-Role"
}

Mit den vorgestellten Beispielen ist es möglich, gezielt Fehler in der AWS-Infrastruktur zu simulieren und verschiedene Arten von Fehlern zu testen, wie etwa die Ausfallzeiten von Instanzen, Datenbankverbindungen oder sogar ganze Availability Zones. Dies ist ein wichtiger Bestandteil von Chaos Engineering, da es die Möglichkeit bietet, eine Vielzahl von fehlerhaften Szenarien durchzuspielen, um die Systemresilienz unter verschiedenen Bedingungen zu überprüfen.

Ein wichtiger Aspekt dieser Experimente ist jedoch die Validierung der Hypothesen. Chaos Engineers stellen zu Beginn des Tests Hypothesen auf, die sich darauf beziehen, wie das System auf bestimmte Fehler reagieren sollte. Die Hypothese könnte etwa lauten: „Die Datenbank wird innerhalb von 30 Sekunden nach einem Ausfall wieder verfügbar sein.“ Während des Experiments wird das Systemverhalten genau überwacht, und relevante Metriken werden erfasst, um zu überprüfen, ob das beobachtete Verhalten mit der Hypothese übereinstimmt. Wenn das Ergebnis den Erwartungen entspricht, ist die Hypothese validiert, und das System hat sich als widerstandsfähig gegen den simulierten Fehler erwiesen.

Es gibt jedoch auch Fälle, in denen das beobachtete Verhalten nicht mit der Hypothese übereinstimmt, was auf potenzielle Schwächen im System hinweist. Zum Beispiel könnte ein API-Gateway länger als erwartet ausfallen, was darauf hinweist, dass der Wiederherstellungsmechanismus verbessert werden muss. Solche Erkenntnisse sind entscheidend, um kontinuierlich die Resilienz der Infrastruktur zu steigern.

Zusätzlich zu den vorgestellten Beispielen können Chaos Engineers noch viele andere Fehlerquellen in ihre Tests einbeziehen. Mögliche Szenarien umfassen das Stoppen von Instanzen in spezifischen Subnetzen, das Simulieren von Datenbankverlangsamungen, Ausfällen von Load Balancern oder sogar das Testen von Fehlern auf regionaler Ebene. Diese Tests helfen dabei, das Verhalten des Systems unter extremen Bedingungen zu verstehen und entsprechend zu optimieren.

Die Validierung der Hypothese und die ständige Verbesserung des Systems sind die Kernziele des Chaos Engineerings. Es geht nicht nur darum, Fehler zu simulieren, sondern auch darum, systematisch Schwachstellen zu identifizieren und diese zu beheben, bevor echte Ausfälle das System gefährden.

Wie sich die Neutralität und Unabhängigkeit der GAO in einer parteipolitisch gespaltenen Welt behauptet
Wie die Reise des Unternehmers und die Reise des Helden sich überschneiden: Herausforderungen, Transformation und der Umgang mit Misserfolgen
Was sollte man im ersten Trimester der Schwangerschaft bei der Bewegung beachten?