Condividi tramite

Scalabilità basata su destinazione

  • Articolo

Il ridimensionamento basato su destinazione offre un modello di scalabilità rapido e intuitivo per i clienti ed è attualmente supportato per queste estensioni di associazione:

Il ridimensionamento basato su destinazione sostituisce il precedente modello di scalabilità incrementale di Funzioni di Azure come predefinito per questi tipi di estensione. Il ridimensionamento incrementale ha aggiunto o rimosso un massimo di un ruolo di lavoro a ogni nuova frequenzadi istanza, con decisioni complesse relative alla scalabilità. Al contrario, il ridimensionamento basato su destinazione consente di aumentare le istanze di quattro istanze alla volta e la decisione di ridimensionamento si basa su una semplice equazione basata su destinazione:

Illustrazione dell'equazione: istanze desiderate = lunghezza origine evento/esecuzioni di destinazione per ogni istanza.

In questa equazione, la lunghezza dell'origine evento fa riferimento al numero di eventi che devono essere elaborati. I valori delle esecuzioni di destinazione predefinite per ogni istanza provengono dagli SDK usati dalle estensioni di Funzioni di Azure. Non è necessario apportare modifiche per il funzionamento del ridimensionamento basato su destinazione.

Considerazioni

Quando si usa il ridimensionamento basato su destinazione, si applicano le considerazioni seguenti:

  • Il ridimensionamento basato su destinazione è abilitato per impostazione predefinita per le app per le funzioni nel piano a consumo, nel piano a consumo flessibile e nei piani Elastic Premium. Il ridimensionamento basato su eventi non è supportato durante l'esecuzione in piani dedicati (servizio app).
  • Il ridimensionamento basato su destinazione è abilitato per impostazione predefinita a partire dalla versione 4.19.0 del runtime di Funzioni.
  • Quando si usa il ridimensionamento basato su destinazione, i limiti di ridimensionamento vengono comunque rispettati. Per altre informazioni, vedere Limitare il ridimensionamento orizzontale.
  • Per ottenere il ridimensionamento più accurato in base alle metriche, usare una sola funzione attivata in base alla destinazione per ogni app per le funzioni. È consigliabile prendere in considerazione anche l'esecuzione in un piano Flex Consumption, che offre ridimensionamentoper funzione.
  • Quando più funzioni nella stessa app per le funzioni richiedono tutte di aumentare il numero di istanze contemporaneamente, viene usata una somma tra tali funzioni per determinare la modifica nelle istanze desiderate. Funzioni che richiedono l'aumento delle istanze delle funzioni di override che richiedono il ridimensionamento orizzontale.
  • Quando sono presenti richieste di riduzione del numero di istanze senza richieste di scale-out, viene usato il valore di scalabilità massima.

Rifiuto esplicito

Il ridimensionamento basato su destinazione è abilitato per impostazione predefinita per le app per le funzioni ospitate in un piano a consumo o in piani Premium. Per disabilitare il ridimensionamento basato su destinazione e il fallback al ridimensionamento incrementale, aggiungere l'impostazione dell'app seguente all'app per le funzioni:

Impostazione app Valore
TARGET_BASED_SCALING_ENABLED 0

Personalizzazione del ridimensionamento basato su destinazione

È possibile rendere il comportamento di ridimensionamento più o meno aggressivo in base al carico di lavoro dell'app modificando le esecuzioni di destinazione per ogni istanza. Ogni estensione ha impostazioni diverse che è possibile usare per impostare le esecuzioni di destinazione per ogni istanza.

Questa tabella riepiloga i valori host.json usati per il valori delle esecuzioni di destinazione per ogni istanza e i valori predefiniti:

Estensione valori JSON Valore predefinito
Hub eventi (estensione v5.x+) extensions.eventHubs.maxEventBatchSize 100*
Hub eventi (estensione v3.x+) extensions.eventHubs.eventProcessorOptions.maxBatchSize 10
Hub eventi (se definito) extensions.eventHubs.targetUnprocessedEventThreshold n/d
Bus di servizio (estensione v5.x+, dispatch singolo) extensions.serviceBus.maxConcurrentCalls 16
Bus di servizio (estensione v5.x+, sessioni a invio singolo basato) extensions.serviceBus.maxConcurrentSessions 8
Bus di servizio (estensione v5.x+, elaborazione batch) extensions.serviceBus.maxMessageBatchSize 1000
Bus di servizio (Funzioni v2.x+, Dispatch singolo) extensions.serviceBus.messageHandlerOptions.maxConcurrentCalls 16
Bus di servizio (funzioni v2.x+, basate su sessioni a invio singolo) extensions.serviceBus.sessionHandlerOptions.maxConcurrentSessions 2000
Bus di servizio (funzioni v2.x+, elaborazione batch) extensions.serviceBus.batchOptions.maxMessageCount 1000
Archiviazione - Coda extensions.queues.batchSize 16

* L'impostazione predefinita maxEventBatchSize è stata modificata nella versione 6.0.0 del pacchetto Microsoft.Azure.WebJobs.Extensions.EventHubs. Nelle versioni precedenti questo valore era 10.

Per alcune estensioni di associazione, le esecuzioni di destinazione per ogni istanza vengono impostate usando un attributo di funzione:

Estensione Impostazione del trigger di funzione Valore predefinito
Apache Kafka lagThreshold 1000
Azure Cosmos DB maxItemsPerInvocation 100

Per altre informazioni, vedere le configurazioni di esempio per le estensioni supportate.

Piano Premium con monitoraggio della scalabilità di runtime abilitato

Quando è abilitato il monitoraggio della scalabilità di runtime, le estensioni stesse gestiscono il ridimensionamento dinamico. Ciò è dovuto al fatto che il controller di scalabilità non ha accesso ai servizi protetti da una rete virtuale. Dopo aver abilitato il monitoraggio della scalabilità di runtime, è necessario aggiornare i pacchetti di estensione a queste versioni minime per sbloccare la funzionalità di scalabilità aggiuntiva basata su destinazione:

Nome estensione Versione minima necessaria
Apache Kafka 3.9.0
Azure Cosmos DB 4.1.0
Hub eventi 5.2.0
Bus di servizio 5.9.0
Archiviazione - Coda 5.1.0

Supporto della concorrenza dinamica

Il ridimensionamento basato su destinazione introduce un ridimensionamento più rapido e usa le impostazioni predefinite per le esecuzioni di destinazione per ogni istanza. Quando si usa il bus di servizio, le code di archiviazione o Kafka, è anche possibile abilitare la concorrenza dinamica. In questa configurazione, il valore esecuzioni di destinazione dell'istanza viene determinato automaticamente dalla funzionalità di concorrenza dinamica. Inizia con concorrenza limitata e identifica l'impostazione migliore nel tempo.

Estensioni supportate

Il modo in cui si configura il ridimensionamento basato su destinazione nel file host.json dipende dal tipo di estensione specifico. In questa sezione vengono forniti i dettagli di configurazione per le estensioni che supportano attualmente il ridimensionamento basato su destinazione.

Code e argomenti del bus di servizio

L'estensione del bus di servizio supporta tre modelli di esecuzione, determinati dagli attributi IsBatched e IsSessionsEnabled del trigger del bus di servizio. Il valore predefinito per IsBatched e IsSessionsEnabled è false.

Modello di esecuzione IsBatched IsSessionsEnabled Impostazione utilizzata per le esecuzioni di destinazione per ogni istanza
Elaborazione a invio singolo false false maxConcurrentCalls
Elaborazione a invio singolo (basata su sessione) false true maxConcurrentSessions
Elaborazione batch true false maxMessageBatchSize o maxMessageCount

Nota

Efficienza della scalabilità: per l'estensione del bus di servizio, usare Gestire i diritti per le risorse per il ridimensionamento più efficiente. Con il ridimensionamento dei diritti di essere in ascolto viene ripristinato il ridimensionamento incrementale perché la lunghezza della coda o dell'argomento non può essere usata per informare le decisioni di ridimensionamento. Per altre informazioni sull'impostazione dei diritti nei criteri di accesso al bus di servizio, vedere Criteri di autorizzazione di accesso condiviso.

Elaborazione a invio singolo

In questo modello ogni chiamata della funzione elabora un singolo messaggio. L'impostazione maxConcurrentCalls regola le esecuzioni di destinazione per ogni istanza. L'impostazione specifica dipende dalla versione dell'estensione del bus di servizio.

Modificare host.json dell’impostazione maxConcurrentCalls, come nell'esempio seguente:

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

Elaborazione a invio singolo (basata su sessione)

