Throttling: Verarbeitung unter Last gezielt verlangsamen

Ausfallsicherheit

Throttling

Verarbeitung unter Last gezielt verlangsamen

Die Idee und ihr Nutzen

Nach einem Sturm gehen bei einer Versicherung sehr viele Schadenmeldungen ein. Gleichzeitig fordern Mitarbeitende Statistikberichte an, um den Umfang der Schäden abzuschätzen. Das Schadenportal, über das die Meldungen gespeichert werden, und der Berichtsdienst, der die Berichte erstellt, nutzen dieselbe Datenbank. Startet der Berichtsdienst alle Berichte sofort, belastet er die Datenbank so stark, dass auch das Schadenportal neue Schadenmeldungen nur noch langsam speichern kann. Deshalb geht jede Berichtsanfrage zuerst an einen Programmteil namens „Drosselung“, der entscheidet, wann die Anfrage an den Berichtsdienst weitergeht. Berichte dürfen nur einen Teil der Datenbankverbindungen nutzen, also der begrenzt vielen Zugänge, über die Programme gleichzeitig mit der Datenbank arbeiten können. Sind 80 Prozent dieser Verbindungen belegt, lässt die „Drosselung“ neue Berichtsanfragen nur noch so schnell zum Berichtsdienst durch, wie laufende Berichte fertig werden. Die übrigen Anfragen warten. Bis zu einer Belegung von 80 Prozent hat die Datenbank noch genug Rechenleistung für die dringenderen Schadenmeldungen, deshalb greift die „Drosselung“ erst ab diesem Wert ein. Dieses Vorgehen heißt Throttling, auf Deutsch Drosseln.

Bausteine: Mitarbeitende: fordern Statistikberichte an; Drosselung: Berichte warten höchstens 30 Minuten; Berichtsdienst: erstellt Berichte; Schadenportal: speichert neue Schadenmeldungen; Datenbank: ein Teil der Verbindungen ist für Schadenmeldungen reserviert. Verbindungen: Mitarbeitende — Drosselung; Drosselung — Berichtsdienst; Berichtsdienst — Datenbank; Schadenportal — Datenbank. Sind 80 Prozent der Verbindungen für Berichte belegt, lässt die „Drosselung“ einen neuen Bericht erst durch, wenn ein laufender fertig ist; so speichert das Schadenportal neue Schadenmeldungen weiterhin ohne Verzögerung.

Wie funktioniert es?

Am Tag nach dem Sturm fordern innerhalb einer Stunde 60 Mitarbeitende Statistikberichte an. Die „Drosselung“ misst laufend, wie stark die Datenbankverbindungen für Berichte belegt sind. Einen festen Teil der Datenbankverbindungen hat das IT-Team für Schadenmeldungen reserviert, und Berichte dürfen nur die übrigen Verbindungen belegen. Die Verbindungen für Berichte sind jetzt zu 80 Prozent belegt, und damit ist die Schwelle erreicht. Ab jetzt lässt die „Drosselung“ einen neuen Bericht nur durch, wenn ein laufender Bericht fertig wird. Frau Schulz aus dem Controlling fordert einen Bericht an. Die „Drosselung“ stellt den Bericht in eine Warteschlange, statt ihn sofort an den Berichtsdienst zu geben. Auf dem Bildschirm von Frau Schulz steht „Ihr Bericht wartet, voraussichtlicher Start in etwa 5 Minuten“. Nach vier Minuten ist ein laufender Bericht fertig, und die Warteschlange gibt den Bericht von Frau Schulz an den Berichtsdienst. Der Berichtsdienst fragt die Datenbank nur über die Verbindungen für Berichte ab. Die reservierten Verbindungen für Schadenmeldungen bleiben frei. Danach fordert ein Kollege einen besonders großen Bericht an, und die „Drosselung“ stellt auch diesen Bericht in die Warteschlange. Nach 30 Minuten ist der große Bericht immer noch nicht gestartet. Länger darf keine Anfrage warten; diese Grenze heißt Höchstwartezeit. Mitarbeitende, die nach einem Sturm einen Bericht anfordern, brauchen das Ergebnis meist innerhalb der nächsten Stunde; ein Bericht, der erst nach mehr als 30 Minuten startet, käme dafür oft zu spät. Die „Drosselung“ lehnt die Anfrage ab und zeigt dem Kollegen die Meldung „Bericht wegen hoher Auslastung abgelehnt, bitte später erneut anfordern“.

