Hohe Verfügbarkeit im Vergleich zu Fehlertoleranz: Definitionen und Abwägungen

Hochverfügbarkeit (HA) und Fehlertoleranz (FT) sind zwei unterschiedliche Ziele der Zuverlässigkeit, die Architekten häufig verwechseln. Hochverfügbarkeit bedeutet, dass ein System nur minimale Ausfallzeiten aufweist — es kann Fehler tolerieren, während der Wiederherstellung jedoch kurzzeitig unterbrochen sein. Fehlertoleranz bedeutet, dass ein System auch beim Ausfall von Komponenten ohne Unterbrechung weiterarbeitet, weil vollständig redundante Pfade vorhanden sind, die sofort übernehmen.

Die Verfügbarkeit wird als Prozentsatz der Betriebszeit innerhalb eines Jahres gemessen. 99,9 % Verfügbarkeit (drei Neunen) bedeuten ungefähr 8,7 Stunden Ausfallzeit pro Jahr, während 99,99 % (vier Neunen) nur 52,6 Minuten zulassen. 99,999 % (fünf Neunen) erlauben lediglich 5,26 Minuten. Jede weitere Neun erfordert typischerweise mehr Redundanz, Automatisierung und Kosten. In der SAA-C03-Prüfung wird häufig gefragt, welche Architektur ein bestimmtes Verfügbarkeitsziel erfüllt.

Eine hochverfügbare Architektur toleriert den Ausfall einer Komponente, indem sie den Ausfall automatisch erkennt und innerhalb von Sekunden oder Minuten auf einen fehlerfreien Ersatz umschaltet. Beispiele sind RDS Multi-AZ (automatisches Failover auf eine Standby-Instanz in einer anderen AZ), Auto Scaling Groups, die beendete Instanzen ersetzen, und Elastic Load Balancers, die den Datenverkehr von fehlerhaften Zielen weg leiten. Es kommt zu einer kurzen Unterbrechung, aber das System erholt sich ohne manuellen Eingriff.

Eine fehlertolerante Architektur verfügt über aktive Redundanz — mehrere identische Komponenten bedienen gleichzeitig Anfragen, sodass die übrigen Komponenten beim Ausfall einer Komponente die Last sofort und ohne Ausfallzeit übernehmen. Beispiele sind Active-Active-ELB mit mehreren EC2-Instanzen, DynamoDB Global Tables, die gleichzeitig Lese- und Schreibvorgänge in mehreren Regionen bedienen, sowie Aurora mit mehreren Read Replicas. Fehlertoleranz erfordert, dass jederzeit mehr Ressourcen ausgeführt werden.

Fehlertoleranz ist deutlich teurer als Hochverfügbarkeit, da jederzeit vollständig bereitgestellte redundante Kapazität erforderlich ist. Eine hochverfügbare RDS-Multi-AZ-Instanz verdoppelt Ihre Datenbankkosten für eine Standby-Instanz, die nur bei einem Ausfall aktiviert wird. Eine fehlertolerante aktive-aktive Aurora-Bereitstellung über mehrere Regionen kann viermal so viel kosten, beseitigt dafür aber bei regionalen Ausfällen jegliche Ausfallzeit. Architekten müssen die Kosten der Redundanz gegen die geschäftlichen Kosten von Ausfallzeiten abwägen.

Das Recovery Time Objective (RTO) ist die maximal akzeptable Zeit, während der ein System nicht verfügbar sein darf. Hochverfügbare Architekturen zielen durch automatisches Failover auf ein niedriges RTO — typischerweise im Minutenbereich. Fehlertolerante Architekturen zielen auf ein RTO von nahezu null. Beim Entwurf für HA müssen Sie Services und Konfigurationen auswählen, die eine Wiederherstellung innerhalb Ihres RTO-Budgets garantieren. RDS Multi-AZ bietet beispielsweise ein RTO von ungefähr 60–120 Sekunden und eignet sich damit für viele HA-Anforderungen.

Ein Single Point of Failure (SPOF) ist jede Komponente, deren Ausfall den Ausfall des gesamten Systems verursacht. Häufige SPOFs sind eine einzelne EC2-Instanz ohne ASG, eine RDS-Datenbank in nur einer AZ, ein einzelnes NAT-Gateway oder eine einzelne Availability Zone. Das Beseitigen von SPOFs ist der erste Schritt auf dem Weg zu HA und FT. In der SAA-C03-Prüfung wird häufig getestet, ob Sie SPOFs in vorgegebenen Architekturdiagrammen erkennen und beseitigen können.

HA oder FT zu erreichen ist bei zustandslosen Services (wie Webservern oder Lambda-Funktionen) deutlich einfacher, da jede Instanz jede Anfrage verarbeiten kann. Zustandsbehaftete Services (Datenbanken, Caches, Dateisysteme) sind schwieriger — Sie müssen den Zustand über Replikate hinweg synchronisieren, Replikationsverzögerungen handhaben und während des Failovers die Konsistenz sicherstellen. AWS-Services wie EFS (gemeinsam genutztes Dateisystem), ElastiCache mit Replikationsgruppen und Aurora (gemeinsam genutzter Speicher) wurden entwickelt, um hochverfügbare zustandsbehaftete Systeme einfacher umzusetzen.

Zu den gängigen HA-Mustern auf AWS gehören: 1) Multi-AZ-Load-Balancing — EC2-Instanzen werden über mehrere AZs verteilt und hinter einem ALB betrieben. 2) Read Replicas — Leseverkehr wird ausgelagert; im Rahmen der Disaster Recovery erfolgt eine Hochstufung. 3) S3 für zustandslose Ressourcen — S3 ist mit einer Haltbarkeit von 11 Neunen grundsätzlich hochverfügbar. 4) Global Accelerator — statische Anycast-IP-Adressen leiten den Datenverkehr über Regionen hinweg an fehlerfreie Endpunkte. Jedes Muster stellt Kosten und ein bestimmtes Verfügbarkeitsniveau gegenüber.

Fehlertolerante Muster erfordern überall aktive Redundanz. Wichtige FT-Muster sind: DynamoDB ist grundsätzlich fehlertolerant — die Daten werden über drei AZs repliziert, ohne dass ein Failover erforderlich ist. S3 verfügt über integrierte Fehlertoleranz. Aurora Multi-Master (jetzt Aurora Serverless v2 Multi-Writer) ermöglicht gleichzeitige Schreibvorgänge in mehreren AZs. Kinesis speichert Daten standardmäßig über mehrere AZs hinweg. Die Auswahl verwalteter Services mit integrierter Fehlertoleranz ist der kosteneffizienteste Weg zu Architekturen ohne Ausfallzeit.

Der Entwurf für HA oder FT ist nur so gut wie Ihre Tests. AWS empfiehlt, den AWS Fault Injection Simulator (FIS) für kontrollierte Experimente zu verwenden, bei denen Instanzen beendet, APIs gedrosselt oder Netzwerkausfälle simuliert werden. Sie sollten überprüfen, ob das Failover tatsächlich innerhalb Ihres RTO abgeschlossen wird, ob über Ihr RPO hinaus keine Daten verloren gehen und ob Alarme korrekt ausgelöst werden. Regelmäßige Game Days und Übungen zum Chaos Engineering decken Lücken in Ihren Annahmen zur Resilienz auf, bevor dies durch Produktionsvorfälle geschieht.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Hochverfügbarkeit minimiert Ausfallzeiten durch automatische Wiederherstellung (RTO im Minutenbereich), Fehlertoleranz beseitigt Ausfallzeiten durch aktive Redundanz (RTO gleich null) und die Kosten steigen mit jeder Stufe der Resilienz deutlich. Das Beseitigen von Single Points of Failure bildet die Grundlage beider Ansätze. Als Nächstes untersuchen wir Multi-AZ-Muster für zustandsbehaftete Services.