In questo modello ogni chiamata della funzione elabora un singolo messaggio. Tuttavia, a seconda del numero di sessioni attive per l'argomento o la coda del bus di servizio, ogni istanza esegue il lease di una o più sessioni. L'impostazione specifica dipende dalla versione dell'estensione del bus di servizio.

Modificare host.json dell'impostazione maxConcurrentSessions per impostare le esecuzioni di destinazione per ogni istanza, come nell'esempio seguente:

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

Elaborazione batch

In questo modello ogni chiamata della funzione elabora un batch di messaggi. L'impostazione specifica dipende dalla versione dell'estensione del bus di servizio.

Modificare host.json dell'impostazione maxMessageBatchSize per impostare le esecuzioni di destinazione per ogni istanza, come nell'esempio seguente:

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

Hub eventi

Per Hub eventi di Azure, Funzioni di Azure viene ridimensionato in base al numero di eventi non elaborati distribuiti in tutte le partizioni nell'hub eventi. Per impostazione predefinita, gli attributi di host.json usati per le esecuzioni di destinazione per ogni istanza sono maxEventBatchSize e maxBatchSize. Tuttavia, se si sceglie di ottimizzare il ridimensionamento basato su destinazione, è possibile definire un parametro targetUnprocessedEventThreshold separato che esegue l'override per impostare le esecuzioni di destinazione per ogni istanza senza modificare le impostazioni batch. Se targetUnprocessedEventThreshold è impostato, il numero totale di eventi non elaborati viene diviso per questo valore per determinare il numero di istanze, che viene quindi arrotondato a un numero di istanze di lavoro che crea una distribuzione di partizione bilanciata.

Nota

Poiché Hub eventi è un carico di lavoro partizionato, il numero di istanze di destinazione per Hub eventi è limitato dal numero di partizioni nell'hub eventi.

L'impostazione specifica dipende dalla versione dell'estensione di Hub eventi.

Modificare host.json dell'impostazione maxEventBatchSize per impostare le esecuzioni di destinazione per ogni istanza, come nell'esempio seguente:

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

Se definito in host.json, targetUnprocessedEventThreshold viene usato come esecuzioni di destinazione per ogni istanza invece di maxEventBatchSize, come nell'esempio seguente:

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

Code di archiviazione

Per v2.x+ dell'estensione Archiviazione, modificare host.json dell'impostazione batchSize per impostare le esecuzioni di destinazione per ogni istanza:

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

Nota

Efficienza della scalabilità: per l'estensione della coda di archiviazione, i messaggi con visibilityTimeout vengono ancora conteggiati nella lunghezza dell'origine evento dalle API della coda di archiviazione. Ciò può causare l'overscaling dell'app per le funzioni. Prendere in considerazione l'uso delle code del bus di servizio per i messaggi pianificati, limitare la scalabilità orizzontale o non usare visibilityTimeout per la soluzione.

Azure Cosmos DB

Azure Cosmos DB usa un attributo a livello di funzione, MaxItemsPerInvocation. Il modo in cui si imposta questo attributo a livello di funzione dipende dal linguaggio di funzione.

Per una funzione C# compilata, impostare MaxItemsPerInvocation nella definizione del trigger, come illustrato negli esempi seguenti per una funzione C# in-process:

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}");
            }
        }
    }
}

Nota

Poiché Azure Cosmos DB è un carico di lavoro partizionato, il numero di istanze di destinazione per il database è limitato dal numero di partizioni fisiche nel contenitore. Per altre informazioni sul ridimensionamento di Azure Cosmos DB, vedere Partizioni fisiche e proprietà del lease.

Apache Kafka

L'estensione Apache Kafka usa un attributo a livello di funzione, LagThreshold. Per Kafka, il numero di istanze desiderate viene calcolato in base al ritardo totale del consumer diviso per l'impostazione LagThreshold . Per un determinato ritardo, la riduzione della soglia di ritardo aumenta il numero di istanze desiderate.

Il modo in cui si imposta questo attributo a livello di funzione dipende dal linguaggio di funzione. In questo esempio la soglia viene impostata su 100.

Per una funzione C# compilata, impostare LagThreshold nella definizione del trigger, come illustrato negli esempi seguenti per una funzione C# in-process per un trigger di Hub eventi Kafka:

[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}");
}

Passaggi successivi

Per ulteriori informazioni, vedere gli articoli seguenti: