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

V plánech Consumption a Premium služba Azure Functions škáluje prostředky procesoru a paměti přidáním dalších instancí hostitele Functions. Počet instancí se určuje podle počtu událostí, které aktivují funkci.

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 je celá aplikace funkcí, což znamená, že všechny funkce v rámci aplikace funkcí sdílejí prostředek v instanci a škálují se současně. Aplikace funkcí, které sdílejí stejné škálování plánu Consumption, nezávisle na sobě V plánu Premium určuje velikost plánu dostupnou paměť a procesor pro všechny aplikace v tomto plánu v dané instanci.

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.

Scale controller monitoring events and creating instances

Studený start

Po několika minutách nečinnosti aplikace funkcí může platforma š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 na vaše funkce dopadají studené starty, zvažte spuštění v plánu Premium nebo ve vyhrazeném plánu 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 najednou zpracovávat více než jednu zprávu nebo požadavek, takže počet paralelních provádění není nijak omezený. 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í založené na cílech: 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ě, služby Event Hubs a rozšíření Cosmos DB. Nezapomeňte zkontrolovat cílové škálování, abyste porozuměli jejich chování škálování.

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

Možná budete chtít omezit maximální počet instancí, které aplikace používá k horizontálnímu navýšení kapacity. Nejčastěji se jedná o případy, kdy podřízená komponenta, jako je databáze, má omezenou propustnost. Ve výchozím nastavení kapacitu funkcí plánu Consumption navyšují kapacitu až na 200 instancí a funkce plánu Premium se škálují na až 100 instancí. Úpravou hodnoty můžete zadat nižší maximum pro konkrétní aplikaci functionAppScaleLimit . 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ánu 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í funkcí plánu Consumption spuštěných ve Windows 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.

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.

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.

Model fakturace

Fakturace různých plánů je podrobně popsaná na stránce s cenami služby Azure Functions. Využití se agreguje na úrovni aplikace funkcí a počítá pouze čas spuštění kódu funkce. Pro fakturaci jsou uvedené následující jednotky:

  • Spotřeba prostředků v gigabajtových sekundách (GB-s) Vypočítá se jako kombinace velikosti paměti a doby provádění pro všechny funkce v aplikaci funkcí.
  • Provádění. Počítá se při každém spuštění funkce v reakci na trigger události.

Užitečné dotazy a informace o tom, jak porozumět vyúčtování spotřeby, najdete v nejčastějších dotazech k fakturaci.

Další kroky

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