Integritätsprüfungen und kontrollierte Degradation

Integritätstests sind der Mechanismus, mit dem Load Balancer und Traffic Manager erkennen, ob eine Backendinstanz Anforderungen verarbeiten kann. Ohne Integritätstests könnte ein Load Balancer weiterhin Datenverkehr an einen ausgefallenen oder nicht reagierenden Server senden, was zu für Benutzer sichtbaren Fehlern führt. Richtig konfigurierte Integritätstests ermöglichen innerhalb von Sekunden nach einem Ausfall eine automatische Umleitung des Datenverkehrs weg von fehlerhaften Instanzen.

Azure Load Balancer unterstützt zwei Arten von Integritätstests:

• TCP-Test – prüft, ob das Backend eine TCP-Verbindung an einem angegebenen Port akzeptieren kann. Dieser Test ist einfach, überprüft jedoch nicht die Anwendungslogik.
• HTTP/HTTPS-Test – sendet eine GET-Anforderung an einen angegebenen Pfad und erwartet eine 200-OK-Antwort. Dieser Test ist genauer, da er den Anwendungsendpunkt direkt überprüft.

Ein Backend wird als fehlerhaft eingestuft, wenn der Test bei einer konfigurierbaren Anzahl aufeinanderfolgender Versuche fehlschlägt.

Ein gut konzipierter Integritätsendpunkt (/health) gibt nicht nur 200 OK zurück, sondern überprüft auch, ob die kritischen Abhängigkeiten der Anwendung erreichbar sind. Eine umfassende Integritätsprüfung kann die Verbindung zur Datenbank, zum Cache und zu nachgelagerten APIs testen. Wenn eine Abhängigkeit nicht verfügbar ist, gibt der Endpunkt einen 5xx-Statuscode zurück und signalisiert dem Load Balancer, diese Instanz aus dem Rotationspool zu entfernen.

Azure Traffic Manager verwendet ebenfalls Integritätstests, allerdings auf regionaler Ebene. Der Dienst sendet regelmäßig HTTP- oder HTTPS-GET-Anforderungen an die konfigurierte Endpunkt-URL in jeder Region. Wenn ein Endpunkt innerhalb des Timeoutzeitraums bei einer festgelegten Anzahl aufeinanderfolgender Intervalle nicht antwortet, markiert Traffic Manager ihn als beeinträchtigt und leitet keine DNS-Abfragen mehr an ihn weiter. Stattdessen werden Benutzer an eine fehlerfreie Region weitergeleitet.

Azure Application Gateway bietet ausgefeiltere Funktionen für Integritätstests als der Standard-Load-Balancer. Es unterstützt benutzerdefinierte Tests, bei denen der Hostheader, der erwartete Statuscodebereich (z. B. 200–399) und eine Zeichenfolge für den Abgleich mit dem Antworttext angegeben werden können. Application Gateway unterstützt außerdem Routing nach Pfad, sodass verschiedene Backendpools für unterschiedliche URL-Pfade jeweils eigene Konfigurationen für Integritätstests verwenden können.

Kontrollierte Funktionseinschränkung bezeichnet die Fähigkeit einer Anwendung, bei Ausfall einer oder mehrerer Abhängigkeiten weiterhin einen Teil ihrer Funktionen bereitzustellen. Statt vollständig abzustürzen, erkennt die Anwendung, dass ein nicht kritischer Dienst nicht verfügbar ist, und wechselt in einen eingeschränkten, aber weiterhin nützlichen Zustand. Wenn beispielsweise ein Empfehlungsdienst ausfällt, kann eine E-Commerce-Website allgemeine Vorschläge anzeigen, anstatt die gesamte Produktseite nicht mehr bereitzustellen.

Das Circuit-Breaker-Pattern verhindert, dass eine Anwendung wiederholt einen fehlerhaften nachgelagerten Dienst aufruft. Sobald ein Dienst ausfällt, wird der Circuit Breaker geöffnet und gibt sofort eine Fehlermeldung oder eine Fallback-Antwort zurück, ohne den Netzwerkaufruf auszuführen. Nach einer Abkühlphase wechselt er in den Zustand halb geöffnet und lässt eine Testanfrage zu. Ist diese erfolgreich, wird der Circuit geschlossen und der normale Betrieb fortgesetzt.

Bei vorübergehenden Fehlern (kurzen Netzwerkstörungen oder einer temporären Überlastung des Dienstes) eignet sich eine Strategie mit Wiederholungsversuchen und exponentiellem Backoff. Die Anwendung wiederholt den fehlgeschlagenen Aufruf nach einer Wartezeit und verdoppelt diese Wartezeit bei jedem weiteren Versuch bis zu einem festgelegten Maximum. Ein Jitter (eine zufällige Abweichung) bei der Wartezeit verhindert, dass alle Wiederholungsversuche gleichzeitig stattfinden und einen sich erholenden Dienst überlasten.

Das Bulkhead-Pattern isoliert verschiedene Teile einer Anwendung in separaten Ressourcenpools. Dadurch kann ein Fehler in einem Bereich nicht alle Ressourcen aufbrauchen und das gesamte System zum Ausfall bringen. Der Name leitet sich von den Schotten eines Schiffs ab, die verhindern, dass ein überflutetes Abteil das gesamte Schiff zum Sinken bringt. In Azure kann dies bedeuten, für verschiedene Dienste separate Threadpools oder separate App Service-Pläne zu verwenden, um Fehler einzugrenzen.

Eine gängige Technik für eine kontrollierte Verschlechterung besteht darin, zwischengespeicherte oder veraltete Daten bereitzustellen, wenn eine Live-Datenquelle nicht verfügbar ist. Eine Produktkatalogseite kann beispielsweise die gestrigen, in Azure Cache for Redis zwischengespeicherten Preise anzeigen, anstatt bei einer vorübergehend nicht erreichbaren Datenbank einen Fehler auszugeben. Die Benutzer erleben dadurch nur eine geringfügige Einschränkung (leicht veraltete Preise) statt eines vollständigen Ausfalls.

Eine kontrollierte Verschlechterung sollte sichtbar gemacht und gemessen werden. Verwenden Sie Application Insights, um die Häufigkeit geöffneter Circuit Breaker, von Fallback-Antworten und von Wiederholungsversuchen als benutzerdefinierte Metriken zu erfassen. Richten Sie Warnungen ein, wenn diese Metriken Schwellenwerte überschreiten. So wird das Bereitschaftsteam darüber informiert, dass die Anwendung in einem eingeschränkten Zustand läuft, auch wenn die für Benutzer sichtbare Funktionalität weiterhin akzeptabel erscheint.

Testen Sie Ihr Verständnis der Konzepte aus Microsoft Azure Fundamentals (AZ-900), die in dieser Lektion behandelt wurden.

In dieser Lektion haben Sie gelernt: Health Probes ermöglichen es Load Balancern, ausgefallene Backends zu erkennen und den Datenverkehr automatisch umzuleiten; kontrollierte Verschlechterung hält Anwendungen teilweise funktionsfähig, wenn Abhängigkeiten ausfallen; und Patterns wie Circuit Breaker, Wiederholungsversuche mit Backoff und Bulkhead setzen Resilienz auf Anwendungsebene um. Als Nächstes beschäftigen wir uns mit Konzepten der Notfallwiederherstellung – mit der Definition von RTO, RPO und Wiederherstellungsstufen.