Die Schwelle von 80 Prozent und die Höchstwartezeit von 30 Minuten hat das IT-Team der Versicherung für die „Drosselung“ festgelegt. Das IT-Team bestimmt auch, welche Auslastung die „Drosselung“ misst. Möglich sind zum Beispiel der Anteil belegter Datenbankverbindungen oder die Zahl gleichzeitig laufender Berichte. Bevor das IT-Team die „Drosselung“ einrichtet, muss klar sein, welche Vorgänge warten können und welche eine sofortige Antwort brauchen. Bei der Versicherung können die Berichte warten, und die Schadenmeldungen brauchen eine sofortige Antwort. Die „Drosselung“ nimmt jede Berichtsanfrage entgegen, bevor die Anfrage den Berichtsdienst erreicht. Die Warteschlange hält die Berichtsanfragen fest, die warten müssen. Der Berichtsdienst erstellt die Berichte und erhält von der „Drosselung“ nur so viele Anfragen, wie die Schwelle zulässt. Die „Drosselung“ greift ein, bevor die Datenbank so stark belastet ist, dass das Schadenportal Schadenmeldungen nur noch langsam speichert. Throttling macht einen langsamen Dienst nicht schneller. Throttling teilt die vorhandenen Datenbankverbindungen und die Rechenleistung der Datenbank so auf, dass das Schadenportal neue Schadenmeldungen auch dann in einer halben Sekunde speichert, wenn viele Berichte angefordert werden.

Eine wartende Anfrage ist nicht erledigt, sondern verzögert. Deshalb zeigt die „Drosselung“ an, dass ein Bericht wartet und etwa wie lange noch. Throttling sorgt auch nicht dafür, dass jeder angeforderte Bericht erstellt wird. Wird eine Anfrage nicht mehr bearbeitet, erhält der Absender eine klare Ablehnung, statt auf einen Bericht zu warten, der nie kommt. Eine abgelehnte Anfrage ist danach nicht mehr in der Warteschlange, und der Kollege muss seinen Bericht neu anfordern. Sind wieder weniger als 80 Prozent der Verbindungen für Berichte belegt, gibt die „Drosselung“ Berichtsanfragen wieder sofort weiter. Anhand der Messwerte prüft das IT-Team, ob das Schadenportal die Schadenmeldungen während dieser Zeit weiterhin in einer halben Sekunde gespeichert hat und die reservierten Verbindungen frei geblieben sind.

Beteiligte: Frau Schulz: Controlling, fordert einen Bericht an; Kollege: fordert einen sehr großen Bericht an; Drosselung: Schwelle 80 %, Höchstwartezeit 30 min; Warteschlange: wartende Berichte; Berichtsdienst: erstellt Berichte; Datenbank: Verbindungen, ein Teil reserviert für Schadenmeldungen. Ablauf: 1. Am Tag nach dem Sturm fordern 60 Mitarbeitende Berichte an. Die „Drosselung“ misst, wie stark die Datenbankverbindungen für Berichte belegt sind. 2. Die Verbindungen für Berichte sind zu 80 Prozent belegt. Ab jetzt lässt die „Drosselung“ neue Berichte nur durch, wenn ein laufender Bericht fertig wird. 3. Frau Schulz aus dem Controlling fordert einen Bericht an. 4. Die „Drosselung“ stellt den Bericht von Frau Schulz in die Warteschlange, statt ihn sofort an den Berichtsdienst zu geben. 5. Frau Schulz sieht, dass ihr Bericht wartet und in etwa 5 Minuten startet. 6. Ein laufender Bericht wird fertig. Die Warteschlange gibt den Bericht von Frau Schulz an den Berichtsdienst. 7. Der Berichtsdienst fragt die Datenbank nur über die Verbindungen für Berichte ab. Die reservierten Verbindungen für Schadenmeldungen bleiben frei. 8. Ein Kollege fordert einen besonders großen Bericht an. 9. Die „Drosselung“ stellt auch den großen Bericht des Kollegen in die Warteschlange. 10. Nach 30 Minuten Wartezeit lehnt die „Drosselung“ den großen Bericht ab. Der Kollege erfährt, dass er den Bericht später erneut anfordern muss.

Wann ist es sinnvoll und wann nicht?

Throttling lohnt sich

Es gibt wichtige Vorgänge, die Vorrang haben müssen, und weniger wichtige, die warten können. Bei der Versicherung haben die Schadenmeldungen Vorrang, und die Statistikberichte können warten. Ohne Throttling startet der Berichtsdienst jeden Bericht sofort, ganz gleich, wie viele Schadenmeldungen das Schadenportal gerade speichern muss.
Beide Arten von Vorgängen nutzen denselben begrenzt belastbaren Dienst. Bei der Versicherung nutzen Schadenmeldungen und Berichte dieselbe Datenbank. Jeder Statistikbericht liest Hunderttausende Datensätze und belegt dabei Rechenleistung der Datenbank und eine Datenbankverbindung. Startet der Berichtsdienst ohne Throttling alle angeforderten Berichte sofort, dauert das Speichern einer Schadenmeldung plötzlich zehn Sekunden statt einer halben, und manche Meldungen scheitern.
Die Last kommt in Spitzen, zum Beispiel nach einem Sturm. Zusätzliche Rechenleistung lässt sich nicht schnell genug oder nicht wirtschaftlich bereitstellen. Ohne Throttling müsste das IT-Team die Datenbank für die wenigen Tage nach einem Sturm so groß auslegen, dass alle Berichte sofort laufen können. Mit Throttling reicht die vorhandene Datenbank, und die Berichte warten in der Spitze einige Minuten.

Throttling ist nicht das Richtige

Alle Vorgänge sind gleich dringend. Dann gibt es keinen Vorgang, der für einen anderen warten kann, und eine Warteschlange würde dringende Anfragen nur verzögern. Das IT-Team richtet die Programme, die diese Anfragen annehmen, so ein, dass sie neue Anfragen bei hoher Auslastung sofort mit einer klaren Meldung ablehnen. Die Nutzer wissen dann sofort, dass sie es später erneut versuchen müssen, und warten nicht in einer immer länger werdenden Warteschlange.
Die Datenbank ist schon ohne Berichte vollständig ausgelastet. Eine Warteschlange würde dann nur immer länger, weil kein wartender Bericht starten kann, ohne die Schadenmeldungen zu bremsen. Der Berichtsdienst lehnt neue Berichtsanfragen in dieser Lage sofort mit einer klaren Meldung ab, statt sie in eine Warteschlange zu stellen. Die Mitarbeitenden warten so nicht auf Berichte, die erst nach Stunden oder gar nicht starten.
Die Last steigt dauerhaft und nicht nur in Spitzen. Throttling verschiebt die Arbeit dann nur, und die Warteschlange wird nie leer. Das IT-Team erweitert dann die Rechenleistung der Datenbank. Berichte und Schadenmeldungen laufen danach ohne Warteschlange.
Die Datenbank lässt sich schnell genug um zusätzliche Rechenleistung erweitern. Dann richtet das IT-Team Autoscaling ein, also das automatische Hinzufügen von Rechenleistung, sobald die Last steigt. Die Berichte müssen dann nicht warten. Throttling kann die Zeit überbrücken, bis die zusätzliche Rechenleistung bereitsteht.
Ein einzelner Absender soll unabhängig von der Auslastung nicht mehr als eine feste Zahl von Anfragen stellen. Die „Drosselung“ greift erst ab der Schwelle von 80 Prozent ein und lässt bis dahin jeden Absender beliebig viele Berichte anfordern. Dann richtet das IT-Team Rate Limiting ein: Jeder Absender darf in einem festen Zeitraum nur eine feste Zahl von Anfragen stellen. Frau Schulz darf dann zum Beispiel höchstens fünf Berichte in der Stunde anfordern, auch wenn die Datenbank wenig zu tun hat. Beim Rate Limiting muss das IT-Team keine Auslastung messen und keine Schwelle im Betrieb anpassen.

