Drosselungsvorgänge für Azure Service Bus
Cloudnative Lösungen erwecken den Eindruck, dass unbegrenzt Ressourcen zur Verfügung stehen, die gemäß Ihrer jeweiligen Arbeitsauslastung skaliert werden können. Dies ist für die Cloud zwar eher zutreffend als für lokale Systeme, aber auch für die Cloud gelten gewisse Einschränkungen. Diese Einschränkungen können sowohl für den Tarif „Standard“ als auch für „Premium“ – wie in diesem Artikel beschrieben – zur Drosselung der Anforderungen von Clientanwendungen führen.
Drosselung im Standardtarif
Im Tarif „Standard“ von Service Bus wird ein mehrinstanzenfähiges Setup mit einem Preismodell mit nutzungsbasierter Bezahlung verwendet. Hier werden die zugeordneten Ressourcen von mehreren Namespaces in demselben Cluster gemeinsam verwendet. Der Tarif „Standard“ ist die empfohlene Wahl für Entwickler- und Qualitätssicherungsumgebungen und Produktionssysteme mit geringem Durchsatz.
In der Vergangenheit hat Service Bus nur über grobe Drosselungslimits verfügt, die strikt an der Ressourcennutzung ausgerichtet waren. Es gibt aber die Möglichkeit, die Drosselungslogik zu verfeinern und ein vorhersagbares Drosselungsverhalten für alle Namespaces zu erzielen, von denen diese Ressourcen gemeinsam genutzt werden.
Zur Sicherstellung einer möglichst fairen Nutzung und Verteilung von Ressourcen für alle Service Bus-Standardnamespaces, für die dieselben Ressourcen verwendet werden, wendet Azure Service Bus aktuell die guthabenbasierte Drosselungslogik an.
Hinweis
Beachten Sie hierbei, dass die Drosselung für Azure Service Bus oder andere cloudnative Dienste nicht neu ist.
Bei der auf Guthaben basierenden Drosselung wird lediglich die Art und Weise verfeinert, wie Ressourcen von verschiedenen Namespaces in einer mehrinstanzenfähigen Umgebung im Tarif „Standard“ gemeinsam genutzt werden. So kann für alle Namespaces, die die Ressourcen gemeinsam verwenden, eine faire Nutzung erzielt werden.
Was ist die auf Guthaben basierende Drosselung?
Bei der auf Guthaben basierenden Drosselung wird die Anzahl von Vorgängen beschränkt, die für einen Namespace in einem bestimmten Zeitraum durchgeführt werden können. Dies ist der Workflow für auf Guthaben basierende Drosselung.
- Zu Beginn jedes Zeitraums stellt Service Bus für jeden Namespace ein Guthaben bereit.
- Alle Vorgänge, die von den sendenden oder empfangenden Clientanwendungen durchgeführt werden, führen jeweils zu einer Verringerung des Guthabens (werden also vom verfügbaren Guthabenwert subtrahiert).
- Wenn das Guthaben aufgebraucht ist, werden die nachfolgenden Vorgänge bis zum Beginn des nächsten Zeitraums gedrosselt.
- Das Guthaben wird zu Beginn des nächsten Zeitraums wieder aufgefüllt.
Was sind die Guthabenlimits?
Die Guthabenlimits sind derzeit auf 1.000 pro Sekunde (pro Namespace) festgelegt. Nicht alle Vorgänge werden gleich erstellt. Hier werden die Guthabenkosten für die einzelnen Vorgänge angegeben.
| Vorgang | Guthabenkosten |
|---|---|
Datenvorgänge (Send, SendAsync, Receive, ReceiveAsync, Peek) |
Guthabenwert 1 pro Nachricht |
Verwaltungsvorgänge (Create, Read, Update, Delete für Warteschlangen, Themen, Abonnements, Filter) |
Guthabenwert 10 |
Hinweis
Beim Senden an ein Thema wird jede Nachricht anhand von Filtern ausgewertet, bevor sie für das Abonnement verfügbar gemacht wird. Jede Filterauswertung wird auch auf das Guthabenlimit (d. h. 1 Gutschrift pro Filterauswertung) angerechnet.
Woher weiß ich, dass eine Drosselung erfolgt?
Wenn die Clientanwendungsanforderungen gedrosselt werden, erhält die Clientanwendung die folgende Serverantwort.
The request was terminated because the entity is being throttled. Error code: 50009. Please wait 2 seconds and try again.
Wie kann ich eine Drosselung vermeiden?
Bei der gemeinsamen Nutzung von Ressourcen ist es wichtig, für die verschiedenen Service Bus-Namespaces, von denen diese Ressourcen verwendet werden, eine faire Nutzung zu erzwingen. Mit Drosselung wird sichergestellt, dass Spitzen einer einzelnen Workload nicht dazu führen, dass andere Workloads für dieselben Ressourcen gedrosselt werden. Wie weiter unten in diesem Artikel erwähnt, besteht bei einer Drosselung kein Risiko, weil in die Client-SDKs (Software Development Kit, SDK) und andere PaaS-Angebote in Azure die Standardwiederholungsrichtlinie integriert ist. Alle gedrosselten Anforderungen werden mit exponentiellem Backoff wiederholt und letztendlich übermittelt, nachdem das Guthaben aufgefüllt wurde.
Es ist klar, dass einige Anwendungen unter Umständen sensibel auf eine Drosselung reagieren. In diesem Fall empfehlen wir Ihnen, Ihren derzeitigen Service Bus-Standardnamespace zu Premium zu migrieren. Bei der Migration können Sie Ihrem Service Bus-Namespace dedizierte Ressourcen zuordnen und diese entsprechend hochskalieren, wenn Ihre Arbeitsauslastung eine Spitze aufweist, und die Wahrscheinlichkeit einer Drosselung verringern. Wenn sich Ihre Arbeitsauslastung wieder normalisiert hat, können Sie die Ressourcen, die Ihrem Namespace zugeordnet sind, dann auch wieder zentral herunterskalieren.
Drosselung im Premium-Tarif
Im Tarif „Premium“ von Service Bus werden jedem Namespace, der vom Kunden eingerichtet wird, dedizierte Ressourcen in Form von Messagingeinheiten zugeordnet. Für diese dedizierten Ressourcen sind der Durchsatz und die Latenz vorhersagbar, und sie werden für Fälle empfohlen, in denen Produktionssysteme mit hohem Durchsatz oder erhöhter Sensibilität genutzt werden. Darüber hinaus ermöglicht der Tarif „Premium“ Kunden auch das Hochskalieren ihrer Durchsatzkapazität, falls es zu Spitzen bei der Arbeitsauslastung kommt. Weitere Informationen finden Sie unter Automatisches Aktualisieren von Messagingeinheiten eines Azure Service Bus-Namespace.
Wie funktioniert die Drosselung für den Tarif „Premium“ von Service Bus?
Bei der exklusiven Ressourcenzuordnung für den Tarif „Premium“ basiert die Drosselung allein auf den Einschränkungen der Ressourcen, die dem Namespace zugeordnet sind. Falls die Anzahl von Anforderungen so hoch ist, dass sie von den aktuellen Ressourcen nicht mehr verarbeitet werden können, werden die Anforderungen gedrosselt.
Woher weiß ich, dass eine Drosselung erfolgt?
Es gibt verschiedene Möglichkeiten, Drosselung in im Tarif „Premium“ von Service Bus zu identifizieren.
- Gedrosselte Anforderungen werden in den Azure Monitor-Anforderungsmetriken angezeigt, um ermitteln zu können, wie viele Anforderungen gedrosselt wurden.
- Eine hohe CPU-Auslastung ist ein Hinweis darauf, dass die derzeitige Ressourcenzuordnung hoch ist und Anforderungen möglicherweise gedrosselt werden, falls die aktuelle Arbeitsauslastung nicht reduziert wird.
- Eine hohe Arbeitsspeicherauslastung ist ein Hinweis darauf, dass die derzeitige Ressourcenzuordnung hoch ist und Anforderungen möglicherweise gedrosselt werden, falls die aktuelle Arbeitsauslastung nicht reduziert wird.
Wie kann ich eine Drosselung vermeiden?
Da der Service Bus Premium-Namespace bereits über dedizierte Ressourcen verfügt, können Sie die Wahrscheinlichkeit einer Drosselung reduzieren. Führen Sie hierfür das zentrale Hochskalieren für die Anzahl von Messagingeinheiten durch, die Ihrem Namespace zugeordnet sind, falls es zu einer Spitze für die Arbeitsauslastung kommt (bzw. diese antizipiert wird). Weitere Informationen finden Sie unter Automatisches Aktualisieren von Messagingeinheiten eines Azure Service Bus-Namespace.
Häufig gestellte Fragen
Wie wirkt sich die Drosselung auf meine Anwendung aus?
Die Drosselung einer Anforderung ist ein Hinweis darauf, dass der Dienst ausgelastet ist, weil mehr Anforderungen eingehen, als durch die Ressourcen zulässig sind. Wenn nach einigen Augenblicken der gleiche Vorgang wiederholt wird, kann die Anforderung berücksichtigt werden, nachdem der Dienst seine aktuelle Arbeitsauslastung abgearbeitet hat.
Da Drosselung das erwartete Verhalten eines jeden nativen Clouddiensts ist, ist die Wiederholungslogik in das Service Bus SDK selbst integriert. Die Standardeinstellung ist eine automatische Wiederholung mit einem exponentiellen Backoff, um sicherzustellen, dass nicht jedes Mal dieselbe Anforderung gedrosselt wird. Die Standardwiederholungslogik gilt für jeden Vorgang.
Hinweis
Der Nachrichtenverarbeitungscode, der andere Dienste von Drittanbietern aufruft, kann auch von diesen anderen Diensten gedrosselt werden. Weitere Informationen zum Umgang mit diesen Szenarien finden Sie in der Dokumentation zum Muster „Drosselung“.
Führt die Drosselung zu Datenverlust?
Azure Service Bus ist auf Persistenz ausgelegt. Wir stellen sicher, dass für alle an Service Bus gesendeten Daten ein Commit in den Speicher erfolgt, bevor der Dienst die erfolgreiche Durchführung der Anforderung bestätigt.
Wenn die Anforderung von Service Bus bestätigt wurde, bedeutet dies, dass die Anforderung von Service Bus erfolgreich verarbeitet wurde. Falls von Service Bus ein Fehler zurückgegeben wird, bedeutet dies, dass die Anforderung von Service Bus nicht verarbeitet werden konnte und die Clientanwendung die Anforderung wiederholen muss.
Die Drosselung einer Anforderung bedeutet hingegen, dass die Anforderung vom Dienst aufgrund von Ressourceneinschränkungen derzeit nicht akzeptiert und verarbeitet werden kann. Dies ist kein Hinweis auf einen Datenverlust, sondern die Anforderung wurde von Service Bus lediglich noch nicht verarbeitet. In diesem Fall wird durch die Verwendung der Standardwiederholungsrichtlinie des Service Bus SDK sichergestellt, dass die Anforderung schließlich verarbeitet wird.
Zugehöriger Inhalt
Weitere Informationen und Beispiele für die Verwendung von Service Bus-Messaging finden Sie in den folgenden erweiterten Themen: