Behandeln von Drosselungsproblemen (Fehler 429: „Zu viele Anforderungen“) in Azure Logic Apps
Gilt für: Azure Logic Apps (Verbrauch + Standard)
Wenn bei Ihrem Logik-App-Workflow Drosselung auftritt, was dann passiert, wenn die Anzahl der Anfragen die Rate übersteigt, die das Ziel innerhalb einer bestimmten Zeitspanne verarbeiten kann, erhalten Sie die Fehlermeldung „HTTP 429 Zu viele Anforderungen“. Die Drosselung kann verschiedene Probleme nach sich ziehen, z. B. eine verzögerte Datenverarbeitung, eine verringerte Geschwindigkeit und Fehler wie etwa eine Überschreitung der angegebenen Wiederholungsrichtlinie.
Die folgende SQL Server-Aktion in einem Verbrauchsworkflow zeigt beispielsweise einen Fehler 429 an, der ein Drosselungsproblem meldet:
In den folgenden Abschnitten werden die allgemeinen Ebenen beschrieben, auf denen ihr Workflow möglicherweise gedrosselt wird:
Logik-App-Ressourcendrosselung
Der Azure Logic Apps-Dienst hat eigene Durchsatzgrenzwerte. Wenn Ihre Logik-App-Ressource diese Grenzwerte überschreitet, wird Ihre Logik-App-Ressource gedrosselt, nicht nur eine bestimmte Workflowinstanz oder -Ausführung.
Führen Sie die folgenden Schritte aus, um Drosselungsereignisse auf dieser Ebene zu finden:
Öffnen Sie Ihre Logik-App-Ressource im Azure-Portal.
Wählen Sie im Ressourcenmenü der Logik-App unter Überwachung die Option Metriken aus.
Wählen Sie unter Diagrammtitel die Option Metrik hinzufügen aus, wodurch dem Diagramm ein weiterer Metrikbalken hinzugefügt wird.
Wählen Sie für den erste Metrikbalken in der Liste Metrik die Option Drosselungsereignisse für Aktionen aus. Wählen Sie aus der Liste Aggregation die Option Anzahl aus.
Wählen Sie für den zweiten Metrikbalken in der Liste Metrik die Option Drosselungsereignisse für Trigger aus. Wählen Sie aus der Liste Aggregation die Option Anzahl aus.
Das Diagramm zeigt nun gedrosselte Ereignisse sowohl für Aktionen als auch für Trigger in Ihrem Logik-App-Workflow an. Weitere Informationen finden Sie unter Anzeigen von Integritäts- und Leistungsmetriken für Workflows in Azure Logic Apps.
Zum Steuern der Drosselung auf dieser Ebene haben Sie folgenden Optionen:
Ändern Sie die Anzahl von Workflowinstanzen, die gleichzeitig ausgeführt werden können.
Wenn die Triggerbedingung Ihres Workflows mehr als einmal gleichzeitig erfüllt wird, werden standardmäßig mehrere Instanzen dieses Triggers ausgelöst und gleichzeitig oder parallel ausgeführt. Jede Triggerinstanz wird ausgelöst, bevor die Ausführung der vorherigen Workflowinstanz beendet ist.
Obwohl standardmäßig eine unbegrenzte Anzahl von parallelen Triggerinstanzen ausgeführt werden kann, können Sie diese Anzahl begrenzen, indem Sie die Parallelitätseinstellung für den Trigger aktivieren und bei Bedarf einen anderen als den Standardwert auswählen.
Aktivieren Sie den Modus für hohen Durchsatz.
Ein Verbrauchsworkflow hat einen Standardgrenzwert für die Anzahl von Aktionen, die in einem rollierenden Intervall von 5 Minuten ausgeführt werden können. Um dieses Grenzwert auf die maximale Anzahl von Aktionen zu erhöhen, aktivieren Sie den Modus für hohen Durchsatz für Ihre Logik-App-Ressource.
Ein Standardworkflow hat keinen Grenzwert für die Anzahl von Aktionen, die während eines beliebigen Intervalls ausgeführt werden können.
Deaktivieren Sie das Verhalten zum Auflösen von Batches für Arrays oder zum „Teilen bei“ in Triggern.
Wenn ein Trigger ein Array der verbleibenden zu verarbeitenden Workflowaktionen zurückgibt, werden mit der Teilen bei-Einstellung des Triggers die Arrayelemente unterteilt, und es wird für jedes Arrayelement eine Workflowinstanz gestartet. Dieses Verhalten löst effektiv mehrere gleichzeitige Ausführungen bis zum Teilen bei-Grenzwert aus.
Um die Drosselung zu steuern, deaktivieren Sie das Teilen bei-Verhalten des Triggers und lassen Ihren Workflowprozess das gesamte Array mit einem einzigen Aufruf verarbeiten, anstatt ein einzelnes Element pro Aufruf zu verarbeiten.
Umgestalten von Aktionen in mehrere, kleinere Workflows.
Wie zuvor erwähnt, ist ein Logik-App-Verbrauchsworkflow auf eine Standardanzahl von Aktionen beschränkt, die in einem 5-Minuten-Zeitraum ausgeführt werden können. Obwohl Sie diesen Grenzwert erhöhen können, indem Sie den Modus für hohen Durchsatz aktivieren, können Sie alternativ auch das Aufteilen der Aktionen Ihres Workflows in kleinere Workflows erwägen, damit die Anzahl von Aktionen, die in jedem Workflow ausgeführt werden, unterhalb des Grenzwerts gehalten werden kann. Auf diese Weise reduzieren Sie die Belastung eines einzelnen Workflows und verteilen die Last auf mehrere Workflows. Diese Lösung eignet sich insbesondere für Aktionen, die große Datensätze verarbeiten oder so viele parallel ausgeführte Aktionen, Schleifeniterationen oder Aktionen innerhalb jeder Schleifeniteration auslösen, dass sie das Ausführungslimit der Aktion überschreiten.
Der folgende Verbrauchsworkflow erledigt beispielsweise die gesamte Arbeit, um Tabellen aus einer SQL Server-Datenbank abzurufen, und er ruft die Zeilen aus jeder Tabelle ab. Die For each-Schleife durchläuft parallel jede Tabelle, sodass die Get rows-Aktion die Zeilen für jede Tabelle zurückgibt. Basierend auf der Menge an Daten in diesen Tabellen können die Aktionen zu einer Überschreitung des Limits für die Aktionsausführung führen.
Nach dem Refactoring wird der ursprüngliche Workflow in einen übergeordneten und einen untergeordneten Workflow aufgeteilt.
Der folgende übergeordnete Workflow ruft die Tabellen aus SQL Server ab, und ruft dann den untergeordneten Workflow für jede Tabelle auf, um die Zeilen abzurufen:
Der folgende untergeordnete Workflow wird vom übergeordneten Workflow aufgerufen, um die Zeilen für jede Tabelle abzurufen:
Connectordrosselung
Jeder Connector hat seine eigenen Drosselungsgrenzwerte, diese finden Sie auf der Seite mit der technischen Referenz für jeden Connector. Beispielsweise gilt für den Azure Service Bus-Connector ein Drosselungslimit, das bis zu 6.000 Aufrufe pro Minute zulässt, während für den SQL Server-Connector Drosselungslimits basierend auf dem Vorgangstyp gelten.
Einige Trigger und Aktionen, z. B. HTTP, verwenden eine „Wiederholungsrichtlinie“, die Sie basierend auf den Limits für Wiederholungsrichtlinien anpassen können, um eine Ausnahmebehandlung zu implementieren. Diese Wiederholungsrichtlinie gibt an, ob und wie ein Trigger bzw. eine Aktion versucht, eine Anforderung zu wiederholen, wenn die ursprüngliche Anforderung nicht erfolgreich ist und es zu Timeouts oder Antworten vom Typ 408, 429 oder 5xx kommt. Wenn also die Drosselung gestartet und ein 429-Fehler zurückgegeben wird, folgen die Logik-Apps der Wiederholungsrichtlinie (sofern unterstützt).
Um festzustellen, ob ein Trigger oder eine Aktion Wiederholungsrichtlinien unterstützen, überprüfen Sie die Einstellungen für den Trigger oder die Aktion. Um die Wiederholungsversuche eines Triggers oder einer Aktion anzuzeigen, wechseln Sie zum Ausführungsverlauf Ihrer Logik-App und wählen die zu überprüfende Ausführung aus. Erweitern Sie dann den Trigger oder die Aktion, um Details zu Eingaben, Ausgaben und allfälligen Wiederholungsversuchen anzuzeigen.
Das folgende Beispiel für einen Verbrauchsworkflow zeigt, wo Sie diese Informationen für eine HTTP-Aktion finden können:
Wenngleich der Wiederholungsverlauf Informationen zu Fehlern liefert, ist es unter Umständen schwierig, zwischen Connectordrosselung und Zieldrosselung zu unterscheiden. In diesem Fall müssen Sie möglicherweise die Details der Antwort überprüfen oder einige Drosselintervallberechnungen durchführen, um die Quelle zu identifizieren.
Für Logik-App-Verbrauchsworkflows im mehrmandantenfähigen Azure Logic Apps-Dienst erfolgt die Drosselung auf Ebene der Verbindung.
Zum Steuern der Drosselung auf dieser Ebene haben Sie folgenden Optionen:
Richten Sie mehrere Verbindungen für eine einzelne Aktion ein, damit der Workflow die Daten zur Verarbeitung partitionieren kann.
Erwägen Sie, ob Sie die Arbeitsauslastung aufteilen können, indem Sie die Anforderungen einer Aktion auf mehrere Verbindungen mit demselben Ziel aufteilen und hierbei dieselben Anmeldeinformationen verwenden.
Nehmen wir beispielsweise an, dass Ihr Workflow Tabellen aus einer SQL Server-Datenbank und dann die Zeilen aus jeder Tabelle abruft. Basierend auf der Anzahl von Zeilen, die Sie verarbeiten müssen, können Sie mehrere Verbindungen und mehrere For each-Schleifen verwenden, um die Gesamtanzahl von Zeilen zur Verarbeitung in kleinere Sätze aufzuteilen. Dieses Szenario verwendet zwei For each-Schleifen, um die Gesamtzahl an Zeilen zu halbieren. Die erste For each-Schleife verwendet einen Ausdruck, mit dem die erste Hälfte der Zeilen abgerufen wird. Die zweite For each-Schleife verwendet einen anderen Ausdruck zum Abrufen der zweiten Hälfte an Zeilen:
Ausdruck 1: Die
take()-Funktion ruft den ersten Teil einer Sammlung ab. Weitere Informationen finden Sie untertake()-Funktion.@take(collection-or-array-name, div(length(collection-or-array-name), 2))Ausdruck 2: Die
skip()-Funktion entfernt den ersten Teil einer Sammlung und gibt alle weiteren Elemente zurück. Weitere Informationen finden Sie unterskip()-Funktion.@skip(collection-or-array-name, div(length(collection-or-array-name), 2))Im folgenden Beispiel für den Verbrauchsworkflow wird gezeigt, wie Sie diese Ausdrücke verwenden können:
Richten Sie für jede Aktion eine eigene Verbindung ein.
Erwägen Sie, ob Sie die Arbeitsauslastung aufteilen können, indem Sie für die Anforderungen jeder Aktion eine eigene Verbindung nutzen, selbst wenn die Aktionen eine Verbindung mit demselben Dienst oder System herstellen und dieselben Anmeldeinformationen verwenden.
Nehmen wir beispielsweise an, dass Ihr Workflow die Tabellen aus einer SQL Server-Datenbank abruft und dann jede Zeile aus jeder Tabelle abruft. Sie können getrennte Verbindungen verwenden, sodass zum Abrufen der Tabellen eine Verbindung und zum Abrufen jeder Zeile eine andere Verbindung verwendet wird.
Das folgende Beispiel zeigt einen Verbrauchsworkflow, der eine andere Verbindung für jede Aktion erstellt und verwendet:
Ändern Sie die Parallelität für eine For each-Schleife.
Standardmäßig werden Iterationen für „for each“-Schleifen gleichzeitig bzw. parallel ausgeführt, bis das Parallelitätslimit erreicht ist. Wenn Sie eine Verbindung haben, die innerhalb einer „Für jede“-Schleife gedrosselt wird, können Sie die Anzahl von Schleifeniterationen verringern, die gleichzeitig ausgeführt werden. Weitere Informationen finden Sie in der folgenden Dokumentation:
„For each“-Schleifen – Ändern der Parallelität oder sequenzielle Ausführung
Schemareferenz für die Workflowdefinitionssprache – „For each“-Schleifen
Schemareferenz für die Workflowdefinitionssprache – Ändern der Parallelität von „For each“-Schleifen
Schemareferenz für die Workflowdefinitionssprache – Sequenzielles Ausführen von „For each“-Schleifen
Zieldienst- oder Zielsystemdrosselung
Während ein Connector eigene Drosselungslimits aufweist, können für den Zieldienst oder für das vom Connector aufgerufene Zielsystem ebenfalls Drosselungslimits gelten. Beispielsweise gelten für einige APIs in Microsoft Exchange Server strengere Drosselungslimits als für den Office 365 Outlook-Connector.
Standardmäßig werden die Workflowinstanzen einer Logik-App oder aller Schleifen oder Verzweigungen innerhalb dieser Instanzen parallel ausgeführt. Bei diesem Verhalten können mehrere Instanzen gleichzeitig denselben Endpunkt aufrufen. Die einzelnen Instanzen haben keine Kenntnis über andere Instanzen, deshalb können erfolglose Versuche und anschließende Wiederholungsversuche zu Racebedingungen führen: Mehrere Aufrufe werden gleichzeitig ausgeführt, aber für deren Erfolg müssen diese Aufrufe am Zieldienst oder Zielsystem eingehen, bevor eine Drosselung stattfindet.
Angenommen, Sie verfügen über ein Array mit 100 Elementen. Sie verwenden eine „Für jede“-Schleife, um das Array zu durchlaufen, und Sie aktivieren die Parallelitätssteuerung für die Schleife, um die Anzahl gleichzeitiger Iterationen auf 20 oder den aktuellen Standardgrenzwert zu beschränken. Innerhalb dieser Schleife fügt eine Aktion ein Element aus dem Array in eine SQL Server-Datenbank ein, für die nur 15 Aufrufe pro Sekunde zulässig sind. Dieses Szenario führt zu einem Drosselungsproblem, weil ein Backlog bei den Wiederholungsversuchen entsteht, die niemals ausgeführt werden.
Die folgende Tabelle beschreibt die Zeitachse der Ereignisse in der Schleife, wenn das Wiederholungsintervall der Aktion auf 1 Sekunde festgelegt ist:
| Zeitpunkt | Anzahl von Aktionen, die ausgeführt werden | Anzahl von Aktionen, die fehlschlagen | Anzahl wartender Wiederholungsversuche |
|---|---|---|---|
| Zeitpunkt + 0 Sekunden | 20 Einfügevorgänge | 5 fehlerhafte Vorgänge aufgrund des SQL-Limits | 5 Wiederholungsversuche |
| Zeitpunkt + 0,5 Sekunden | 15 Einfügevorgänge aufgrund von 5 ausstehenden vorherigen Wiederholungsversuchen | Alle 15 Vorgänge schlagen fehl, weil das vorherige SQL-Limit weitere 0,5 Sekunden gilt | 20 Wiederholungsversuche (vorherige 5 + 15 neue) |
| Zeitpunkt + 1 Sekunde | 20 Einfügevorgänge | 5 fehlerhafte Vorgänge plus vorherige 20 Wiederholungsversuche aufgrund des SQL-Limits | 25 Wiederholungsversuche (vorherige 20 + 5 neue) |
Zum Steuern der Drosselung auf dieser Ebene haben Sie folgenden Optionen:
Erstellen Sie einzelne Workflows, damit jeder einen einzelnen Vorgang verarbeitet.
Um mit dem Beispiel-SQL Server-Szenario in diesem Abschnitt fortzufahren, können Sie einen Workflow erstellen, der Arrayelemente in eine Warteschlange einreiht, z. B. in eine Azure Service Bus-Warteschlange. Sie erstellen dann einen weiteren Workflow, der nur den Einfügevorgang für jedes Element in dieser Warteschlange ausführt. Auf diese Weise wird zu jedem Zeitpunkt nur eine Workflowinstanz ausgeführt, die entweder den Einfügevorgang abschließt und mit dem nächsten Element in der Warteschlange fortfährt oder einen Fehler vom Typ 429 ausgibt, aber keine unproduktiven Wiederholungsversuche ausführt.
Erstellen Sie einen übergeordneten Workflow, der für jede Aktion einen untergeordneten oder geschachtelten Workflow aufruft. Wenn der übergeordnete Workflow basierend auf dem Ergebnis des übergeordneten Workflows unterschiedliche untergeordnete Workflows aufrufen muss, können Sie eine Bedingungs- oder Umschaltaktion verwenden, die bestimmt, welcher untergeordnete Workflow aufgerufen werden muss. Dieses Muster kann dazu beitragen, die Anzahl von Aufrufen oder Vorgängen zu verringern.
Nehmen wir beispielsweise an, Sie verfügen über zwei Workflows, jeder mit einem Abruftrigger, der Ihr E-Mail-Konto jede Minute auf einen bestimmten Betreff überprüft, z. B. „Erfolgreich“ oder „Fehler“. Dieses Setup führt zu 120 Aufrufen pro Stunde. Wenn Sie stattdessen einen einzelnen übergeordneten Workflow erstellen, der jede Minute einen Abruf durchführt, aber einen untergeordneten Workflow aufruft, der abhängig davon ausgeführt wird, ob der Betreff „Erfolgreich“ oder „Fehler“ lautet, reduzieren Sie die Anzahl von Abrufüberprüfungen auf die Hälfte, in diesem Fall auf 60.
Richten Sie eine Batchverarbeitung ein. (nur Verbrauchsworkflows)
Wenn der Zieldienst Batchvorgänge unterstützt, können Sie die Drosselung durch das Verarbeiten von Elementen in Gruppen oder Batches steuern, statt Elemente einzeln zu verarbeiten. Um die Lösung zur Batchverarbeitung zu implementieren, erstellen Sie einen Logik-App-Workflow als „Batchempfänger“ und einen Logik-App-Workflow als „Batchsender“. Der Batchsender erfasst Nachrichten oder Elemente, bis ein von Ihnen angegebenes Kriterium erfüllt ist. Anschließend werden diese Nachrichten oder Elemente in einer einzelnen Gruppe gesendet. Der Batchempfänger akzeptiert diese Gruppe und verarbeitet die darin enthaltenen Nachrichten oder Elemente. Weitere Informationen finden Sie im Artikel zur Batchverarbeitung in Gruppen.
Verwenden Sie anstelle der Abrufversionen die Webhookversionen für Trigger und Aktionen.
Warum? Ein Abruftrigger setzt die Überprüfung des Zieldiensts oder -systems in bestimmten Intervallen fort. Ein sehr kurzes Intervall – z. B. 1 Sekunde – kann zu Drosselungsproblemen führen. Ein Webhooktrigger oder eine Webhookaktion hingegen – z. B. ein HTTP-Webhook – erstellt nur einen einzelnen Aufruf des Zieldiensts oder -systems, der zum Abonnementzeitpunkt ausgeführt wird und das Ziel anweist, den Trigger oder die Aktion nur bei Eintritt eines Ereignisses zu benachrichtigen. Auf diese Weise müssen der Trigger oder die Aktion das Ziel nicht fortlaufend überprüfen.
Wenn also der Zieldienst oder das Zielsystem Webhooks unterstützt oder einen Connector mit einer Webhookversion bereitstellt, ist diese Option gegenüber der Abrufversion vorzuziehen. Um Webhooktrigger und -aktionen zu identifizieren, vergewissern Sie sich, dass sie den Typ
ApiConnectionWebhookaufweisen oder nicht erfordern, dass Sie eine Wiederholung angeben. Weitere Informationen finden Sie unter APIConnectionWebhook-Trigger und APIConnectionWebhook-Aktion.