Sdílet prostřednictvím

Škálování řízené událostmi ve službě Azure Functions

  • Článek

V plánech Consumption, Flex Consumption a Premium služba Azure Functions škáluje prostředky přidáním dalších instancí na základě počtu událostí, které aktivují funkci.

Způsob škálování vaší aplikace funkcí závisí na plánu hostování:

  • Plán Consumption: Každá instance hostitele služby Functions v plánu Consumption je omezená, obvykle na 1,5 GB paměti a jeden procesor. Instance hostitele podporuje celou aplikaci funkcí. Všechny funkce v rámci aplikace funkcí sdílejí prostředek v instanci se proto škálují současně. Když aplikace funkcí sdílejí stejný plán Consumption, stále se škálují nezávisle.

  • Plán Flex Consumption: Plán používá deterministický strategii škálování jednotlivých funkcí, kde se každá funkce škáluje nezávisle, s výjimkou funkcí HTTP, Blob a Durable Functions aktivovaných funkcí, které se škálují ve svých vlastních skupinách. Další informace najdete v tématu Škálování jednotlivých funkcí. Tyto instance se pak škálují na základě souběžnosti vašich požadavků.

  • Plán Premium: Konkrétní velikost plánu Premium určuje dostupnou paměť a procesor pro všechny aplikace v tomto plánu v dané instanci. Plán škáluje své instance na základě potřeb škálování aplikací v plánu a podle potřeby se aplikace škálují v rámci plánu.

Soubory kódu funkce se ukládají do sdílených složek Azure Files v hlavním účtu úložiště funkce. Když odstraníte hlavní účet úložiště aplikace funkcí, odstraní se soubory kódu funkce a nejde je obnovit.

Škálování modulu runtime

Azure Functions používá komponentu označovanou jako kontroler škálování ke sledování četnosti událostí a určení, jestli se má škálovat na více instancí nebo jak se má škálovat. Kontroler škálování používá heuristiku pro jednotlivé typy triggerů. Pokud například používáte trigger azure Queue Storage, používá cílové škálování.

Jednotkou škálování pro Azure Functions je aplikace funkcí. Při horizontálním navýšení kapacity aplikace funkcí se přidělí více prostředků ke spuštění více instancí hostitele Azure Functions. Naopak při snižování požadavků na výpočetní výkon kontroler škálování odebírá instance hostitele funkcí. Počet instancí se nakonec škáluje, když v aplikaci funkcí neběží žádné funkce.

Škálování událostí monitorování kontroleru a vytváření instancí

Studený start

Pokud se vaše aplikace funkcí na několik minut stane nečinnou, může se platforma rozhodnout škálovat počet instancí, na kterých vaše aplikace běží až na nulu. Další požadavek má přidanou latenci škálování od nuly na jednu. Tato latence se označuje jako studený start. Počet závislostí vyžadovaných vaší aplikací funkcí může ovlivnit dobu studeného spuštění. Studený start je spíše problém pro synchronní operace, jako jsou triggery HTTP, které musí vrátit odpověď. Pokud vaše funkce ovlivňují studené starty, zvažte použití jiného plánu, než je spotřeba. Ostatní plány nabízejí tyto strategie pro zmírnění nebo odstranění studených startů:

  • Plán Premium: podporuje jak předzbrojené instance, tak vždy připravené instance s minimálně jednou instancí.

  • Plán Flex Consumption: podporuje volitelný počet vždy připravených instancí, které je možné definovat na základě škálování jednotlivých instancí.

  • Vyhrazený plán: Samotný plán se dynamicky nes škáluje, ale aplikaci můžete spouštět nepřetržitě s povoleným nastavením AlwaysOn .

Porozumění chování při škálování

Škálování se může lišit v závislosti na několika faktorech a aplikace se v závislosti na vybraných triggerech a jazyce škálují různě. Je třeba si uvědomit některé složité aspekty škálování:

  • Maximální počet instancí: Jedna aplikace funkcí se škáluje jenom na maximum povolené plánem. Jedna instance však může zpracovat více než jednu zprávu nebo požadavek najednou. Podle potřeby můžete určit nižší maximální omezení škálování.
  • Nová rychlost instancí: U triggerů HTTP se nové instance přidělují maximálně jednou za sekundu. V případě jiných triggerů než HTTP se nové instance přidělují maximálně jednou za 30 sekund. Škálování je rychlejší při spuštění v plánu Premium.
  • Škálování na základě cílů: Cílové škálování poskytuje zákazníkům rychlý a intuitivní model škálování a v současné době se podporuje pro fronty a témata služby Service Bus, fronty úložiště, Event Hubs, Apache Kafka a rozšíření Azure Cosmos DB. Nezapomeňte zkontrolovat cílové škálování , abyste porozuměli jejich chování škálování.
  • Škálování na jednotlivé funkce: S některými z nájimnými výjimkami se funkce spuštěné v plánu Flex Consumption škálují na nezávislých instancích. Mezi výjimky patří triggery HTTP a triggery služby Blob Storage (Event Grid). Každý z těchto typů triggerů se škáluje společně jako skupina ve stejných instancích. Stejně tak všechny triggery Durable Functions sdílejí instance a škálují se společně. Další informace najdete v tématu Škálování jednotlivých funkcí.
  • Maximální monitorované triggery: V současné době může kontroler škálování monitorovat až 100 aktivačních událostí pro rozhodování o škálování. Pokud má vaše aplikace více než 100 triggerů založených na událostech, rozhodnutí o škálování se provádějí pouze na prvních 100 triggerech, které se spustí. Další informace najdete v tématu Osvědčené postupy a vzory pro škálovatelné aplikace.

