Souběžnost ve službě Azure Functions
Tento článek popisuje chování souběžnosti triggerů řízených událostmi ve službě Azure Functions. Také porovnává statické a dynamické modely souběžnosti.
Ve službě Functions můžete mít více spuštěných procesů dané funkce současně v jedné výpočetní instanci. Představte si například případ, kdy máte ve své aplikaci funkcí tři různé funkce, které se škálují na více instancí, aby zvládly zvýšené zatížení. V tomto scénáři se každá funkce spouští v reakci na jednotlivá vyvolání ve všech třech instancích a daná instance dokáže zpracovat více vyvolání stejného typu. Mějte na paměti, že provádění funkcí v jedné instanci sdílí stejnou paměť, procesor a prostředky připojení. Vzhledem k tomu, že na každé instanci může souběžně běžet více spuštění funkcí, musí mít každá funkce způsob, jak spravovat počet souběžných spuštění.
Když je vaše aplikace hostovaná v dynamickém plánu škálování (Consumption, Flex Consumption nebo Premium), hostitel škáluje počet instancí aplikace funkcí nahoru nebo dolů na základě počtu příchozích událostí. Další informace najdete v tématu Škálování řízené událostmi. Při hostování funkcí v plánu Dedicated (App Service) musíte instance nakonfigurovat ručně nebo nastavit schéma automatického škálování.
Tato rozhodnutí o škálování jsou také přímo ovlivněna souběžností spuštění v dané instanci. Když aplikace v plánu dynamického škálování dosáhne limitu souběžnosti, může být potřeba škálovat, aby udržela krok s příchozí poptávkou.
Funkce poskytují dva hlavní způsoby správy souběžnosti:
Statická souběžnost: Můžete nakonfigurovat limity na úrovni hostitele pro souběžnost, které jsou specifické pro jednotlivé triggery. Toto je výchozí chování souběžnosti pro službu Functions.
Dynamická souběžnost: U určitých typů triggerů může hostitel Functions automaticky určit nejlepší úroveň souběžnosti pro danou aktivační událost ve vaší aplikaci. Musíte se přihlásit k tomuto modelu souběžnosti.
Statická souběžnost
Ve výchozím nastavení podporuje většina triggerů statický konfigurační model na úrovni hostitele. V tomto modelu má každý typ triggeru limit souběžnosti jednotlivých instancí. U většiny triggerů ale můžete také požádat o konkrétní souběžnost jednotlivých instancí pro daný typ triggeru. Trigger služby Service Bus například poskytuje MaxConcurrentCalls nastavení v souboru host.json i MaxConcurrentSessions nastavení. Tato nastavení společně řídí maximální počet zpráv, které jednotlivé funkce zpracovávají současně v každé instanci. Jiné typy triggerů mají integrované mechanismy pro vyvolání vyrovnávání zatížení napříč instancemi. Například služba Event Hubs a Azure Cosmos DB používají schéma založené na oddílech.
U typů triggerů, které podporují konfiguraci souběžnosti, se nastavení, která zvolíte, použijí pro všechny spuštěné instance. To vám umožní řídit maximální souběžnost vašich funkcí v jednotlivých instancích. Pokud je například vaše funkce náročná na procesor nebo prostředky, můžete se rozhodnout omezit souběžnost, abyste zachovali instance v pořádku a spoléhat se na škálování, aby se zvládlo zvýšené zatížení. Podobně platí, že pokud vaše funkce provádí požadavky na podřízenou službu, která je omezena, měli byste také zvážit omezení souběžnosti, abyste se vyhnuli přetížení podřízené služby.
Souběžnost triggeru HTTP
Platí jenom pro plán Flex Consumption (Preview).
Plán Flex Consumption škáluje všechny funkce triggeru HTTP společně jako skupinu. Další informace najdete v tématu Škálování jednotlivých funkcí. Následující tabulka uvádí výchozí nastavení souběžnosti pro triggery HTTP v dané instanci na základě nakonfigurované velikosti paměti instance.
| Velikost instance (MB) | Výchozí souběžnost* |
|---|---|
2048 |
16 |
4096 |
32 |
*Pro aplikace v Pythonu je 1výchozí souběžnost triggeru HTTP pro všechny velikosti instancí .
Ve většině případů by tyto výchozí hodnoty měly fungovat dobře a začnete s nimi. Vezměte v úvahu, že při daném počtu požadavků HTTP se zvýšením hodnoty souběžnosti HTTP sníží počet instancí potřebných ke zpracování požadavků HTTP. Stejně tak snížení hodnoty souběžnosti HTTP vyžaduje více instancí pro zpracování stejného zatížení.
Pokud potřebujete vyladit souběžnost HTTP, můžete to udělat pomocí Azure CLI. Další informace najdete v tématu Nastavení limitů souběžnosti HTTP.
Výchozí hodnoty souběžnosti v předchozí tabulce platí jenom v případech, kdy jste nenastavili vlastní nastavení souběžnosti HTTP. Pokud jste explicitně nenastavili nastavení souběžnosti HTTP, výchozí souběžnost se zvýší, jak je znázorněno v tabulce při změně velikosti instance. Po nastavení hodnoty souběžnosti HTTP se tato hodnota zachová i přes změny velikosti instance.
Určení optimální statické souběžnosti
I když konfigurace statické souběžnosti poskytují kontrolu nad určitými chováními triggerů, jako je omezování vašich funkcí, může být obtížné určit optimální hodnoty pro tato nastavení. Obecně platí, že je nutné dorazit na přijatelné hodnoty iterativním procesem zátěžového testování. I když určíte sadu hodnot, které pracují pro konkrétní profil zatížení, může se počet událostí přicházejících z připojených služeb změnit od dne do dne. Tato variabilita znamená, že vaše aplikace může často běžet s neoptimálními hodnotami. Aplikace funkcí může například zpracovávat obzvláště náročné datové části zpráv na poslední den v týdnu, což vyžaduje omezení souběžnosti. Ve zbytku týdne jsou ale datové části zpráv jednodušší, což znamená, že byste mohli použít vyšší úroveň souběžnosti ve zbytku týdne.
V ideálním případě chceme, aby systém umožnil zpracování instancí tak, jak je to možné, a současně udržovat každou instanci v dobrém stavu a latenci, což je to, co je navržené tak, aby dynamická souběžnost fungovala.
Dynamická souběžnost
Funkce teď poskytují model dynamické souběžnosti, který zjednodušuje konfiguraci souběžnosti pro všechny aplikace funkcí běžící ve stejném plánu.
Poznámka:
Dynamické souběžnosti se v současné době podporuje jenom pro triggery Azure Blob, Azure Queue a Service Bus a vyžaduje použití verzí uvedených v části podpory rozšíření níže.
Zaměstnanecké výhody
Použití dynamické souběžnosti poskytuje následující výhody:
- Zjednodušená konfigurace: Už nemusíte ručně určit nastavení souběžnosti pro jednotlivé triggery. Systém zjišťuje optimální hodnoty pro vaši úlohu v průběhu času.
- Dynamické úpravy: Souběžnost se dynamicky upravuje nahoru nebo dolů v reálném čase, což umožňuje systému přizpůsobit se měnícím vzorcům zatížení v průběhu času.
- Ochrana stavu instance: Modul runtime omezuje souběžnost na úrovně instance aplikace funkcí, které se dají pohodlně zpracovat. Tím se aplikace chrání před přetížením samotného tím, že převezme více práce, než by měla.
- Vylepšená propustnost: Celková propustnost je vylepšená, protože jednotlivé instance nevytahují více práce, než mohou rychle zpracovat. To umožňuje efektivnější vyrovnávání zatížení napříč instancemi. U funkcí, které můžou zpracovávat vyšší zatížení, je možné získat vyšší propustnost zvýšením souběžnosti na hodnoty nad výchozí konfigurací.
Konfigurace dynamické souběžnosti
Dynamickou souběžnost je možné povolit na úrovni hostitele v souboru host.json. Pokud je tato funkce povolená, úrovně souběžnosti všech rozšíření vazeb, které tuto funkci podporují, se automaticky upraví podle potřeby. V těchto případech nastavení dynamické souběžnosti přepíší ručně nakonfigurovaná nastavení souběžnosti.
Ve výchozím nastavení je dynamická souběžnost zakázaná. Když je povolená dynamická souběžnost, souběžnost začíná u každé funkce na 1 a je upravena na optimální hodnotu, která je určena hostitelem.
V aplikaci funkcí můžete povolit dynamickou souběžnost přidáním následujících nastavení do souboru host.json:
{
"version": "2.0",
"concurrency": {
"dynamicConcurrencyEnabled": true,
"snapshotPersistenceEnabled": true
}
}
Když SnapshotPersistenceEnabled je trueto výchozí hodnota, naučené hodnoty souběžnosti se pravidelně uchovávají v úložišti, takže nové instance začínají od těchto hodnot místo toho, aby začínaly od 1 a nemusely se učit znovu.
Správce souběžnosti
Když je na pozadí povolená dynamická souběžnost, běží na pozadí proces správce souběžnosti. Tento správce neustále monitoruje metriky stavu instancí, jako je využití procesoru a vlákna, a podle potřeby mění omezení. Pokud je povolená jedna nebo více omezení, upraví se souběžnost funkcí dolů, dokud nebude hostitel znovu v pořádku. Pokud jsou omezení zakázaná, může se zvýšit souběžnost. Různé heuristiky se používají k inteligentní úpravě souběžnosti nahoru nebo dolů podle potřeby na základě těchto omezení. V průběhu času se souběžnost jednotlivých funkcí stabilizuje na konkrétní úrovni.
Úrovně souběžnosti se spravují pro každou jednotlivou funkci. Systém tak vyrovnává mezi funkcemi náročnými na prostředky, které vyžadují nízkou úroveň souběžnosti a odlehčí funkce, které dokážou zvládnout vyšší souběžnost. Vyvážení souběžnosti jednotlivých funkcí pomáhá udržovat celkový stav instance aplikace funkcí.
Když je povolená dynamická souběžnost, uvidíte v protokolech rozhodnutí o dynamické souběžnosti. Například uvidíte protokoly, když jsou povoleny různé omezení a kdykoli se pro každou funkci upraví souběžnost nahoru nebo dolů. Tyto protokoly se zapisují do kategorie protokolu Host.Concurrency v tabulce trasování.
Podpora rozšíření
Dynamická souběžnost je povolená pro aplikaci funkcí na úrovni hostitele a všechna rozšíření, která podporují dynamické souběžnosti, se spouští v daném režimu. Dynamická souběžnost vyžaduje spolupráci mezi hostitelem a rozšířeními jednotlivých aktivačních událostí. Dynamické souběžnosti podporují pouze uvedené verze následujících rozšíření.
| Rozšíření | Verze | Popis |
|---|---|---|
| Queue Storage | verze 5.x (rozšíření úložiště) | Trigger azure Queue Storage má vlastní smyčku dotazování zpráv. Při použití statické konfigurace se souběžnost řídí možnostmi BatchSize/NewBatchThreshold konfigurace. Při použití dynamické souběžnosti se tyto hodnoty konfigurace ignorují. Dynamická souběžnost je integrovaná do smyčky zpráv, takže počet zpráv načtených za iteraci se dynamicky upraví. Pokud jsou povoleny omezení (hostitel je přetížen), zpracování zpráv se pozastaví, dokud nebudou zakázány omezení. Pokud jsou omezení zakázaná, zvýší se souběžnost. |
| Blob Storage | verze 5.x (rozšíření úložiště) | Trigger služby Azure Blob Storage interně používá stejnou infrastrukturu, jakou používá trigger fronty Azure. Když je potřeba zpracovat nové nebo aktualizované objekty blob, zprávy se zapíšou do fronty řízení spravované platformy a tato fronta se zpracuje pomocí stejné logiky jako pro QueueTrigger. Pokud je povolená dynamická souběžnost, bude dynamicky spravována souběžnost pro zpracování této řídicí fronty. |
| Service Bus | verze 5.x | Trigger služby Service Bus aktuálně podporuje tři modely spouštění. Dynamická souběžnost ovlivňuje tyto modely spouštění následujícím způsobem: • Jedno téma odeslání nebo zpracování fronty: Každé vyvolání funkce zpracuje jednu zprávu. Při použití statické konfigurace se souběžnost řídí MaxConcurrentCalls možností konfigurace. Při použití dynamické souběžnosti se tato hodnota konfigurace ignoruje a souběžnost se dynamicky upraví.• Jednoúčelové zpracování tématu nebo fronty založené na relaci: Každé vyvolání funkce zpracuje jednu zprávu. V závislosti na počtu aktivních relací pro vaše téma nebo frontu každá instance zapůjčí jednu nebo více relací. Zprávy v každé relaci se zpracovávají sériově, aby se zajistilo řazení v relaci. Pokud se nepoužívá dynamická souběžnost, řídí se souběžnost nastavením MaxConcurrentSessions . Když je povolená dynamická souběžnost, ignoruje se a počet relací, které každá instance zpracovává, MaxConcurrentSessions se dynamicky upraví.• Dávkové zpracování: Každé vyvolání funkce zpracuje dávku zpráv, která MaxMessageCount se řídí nastavením. Vzhledem k tomu, že dávkové vyvolání jsou sériové, souběžnost funkce aktivované dávkovou službou je vždy jedna a dynamická souběžnost se nepoužije. |
Další kroky
Další informace naleznete v následujících zdrojích: