Řešení problémů s omezováním (429 – Příliš mnoho požadavků) v Azure Logic Apps
Platí pro: Azure Logic Apps (Consumption + Standard)
Pokud dojde k omezování pracovního postupu aplikace logiky, ke kterému dochází, když počet požadavků překročí rychlost, kterou může cíl zpracovat za určitou dobu, zobrazí se chyba HTTP 429 Příliš mnoho požadavků. Omezování může vytvářet problémy, jako je zpožděné zpracování dat, nižší rychlost výkonu a chyby, jako je překročení zadané zásady opakování.
Například následující SQL Server akce v pracovním postupu Consumption zobrazuje chybu 429, která hlásí problém s omezováním:
Následující části popisují běžné úrovně, na kterých může docházet k omezování pracovního postupu:
Omezování prostředků aplikace logiky
Azure Logic Apps má vlastní omezení propustnosti. Pokud váš prostředek aplikace logiky překročí tato omezení, omezí se váš prostředek aplikace logiky, ne jenom konkrétní instance pracovního postupu nebo spuštění.
Pokud chcete najít události omezování na této úrovni, postupujte takto:
V Azure Portal otevřete prostředek aplikace logiky.
V nabídce prostředků aplikace logiky v části Monitorování vyberte Metriky.
V části Název grafu vyberte Přidat metriku, která přidá do grafu další pruh metriky.
Na prvním panelu metrik v seznamu Metriky vyberte Akce Omezené události. V seznamu Agregace vyberte Počet.
Na druhém panelu metrik v seznamu Metriky vyberte Trigger Throttled Events (Aktivovat omezené události). V seznamu Agregace vyberte Počet.
Graf teď zobrazuje omezené události akcí i triggerů v pracovním postupu aplikace logiky. Další informace najdete v tématu Zobrazení metrik stavu a výkonu pracovního postupu v Azure Logic Apps.
Pokud chcete zvládnout omezování na této úrovni, máte k dispozici následující možnosti:
Omezte počet instancí pracovního postupu, které se dají spustit současně.
Ve výchozím nastavení platí, že pokud je podmínka triggeru pracovního postupu splněna více než jednou najednou, aktivuje se několik instancí tohoto triggeru a spustí se souběžně nebo paralelně. Každá instance triggeru se aktivuje před dokončením spuštění předchozí instance pracovního postupu.
I když je výchozí počet instancí triggerů, které se dají spustit souběžně, neomezený, můžete tento počet omezit zapnutím nastavení souběžnosti triggeru a v případě potřeby vybrat jiný limit, než je výchozí hodnota.
Povolte režim vysoké propustnosti.
Pracovní postup Consumption má výchozí limit počtu akcí, které se můžou spouštět v 5minutovém průběžném intervalu. Pokud chcete tento limit zvýšit na maximální počet akcí, zapněte u prostředku aplikace logiky režim vysoké propustnosti .
Standardní pracovní postup nemá žádné omezení počtu akcí, které se můžou spouštět během libovolného intervalu.
Zakažte chování při debatách o polích nebo "Rozdělit" v aktivačních událostech.
Pokud aktivační událost vrátí pole pro zbývající akce pracovního postupu, které se mají zpracovat, nastavení Rozdělit na aktivační události rozdělí položky pole a spustí instanci pracovního postupu pro každou položku pole. Toto chování efektivně aktivuje více souběžných spuštění až do limitu Split On.
Pokud chcete řídit omezování, vypněte chování triggeru Split On a nechte váš pracovní postup zpracovat celé pole jediným voláním, místo toho, aby zpracovával jednu položku pro každé volání.
Refaktorujte akce do několika menších pracovních postupů.
Jak už bylo zmíněno dříve, pracovní postup aplikace logiky Consumption je omezený na výchozí počet akcí, které se můžou spouštět po dobu 5 minut. I když můžete tento limit zvýšit povolením režimu s vysokou propustností, můžete také zvážit, jestli chcete akce pracovního postupu rozdělit na menší pracovní postupy, aby počet akcí spuštěných v každém pracovním postupu zůstal pod limitem. Tímto způsobem snížíte zatížení jednoho pracovního postupu a rozdělíte zatížení mezi více pracovních postupů. Toto řešení funguje lépe pro akce, které zpracovávají velké datové sady nebo spouští tolik souběžně spuštěných akcí, iterací smyčky nebo akcí uvnitř každé iterace smyčky, že překročí limit provádění akcí.
Například následující pracovní postup Consumption provede veškerou práci, aby získal tabulky z databáze SQL Server a získá řádky z každé tabulky. Smyčka For each souběžně iteruje každou tabulku tak, aby akce Získat řádky vrátila řádky pro každou tabulku. Na základě objemu dat v těchto tabulkách můžou tyto akce překročit limit provádění akcí.
Po refaktoringu se původní pracovní postup rozdělí na nadřazený pracovní postup a podřízený pracovní postup.
Následující nadřazený pracovní postup získá tabulky z SQL Server a potom zavolá podřízený pracovní postup pro každou tabulku, aby získal řádky:
Následující podřízený pracovní postup je volána nadřazeným pracovním postupem, aby získal řádky pro každou tabulku:
Omezování konektoru
Každý konektor má své vlastní omezení omezování, které najdete na technické stránce s referenčními informacemi jednotlivých konektorů. Například konektor Azure Service Bus má omezení, které umožňuje až 6 000 volání za minutu, zatímco konektor SQL Server má omezení omezování, které se liší v závislosti na typu operace.
Některé triggery a akce, například HTTP, mají zásadu opakování , kterou můžete přizpůsobit na základě omezení zásad opakování a implementovat zpracování výjimek. Tato zásada určuje, jestli a jak často trigger nebo akce opakuje požadavek, když původní požadavek selže nebo vyprší jeho časový limit a výsledkem je odpověď 408, 429 nebo 5xx. Takže když se spustí omezování a vrátí chybu 429, Logic Apps se řídí zásadami opakování tam, kde jsou podporované.
Pokud chcete zjistit, jestli trigger nebo akce podporuje zásady opakování, zkontrolujte nastavení triggeru nebo akce. Pokud chcete zobrazit pokusy o opakování triggeru nebo akce, přejděte do historie spuštění aplikace logiky, vyberte spuštění, které chcete zkontrolovat, a rozbalte tento trigger nebo akci, abyste zobrazili podrobnosti o vstupech, výstupech a případných opakováních.
Následující příklad pracovního postupu Consumption ukazuje, kde najdete tyto informace o akci HTTP:
I když historie opakování obsahuje informace o chybách, můžete mít potíže s odlišováním mezi omezováním konektoru a cílovým omezováním. V takovém případě možná budete muset zkontrolovat podrobnosti odpovědi nebo provést výpočty intervalu omezování, abyste identifikovali zdroj.
V případě pracovních postupů aplikace logiky Consumption v Azure Logic Apps s více tenanty dochází k omezování na úrovni připojení . U pracovních postupů aplikací logiky, které běží v prostředí integrační služby (ISE), stále dochází k omezování připojení mimo ISE, protože běží v Azure Logic Apps s více tenanty. Připojení ISE, která jsou vytvořená konektory ISE, ale nejsou omezena, protože běží ve vašem ISE.
Pokud chcete zvládnout omezování na této úrovni, máte k dispozici následující možnosti:
Nastavte více připojení pro jednu akci, aby pracovní postup mohl rozdělit data ke zpracování.
Zvažte, jestli můžete distribuovat úlohu rozdělením požadavků akce mezi více připojení ke stejnému cíli pomocí stejných přihlašovacích údajů.
Předpokládejme například, že pracovní postup získá tabulky z SQL Server databáze a pak získá řádky z každé tabulky. Na základě počtu řádků, které potřebujete zpracovat, můžete použít více připojení a více smyček For each k rozdělení celkového počtu řádků do menších sad pro zpracování. Tento scénář používá dvě smyčky For each k rozdělení celkového počtu řádků na polovinu. První smyčka For each používá výraz, který získá první polovinu. Druhá smyčka For each používá jiný výraz, který získá druhou polovinu, například:
Výraz 1: Funkce
take()získá přední část kolekce. Další informace najdete vetake()funkci .@take(collection-or-array-name, div(length(collection-or-array-name), 2))Výraz 2: Funkce
skip()odebere přední část kolekce a vrátí všechny ostatní položky. Další informace najdete veskip()funkci .@skip(collection-or-array-name, div(length(collection-or-array-name), 2))Následující příklad pracovního postupu Consumption ukazuje, jak můžete použít tyto výrazy:
Pro každou akci nastavte jiné připojení.
Zvažte, jestli můžete distribuovat úlohy rozložením požadavků jednotlivých akcí do jejich vlastního připojení, i když se akce připojují ke stejné službě nebo systému a používají stejné přihlašovací údaje.
Předpokládejme například, že pracovní postup získá tabulky z SQL Server databáze a získá každý řádek v každé tabulce. Můžete použít samostatná připojení, aby se při získávání tabulek používalo jedno připojení, zatímco při získávání jednotlivých řádků se používá jiné připojení.
Následující příklad ukazuje pracovní postup Consumption, který pro každou akci vytvoří a používá jiné připojení:
Změňte souběžnost nebo paralelismus ve smyčce For each.
Ve výchozím nastavení se iterace smyčky For each spouští současně až do limitu souběžnosti. Pokud máte připojení, které se omezuje ve smyčce For each, můžete snížit počet paralelně spuštěných iterací smyčky. Další informace najdete v následující dokumentaci:
Omezování cílové služby nebo systému
I když má konektor vlastní limity omezení, cílová služba nebo systém volaný konektorem můžou mít omezení také. Například některá rozhraní API v Microsoft Exchange Server mají přísnější omezení omezení než Office 365 Outlook Connector.
Ve výchozím nastavení se instance pracovního postupu aplikace logiky a všechny smyčky nebo větve uvnitř těchto instancí spouští paralelně. Toto chování znamená, že více instancí může volat stejný koncový bod současně. Každá instance neví o existenci druhé instance, takže pokusy o opakování neúspěšných akcí můžou vytvořit konflikty časování , kdy se několik volání pokusí spustit současně, ale aby byla tato volání úspěšná, musí tato volání dorazit do cílové služby nebo systému před tím, než začne docházet k omezování.
Předpokládejme například, že máte pole, které má 100 položek. Pomocí smyčky For each můžete iterovat polem a zapnout řízení souběžnosti smyčky, abyste mohli omezit počet paralelních iterací na 20 nebo aktuální výchozí limit. Uvnitř této smyčky vloží akce položku z pole do SQL Server databáze, která umožňuje pouze 15 volání za sekundu. Výsledkem tohoto scénáře je problém s omezováním, protože backlog opakovaných pokusů se sestaví a nikdy se nespustí.
Následující tabulka popisuje časovou osu pro to, co se stane ve smyčce, když je interval opakování akce 1 sekunda:
| Bod v čase | Počet spuštěných akcí | Počet neúspěšných akcí | Počet čekajících opakovaných pokusů |
|---|---|---|---|
| T + 0 sekund | 20 břitových destiček | 5 selhání kvůli limitu SQL | 5 opakovaných pokusů |
| T + 0,5 sekundy | 15 vložení, kvůli předchozím 5 čekáním na opakování | Všech 15 selže kvůli předchozímu limitu SQL, který stále platí dalších 0,5 sekundy | 20 opakování (předchozích 5 + 15 nových) |
| T + 1 sekunda | 20 břitových destiček | 5 neúspěšných pokusů plus předchozích 20 opakování kvůli limitu SQL | 25 opakování (předchozích 20 + 5 nových) |
Pokud chcete zvládnout omezování na této úrovni, máte následující možnosti:
Vytvořte jednotlivé pracovní postupy tak, aby každý z nich zpracovával jednu operaci.
Když budeme pokračovat v příkladu SQL Server scénáři v této části, můžete vytvořit pracovní postup, který umístí položky pole do fronty, například Azure Service Bus frontu. Potom vytvoříte další pracovní postup, který provede pouze operaci vložení pro každou položku v dané frontě. Tímto způsobem se v určitém čase spustí pouze jedna instance pracovního postupu, která buď dokončí operaci vložení a přesune se na další položku ve frontě, nebo instance obdrží chyby 429, ale nepokusí se neproduktivní opakování.
Vytvořte nadřazený pracovní postup, který volá podřízený nebo vnořený pracovní postup pro každou akci. Pokud nadřazený pracovní postup potřebuje volat různé podřízené pracovní postupy na základě výsledku nadřazeného, můžete použít akci podmínky nebo akci přepínače, která určuje, který podřízený pracovní postup se má volat. Tento model vám může pomoct snížit počet volání nebo operací.
Předpokládejme například, že máte dva pracovní postupy, každý s triggerem dotazu, který každou minutu kontroluje u vašeho e-mailového účtu konkrétní předmět, například Úspěch nebo Neúspěch. Výsledkem tohoto nastavení je 120 volání za hodinu. Pokud místo toho vytvoříte jeden nadřazený pracovní postup, který se dotazuje každou minutu, ale zavolá podřízený pracovní postup, který se spustí na základě toho, zda je předmět "Úspěch" nebo "Neúspěch", snížíte počet kontrol dotazování na polovinu nebo 60 v tomto případě.
Nastavte dávkové zpracování. (Pouze pracovní postupy služby Consumption)
Pokud cílová služba podporuje dávkové operace, můžete omezování řešit tak, že položky zpracováváte ve skupinách nebo dávkách, nikoli jednotlivě. Pokud chcete implementovat řešení dávkového zpracování, vytvoříte pracovní postup aplikace logiky "příjemce dávky" a pracovní postup aplikace logiky "odesílatel dávky". Odesílatel dávky shromažďuje zprávy nebo položky, dokud nebudou splněna zadaná kritéria, a pak tyto zprávy nebo položky odešle v jedné skupině. Dávkový příjemce přijme seskupení a zpracuje tyto zprávy nebo položky. Další informace najdete v tématu Dávkové zpracování zpráv ve skupinách.
Pro triggery a akce používejte verze webhooků, nikoli verze dotazování.
Proč? Trigger dotazování pokračuje v kontrole cílové služby nebo systému v určitých intervalech. Velmi častý interval, například každá sekunda, může způsobovat problémy s omezováním. Aktivační událost nebo akce webhooku, jako je webhook HTTP, však vytvoří pouze jedno volání cílové služby nebo systému, ke kterému dojde v době odběru, a vyžaduje, aby cíl aktivační událost nebo akci upozornil pouze v případě, že dojde k události. Trigger nebo akce tak nemusí neustále kontrolovat cíl.
Pokud tedy cílová služba nebo systém podporuje webhooky nebo poskytuje konektor s verzí webhooku, je tato možnost lepší než použití verze dotazování. Pokud chcete identifikovat triggery a akce webhooku, ověřte, že mají
ApiConnectionWebhooktyp nebo že nevyžadují, abyste zadali opakování. Další informace najdete v tématech Trigger APIConnectionWebhook a Akce APIConnectionWebhook.