Omezení horizontálního navýšení kapacity

Můžete se rozhodnout omezit maximální počet instancí, které může aplikace použít pro horizontální navýšení kapacity. Nejčastěji se jedná o případy, kdy podřízená komponenta, jako je databáze, má omezenou propustnost. Maximální limity škálování při spouštění různých plánů hostování najdete v tématu Omezení škálování.

Plán Flex Consumption

Ve výchozím nastavení mají aplikace spuštěné v plánu Flex Consumption limit 100 celkového počtu instancí. V současné době je 40nejnižší maximální hodnota počtu instancí a nejvyšší podporovaná maximální hodnota počtu instancí je 1000. Když použijete az functionapp create příkaz k vytvoření aplikace funkcí v plánu Flex Consumption, použijte --maximum-instance-count parametr k nastavení tohoto maximálního počtu instancí pro vaši aplikaci.

Všimněte si, že i když můžete změnit maximální počet instancí aplikací Flex Consumption až 1000, vaše aplikace před dosažením tohoto čísla dosáhne limitu kvóty. Další podrobnosti najdete v kvótách paměti místního předplatného.

Tento příklad vytvoří aplikaci s maximálním počtem 200instancí:

az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage <STORAGE_ACCOUNT_NAME> --runtime <LANGUAGE_RUNTIME> --runtime-version <RUNTIME_VERSION> --flexconsumption-location <REGION> --maximum-instance-count 200

V tomto příkladu se az functionapp scale config set pomocí příkazu změní maximální počet instancí existující aplikace na 150:

az functionapp scale config set --resource-group <RESOURCE_GROUP> --name <APP_NAME> --maximum-instance-count 150

Plány Consumption/Premium

V plánu Consumption nebo Elastic Premium můžete zadat nižší maximální limit pro vaši aplikaci úpravou hodnoty functionAppScaleLimit nastavení konfigurace webu. Lze functionAppScaleLimit nastavit 0 na neomezenou nebo null neomezenou hodnotu nebo platnou hodnotu mezi 1 a maximálním počtem aplikací.

az resource update --resource-type Microsoft.Web/sites -g <RESOURCE_GROUP> -n <FUNCTION_APP-NAME>/config/web --set properties.functionAppScaleLimit=<SCALE_LIMIT>

Chování škálování na více instancí

Škálování řízené událostmi automaticky snižuje kapacitu, když se sníží poptávka po vašich funkcích. Dělá to tak, že vyprázdní instance jejich aktuálních spuštění funkce a pak tyto instance odebere. Toto chování se protokoluje jako režim vyprázdnění. Období odkladu pro funkce, které se aktuálně spouští, může prodloužit až 10 minut pro aplikace plánu Consumption a až 60 minut pro aplikace plánů Flex Consumption a Premium. Škálování řízené událostmi a toto chování se nevztahuje na aplikace vyhrazeného plánu.

Pro chování horizontálního snížení kapacity platí následující aspekty:

  • U aplikací běžících ve Windows v plánu Consumption mají ve výchozím nastavení povolené režimy vyprázdnění jenom aplikace vytvořené po květnu 2021.
  • Pokud chcete povolit řádné vypnutí funkcí pomocí triggeru služby Service Bus, použijte verzi 4.2.0 nebo novější verzi rozšíření služby Service Bus.

Škálování podle funkcí

Platí pouze pro plán Flex Consumption.

Plán Flex Consumption je jedinečný v tom, že implementuje chování škálování jednotlivých funkcí. Ve škálování jednotlivých funkcí s výjimkou triggerů HTTP, triggerů objektů blob (Event Grid) a Durable Functions se všechny ostatní typy triggerů funkcí ve vaší aplikaci škálují na nezávislé instance. Triggery HTTP ve vaší aplikaci se škálují společně jako skupina ve stejných instancích, jako všechny triggery Blob (Event Grid) a všechny triggery Durable Functions, které mají vlastní sdílené instance.

Zvažte, jestli je aplikace funkcí hostovaná v plánu Flex Consumption, který má tuto funkci:

function1 function2 function3 function4 function5 function6 function7
Trigger HTTP Trigger HTTP Aktivační událost orchestrace (Durable) Trigger aktivity (Durable) Trigger služby Service Bus Trigger služby Service Bus Trigger služby Event Hubs

V tomto příkladu:

Osvědčené postupy a vzory pro škálovatelné aplikace

Existuje mnoho aspektů aplikace funkcí, které ovlivňují škálování, včetně konfigurace hostitele, stopy za běhu a efektivity prostředků. Další informace najdete v části škálovatelnosti článku o aspektech výkonu. Měli byste také vědět, jak se připojení chovají při škálování vaší aplikace funkcí. Další informace najdete v tématu Správa připojení ve službě Azure Functions.

Pokud má vaše aplikace více než 100 funkcí, které používají triggery založené na událostech, zvažte rozdělení aplikace do jedné nebo více aplikací, kde každá aplikace má méně než 100 funkcí založených na událostech.

Další informace o škálování v Pythonu a Node.js najdete v příručce pro vývojáře Pro Azure Functions v Pythonu – Škálování a souběžnost a příručka pro vývojáře azure Functions Node.js – Škálování a souběžnost.

Další kroky

Další informace najdete v těchto článcích: