Drosselungsmuster

Beschränken Sie die Ressourcen, die eine Anwendungsinstanz, ein einzelner Mandant oder ein ganzer Dienst nutzen können. Dadurch kann das System funktionieren und seine Service Level Objectives (SLOs) auch bei plötzlicher oder anhaltender Auslastung erfüllen.

Kontext und Problem

Die Auslastung einer Cloudanwendung variiert im Laufe der Zeit je nach aktiven Benutzern und ihrer Aktivität. Mehr Benutzer melden sich während der Geschäftszeiten an, und das System führt rechenintensive Analysen am Ende jedes Monats aus. Plötzliche Brüche treten auch auf. Wenn die Verarbeitungsnachfrage die verfügbare Kapazität überschreitet, verlangsamt oder schlägt das System fehl. Wenn das System über einen vereinbarten Servicelevel verfügt, verstößt dieser Fehler gegen den SLO.

Verschiedene Strategien behandeln unterschiedliche Last, je nach den Geschäftszielen der Anwendung. Eine Strategie ist die automatische Skalierung, die den bereitgestellten Ressourcen für die aktuelle Nachfrage entspricht und die Kosten steuert. Die Bereitstellung neuer Ressourcen erfordert jedoch Zeit und fügt Kosten hinzu. Die Nachfrage, die das Kapazitätswachstum oder das Budget überschreitet, erzeugt ein Ressourcendefizit.

Lösung

Eine Alternative zur Autoskalierung besteht darin, die Ressourcennutzung zu begrenzen und Anfragen zu drosseln, wenn die Nutzung diese Obergrenze überschreitet. Die Arbeitslast überwacht ihre eigene Ressourcennutzung und drosselt Anfragen von einem oder mehreren Benutzern, wenn die Nutzung den Schwellenwert überschreitet. Das System funktioniert weiterhin und erfüllt seine SLOs.

Drosselung ist eine Kontrollschleife, keine einzige Zulassungsentscheidung. Das System benötigt Signale mit geringer Latenz auf drei Ebenen: Infrastrukturnutzung, Anwendungsstatus und pro Prinzipalzähler. Es misst kontinuierlich die Sättigung, erzwingt Grenzwerte an gut definierten Grenzen und passt diese Grenzwerte an, wenn sich die Verkehrsmuster ändern. Überlastung ist ein normaler Betriebszustand, den ein ausgereiftes System erkennt und von dem es sich erholt. Throttling stattet Ihre Workload mit Funktionen zur Selbsterhaltung aus.

Das System kann mehrere Drosselungs- oder verwandte Strategien implementieren:

• Ratenbegrenzungen pro Prinzipal: Anfragen eines Benutzers ablehnen, der die konfigurierte Rate innerhalb eines festgelegten Zeitfensters bereits überschritten hat. Für diese Strategie muss das System jede Anfrage einem Prinzipal zuordnen und die Ressourcennutzung für diesen Prinzipal messen. Informationen zu mehrinstanzenfähigen Workloads finden Sie unter Messen des Verbrauchs der einzelnen Mandanten.

• Kontrollierte Reduzierung von Funktionen: Deaktivieren oder schränken Sie nicht essenzielle Funktionen ein, sodass essenzielle Funktionen über genügend Ressourcen verfügen. Diese Strategie tauscht Vollständigkeit der Antwort gegen Verfügbarkeit ein. Beispielsweise kann eine Videostreaminganwendung auf eine niedrigere Auflösung fallen.

• Kapazitätsausgleich: Reibungsloses Aktivitätsvolumen mithilfe einer Warteschlange. In einer Multimandantenumgebung verringert die Nivellierung die Leistung aller Mandanten. Wenn Mandanten unterschiedliche Service-Level-Agreements (SLAs) haben, bearbeiten Sie Aufgaben für besonders wichtige Mandanten sofort und stellen Sie Aufgaben mit niedrigerer Priorität zurück, bis der Rückstau nachlässt. Implementieren Sie diesen Ansatz mithilfe des Musters "Prioritätswarteschlange" oder durch Verfügbarmachen separater Endpunkte für jede Prioritätsstufe.

