Škálování na základě cílů

  • Článek

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 následující rozšíření:

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:

Illustration of the equation: desired instances = event source length / target executions per instance.

Výchozí cílové spouštění na hodnoty instancí pocházejí ze sad SDK používaných 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:

  • Škálování na základě cílů je ve výchozím nastavení povolené pro aplikace funkcí v plánu Consumption nebo pro plány Premium, ale můžete se odhlásit. Š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íle je ve výchozím nastavení povolené v modulu runtime aplikace funkcí 4.19.0 nebo novější verzi.
  • Při použití cílového škálování functionAppScaleLimit se nastavení webu stále respektuje. 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í.
  • 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
Service Bus (Functions v2.x+, Single Dispatch) 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é spuš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 povolené monitorování škálování modulu runtime, rozšíření sama zpracovávají dynamické škálování. Důvodem je to, ž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
Event Hubs 5.2.0
Service Bus 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 se cílové spouštění na hodnotu instance určuje automaticky funkcí dynamické 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í. Pokud se škálování naslouchací práva 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
        }
    }
}

Event Hubs

Pro Službu Azure Event Hubs se Služba Azure Functions škáluje na základě počtu nezpracovaných událostí distribuovaných napříč všemi oddíly v centru událostí. 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ů.

Poznámka:

Vzhledem k tomu, že služba Event Hubs je dělená úloha, počet cílových instancí služby Event Hubs je omezený počtem oddílů ve vašem centru událostí.

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 rozdělená úloha, počet cílových instancí databáze je omezený počtem fyzických oddílů v kontejneru. 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: