Sdílet prostřednictvím

Souběžnost ve službě Azure Functions

V Azure Functions umožňuje jedna instance aplikace funkcí zpracovávat více událostí současně. Vzhledem k tomu, že jsou spuštěné ve stejné výpočetní instanci, sdílejí paměť, procesor a prostředky připojení. V některých plánech hostování způsobuje vysoká poptávka po konkrétní instanci, že hostitel služby Functions automaticky vytvoří nové instance, které zvládnou zvýšené zatížení. V těchto dynamických plánech škálování existuje kompromis mezi souběžností a chováním škálování. Aby služba Functions poskytovala větší kontrolu nad tím, jak vaše aplikace běží, poskytuje způsob, jak spravovat počet souběžných spuštění.

Funkce poskytují dva hlavní způsoby správy souběžnosti:

Tento článek popisuje chování souběžnosti triggerů řízených událostmi ve službě Functions a o tom, jak toto chování ovlivňuje škálování v dynamických plánech. Porovnává také pevné modely pro jednotlivé instance a dynamické modely paralelnosti.

Škálování versus souběžnost

U funkcí, které používají triggery založené na událostech nebo reagují na požadavky HTTP, můžete rychle dosáhnout limitů souběžných spuštění během období vysoké poptávky. Během takových období musíte být schopni škálovat aplikaci funkcí přidáním instancí, abyste se vyhnuli backlogu při zpracování příchozích požadavků. Způsob škálování vaší aplikace závisí na vašem plánu hostování:

Typ škálování Plány hostování Popis
Dynamické škálování (řízené událostmi) Spotřeba
Flex Consumption
Premium		 V plánu dynamického škálování 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 ve službě Azure Functions.
Ruční škálování Vyhrazené plány (App Service) Když hostujete aplikaci funkcí ve vyhrazeném plánu, musíte instance nakonfigurovat ručně během období vyššího zatížení nebo nastavit schéma automatického škálování.

Než dojde k nějakému škálování, vaše aplikace funkcí se pokusí zpracovat zvýšení zatížení tím, že zpracuje více vyvolání stejného typu v jedné instanci. V důsledku toho tato souběžná spuštění na dané instanci přímo ovlivňují rozhodnutí o škálování. Když například aplikace v plánu dynamického škálování dosáhne limitu souběžnosti, může být potřeba vertikálně navýšit kapacitu, aby udržela krok s příchozí poptávkou.

Vyvážení škálování a souběžnosti, které se v aplikaci snažíte dosáhnout, závisí na tom, kde může dojít k kritickým bodům: při zpracování (omezení procesů náročných na procesor) nebo v podřízené službě (omezení založená na vstupně-výstupních operacích).

Opravená konkurence instancí

Většina triggerů ve výchozím nastavení podporuje pevný konfigurační model souběžnosti jednotlivých instancí prostřednictvím cílového škálování. V tomto modelu má každý typ triggeru limit souběžnosti jednotlivých instancí.

Výchozí hodnoty souběžnosti u většiny triggerů můžete přepsat nastavením konkrétní souběžnosti pro jednotlivé instance pro daný typ triggeru. U mnoha triggerů nakonfigurujete nastavení souběžnosti v souboruhost.json. Například trigger služby Azure Service Bus poskytuje jak MaxConcurrentCalls, tak MaxConcurrentSessions nastavení v host.json. Tato nastavení spolupracují na řízení maximálního počtu zpráv, které každá aplikace funkcí zpracovává současně v každé instanci.

V určitých cílových scénářích škálování, například při použití triggeru Apache Kafka nebo Azure Cosmos DB, je konfigurace souběžnosti v deklaraci funkce, nikoli v souboru host.json . Jiné typy triggerů mají integrované mechanismy pro vyvolání vyrovnávání zatížení napříč instancemi. Například Azure Event Hubs i Azure Cosmos DB používají schéma založené na oddílech.

U typů triggerů, které podporují konfiguraci souběžnosti, se nastavení souběžnosti použije u všech spuštěných instancí. Tímto způsobem můžete ří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 na prostředky, můžete se rozhodnout omezit souběžnost, aby byly instance v pořádku. V takovém případě se můžete spolehnout na škálování, abyste zvládli zvýšené zatížení. Podobně platí, že když vaše funkce odesílá 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í pouze pro plán Flex Consumption.

Souběžnost triggeru HTTP je speciální typ pevného souběžnosti jednotlivých instancí. V souběžnosti triggeru HTTP závisí výchozí souběžnost také na velikosti instance.

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*
512 4
2,048 16
4,096 32

*V aplikacích Pythonu se u všech velikostí instancí ve výchozím nastavení používá úroveň souběžnosti triggeru HTTP nastavená na jeden.

Tyto výchozí hodnoty by měly ve většině případů dobře fungovat a můžete s nimi začít. 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 ke zpracování stejného zatížení více instancí.

Pokud potřebujete doladit 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 nenastavíte vlastní nastavení souběžnosti HTTP. Pokud explicitně nenastavíte 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í pevného souběžnosti pro jednotlivé instance

Pevné konfigurace souběžnosti pro jednotlivé instance vám poskytují kontrolu nad určitými spouštěcími chováními, například omezením výkonu vašich funkcí. Ale 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 po určení sady hodnot, které fungují pro určitý profil zatížení, se počet událostí, které přicházejí z připojených služeb, může změnit od dne do dne. Tato variabilita může způsobit, že se vaše aplikace spustí s neoptimálními hodnotami. Aplikace funkcí může například zpracovávat náročné datové části zpráv v poslední den týdne, což vyžaduje omezení úrovně souběžnosti. Ve zbytku týdne však mohou být datové části zpráv lehčí, což znamená, že můžete použít vyšší úroveň souběžnosti po zbytek týdne.

V ideálním případě by systém měl umožnit instancím zpracovat co nejvíce práce, udržovat každou instanci ve zdravém stavu a zároveň zachovávat nízkou latenci. Dynamická souběžnost je určená pro tento účel.

Dynamická souběžnost

Functions poskytuje model dynamické souběžnosti, který zjednodušuje konfiguraci souběžnosti pro všechny aplikace funkcí, které běží ve stejném plánu.

Poznámka:

Dynamická souběžnost se v současné době podporuje jenom pro triggery Azure Blob Storage, Azure Queue Storage a Service Bus. Dále v tomto článku musíte použít verze rozšíření uvedené v podpoře rozšíření.

Zaměstnanecké výhody

Dynamická souběžnost 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ě, které může instance aplikace funkcí pohodlně zpracovat. Tato omezení chrání aplikaci před přetížením samotného tím, že převezme více práce, než by mělo.
  • Vylepšená propustnost: Celková propustnost je vylepšená, protože jednotlivé instance nevytahují větší množství práce, než mohou rychle zpracovat. Výsledkem je 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 můžete zapnout na úrovni hostitele v souboruhost.json . Po zapnutí se úrovně souběžnosti všech rozšíření vazeb, která tuto funkci podporují, upraví automaticky 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 vypnutá. Když zapnete dynamickou souběžnost, spustí se souběžnost na úrovni jedné pro každou funkci. Úroveň souběžnosti se upraví na optimální hodnotu, kterou hostitel určí.

V aplikaci funkcí můžete zapnout dynamickou souběžnost tak, že do souboruhost.json přidáte následující nastavení:

    { 
        "version": "2.0", 
        "concurrency": { 
            "dynamicConcurrencyEnabled": true, 
            "snapshotPersistenceEnabled": true 
        } 
    }

Když snapshotPersistenceEnabled je true, což je výchozí hodnota, naučené hodnoty souběžnosti se pravidelně uchovávají v úložišti. Nové instance začínají z těchto hodnot místo toho, aby začínaly na úrovni jedné a musely znovu provádět výuku.

Správce souběžnosti

Když je zapnutá dynamická souběžnost, spustí se proces správce souběžnosti na pozadí. 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 zapnut jeden nebo více škrticích prvků, upraví se souběžnost funkcí, dokud nebude hostitel znovu stabilní. Pokud jsou regulace vypnuté, 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. Vzhledem k tomu, že určení optimální hodnoty souběžnosti může nějakou dobu trvat, použijte dynamickou souběžnost pouze v případě, že je pro vaše řešení zpočátku nebo po určité době nečinnosti přijatelná neoptimální hodnota.

Úrovně souběžnosti se spravují pro každou jednotlivou funkci. Konkrétně systém vyrovnává mezi funkcemi náročnými na prostředky, které vyžadují nízkou úroveň souběžnosti a jednodušší 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 zapnutá dynamická souběžnost, najdete v protokolech rozhodnutí o dynamické souběžnosti. Například položky protokolu se přidají, když jsou aktivovány různé regulátory, a kdykoli se pro každou funkci upraví nastavení souběžnosti. Tyto protokoly se zapisují do kategorie protokolu Host.Concurrency v tabulce záznamy.

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ě) Spouštěč Queue Storage má vlastní smyčku pro dotazování na zprávy. Pokud použijete pevnou konfiguraci pro každou instanci, možnosti konfigurace BatchSize a NewBatchThreshold určují souběžnost. 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í. Když jsou aktivována omezení výkonu, hostitel je přetížen. Zpracování zpráv je pozastaveno, dokud se omezení nevypnou. Když jsou omezení výkonu vypnutá, zvýší se souběžnost.
Blob Storage Verze 5.x (rozšíření úložiště) Trigger služby Blob Storage interně používá stejnou infrastrukturu, jakou používá trigger Queue Storage. Když je potřeba zpracovat nové nebo aktualizované objekty blob, zprávy se zapíšou do fronty řízení spravované platformou. Tato fronta se zpracovává pomocí stejné logiky jako u triggeru služby Queue Storage. Pokud je zapnutá dynamická souběžnost, je souběžnost pro zpracování této řídicí fronty dynamicky spravovaná.
Sběrnice služeb 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ími způsoby:
  • Jedno téma odeslání nebo zpracování fronty: Každé vyvolání funkce zpracuje jednu zprávu. Pokud použijete pevnou konfiguraci pro každou instanci, MaxConcurrentCalls možnost konfigurace řídí souběžnost. 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 zpracovává 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 nepoužíváte dynamickou souběžnost, MaxConcurrentSessions nastavení řídí souběžnost. Pokud je zapnutá dynamická souběžnost, MaxConcurrentSessions hodnota se ignoruje a počet relací, které každá instance zpracovává, se dynamicky upravuje.
  • Dávkové zpracování: Každé vyvolání funkce zpracovává 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 funkcí je vždy jedna a dynamická souběžnost se nepoužije.
    		•

    Další kroky

    Další informace naleznete v následujících zdrojích:

    • Last updated on