BERND KUHLENAlle Notizen ↗Ein Amazon EFS-Problem kann vorhanden sein, lange bevor es sichtbar wird. Ein kleines Dateisystem kann eine Arbeitslast wochen- oder monatelang erfolgreich verarbeiten und dabei eine begrenzte Reserve an Burst-Credits verbrauchen. Die Anwendung sieht gesund aus, die Dashboards bleiben grün und die Architektur verdient Vertrauen. Dann erreicht die Reserve Null und dieselbe Arbeitslast trifft auf eine viel niedrigere nachhaltige Durchsatzobergrenze.
Durch diese Verzögerung fühlt sich der Ausfall plötzlich an. Operativ gesehen ist es alles andere als plötzlich.
Die versteckte Diskrepanz
Bei Bursting Throughput wächst der Basisdurchsatz mit der Datenmenge, die in der Speicherklasse EFS Standard gespeichert ist. AWS dokumentiert eine Basisrate von 50 KiB/s pro GiB, wobei jedes Dateisystem einen gemessenen Durchsatz von mindestens 1 MiB/s erhält. Für Arbeit, die unter dem Ausgangswert geleistet wird, werden Punkte gutgeschrieben; Arbeit, die darüber liegt, verbraucht sie.
Das gefährliche Muster ist eine Arbeitsbelastung, deren langfristiger Durchschnitt leicht über dem Ausgangswert liegt. Es führt möglicherweise nicht zu einem unmittelbaren Vorfall, da zuvor angesammelte Credits die Differenz ausgleichen. Der Saldo tendiert jedoch täglich nach unten.
Warum die Symptome in die falsche Richtung zeigen
Wenn Speicheranrufe länger dauern, warten die Anwendungsmitarbeiter. Unter Linux tragen Prozesse, die durch eine unterbrechungsfreie I/O-Wartezeit blockiert sind, zur durchschnittlichen Auslastung bei, sodass ein Speicherengpass einem Problem mit der Rechenkapazität ähneln kann. Anfragen stellen sich in die Warteschlange, Worker-Pools füllen sich und Timeouts verteilen sich über den gesamten Service, auch wenn die CPU-Auslastung nicht die Hauptursache ist.
Das Hinzufügen von Instanzen kann die Situation noch verschlimmern, wenn jeder neue Mitarbeiter mehr Anfragen für dasselbe eingeschränkte gemeinsame Dateisystem generiert. Der Engpass wird geteilt, während die zusätzliche Parallelität den Druck erhöht.
Warum sich sechs gesunde Monate als sehr wenig erweisen
Ein langer Zeitraum ohne Fehler bestätigt nur die Kombination aus Nachfrage, Basisdurchsatz und verbleibenden Gutschriften in diesem Zeitraum. Es ist kein Beweis dafür, dass die Arbeitsbelastung tragbar ist, nachdem die Credits aufgebraucht sind. Ein rückläufiger BurstCreditBalance ist daher nicht nur ein Kapazitätsdetail; es ist ein frühes Zuverlässigkeitssignal.
Die Belastungstests müssen den stationären Zustand abdecken, nicht nur einen kurzen Spitzentest. Ein zehnminütiger Test kann zeigen, dass die Bruchgrenze hoch genug ist. Es sagt wenig über ein Defizit aus, das sich über Tausende von Stunden ansammelt.
Eine bessere Ermittlungssequenz
- Vergleichen Sie die CPU-Auslastung mit der durchschnittlichen Auslastung und der I/O-Wartezeit.
- Prüfen Sie EFS
BurstCreditBalanceüber Wochen oder Monate. - Vergleichen
MeteredIOBytesmitPermittedThroughput. - Korrelieren Sie Speicherbeschränkungen mit der Anwendungslatenz und der Auslastung der Mitarbeiter.
- Prüfen Sie, wie viele Daten sich tatsächlich in der Standard-Speicherklasse befinden, weil das die Bursting-Basislinie bestimmt.
- Entscheiden Sie, ob der Workload zum Bursting-, Elastic- oder Provisioned Throughput gehört.
Die Ingenieurstunde
Burst-Kapazität ist ein Puffer, kein Kapazitätsplan. Jede kreditbasierte Dienstleistung sollte anhand der Richtung und des Zinssatzes ihres Guthabens bewertet werden, nicht nur danach, ob der aktuelle Wert über Null liegt. Der frühere Artikel dieser Reihe beschreibt das tatsächliche Vorfallmuster im Detail; der nächste Artikel setzt diese Lektion in ein konkretes CloudWatch-Monitoring-Design um.