Entwerfen von Chaosexperimenten
Ihre unternehmenskritische Anwendung muss resilient sein und bereit sein, auf Fehler zu reagieren. Es ist jedoch schwierig, potenzielle Fehlerszenarien in der Cloud vorherzusagen. Mit Chaos Engineering können Sie Fehlerexperimente in einer kontrollierten Umgebung durchführen, um Probleme zu identifizieren, die während der Entwicklung und Bereitstellung wahrscheinlich auftreten. Sie fügen bewusst reale Fehler ein und beobachten, wie das System reagiert.
In dieser Lerneinheit verwenden wir Azure Chaos Studio. Der Dienst hilft Ihnen dabei, die Resilienz Ihrer Cloudanwendung und Ihres Diensts zu messen, zu verstehen und zu verbessern. Es bereit Sie darauf vor, schnell zu reagieren, wenn ein Fehler unter widrigen Bedingungen in der Produktion auftritt.
Ausführen einer Fehlermodusanalyse
Beim Entwerfen eines Chaosexperiments besteht der erste Schritt darin, eine Fehlermodusanalyse (FMA) der Anwendungskomponenten durchzuführen, um potenzielle Fehlerszenarien zu identifizieren:
Listen Sie alle für einen Benutzerflow relevanten Komponenten auf, die verfügbar und funktionsfähig sein müssen. Der Check-Out-Benutzerflow verwendet beispielsweise Azure App Services, Azure Functions und die Azure Cosmos DB-Datenbank.
Listen Sie für jede Komponente mögliche Fehlerfälle, deren Auswirkungen und eine mögliche Risikominderung auf.
Sehen wir uns das Ergebnis der FMA für die Komponenten des Benutzerflows des Contoso Shoes-Checkout-Beispiels an.
Azure App Service zum Hosten der Front-End-Anwendung
| Risiko | Auswirkung | Mögliche Entschärfung |
|---|---|---|
| Ausfall der Verfügbarkeitszone | Instanzen, bei denen diese Zone möglicherweise nicht mehr verfügbar ist. Ein vollständiger Ausfall wird nicht erwartet, da die Zonenredundanz für den App Service-Plan aktiviert ist. |
Ermöglichen Sie, die Übernahme der zusätzlichen Last durch die verbleibenden Instanzen, und lassen Sie genügend Spielraum für dieses Szenario, während die Leistungsziele dennoch erreicht werden. |
| SNAT-Portauslastung | Es können keine ausgehenden Verbindungen erstellt werden. Daher schlagen nachgeschaltete Aufrufe, wie z. B. Aufrufe an die Datenbank, fehl. | Verwenden Sie private Endpunkte, um eine Verbindung mit den nachgeschalteten Komponenten herzustellen. |
| Einzelne Instanz wird fehlerhaft | Benutzerdatenverkehr, der an eine fehlerhafte Instanz weitergeleitet wird, kann zu einer schlechten Leistung oder sogar zu einem vollständigen Ausfall führen. | Verwenden Sie das Feature „App Service-Integritätsprüfung“. Dieses Feature bewirkt, dass fehlerhafte Instanzen automatisch identifiziert und durch neue, fehlerfreie Instanzen ersetzt werden. |
Azure Functions für Check-Out-Logik
| Risiko | Auswirkung | Mögliche Entschärfung |
|---|---|---|
| Leistung bei langsamem (Kalt-)Start | Da der Azure Functions-Verbrauchsplan verwendet wird, kann die Leistung neuer Instanzen nicht garantiert werden. Eine hohe Nachfrage an den Dienst (von „lauten Nachbarn“) kann dazu führen, dass die Check-Out-Funktion eine lange Startdauer aufweist, die sich auf die Leistungsziele auswirkt. |
Führen Sie ein Upgrade auf den Azure Functions Premium-Plan aus. |
| Zugrunde liegender Speicherausfall | Wenn das zugrunde liegende Speicherkonto nicht mehr verfügbar ist, funktioniert die Funktion nicht mehr. | Verwenden Sie Compute mit Lastenausgleich mit regionalem Speicher oder Compute mit Lastenausgleich mit freigegebenem GRS-Speicher. |
Azure Cosmos DB-Datenbank
| Risiko | Auswirkung | Mögliche Entschärfung |
|---|---|---|
| Umbenennen einer Datenbank oder Sammlung | Aufgrund einer nicht übereinstimmenden Konfiguration könnte es zu Datenverlusten kommen. Die Anwendung kann erst auf Daten zugreifen, wenn die Konfiguration aktualisiert wird und ihre Komponenten neu gestartet werden. | Verhindern Sie diese Situation mithilfe von Sperren auf Datenbank- und Sammlungsebene. |
| Schreiben eines Ausfalls von Regionen | Wenn es bei der primären Region (oder der Schreibregion) zu einem Ausfall kommt, macht das Azure Cosmos DB-Konto automatisch eine sekundäre Region zur neuen primären Schreibregion, wenn das automatische (dienstseitig verwaltete) Failover für das Azure Cosmos DB-Konto konfiguriert ist. Das Failover erfolgt in einer anderen Region in der von Ihnen angegebenen Reihenfolge der Regionspriorität. | Konfigurieren Sie das Datenbankkonto, um mehrere Regionen und automatischem Failover zu nutzen. Wenn ein Fehler auftritt, führt der Dienst automatisch ein Failover durch und verhindert etwaige dauerhafte Probleme in der Anwendung. |
| Umfassende Drosselung aufgrund fehlender Anforderungseinheiten (Request Units, RUs) | Bestimmte Skalierungseinheiten können bei der Azure Cosmos DB-Nutzung heißlaufen, während andere weiterhin Anforderungen verarbeiten können. | Verteilen Sie die Last besser auf mehrere Skalierungseinheiten oder fügen Sie weitere RUs hinzu. |
Entwerfen eines Chaosexperiments
Um ein Chaosexperiment zu entwerfen, wählen Sie einige Fehlerfälle aus. Die Wahl kann auf der Wahrscheinlichkeit, dass der Fehler auftritt, oder auf möglichen Auswirkungen basieren.
Das Ziel des Experiments besteht darin, die Resilienzmaßnahmen zu überprüfen, die Sie in Ihrer Anwendung implementiert haben. Nehmen wir einmal hypothetisch an, Sie führen Ihre Anwendung auf App Service mit aktivierter Zonenredundanz aus. Wenn alle zugrunde liegenden Instanzen in einer Zone ausfallen, erwarten Sie, dass Ihre Anwendung weiterhin ausgeführt wird.
Verwenden Sie Chaos Studio, um die Fehler in die relevanten Komponenten einzuschleusen. Chaos Studio bietet eine Bibliothek mit Fehlern, aus der Sie auswählen können. Da die Fehlerbibliothek jedoch nicht alles abdeckt, müssen Sie Ihr Szenario möglicherweise anpassen. Oder Sie müssen weitere Tools finden, die Ihnen beim Einschleusen des Fehlers helfen.
Wichtig
Richten Sie Ihre Experimente nur auf eine nicht für die Produktion bestimmte Umgebung aus. Das Einschleusen von Fehlern in Ihre Produktionsumgebung kann riskant sein und erfordert Erfahrung und Planung.
Beispiel: Ausfall von Azure Cosmos DB und Failover
Angenommen, Sie wählen das in der Tabelle aufgeführte Azure Cosmos DB-Fehlerszenario „Schreibregion-Ausfall“ aus. Die Hypothese lautet: Ein dienstinitiiertes Failover sollte keine nachhaltigen Auswirkungen auf die Anwendung haben. Wenn sich diese Hypothese als wahr erweist, haben Sie überprüft, dass Ihr Maß an Resilienz für die Replikation in mehrere Regionen den gewünschten positiven Effekt auf die Anwendungszuverlässigkeit hat.
Verwenden Sie zum Simulieren dieses Fehlers den Azure Cosmos DB-Fehler aus der Chaos Studio-Fehlerbibliothek.
Dieses Beispiel bezieht sich auf ein Azure Cosmos DB-Failover, das 10 Minuten lang (PT10M) ausgeführt wird und West US 2 als neue Schreibregion verwendet. Es wird davon ausgegangen, dass West US 2 bereits als eine der Lesereplikationsregionen eingerichtet wurde.
{
"name": "branchOne",
"actions": [
{
"type": "continuous",
"name": "urn:csci:microsoft:cosmosDB:failover/1.0",
"parameters": [
{
"key": "readRegion",
"value": "West US 2"
}
],
"duration": "PT10M",
"selectorid": "myCosmosDbResource"
}
]
}
Nach Abschluss des Experiments ändert Chaos Studio den Schreibbereich wieder in seinen ursprünglichen Wert.
Bevor Sie einen Fehler für eine Azure-Ressource einschleusen können, müssen Sie die entsprechenden Ziele und Funktionen für diese Ressource aktivieren. Durch diese Einstellung wird gesteuert, welche Fehler bei den Ressourcen ausgeführt werden können, die für die Fehlereinschleusung aktiviert sind. Wenn Sie Ziele und Funktionen zusammen mit anderen Sicherheitsmaßnahmen verwenden, können Sie versehentliche oder böswillige Fehlereinschleusungen vermeiden.
Nachdem Sie nun sowohl Auslastungstests als auch Chaosexperimente entworfen haben, müssen Sie diese in Ihren Pipelines automatisieren, damit sie konsistent und regelmäßig ausgeführt werden. In der nächsten Lerneinheit erfahren Sie, wie Sie die Tests zu Ihren CI/CD-Pipelines hinzufügen.