Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Dokument zur Planung des Experiments
Stabiler Zustand
| Prozessname | Website zur Adoption von Haustieren |
|---|---|
Physikalische Architektur |
(Link zum Architekturdiagramm.) |
Logische Architektur |
(Link zum logischen Diagramm.) |
Definieren Sie den stationären Zustand |
Die durchschnittliche Seitenladezeit, gemessen anhand von Largest Contentful Paint (LCP), beträgt für die Website zur Aufnahme von Haustieren 2,5 Sekunden oder weniger bei einer Latenz von 99 Prozent (P99) von 4,0 Sekunden oder weniger bei einer Ausgangsrate von 5000 gleichzeitigen Benutzern. |
Steady-State-Kennzahlen |
LCP-Metriken, die für die gesamte Benutzerbasis erfasst wurden, und goldene Metriken (Latenz, Durchsatz, Fehlerraten, Sättigung). |
Beobachtbarkeit im stationären Zustand |
LCP wird vom Browser des Benutzers erfasst, an Amazon CloudWatch gesendet und mit CloudWatch RUM überprüft. Über einen Zeitraum von 60 Sekunden werden die durchschnittliche und die P99-LCP-Zeit für alle Anfragen in diesem Zeitraum aggregiert. Goldene Metriken auf höchster Ebene werden mithilfe von erfasst. CloudWatch |
Prozess zur Erreichung eines stabilen Zustands |
Grafana K6 wird verwendet, um eine Last zu erzeugen, die den normalen Produktionsverkehr von etwa 5.000 gleichzeitigen Benutzern simuliert. |
Anforderungen an die Beobachtbarkeit
Teams sollten in der Lage sein, Folgendes zu sehen:
-
Steady State: Was wird beobachtet, um sicherzustellen, dass sich die Anwendung unter normalen Bedingungen befindet?
-
Fehlerzustand: Wie wird der Fehlerzustand im Dashboard angezeigt? Beispiel:
-
Alarme, die ausgelöst werden sollten
-
Protokolle, die generiert werden sollten
-
-
Auswirkung eines Fehlers: Was sollte beachtet werden, um Komponenten zu erkennen, die voraussichtlich betroffen sein werden (Umfang der Auswirkungen)?
-
Wiederherstellung: Wie wird die Wiederherstellung betrachtet und gemessen, um die MTTR zu ermitteln?
-
Debug: Einzelheiten zur Fehlerbehebung bei fehlgeschlagenen Experimenten.
Die folgende Tabelle enthält Vorschläge und Beispiele für ein Diagramm mit den Anforderungen an die Beobachtbarkeit. Sie sollten anhand Ihres spezifischen Experiments definieren, was beobachtet werden soll.
| Was muss beachtet werden | Link zum Beobachtbarkeitstool | Was wird beobachtet |
|---|---|---|
Quelle der Eingabe |
Grafana K6 Armaturenbrett |
|
Allgemeiner Zustand der Anwendung |
|
|
Integrität des Workflows |
CloudWatch Dashboard zur Adoption von Haustieren |
LCP-Zeit, goldene Kennzahlen |
Ablaufverfolgungen |
X-Ray-Dashboard zur Tieradoption |
|
Protokolle |
CloudWatch Protokolle zur Adoption von Haustieren |
Alle Fehler, auf die die Pods stoßen, werden in CloudWatch Logs gespeichert. |
Definition des Experiments
| Name des Experiments | CPU-Auslastung des Amazon PetSite EKS-Pods |
|---|---|
Experimentieren Sie mit dem Quellcode |
(Link zum Quell-Repository für Experimente.) |
Beschreibung des Experiments |
In diesem Experiment wird untersucht, wie sich eine Erhöhung der CPU-Auslastung des PetSite Anwendungs-Pods auf das allgemeine Kundenerlebnis auswirken würde. Indem wir jedem laufenden PetSite Pod CPU-Stress zuweisen, können wir nachvollziehen, ob es Auswirkungen auf die Kunden gibt und in welchem Ausmaß diese Auswirkungen sind. |
Anforderungen oder Parameter des Experiments |
Anwendungslast: Produktionsdurchschnitt Auswahl der Pod-Bezeichnung: |
Experimentdauer |
10 Minuten |
Umgebung |
Alpha-Testumgebung |
Experimentieren Sie mit Zielressourcen |
PetSite Anwendungs-Pods |
Ausgangsbasis für das Experiment, die mit dem Tool zur Lastgenerierung eingeführt wird |
|
Backoff-Zustand |
Keine |
Hypothese
| Was wäre wenn | Auswirkung | Wiederherstellung |
|---|---|---|
Was würde mit dem Steady State passieren, wenn die PetSite Anwendungs-Pods bei normalem Datenverkehr auf Produktionsebene 10 Minuten lang eine CPU-Auslastung von mehr als 60% erfahren oder verursachen würden?
|
Die LCP-Zeiten bleiben für P50 der Benutzer unter 2,5 Sekunden, während P99 bei 4,0 Sekunden oder weniger liegt. Der Verbraucher sollte in der Lage sein, die Landingpage zu laden. PetSite |
Erkennung:
Selbstheilung:
Wiederherstellung: Wenn die CPU-Auslastung wieder normal ist, sollte das LCP automatisch wiederhergestellt werden. |
Ablauf des Experiments
Passen Sie den folgenden step-by-step Beispielprozess an Ihr spezifisches Experiment an:
-
Überprüfen Sie den Zugriff auf und die Funktionalität aller Amazon- CloudWatch, CloudWatch RUM- und AWS X-Ray Dashboards.
-
Überprüfen Sie den Zustand der Anwendungsumgebung:
-
Vergewissern Sie sich mithilfe des CloudWatch Dashboards, dass der EKS-Cluster fehlerfrei ist.
-
Rufen Sie unter der Beispiel-URL die Anwendungsbereitstellung auf der Testseite zur Adoption von Haustieren auf.
-
-
Starten Sie einen Ladevorgang, um einen stabilen Zustand zu erreichen:
-
Vergewissern Sie sich, dass der Lastgenerator läuft und 5000 Anfragen pro Sekunde sendet.
-
Warten Sie 5 Minuten, bis die Anwendung ihren stationären Status erreicht hat.
-
Bestätigen Sie den stabilen Status der Anwendung mithilfe des CloudWatch RUM-Dashboards.
-
-
Einen Fehler einleiten (Experiment):
-
Öffnen Sie die AWS FIS Konsole.
-
Führe das pet-adoption-pod-stress Experiment durch.
-
Vergewissern Sie sich, dass das Experiment in der Konsole ausgeführt wird.
-
-
Beobachten Sie die Auswirkungen des Fehlers auf Ihre Anwendung:
-
Erfassen Sie Screenshots aus dem CloudWatch RUM und den CloudWatch Dashboards und notieren Sie sich alle anomalen Datenpunkte.
-
Machen Sie nach Abschluss des Experiments zusätzliche Screenshots AWS FIS, um aufzuzeichnen, ob die Anwendung ohne Stress wieder in den stationären Zustand zurückkehrt, und notieren Sie alle Anomalien in den Datenpunkten.
-
Wenn der stationäre Zustand nicht wieder aufgenommen wird, ergreifen Sie Maßnahmen, um die Anwendung wiederherzustellen, und zeichnen Sie die unternommenen Schritte auf.
-
-
Stellen Sie sicher, dass die Umgebung wieder normal ist:
-
Überprüfen Sie alle Kennzahlen zu Geschäft, Benutzererfahrung, Anwendung und Infrastruktur, um sicherzustellen, dass das System wieder in einen bekannten Zustand zurückgekehrt ist. Erfassen Sie Dashboard-Screenshots, falls hilfreich.
-
Zeitplan für das Experiment
Vergewissern Sie sich, dass Sie den Zeitplan des end-to-end Experiments festhalten, angefangen bei der Generierung der Last, dem Einschleusen des Fehlers, der Beobachtung der Auswirkungen und der Wiederherstellung der Anwendung bis hin zum Stopp der Lastgenerierung. Dies wird im folgenden Beispiel veranschaulicht.
Ergebnisse des Experiments
| ID des Versuchslaufs | Ergebnisse des Experiments |
|---|---|
|
(Link zu den Versuchsergebnissen.) |
Identifizierte Mängel
-
Der Kubernetes-Cluster hat die CPU-Beeinträchtigung der PetSite Pods nicht erkannt und daher keine zusätzlichen Bereitstellungen geplant.
-
Infolge dieses Experiments gab es keinen Anstieg der 4XX- oder 5XX-Fehlerraten.
-
Wir müssen den Integritätscheck des Pods anpassen, um die Auswirkungen auf LCP zu berücksichtigen, wenn es zu Ressourcenengpässen kommt.
