Sdílet prostřednictvím

Š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 tato rozšíření vazeb:

Cílové škálování nahrazuje předchozí model přírůstkového škálování služby Azure Functions jako výchozí pro tyto typy rozšíření. Přírůstkové škálování se přidalo nebo odebralo maximálně jeden pracovní proces při každé nové instanci s komplexními rozhodnutími o tom, kdy se má škálovat. Naproti tomu cílové škálování umožňuje vertikálně navýšit kapacitu čtyř instancí najednou a rozhodnutí o škálování je založené na jednoduché cílové rovnici:

Obrázek rovnice: požadované instance = délka zdroje události / cílové spuštění na instanci

V této rovnici odkazuje délka zdroje událostí na počet událostí, které je potřeba zpracovat. Výchozí hodnoty počtu provedení na instanci pocházejí ze sad SDK (Software Development Kit) používané rozšířeními Azure Functions. Pro fungování cílového škálování nemusíte provádět žádné změny.

Důležité informace

Při použití cílového škálování platí následující aspekty:

  • Cílové škálování je ve výchozím nastavení povolené pro aplikace funkcí v plánu Consumption, plánu Flex Consumption a elastických plánech Premium. Škálování řízené událostmi se při spouštění na plánech Dedicated (App Service) nepodporuje.
  • Škálování na základě cílů je ve výchozím nastavení povolené od verze 4.19.0 modulu runtime Služby Functions.
  • Při použití cílového škálování se stále dodržují limity škálování. Další informace najdete v tématu Omezení horizontálního navýšení kapacity.
  • Pokud chcete dosáhnout nejpřesnějšího škálování na základě metrik, použijte pouze jednu cílovou aktivovanou funkci pro každou aplikaci funkcí. Měli byste také zvážit spuštění v plánu Flex Consumption, který nabízí škálování jednotlivých funkcí.
  • Pokud všechny funkce ve stejné aplikaci funkcí požadují horizontální navýšení kapacity najednou, použije se součet těchto funkcí k určení změny v požadovaných instancích. Funkce požadující horizontální navýšení kapacity přepíší funkce, které požadují škálování na více instancí.
  • Pokud existují požadavky horizontálního navýšení kapacity bez jakýchkoli požadavků na horizontální navýšení kapacity, použije se maximální počet požadavků na horizontální navýšení kapacity.

Odhlášení

Škálování na základě cílů je ve výchozím nastavení povolené pro aplikace funkcí hostované v plánu Consumption nebo v plánech Premium. Pokud chcete zakázat cílové škálování a přejít zpět na přírůstkové škálování, přidejte do aplikace funkcí následující nastavení aplikace:

Nastavení aplikace Hodnota
TARGET_BASED_SCALING_ENABLED 0

Přizpůsobení cílového škálování

Chování škálování můžete nastavit více nebo méně agresivně na základě úlohy vaší aplikace úpravou cílových spuštění na instanci. Každé rozšíření má různá nastavení, která můžete použít k nastavení cílových spuštění na instanci.

Tato tabulka shrnuje host.json hodnoty, které se používají pro cílové spuštění na hodnoty instance a výchozí hodnoty:

Rozšíření host.json hodnoty Výchozí hodnota
Event Hubs (rozšíření v5.x+) extensions.eventHubs.maxEventBatchSize 100*
Event Hubs (rozšíření v3.x+) extensions.eventHubs.eventProcessorOptions.maxBatchSize 10
Event Hubs (pokud je definováno) extensions.eventHubs.targetUnprocessedEventThreshold Není k dispozici
Service Bus (rozšíření v5.x+, jednoúčelové volání) extensions.serviceBus.maxConcurrentCalls 16
Service Bus (založené na relacích rozšíření v5.x+, jednoúčelové volání) extensions.serviceBus.maxConcurrentSessions 8
Service Bus (rozšíření v5.x+, dávkové zpracování) extensions.serviceBus.maxMessageBatchSize 1000
Služba Service Bus (Funkce v2.x+, Jednoduché Odesílání) extensions.serviceBus.messageHandlerOptions.maxConcurrentCalls 16
Service Bus (funkce v2.x+, relace single dispatch založené) extensions.serviceBus.sessionHandlerOptions.maxConcurrentSessions 2000
Service Bus (funkce v2.x+, dávkové zpracování) extensions.serviceBus.batchOptions.maxMessageCount 1000
Fronta úložiště extensions.queues.batchSize 16

