Condividi tramite

Scalabilità basata su destinazione

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. Le esecuzioni di destinazione predefinite per ogni valore di istanza provengono dagli SDK (Software Development Kit) 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 Default Value
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
Coda di archiviazione 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 configurazione dell'istanza vengono impostate usando un attributo di funzione:

Estensione Impostazione del trigger di funzione Default Value
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 il monitoraggio della scalabilità di runtime è abilitato, le estensioni stesse gestiscono il ridimensionamento dinamico perché 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
Coda di archiviazione 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, l'esecuzione _target per valore dell'istanza viene determinata 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

Note

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 all'interno di un elenco di conteggi di istanze valide. 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.

Avvertimento

Impostare batchCheckpointFrequency sopra 1 per i piani di hosting supportati dallo scaling basato su obiettivo può causare un comportamento di ridimensionamento non corretto. La piattaforma calcola gli eventi non elaborati come "posizione corrente - posizione con checkpoint", che potrebbe indicare erroneamente messaggi non elaborati quando i batch sono stati elaborati ma non ancora sottoposti a checkpoint, impedendo il ridimensionamento corretto quando non rimangono messaggi.

Comportamento e stabilità del ridimensionamento

Per Hub eventi, le frequenti operazioni di scalabilità orizzontale e scalabilità orizzontale possono attivare il ribilanciamento delle partizioni, determinando ritardi nell'elaborazione e una maggiore latenza. Per attenuare questo problema:

  • La piattaforma usa un elenco predefinito di conteggi dei ruoli di lavoro validi per guidare le decisioni di ridimensionamento.
  • La piattaforma garantisce che il ridimensionamento sia stabile e intenzionale, evitando modifiche di rilievo alle assegnazioni di partizione.
  • Se il numero di ruoli di lavoro desiderato non è incluso nell'elenco valido, ad esempio 17, il sistema seleziona automaticamente il conteggio valido più grande successivo, che in questo caso è 32. Inoltre, per evitare un rapido ridimensionamento ripetuto, le richieste di scalabilità orizzontale vengono limitate per 3 minuti dopo l'ultima scalabilità verticale. Questo ritardo consente di ridurre il ribilanciamento non necessario e contribuisce a mantenere l'efficienza della velocità effettiva.

Conteggi di istanze validi per Hub eventi

Per ogni numero di partizioni di Hub eventi, viene calcolato un elenco corrispondente di conteggi delle istanze valide per garantire una distribuzione ottimale e una scalabilità efficiente. Questi conteggi vengono scelti per allinearsi bene ai requisiti di partizionamento e concorrenza:

Conteggio partizione Conteggi delle istanze valide
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]

Questi conteggi predefiniti consentono di garantire che le istanze vengano distribuite il più uniformemente possibile tra le partizioni, riducendo al minimo i ruoli di lavoro inattive o di overload.

Note

Nota: per i livelli di hub eventi Premium e Dedicato, il numero di partizioni può superare i 32, consentendo set di conteggi di istanze validi più grandi. Questi livelli supportano una velocità effettiva e una scalabilità più elevate e l'elenco di conteggio dei ruoli di lavoro valido viene esteso di conseguenza per distribuire uniformemente le partizioni dell'hub eventi tra istanze. Inoltre, poiché Hub eventi è un carico di lavoro partizionato, il numero di partizioni nell'hub eventi è il limite per il numero massimo di istanze di destinazione.

Impostazioni di 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
        }
    }
}

Note

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

Note

Poiché Azure Cosmos DB è un carico di lavoro partizionato, il numero di partizioni fisiche nel contenitore è il limite per il numero di istanze di destinazione. 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 altre informazioni, vedere gli articoli seguenti:

  • Last updated on