Nachteile und typische Fehler

Das IT-Team muss Messgrößen und Schwellen im Betrieb beobachten und anpassen. Die reservierten Datenbankverbindungen für Schadenmeldungen bleiben auch dann ungenutzt, wenn gerade wenige Meldungen eingehen. Warteschlange, Anzeige der Wartezeit und Ablehnung mit verständlicher Meldung müssen gebaut, getestet und überwacht werden. Die Fachbereiche müssen außerdem vorab festlegen, welche Vorgänge Vorrang haben.

Typische Fehler und woran man sie erkennt:

Unklare Vorrangregeln: Niemand hat festgelegt, welche Vorgänge warten können und welche eine sofortige Antwort brauchen. Das IT-Team leitet dann womöglich auch die Anfragen eines Vorgangs, der eine sofortige Antwort braucht, zuerst an die „Drosselung“, zum Beispiel die Abfrage, mit der die Sachbearbeitung den Stand eines Schadens nachsieht. Diese Abfragen warten dann in der Warteschlange wie die Berichte, ohne dass es jemand bemerkt. Erkennbar ist das, wenn dieselben Abteilungen immer wieder am längsten warten.
Endlose Warteschlange: Wartende Anfragen haben keine Höchstwartezeit. Nach einem Sturm fordern die Mitarbeitenden mehr Berichte an, als fertig werden, und jede Anfrage bleibt in der Warteschlange, bis sie an der Reihe ist. Ein Bericht startet dann womöglich erst nach Stunden, wenn niemand ihn mehr braucht. Erkennbar ist das an einer Warteschlange, die über Stunden nur wächst.
Falsche Schwelle: Die Schwelle liegt zu niedrig, und die „Drosselung“ hält Berichte zurück, obwohl die Datenbank freie Rechenleistung hat. Oder die Schwelle liegt zu hoch, und die Schadenmeldungen werden trotzdem langsam. Erkennbar ist das am Vergleich der Wartezeiten der Berichte mit den Speicherzeiten der Schadenmeldungen.
Nur Verbindungen gezählt: Die „Drosselung“ misst nur, wie viele Verbindungen für Berichte belegt sind, aber der Engpass ist die Rechenleistung der Datenbank. Ein einziger sehr großer Bericht belegt nur eine Verbindung und verlangsamt trotzdem alle Schadenmeldungen, obwohl die Schwelle nicht erreicht ist. Erkennbar ist das an langsamen Schadenmeldungen, während die „Drosselung“ keine Überlast meldet.
Unsichtbares Warten: Die „Drosselung“ meldet nicht, dass ein Bericht wartet. Mitarbeitende halten ihre Anfrage für verloren und fordern denselben Bericht noch einmal an. Die „Drosselung“ stellt jede dieser Anfragen in die Warteschlange, und die Warteschlange füllt sich mit doppelten Anfragen. Erkennbar ist das an mehreren gleichen Berichtsanfragen desselben Nutzers kurz hintereinander.

Weiterführend

Quellen

Microsoft: Throttling pattern: beschreibt Drosselung als laufende Regelung nach gemessener Auslastung, die Möglichkeiten Ablehnen, Abschalten, Zurückstellen und Warteschlange sowie das Zusammenspiel mit automatischem Hinzufügen von Rechenleistung.
AWS Well-Architected Framework: REL05-BP02 Throttle requests: empfiehlt, Anfragen über einer Grenze mit einer klaren Meldung abzulehnen, damit der Absender es später erneut versuchen kann, und nennt typische Fehler wie ungetestete Grenzwerte.