*Výchozí změna maxEventBatchSize v balíčku verze 6.0.0Microsoft.Azure.WebJobs.Extensions.EventHubs. V dřívějších verzích byla tato hodnota 10.

U některých rozšíření vazeb se cílové spouštění na instanci nastaví pomocí atributu funkce:

Rozšíření Nastavení triggeru funkce Výchozí hodnota
Apache Kafka lagThreshold 1000
Azure Cosmos DB maxItemsPerInvocation 100

Další informace najdete v příkladech konfigurací podporovaných rozšíření.

Plán Premium s povoleným monitorováním škálování modulu runtime

Pokud je monitorování škálování za běhu povolené, samotná rozšíření zpracovávají dynamické škálování, protože řadič škálování nemá přístup ke službám zabezpečeným virtuální sítí. Po povolení monitorování škálování modulu runtime budete muset upgradovat balíčky rozšíření na tyto minimální verze, abyste mohli odemknout funkce škálování založené na cíli:

Název rozšíření Minimální potřebná verze
Apache Kafka 3.9.0
Azure Cosmos DB 4.1.0
Centra událostí 5.2.0
Sběrnice 5.9.0
Fronta úložiště 5.1.0

Podpora dynamické souběžnosti

Cílové škálování zavádí rychlejší škálování a používá výchozí hodnoty pro cílové spouštění na instanci. Pokud používáte Service Bus, fronty úložiště nebo Kafka, můžete také povolit dynamickou souběžnost. V této konfiguraci je hodnota _target execution per instance určena automaticky pomocí funkce dynamického času souběžnosti. Začíná omezenou souběžností a identifikuje nejlepší nastavení v průběhu času.

Podporovaná rozšíření

Způsob konfigurace cílového škálování v souboru host.json závisí na konkrétním typu rozšíření. Tato část obsahuje podrobnosti konfigurace pro rozšíření, která aktuálně podporují cílové škálování.

Fronty a témata služby Service Bus

Rozšíření Service Bus podporuje tři modely spouštění, které IsBatched určují atributy IsSessionsEnabled triggeru služby Service Bus. Výchozí hodnota pro IsBatched a IsSessionsEnabled je false.

Model spuštění IsBatched IsSessionsEnabled Nastavení použité pro cílové spouštění na instanci
Jednoúčelové zpracování false (nepravda) false (nepravda) maxConcurrentCalls
Jednoúčelové zpracování (založené na relacích) false (nepravda) true maxConcurrentSessions
Dávkové zpracování true false (nepravda) maxMessageBatchSize nebo maxMessageCount

Poznámka:

Efektivita škálování: Pro rozšíření Service Bus použijte práva Spravovat u prostředků pro nejúčinnější škálování. S právy naslouchání se škálování vrátí k přírůstkovém škálování, protože délka fronty nebo tématu se nedá použít k informování o rozhodnutích o škálování. Další informace o nastavení práv v zásadách přístupu ke službě Service Bus najdete v tématu Zásady autorizace sdíleného přístupu.

Jednoúčelové zpracování

Každé vyvolání funkce v tomto modelu zpracuje jednu zprávu. Nastavení maxConcurrentCalls řídí provádění cílů na instanci. Konkrétní nastavení závisí na verzi rozšíření Service Bus.

host.json Upravte nastavení maxConcurrentCalls, jako v následujícím příkladu:

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "maxConcurrentCalls": 16
        }
    }
}

Jednoúčelové zpracování (založené na relacích)

Každé vyvolání funkce v tomto modelu zpracuje jednu zprávu. V závislosti na počtu aktivních relací pro vaše téma nebo frontu služby Service Bus ale každá instance zapůjčí jednu nebo více relací. Konkrétní nastavení závisí na verzi rozšíření Service Bus.

host.json Upravte nastavení maxConcurrentSessions tak, aby nastavil cílové spouštění na instanci, jak je znázorněno v následujícím příkladu:

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "maxConcurrentSessions": 8
        }
    }
}

Dávkové zpracování

Každé vyvolání funkce v tomto modelu zpracuje dávku zpráv. Konkrétní nastavení závisí na verzi rozšíření Service Bus.

host.json Upravte nastavení maxMessageBatchSize tak, aby nastavil cílové spouštění na instanci, jak je znázorněno v následujícím příkladu:

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "maxMessageBatchSize": 1000
        }
    }
}

Centra událostí

V případě služby Azure Event Hubs služba Azure Functions škáluje podle počtu nezpracovaných událostí distribuovaných napříč všemi oddíly v centru událostí v seznamu platných počtů instancí. Ve výchozím nastavení host.json jsou atributy používané pro cílové spuštění na instancimaxEventBatchSize a maxBatchSize. Pokud se ale rozhodnete doladit škálování založené na cíli, můžete definovat samostatný parametr targetUnprocessedEventThreshold , který přepíše nastavení cíle na instanci beze změny nastavení dávky. Pokud targetUnprocessedEventThreshold je nastavená hodnota, celkový počet nezpracovaných událostí se vydělí touto hodnotou a určí počet instancí, které se pak zaokrouhlí nahoru na počet instancí pracovního procesu, který vytvoří vyváženou distribuci oddílů.

Výstraha

Nastavení batchCheckpointFrequency výše 1 pro plány hostování podporované cílovým škálováním může způsobit nesprávné chování škálování. Platforma vypočítá nezpracované události jako „aktuální pozice – zaznamenaná pozice“, což může nesprávně indikovat nezpracované zprávy, pokud byly dávky zpracovány, ale ještě nejsou zaznamenány. To brání správnému snížení kapacity, pokud žádné zprávy nezůstanou.

Chování a stabilita škálování

V případě služby Event Hubs můžou časté operace škálování směrem dovnitř a ven aktivovat vyrovnávání oddílů, což vede ke zpoždění zpracování a zvýšení latence. Pokud chcete tento problém zmírnit:

  • Platforma používá předdefinovaný seznam platných počtů pracovníků k usměrňování rozhodování o škálování.
  • Platforma zajišťuje, aby škálování bylo stabilní a záměrné, aby nedocházelo k rušivým změnám přiřazení oddílů.
  • Pokud požadovaný počet pracovníků není v platném seznamu – například 17, systém automaticky vybere nejbližší vyšší platný počet, což je v tomto případě 32. Aby se zabránilo rychlému opakovanému škálování, budou požadavky na zmenšení kapacity omezeny na 3 minuty od posledního navýšení kapacity. Toto zpoždění pomáhá snížit zbytečné vyrovnávání a přispět k zachování efektivity propustnosti.

Platné počty instancí pro službu Event Hubs

Pro každý počet oddílů služby Event Hubs vypočítáme odpovídající seznam platných počtů instancí, abychom zajistili optimální distribuci a efektivní škálování. Tyto počty jsou zvoleny tak, aby dobře odpovídaly požadavkům na dělení a souběžnost:

Počet oddílů Platné počty instancí
1 [1]
2 [1, 2]
4 [1, 2, 4]
8 [1, 2, 3, 4, 8]
10 [1, 2, 3, 4, 5, 10]
16 [1, 2, 3, 4, 5, 6, 8, 16]
32 [1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 16, 32]

Tyto předdefinované počty pomáhají zajistit, aby instance byly co nejrovnoměrněji distribuovány napříč oddíly, což minimalizuje výskyt pracovníků, kteří jsou buď nečinní, nebo přetížení.

Poznámka:

Poznámka: U prémiových a dedikovaných úrovní Event Hub může počet oddílů překročit 32, což umožňuje sestavy s větším počtem platných instancí. Tyto úrovně podporují vyšší propustnost a škálovatelnost a platný seznam počtu pracovníků je odpovídajícím způsobem rozšířen, aby zajistil rovnoměrnou distribuci oddílů centra událostí napříč instancemi. Vzhledem k tomu, že Event Hubs je particionovaná zátěž, počet oddílů v daném Event Hubu je limitem pro maximální počet cílových instancí.

Nastavení služby Event Hubs

Konkrétní nastavení závisí na verzi rozšíření Event Hubs.

host.json Upravte nastavení maxEventBatchSize tak, aby nastavil cílové spouštění na instanci, jak je znázorněno v následujícím příkladu:

{
    "version": "2.0",
    "extensions": {
        "eventHubs": {
            "maxEventBatchSize" : 100
        }
    }
}

Pokud je definován v host.json, targetUnprocessedEventThreshold se používá jako cílové spouštění na instanci místo maxEventBatchSize, jako v následujícím příkladu:

{
    "version": "2.0",
    "extensions": {
        "eventHubs": {
            "targetUnprocessedEventThreshold": 153
        }
    }
}

Fronty služby Storage

U rozšíření úložiště verze 2.x+ upravte host.json nastavení batchSize tak, aby se nastavily cílové spouštění na instanci:

{
    "version": "2.0",
    "extensions": {
        "queues": {
            "batchSize": 16
        }
    }
}

Poznámka:

Efektivita škálování: U rozšíření fronty úložiště se zprávy s časem viditelnosti stále započítávají do délky zdroje událostí pomocí rozhraní API fronty úložiště. To může způsobit nadměrné škálování aplikace funkcí. Zvažte použití naplánovaných zpráv front Service Bus, omezení horizontálního navýšení kapacity nebo použití funkce visibilityTimeout pro vaše řešení.

Azure Cosmos DB

Azure Cosmos DB používá atribut na úrovni funkce. MaxItemsPerInvocation Způsob nastavení tohoto atributu na úrovni funkce závisí na jazyce vaší funkce.

Pro zkompilovanou funkci jazyka C# nastavte MaxItemsPerInvocation v definici triggeru, jak je znázorněno v následujících příkladech pro funkci jazyka C#v procesu:

namespace CosmosDBSamplesV2
{
    public static class CosmosTrigger
    {
        [FunctionName("CosmosTrigger")]
        public static void Run([CosmosDBTrigger(
            databaseName: "ToDoItems",
            collectionName: "Items",
            MaxItemsPerInvocation: 100,
            ConnectionStringSetting = "CosmosDBConnection",
            LeaseCollectionName = "leases",
            CreateLeaseCollectionIfNotExists = true)]IReadOnlyList<Document> documents,
            ILogger log)
        {
            if (documents != null && documents.Count > 0)
            {
                log.LogInformation($"Documents modified: {documents.Count}");
                log.LogInformation($"First document Id: {documents[0].Id}");
            }
        }
    }
}

Poznámka:

Vzhledem k tomu, že Azure Cosmos DB je strukturovaná úloha, počet fyzických oddílů v kontejneru představuje limit pro počet cílových instancí. Další informace o škálování služby Azure Cosmos DB najdete v tématu Fyzické oddíly a vlastnictví zapůjčení.

Apache Kafka

Rozšíření Apache Kafka používá atribut na úrovni funkce. LagThreshold U systému Kafka se počet požadovaných instancí vypočítá na základě celkové prodlevy příjemce dělené nastavením LagThreshold . U dané prodlevy se snížením prahové hodnoty prodlevy zvýší počet požadovaných instancí.

Způsob nastavení tohoto atributu na úrovni funkce závisí na jazyce vaší funkce. Tento příklad nastaví prahovou hodnotu na 100.

Pro zkompilovanou funkci jazyka C# nastavte LagThreshold v definici triggeru, jak je znázorněno v následujících příkladech pro funkci jazyka C# v procesu pro trigger služby Kafka Event Hubs:

[FunctionName("KafkaTrigger")]
public static void Run(
    [KafkaTrigger("BrokerList",
                  "topic",
                  Username = "$ConnectionString",
                  Password = "%EventHubConnectionString%",
                  Protocol = BrokerProtocol.SaslSsl,
                  AuthenticationMode = BrokerAuthenticationMode.Plain,
                  ConsumerGroup = "$Default",
                  LagThreshold = 100)] KafkaEventData<string> kevent, ILogger log)
{            
    log.LogInformation($"C# Kafka trigger function processed a message: {kevent.Value}");
}

Další kroky

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

  • Last updated on