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

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. Instanční objekt hostitele podporuje celou aplikační funkci. Proto se všechny funkce v aplikaci funkcí, které sdílejí prostředky v instanci, škálují současně. Když funkční aplikace sdílejí stejný plán Consumption, přesto se škálují nezávisle.

  • Plán Flex Consumption: Tento plán používá deterministickou škálovací strategii na úrovni jednotlivých funkcí. Každá funkce se škáluje nezávisle, s výjimkou funkcí spuštěných HTTP, Blob a funkcemi Durable Functions, 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í, zda má být škálováno ven nebo dovnitř. 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 škálování aplikace funkcí jsou přiděleny další prostředky pro spuštění více instancí hostu 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 postupně škáluje dolů, když v aplikaci funkcí neběží žádné funkce.

Diagram znázorňující události monitorování kontroleru škálování a vytváření instancí

Zahájení za studena

Pokud se vaše funkční aplikace na několik minut stane nečinnou, může se platforma rozhodnout zmenšit počet instancí, na kterých 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í typu funkce může mít vliv na 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 studené starty ovlivňují vaše funkce, zvažte použití jiného plánu než Consumption. Ostatní plány nabízejí tyto strategie pro zmírnění nebo eliminaci studeného startu:

  • Plán Premium: podporuje jak předem spuštěné 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 nedokáže dynamicky škálovat, ale aplikaci můžete spouštět nepřetržitě, pokud je povoleno nastavení Always on.

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žší maximum pro 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í. V současné době se tato metoda škálování 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ů spouštěčů se škáluje společně jako skupina na stejných instancích. Podobně i triggery všech Durable Functions sdílejí instance a společně se škálují. 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. Toto omezení je nejběžnější v případech, 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 1nejnižší 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.

Maximální počet instancí aplikací Flex Consumption můžete změnit až na 1000, ale před dosažením tohoto čísla dosáhnete limitu kvóty pro vaše aplikace. Další informace naleznete v kvótách paměti regionální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-account <STORAGE_ACCOUNT_NAME> --runtime <LANGUAGE_RUNTIME> --runtime-version <RUNTIME_VERSION> --flexconsumption-location <REGION> --maximum-instance-count 200

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

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

Plány Spotřeba/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 na 0 pro neomezenou hodnotu nebo na platnou hodnotu mezi null a maximální hodnotou aplikace.

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. Toto se snižuje vyprázdněním aktuálně probíhajícího spuštění jejich funkcí a následným odebráním těchto instancí. Toto chování se protokoluje jako režim vyprázdnění. Období odkladu pro funkce, které se aktuálně spouštějí, se může prodloužit až o 10 minut pro aplikace spotřebního plánu a až o 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í shrinkování platí následující úvahy:

  • U aplikací běžících ve Windows v plánu Consumption mají ve výchozím nastavení povolené chování režimu 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ý tím, že implementuje chování škálování pro každou jednotlivou funkci. 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 aplikaci funkcí hostované plánem Flex Consumption, který má následující funkce:

function1 function2 function3 function4 function5 function6 funkce7
HTTP spouštěč HTTP spouštěč Spouštěč orchestrace (Durable) Spouštěč aktivity (Durable) Trigger pro Service Bus Trigger pro Service Bus Trigger služby Event Hubs

V tomto příkladu:

  • Obě funkce aktivované protokolem HTTP (function1 a function2) se spouštějí společně na vlastních instancích a škálují se společně podle nastavení souběžnosti HTTP.
  • Obě Durable funkce (function3 a function4) se spouští společně na vlastních instancích a škálují se společně na základě nakonfigurovaných omezení pro řízení souběžnosti.
  • Funkce spuštěná function5 službou Service Bus běží samostatně a je škálována nezávisle podle cílených pravidel škálování pro fronty a témata služby Service Bus.
  • Funkce spuštěná function6 službou Service Bus běží samostatně a je škálována nezávisle podle cílených pravidel škálování pro fronty a témata služby Service Bus.
  • Trigger služby Event Hubs function7 běží ve svých vlastních instancích a škáluje se nezávisle podle pravidel škálování v závislosti na cíli služby Event Hubs.

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

Existuje mnoho aspektů funkční aplikace, které ovlivňují její škálování, včetně konfigurace hostitele, nároků 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.jsnajdete v části Věnované škálování a výkonupříručky pro vývojáře v Azure Functions v Pythonu a v části Škálování a souběžnostv příručce pro vývojáře azure Functions Node.js.

Další kroky

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

  • Last updated on