• Prioritätsbasierte Verzögerung: Zurückstellen von Vorgängen im Auftrag von Anwendungen oder Mandanten mit niedrigerer Priorität. Setzen Sie Vorgänge aus oder schränken Sie sie ein, und geben Sie eine Ausnahme zurück, die den Mandanten anweist, es später erneut zu versuchen.

• Grenzwerte für ausgehende Raten: Beschränken Sie Ihre eigenen ausgehenden Aufrufe, wenn eine externe Abhängigkeit fehlschlägt oder Fehler zurückgibt. Verringern Sie die Anzahl der In-Flight-Anforderungen, um Überschwemmungsprotokolle zu beenden und Wiederholungskosten für eine fehlerhafte Abhängigkeit zu vermeiden. Stellen Sie den normalen Anforderungsfluss wieder her, nachdem die Abhängigkeit wiederhergestellt wurde. Beispielsweise implementiert NServiceBus diese Funktionalität.

Das folgende Diagramm zeigt die Ressourcennutzung (eine Kombination aus Arbeitsspeicher, CPU, Bandbreite und anderen Faktoren) im Laufe der Zeit für eine Anwendung, die drei Features verwendet, die als A, B und C bezeichnet werden. Ein Feature ist ein bestimmter Funktionalitätsbereich, z. B. eine Komponente, die einen bestimmten Satz von Aufgaben ausführt, einen Codeabschnitt, der eine komplexe Berechnung ausführt, oder ein Element, das einen Dienst wie einen Speichercache bereitstellt.

Das Diagramm ist ein gestapeltes Flächendiagramm. Der Bereich unterhalb der Zeile "Feature A" zeigt die Ressourcen an, die Feature A verbraucht, der Bereich zwischen den Zeilen "Feature A" und "Feature B" zeigt die Ressourcen an, die Feature B verbraucht, und der Bereich zwischen Feature B und Feature C zeigt die Ressourcen an, die Feature C verwendet. Die Linie von Feature C befindet sich am oberen Rand des Stapels, sodass auch die Gesamtnutzung der Systemressourcen im Laufe der Zeit angezeigt wird.

Das Diagramm zeigt eine abgestufte Funktionseinschränkung. Kurz vor T1 nähert sich die gesamte Ressourcennutzung dem Schwellenwert und droht, die verfügbare Kapazität auszuschöpfen. Feature B ist weniger kritisch als Feature A oder Feature C, sodass das System Feature B deaktiviert und seine Ressourcen freigibt. Zwischen T1 und T2 laufen Feature A und Feature C normal weiter. Bis zum Zeitpunkt T2 sinkt die gesamte Ressourcennutzung so weit, dass Feature B wieder aktiviert werden kann.

Sie können automatische Skalierung, kontrollierten Funktionsabbau und Drosselung kombinieren, damit Anwendungen reaktionsfähig bleiben und SLAs eingehalten werden. Wenn Sie davon ausgehen, dass die Nachfrage hoch bleibt, sorgt die Drosselung für Stabilität, während das System horizontal skaliert. Sobald die Skalierung abgeschlossen ist, stellt das System die volle Funktionalität wieder her.

Das nächste Diagramm zeigt die gesamte Ressourcennutzung im Zeitverlauf und wie Drosselung mit automatischer Skalierung und anderen kompensierenden Maßnahmen zusammenspielt.

Zum Zeitpunkt T1 erreicht das System die weiche Grenze und beginnt zu skalieren. Wenn neue Ressourcen nicht rechtzeitig ankommen, kann die Nachfrage die vorhandenen Ressourcen ausschöpfen, und das System kann fehlschlagen. Die Drosselung weist während des Scale-outs übermäßige Anfragen zurück, um die Ressourcennutzung unter der harten Obergrenze zu halten, und hebt diese Einschränkungen wieder auf, sobald neue Kapazität verfügbar ist.

Probleme und Überlegungen

Berücksichtigen Sie die folgenden Punkte, wenn Sie sich für die Implementierung dieses Musters entscheiden:

• Treffen Sie frühzeitig Drosselungsentscheidungen. Drosselung ist eine Architekturentscheidung, die sich auf das gesamte System auswirkt. Die Nachrüstung ist später teuer.

• Drosselungsgrenzwerte an der Komponente ausrichten, die zuerst gesättigt wird.

  Die Anforderungsrate ist die vertrautste Dimension, die begrenzt werden soll, aber der echte Engpass ist häufig gleichzeitige In-Flight-Anforderungen, Warteschlangentiefe, CPU- oder Speicherauslastung oder die eigenen Grenzwerte einer nachgeschalteten Abhängigkeit. Eine Begrenzung der Anfragen pro Sekunde schützt kein System, dessen Flaschenhals in der Nebenläufigkeit an einem Fan-out-Punkt liegt.

  An jeder Grenze, an der Drosselung durchgesetzt wird, etwa am Gateway, im Dienst, in einer Partition oder in einer nachgelagerten Abhängigkeit, sollten Sie ermitteln, welche Dimension zuerst ausgelastet ist, und das Limit für diese Dimension festlegen. Informationen zum parallelen Schutz an Fanoutpunkten finden Sie im Bulkhead-Muster, das die Drosselung ergänzt.

• Wählen Sie absichtlich einen Einschränkungsalgorithmus aus. Stimmen Sie sie der Toleranz der zu schützenden Komponente zu.

  Algorithm	Verhalten und optimale Anpassung
  Token-Bucket	Unterstützt Bursts bis zu einer konfigurierten Größe und gewährleistet eine konstante Wiederauffüllrate. Verwenden Sie dies für Gateways, die kurzzeitige Spitzen abfangen müssen.
  Leckige Buckets	Emittiert mit konstanter Rate. Wird für Back-Ends verwendet, die eine stetige Eingangsrate benötigen.
  Festes Fenster	Einfach zu implementieren, lässt aber Back-to-Back-Bursts an Fenstergrenzen zu.
  Gleitendes Fenster	Mildert das Problem an den Fenstergrenzen bei festen Fenstern, allerdings auf Kosten von mehr Zustandsinformationen.

• Legen Sie fest, für wen das Limit gilt. Eine Drosselung an einer grob gefassten Grenze, etwa an einem regionalen Gateway, kann viele unbeteiligte Benutzer betreffen, auch wenn nur wenige von ihnen die Last verursachen.

• Entscheiden Sie, wo sich der Zähler befindet, wenn sich ein Grenzwert über mehrere Knoten erstreckt. Lokale Zähler sind schnell, zählen aber zu wenig, wenn derselbe Aufrufer mehrere Replikate erreicht. Ein zentraler Zähler in einem freigegebenen Speicher wie Redis sieht jede Anforderung, fügt aber jeder Entscheidung Latenz hinzu. Um eine globale Rate näherungsweise zu bestimmen, teilen Sie den Grenzwert auf die Replikate auf und gleichen Sie sie regelmäßig ab.

• Treffen Sie schnell Drosselungsentscheidungen. Das System muss steigende Last erkennen, reagieren und wieder normal zurückkommen, nachdem die Last erleichtert wurde. Für diesen Prozess ist eine kontinuierliche Leistungsinstrumentation erforderlich.

• Werfen Sie Lasten vorausschauend ab, nicht erst kurz vor dem Zusammenbruch. Eine Begrenzung, die Anfragen erst dann zurückweist, wenn eine Komponente ausgelastet ist, lässt die Latenz stark ansteigen, bevor Aufrufer überhaupt Backpressure spüren.

  Da sich die Auslastung dem harten Limit nähert, beginnen Sie mit der Ablehnung eines wachsenden Anteils von Anforderungen. Frühes Zurückweisen signalisiert den Aufrufern, ihre Anfragerate zu drosseln, und verhindert den Latenzeinbruch, den plötzliche Begrenzungen häufig auslösen. Verwenden Sie die p99-Latenz im Verhältnis zu Ihrer SLO als primären Auslöser. Die durchschnittliche Auslastung kann gesund aussehen, während p99 bereits überschritten wurde.

  Wenn Sie den Wert von Anfragen unterscheiden können, sollten Sie zuerst Anfragen mit geringerem Wert oder Arbeit verwerfen, die sich leichter wiederholen lässt. Weitere Informationen finden Sie im Muster "Priority Queue".

• Gibt einen Statuscode zurück, der dem Client mitteilt, dass eine temporäre Ablehnung auf Drosselung zurückzuführen ist:

  • HTTP 429 (zu viele Anforderungen): Der Aufrufer überschreitet eine konfigurierte Anforderungsrate über ein definiertes Fenster.
  • HTTP 503 (Dienst nicht verfügbar): Der Dienst kann die Anforderung derzeit nicht verarbeiten, oft aufgrund einer unerwarteten Auslastungsspitze.

  Fügen Sie einen Retry-After HTTP-Header hinzu, damit der Client eine Wiederholungsstrategie auswählen kann. Geben Sie dem Aufrufer genügend Kontext zurück, damit er gezielt einen erneuten Versuch unternehmen kann, statt raten zu müssen. Benennen Sie z. B. den Grenzwert, den der Aufrufer überschreitet, klären Sie den betroffenen Bereich, oder schlagen Sie eine Erfolgreiche Rate vor. Unerklärte Ablehnungen helfen Anrufern nicht, sich anzupassen.

• Verteilen Sie Überladungssignale aus Ihren Abhängigkeiten, anstatt sie zu absorbieren. Ein Dienst, der seine Aufrufer drosselt, muss auch die Drosselungsantworten berücksichtigen, die er von seinen eigenen nachgeschalteten Abhängigkeiten empfängt. Wenn Ihr Dienst eine nachgelagerte 429- oder 503-Antwort verschleiert, indem er stillschweigend erneut versucht oder stattdessen eine allgemeine HTTP-500-Antwort (Internal Server Error) zurückgibt, können Aufrufer ihre Anfragerate nicht drosseln, Wiederholungsversuche verstärken sich, und die Überlastung setzt sich kaskadenartig zu vorgelagerten Systemen fort. Der Retry Storm Antipattern beschreibt diesen Fehlermodus. Geben Sie Backpressure an vorgelagerte aufrufende Komponenten weiter, sodass die gesamte Aufrufkette gemeinsam Last abbaut.

• Sorgen Sie dafür, dass das Zurückweisen weniger kostet als der Aufwand, den es verhindert. Wenn das Ablehnen einer Anforderung eine hohe Authentifizierung, eine umfassende Analyse oder eine komplexe Richtlinienauswertung erfordert, kann eine Flut von abgelehnten Anforderungen das System weiterhin sättigen. Weisen Sie Anfragen so früh wie möglich in der Anfrage-Pipeline zurück, und führen Sie auch Lasttests für den Zurückweisungspfad selbst durch.

• Planen Sie auch für Fälle, in denen die Drosselung nicht genügend Zeit verschaffen kann, bis die automatische Skalierung greift. Wenn die Nachfrage schneller wächst als neue Kapazität online kommt, kann selbst ein gedrosseltes System fehlschlagen. Wenn das Ergebnis inakzeptabel ist, behalten Sie größere Kapazitätsreserven bei, und konfigurieren Sie aggressivere Autokalierung.

• Verwenden Sie die Zwischenspeicherung nicht als Ersatz für Drosselung. Ein Cache verringert die durchschnittliche Last auf dem Origin-Server, begrenzt aber nicht die Spitzenlast. Jeder Cache-Fehlzugriff wird an den Ursprungsserver weitergeleitet, und wenn ein häufig abgefragter Schlüssel bei hohem Anfrageaufkommen abläuft, können viele Anfragen gleichzeitig darum konkurrieren, ihn neu zu füllen. Verwenden Sie Zwischenspeicherung, um die normale Last zu reduzieren, und Drosselung, um den schlimmsten Fall zu begrenzen. Weitere Informationen finden Sie im Cache-Aside Muster.

• Normalisieren Sie Ressourcenkosten für verschiedene Vorgänge, da sie im Allgemeinen keine gleichen Ausführungskosten tragen. Beispielsweise können Drosselungsgrenzwerte für Lesevorgänge höher und für Schreibvorgänge niedriger sein. Das Ignorieren der Kosten pro Vorgang kann die Kapazität erschöpfen und einen Angriffsvektor schaffen.

• Drosselungskonfiguration zur Laufzeit änderbar machen. Wenn eine ungewöhnliche Last auftritt, müssen Sie die Grenzwerte ohne Deployment anpassen. Bereitstellungen sind während eines Vorfalls langsam und riskant. Das Muster für den externen Konfigurationsspeicher lagert die Konfiguration aus, sodass Sie sie zur Laufzeit ändern können.

• Berücksichtigen Sie adaptive Grenzwerte anstelle statischer Grenzwerte. Einige Drosselungs-SDKs reagieren auf Latenz- oder Warteschlangentiefesignale, sodass der Grenzwert die tatsächlichen Komponentenbedingungen verfolgt. Kombinieren Sie einen adaptiven Limiter immer mit einem festgelegten Höchstwert.

• Überprüfen Sie Ihre Grenzen, während sich die Workload weiterentwickelt. Adaptive Begrenzungen können nicht jede Art von Drift nachverfolgen, z. B. SLO-Änderungen, Änderungen der Abhängigkeitskapazität oder Verschiebungen bei den Kosten pro Betrieb. Planen Sie die regelmäßige Überprüfung des Operators anhand dieser Eingaben.

Wann dieses Muster verwenden

Verwenden Sie dieses Muster:

• Um ein System in seinen SLOs beizubehalten.

• Um zu verhindern, dass ein einzelner Mandant Anwendungsressourcen monopolisiert.

• Um Aktivitätsausbrüche zu bewältigen

• So beschränken Sie die maximale Ressourcenebene, die ein System benötigt.

• Um Rechenaufwand mit geringem Mehrwert während Zeiträumen hoher CO2-Intensität im Stromnetz zu reduzieren.

Arbeitslastgestaltung

Bewerten Sie, wie Sie das Drosselungsmuster bei der Konzeption einer Workload verwenden können, um die in den Azure Well-Architected Framework pillars beschriebenen Ziele und Prinzipien zu berücksichtigen. Die folgende Tabelle enthält Anleitungen dazu, wie dieses Muster die Ziele jeder Säule unterstützt.

Wenn dieses Muster Kompromisse innerhalb einer Säule einführt, sollten Sie sie gegen die Ziele der anderen Säulen berücksichtigen.

Example

Das folgende Diagramm zeigt die Drosselung in einem Mehrinstanzensystem.

Benutzer aus mehreren Mandantenorganisationen greifen auf eine in der Cloud gehostete Anwendung zu, um Umfragen auszufüllen und zu übermitteln. Die Anwendung enthält Instrumentierungskomponenten, die überwachen, wie häufig die Benutzer jedes Mandanten Anfragen senden.

Um zu verhindern, dass Benutzer von einem Mandanten die Reaktionsfähigkeit und Verfügbarkeit für Benutzer in anderen Mandanten beeinträchtigen, schränkt die Anwendung die Anforderungen pro Sekunde ein, die jeder einzelne Mandant übermitteln kann. Die Anwendung blockiert Anforderungen, die diesen Grenzwert überschreiten.

Nächster Schritt

• Architekturstrategien für das Entwerfen eines Überwachungssystems

Zugehörige Ressourcen

• Messen der Nutzung der einzelnen Mandanten
• Autoscaling in Azure
• Warteschlangenbasierter Lastverteilungsmuster
• Muster der Prioritätswarteschlange
• Muster für den externen Konfigurationsspeicher