Scalabilità basata su destinazione

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

• Apache Kafka
• Azure Cosmos DB
• Hub eventi di Azure
• Archiviazione code di Azure
• bus di servizio di Azure (coda e argomenti)

Il ridimensionamento basato su destinazione sostituisce il modello di scalabilità incrementale precedente Funzioni di Azure come impostazione predefinita per questi tipi di estensione. Il ridimensionamento incrementale ha aggiunto o rimosso un massimo di un ruolo di lavoro a ogni nuova frequenza di istanza, con decisioni complesse relative alla scalabilità. Al contrario, la scalabilità basata 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:

Le esecuzioni di destinazione predefinite per ogni valore di istanza provengono dagli SDK usati dalle estensioni 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:

• La scalabilità basata su destinazione è abilitata per impostazione predefinita per le app per le funzioni nel piano a consumo o per i piani Premium, ma è possibile rifiutare esplicitamente. Il ridimensionamento basato su eventi non è supportato durante l'esecuzione in piani dedicati (servizio app).
• Il ridimensionamento basato su destinazione è abilitato per impostazione predefinita nel runtime dell'app per le funzioni 4.19.0 o versione successiva.
• Quando si usa il ridimensionamento basato su destinazione, l'impostazione del functionAppScaleLimit sito viene comunque rispettata. Per altre informazioni, vedere Limitare la scalabilità 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.
• 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 la scalabilità orizzontale.
• Quando sono presenti richieste di scalabilità orizzontale senza richieste di scalabilità orizzontale, viene usato il valore di scalabilità massima.

Rifiuto esplicito

La scalabilità basata su destinazione è abilitata 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 host.json valori usati per le esecuzioni di destinazione per ogni valore dell'istanza e le impostazioni predefinite:

Estensione	host.json valori	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+, invio singolo)	extensions.serviceBus.maxConcurrentCalls	16
bus di servizio (estensione v5.x+, basate su sessioni a invio singolo)	extensions.serviceBus.maxConcurrentSessions	8
bus di servizio (estensione v5.x+, elaborazione batch)	extensions.serviceBus.maxMessageBatchSize	1000
bus di servizio (Funzioni v2.x+, Invio 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 Microsoft.Azure.WebJobs.Extensions.EventHubs pacchetto. 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 il monitoraggio della scalabilità di runtime è abilitato, 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 di	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 usano bus di servizio, Archiviazione code o Kafka, è anche possibile abilitare la concorrenza dinamica. In questa configurazione, le esecuzioni di destinazione per valore dell'istanza vengono determinate 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 bus di servizio supporta tre modelli di esecuzione, determinati dagli IsBatched attributi e IsSessionsEnabled del trigger di 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 bus di servizio, usare Gestisci diritti sulle risorse per il ridimensionamento più efficiente. Con il ridimensionamento dei diritti di 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 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 bus di servizio.

v5.x+

Modificare l'impostazione host.jsonmaxConcurrentCalls, come nell'esempio seguente:

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

v2.x+

Modificare l'impostazione host.jsonmaxConcurrentCalls in messageHandlerOptions, come nell'esempio seguente:

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "messageHandlerOptions": {
                "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 bus di servizio, ogni istanza esegue il lease di una o più sessioni. L'impostazione specifica dipende dalla versione dell'estensione bus di servizio.

v5.x+

Modificare l'impostazione host.jsonmaxConcurrentSessions per impostare le esecuzioni di destinazione per ogni istanza, come nell'esempio seguente:

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

v2.x+

Modificare l'impostazione host.jsonmaxConcurrentSessions in sessionHandlerOptions per impostare le esecuzioni di destinazione per ogni istanza, come nell'esempio seguente:

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "sessionHandlerOptions": {
                "maxConcurrentSessions": 2000
            }
        }
    }
}

Elaborazione batch

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

v5.x+

Modificare l'impostazione host.jsonmaxMessageBatchSize per impostare le esecuzioni di destinazione per ogni istanza, come nell'esempio seguente:

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

v2.x+

Modificare l'impostazione host.jsonmaxMessageCount in batchOptions per impostare le esecuzioni di destinazione per ogni istanza, come nell'esempio seguente:

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "batchOptions": {
                "maxMessageCount": 1000
            }
        }
    }
}

Hub eventi di

Per Hub eventi di Azure, Funzioni di Azure ridimensiona in base al numero di eventi non elaborati distribuiti in tutte le partizioni nell'hub eventi. Per impostazione predefinita, gli host.json attributi 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.

v5.x+

Modificare l'impostazione host.jsonmaxEventBatchSize 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
        }
    }
}

v3.x+

Per v3.x+ dell'estensione di Hub eventi, modificare l'impostazione host.jsonmaxBatchSize in eventProcessorOptions per impostare le esecuzioni di destinazione per ogni istanza:

{
    "version": "2.0",
    "extensions": {
        "eventHubs": {
            "eventProcessorOptions": {
                "maxBatchSize": 10
            }
        }
    }
}

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

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

Code di archiviazione

Per v2.x+ dell'estensione Archiviazione, modificare l'impostazione host.jsonbatchSize 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. È consigliabile usare le code bus di servizio accodare 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.

C#

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

Java

Esempio Java in sospeso.

Python

Per i linguaggi di Funzioni che usano function.json, il MaxItemsPerInvocation parametro è definito nell'associazione specifica, come in questo esempio di trigger di Azure Cosmos DB

{
    "scriptFile": "main.py",
    "bindings": [
        {
          "type": "cosmosDBTrigger",
          "maxItemsPerInvocation": 100,
          "connection": "MyCosmosDb",
          "leaseContainerName": "leases",
          "containerName": "collectionName",
          "databaseName": "databaseName",
          "leaseDatabaseName": "databaseName",
          "createLeaseContainerIfNotExists": false,
          "startFromBeginning": false,
          "name": "input"
        }
    ]
}

Gli esempi per il modello di programmazione Python v2 non sono ancora disponibili.

JavaScript/PowerShell/TypeScript

Per i linguaggi di Funzioni che usano function.json, il MaxItemsPerInvocation parametro viene definito nell'associazione specifica, come in questo esempio di trigger di Azure Cosmos DB:

{
  "bindings": [
    {
      "type": "cosmosDBTrigger",
      "maxItemsPerInvocation": 100,
      "connection": "MyCosmosDb",
      "leaseContainerName": "leases",
      "containerName": "collectionName",
      "databaseName": "databaseName",
      "leaseDatabaseName": "databaseName",
      "createLeaseContainerIfNotExists": false,
      "startFromBeginning": false,
      "name": "input"
    }
  ]
}

Gli esempi per il modello di programmazione Node.js v4 non sono ancora disponibili.

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.

C#

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

Java

public class KafkaTriggerMany {
    @FunctionName("KafkaTriggerMany")
    public void runMany(
            @KafkaTrigger(
                name = "kafkaTriggerMany",
                topic = "topic",  
                brokerList="%BrokerList%",
                consumerGroup="$Default", 
                username = "$ConnectionString", 
                password = "EventHubConnectionString",
                authenticationMode = BrokerAuthenticationMode.PLAIN,
                protocol = BrokerProtocol.SASLSSL,
                LagThreshold = 100,
                // sslCaLocation = "confluent_cloud_cacert.pem", // Enable this line for windows.
                cardinality = Cardinality.MANY,
                dataType = "string"
             ) String[] kafkaEvents,
            final ExecutionContext context) {
            for (String kevent: kafkaEvents) {
                context.getLogger().info(kevent);
            }

Python

Per i linguaggi di Funzioni che usano function.json, il LagThreshold parametro viene definito nell'associazione specifica, come in questo esempio di trigger di Hub eventi Kafka:

{
      "scriptFile": "main.py",
      "bindings": [
        {
          "type": "kafkaTrigger",
          "name": "kevent",
          "topic": "topic",
          "brokerList": "%BrokerList%",
          "username": "$ConnectionString",
          "password": "EventHubConnectionString",
          "consumerGroup" : "functions",
          "protocol": "saslSsl",
          "authenticationMode": "plain",
          "lagThreshold": "100"
        }
    ]
}

Il modello di programmazione Python v2 non è attualmente supportato dall'estensione Kafka.

JavaScript/PowerShell/TypeScript

Per i linguaggi di Funzioni che usano function.json, il LagThreshold parametro viene definito nell'associazione specifica, come in questo esempio di trigger di Hub eventi Kafka:

{
    "bindings": [
      {
            "type": "kafkaTrigger",
            "name": "kafkaEvent",
            "direction": "in",
            "protocol" : "SASLSSL",
            "password" : "EventHubConnectionString",
            "dataType" : "string",
            "topic" : "topic",
            "authenticationMode" : "PLAIN",
            "consumerGroup" : "$Default",
            "username" : "$ConnectionString",
            "brokerList" : "%BrokerList%",
            "sslCaLocation": "confluent_cloud_cacert.pem",
            "lagThreshold": "100"
        }
    ]
}

Il modello di programmazione Node.js v4 non è attualmente supportato dall'estensione Kafka.

Passaggi successivi

Per ulteriori informazioni, vedere gli articoli seguenti:

• Migliorare le prestazioni e l'affidabilità dei Funzioni di Azure
• Funzioni di Azure'elaborazione affidabile degli eventi