Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Configurazione della concorrenza fornita per una funzione evento

In Lambda, la concorrenza è il numero di richieste in corso che la tua Event Function sta attualmente gestendo. Sono disponibili due tipi di controlli di simultaneità:

In questo argomento viene descritta in dettaglio la modalità gestire e configurare la simultaneità fornita. Per una panoramica concettuale di questi due tipi di controlli della simultaneità, consulta la sezione Simultaneità riservata e simultaneità fornita. Per ulteriori informazioni sulla configurazione della simultaneità riservata, consulta la sezione Configurazione della concorrenza riservata per una funzione evento.

Configurazione della simultaneità fornita

Puoi configurare le impostazioni di concorrenza assegnate per una funzione evento Lambda utilizzando la console Lambda o l'API Lambda.

Puoi configurare fino al valore massimo di Simultaneità dell'account non riservata meno 100. Le restanti 100 unità di concorrenza sono per le funzioni di evento che non utilizzano la concorrenza riservata. Ad esempio, se il tuo account ha un limite di concorrenza di 1.000 e non hai assegnato alcuna concorrenza riservata o fornita a nessuna delle altre tue funzioni evento, puoi configurare un massimo di 900 unità di concorrenza predisposte per una singola funzione evento.

La configurazione della concorrenza fornita per una funzione evento ha un impatto sul pool di concorrenza disponibile per altre funzioni di evento. Ad esempio, se si configurano 100 unità di concorrenza predisposte perfunction-a, le altre funzioni di evento presenti nell'account devono condividere le restanti 900 unità di concorrenza. Ciò vale anche se function-a non utilizza tutte le 100 unità.

È possibile allocare sia la concorrenza riservata che la concorrenza fornita per la stessa funzione evento. In questi casi, la concorrenza fornita non può superare la concorrenza riservata.

Questa limitazione si estende alle versioni di Event Function. La concorrenza massima fornita che è possibile assegnare a una versione specifica della funzione evento è la concorrenza riservata della funzione evento meno la concorrenza fornita nelle altre versioni della funzione evento.

Per configurare la simultaneità fornita con l'API Lambda, utilizza le operazioni dell'API seguenti.

Ad esempio, per configurare la concorrenza fornita con ( AWS Command Line Interface CLI), utilizzate il comando. put-provisioned-concurrency-config Il comando seguente alloca 100 unità di concorrenza assegnata per l'BLUEalias di una funzione evento denominata: my-function

aws lambda put-provisioned-concurrency-config --function-name my-function \
  --qualifier BLUE \
  --provisioned-concurrent-executions 100

L'output restituito dovrebbe essere simile al seguente:

{
  "Requested ProvisionedConcurrentExecutions": 100,
  "Allocated ProvisionedConcurrentExecutions": 0,
  "Status": "IN_PROGRESS",
  "LastModified": "2023-01-21T11:30:00+0000"
}

Stima accurata della concorrenza fornita richiesta per una funzione di evento

È possibile visualizzare le metriche di concorrenza di qualsiasi funzione evento attiva utilizzando le metriche. CloudWatch In particolare, la ConcurrentExecutions metrica mostra il numero di chiamate simultanee per Event Functions nel tuo account.

Il grafico precedente suggerisce che questa funzione evento soddisfa in media da 5 a 10 richieste simultanee in un dato momento e raggiunge un picco di 20 richieste. Supponiamo che nel tuo account siano presenti molte altre funzioni relative agli eventi. Se questa Event Function è fondamentale per la tua applicazione e hai bisogno di una risposta a bassa latenza a ogni chiamata, configura almeno 20 unità di contemporanea predisposta.

Ricorda che puoi anche calcolare la simultaneità utilizzando la seguente formula:

Concurrency = (average requests per second) * (average request duration in seconds)

Per stimare la quantità di simultaneità necessaria, moltiplica le richieste medie al secondo per la durata media delle richieste in secondi. Puoi stimare le richieste medie al secondo utilizzando il parametro Invocation e la durata media delle richieste in secondi utilizzando il parametro Duration.

Quando si configura la concorrenza fornita, Lambda suggerisce di aggiungere un buffer del 10% oltre alla quantità di concorrenza normalmente richiesta dalla funzione evento. Ad esempio, se la funzione evento raggiunge in genere un picco di 200 richieste simultanee, imposta la concorrenza fornita su 220 (200 richieste simultanee + 10% = 220 concorrenza fornita).

Ottimizzazione del codice Event Function quando si utilizza la concorrenza fornita

Se utilizzi la concorrenza fornita, valuta la possibilità di ristrutturare il codice Event Function per ottimizzarlo per una bassa latenza. Per le funzioni evento che utilizzano la concorrenza fornita, Lambda esegue qualsiasi codice di inizializzazione, come il caricamento di librerie e l'istanziazione dei client, durante il tempo di allocazione. Pertanto, è consigliabile spostare il maggior numero di inizializzazioni al di fuori del gestore principale di Event Function per evitare di influire sulla latenza durante le chiamate effettive di Event Function. Al contrario, l'inizializzazione delle librerie o l'istanziazione di client all'interno del codice del gestore principale significa che la Event Function deve eseguirla ogni volta che viene richiamata (ciò avviene indipendentemente dal fatto che si stia utilizzando la concorrenza fornita).

Per le chiamate su richiesta, Lambda potrebbe dover eseguire nuovamente il codice di inizializzazione ogni volta che la Event Function subisce un avvio a freddo. Per tali Event Functions, potresti scegliere di posticipare l'inizializzazione di una funzionalità specifica finché la Event Function non ne abbia bisogno. Ad esempio, considera il seguente flusso di controllo per un gestore Lambda:

def handler(event, context):
    ...
    if ( some_condition ):
        // Initialize CLIENT_A to perform a task
    else:
        // Do nothing

Nell'esempio precedente, invece di inizializzare CLIENT_A all'esterno del gestore principale, lo sviluppatore lo ha inizializzato all'interno dell'istruzione if. In tal modo, Lambda esegue il codice solo se la condizione some_condition è soddisfatta. Se esegui l'inizializzazione di CLIENT_A all'esterno del gestore principale, Lambda esegue quel codice a ogni avvio a freddo. Ciò può aumentare la latenza complessiva.

Puoi misurare le partenze a freddo man mano che Lambda aumenta aggiungendo il X-Ray monitoraggio alla tua Event Function. Una funzione di evento che utilizza la concorrenza fornita non presenta un comportamento di avvio a freddo poiché l'ambiente di esecuzione viene preparato prima della chiamata. Tuttavia, la concorrenza fornita deve essere applicata a una versione o alias specifici di una Event Function, non alla versione $LATEST. Nei casi in cui continui a riscontrare un comportamento di avvio a freddo, assicurati di richiamare la versione dell'alias con provisioned concurrency configurata.

Utilizzo di variabili di ambiente per visualizzare e controllare il comportamento della simultaneità fornita

È possibile che la funzione Event utilizzi tutta la concorrenza fornita. Per gestire il traffico in eccesso, Lambda utilizza istanze on demand. Per determinare il tipo di inizializzazione che Lambda ha utilizzato per un ambiente specifico, controlla il valore della variabile di ambiente AWS_LAMBDA_INITIALIZATION_TYPE.

Questa variabile ammette due valori possibili: provisioned-concurrency o on-demand. Il valore di AWS_LAMBDA_INITIALIZATION_TYPE è immutabile e rimane costante per tutta la durata dell'ambiente. Per verificare il valore di una variabile di ambiente nel codice Event Function, vedi. Recupero delle variabili di ambiente Lambda

Se utilizzi il runtime di.NET 8, puoi configurare la variabile di AWS_LAMBDA_DOTNET_PREJIT ambiente per migliorare la latenza delle Event Functions, anche se non utilizzano la concorrenza assegnata. Il runtime .NET impiega la compilazione e l'inizializzazione lenta per ciascuna libreria a cui il codice effettua la chiamata per la prima volta. Di conseguenza, la prima chiamata di una funzione evento Lambda potrebbe richiedere più tempo rispetto a quelle successive. Per ovviare a questo problema, puoi scegliere tra tre valori per AWS_LAMBDA_DOTNET_PREJIT:

Informazioni sul comportamento di registrazione e fatturazione con la simultaneità fornita

Per gli ambienti di concorrenza con provisioning, il codice di inizializzazione della tua Event Function viene eseguito durante l'allocazione e periodicamente quando Lambda ricicla le istanze del tuo ambiente. Lambda ti fattura l'inizializzazione anche se l'istanza di ambiente non elabora mai una richiesta. La simultaneità fornita viene eseguita continuamente e prevede una fatturazione separata rispetto ai costi di inizializzazione e invocazione. Per maggiori dettagli, consulta Prezzi di AWS Lambda.

Quando configuri una funzione di eventi Lambda con la concorrenza fornita, Lambda preinizializza l'ambiente di esecuzione in modo che sia disponibile prima delle richieste di chiamata. Lambda registra il campo Init Duration della Event Function in un evento di registro Platform-InitReport in formato di registrazione JSON ogni volta che l'ambiente viene inizializzato. Per visualizzare questo evento di registro, configura il livello di registro JSON su almeno. INFO Puoi anche utilizzare l'API di telemetria per utilizzare gli eventi della piattaforma in cui viene riportato il campo Init Duration.

Utilizzo di Application Auto Scaling per automatizzare la gestione della simultaneità fornita

Puoi utilizzare Application Auto Scaling per gestire la simultaneità fornita in base a una pianificazione o all'utilizzo. Se la tua Event Function riceve schemi di traffico prevedibili, utilizza la scalabilità pianificata. Se desideri che la tua Event Function mantenga una percentuale di utilizzo specifica, utilizza una politica di scalabilità mirata al tracciamento.

Dimensionamento pianificato

Con Application Auto Scaling, puoi creare una pianificazione personalizzata in base alle variazioni di carico prevedibili. Per ulteriori informazioni ed esempi, consulta Scheduled scaling for Application Auto Scaling nella Application Auto Scaling User Guide AWS Lambda e Scheduling Provisioned Concurrency per i picchi di utilizzo ricorrenti sul blog di Compute. AWS

Monitoraggio degli obiettivi

Con il tracciamento degli obiettivi, Application Auto Scaling crea e gestisce una serie di CloudWatch allarmi in base alla definizione della politica di scalabilità. Quando questi allarmi si attivano, Application Auto Scaling regola automaticamente la quantità di ambienti allocati utilizzando la simultaneità fornita. Utilizza il monitoraggio degli obiettivi per le applicazioni che non presentano modelli di traffico prevedibili.

Per dimensionare la simultaneità fornita utilizzando il tracciamento degli obiettivi, utilizza le operazioni RegisterScalableTarget e PutScalingPolicy dell'API di Application Auto Scaling. Ad esempio, se utilizzi la AWS Command Line Interface (CLI), segui questi passaggi:

L'output visualizzato dovrebbe essere di questo tipo:

{
    "PolicyARN": "arn:aws:autoscaling:us-east-2:123456789012:scalingPolicy:12266dbb-1524-xmpl-a64e-9a0a34b996fa:resource/lambda/function:my-function:BLUE:policyName/my-policy",
    "Alarms": [
        {
            "AlarmName": "TargetTracking-function:my-function:BLUE-AlarmHigh-aed0e274-xmpl-40fe-8cba-2e78f000c0a7",
            "AlarmARN": "arn:aws:cloudwatch:us-east-2:123456789012:alarm:TargetTracking-function:my-function:BLUE-AlarmHigh-aed0e274-xmpl-40fe-8cba-2e78f000c0a7"
        },
        {
            "AlarmName": "TargetTracking-function:my-function:BLUE-AlarmLow-7e1a928e-xmpl-4d2b-8c01-782321bc6f66",
            "AlarmARN": "arn:aws:cloudwatch:us-east-2:123456789012:alarm:TargetTracking-function:my-function:BLUE-AlarmLow-7e1a928e-xmpl-4d2b-8c01-782321bc6f66"
        }
    ]
}

Application Auto Scaling crea due allarmi. CloudWatch Il primo allarme si attiva quando l'utilizzo della simultaneità fornita supera costantemente il 70%. In questo caso, Application Auto Scaling alloca più simultaneità fornita per ridurre l'utilizzo. Il secondo allarme si attiva quando l'utilizzo è costantemente inferiore al 63% (90% dell'obiettivo del 70%). In questo caso, Application Auto Scaling riduce la simultaneità di provisioning dell'alias.

Nell'esempio seguente, una Event Function varia tra una quantità minima e massima di concorrenza fornita in base all'utilizzo.

Quando il numero di richieste aperte aumenta, Application Auto Scaling aumenta la simultaneità fornita a grandi scaglioni fino a raggiungere il massimo configurato. Dopodiché, la funzione Event può continuare a scalare in base alla concorrenza standard e senza riserve se non hai raggiunto il limite di concorrenza del tuo account. Quando l'utilizzo scende e rimane basso, Application Auto Scaling riduce la simultaneità fornita a piccoli scaglioni periodici.

Entrambi gli allarmi di Application Auto Scaling utilizzano per impostazione predefinita la statistica media. Le funzioni che registrano rapidi picchi di traffico potrebbero non attivare questi allarmi. Ad esempio, supponiamo che la Lambda Event Function venga eseguita rapidamente (ad esempio 20-100 ms) e che il traffico arrivi a raffiche rapide. In tal caso, il numero di richieste supera la simultaneità fornita allocata durante il picco.

Tuttavia, Application Auto Scaling richiede che il burst load si mantenga per almeno 3 minuti per fornire ambienti aggiuntivi. Inoltre, entrambi gli CloudWatch allarmi richiedono 3 punti dati che raggiungano la media target per attivare la politica di auto scaling. Se la tua Event Function registra rapidi picchi di traffico, l'utilizzo della statistica Maximum anziché della statistica Average può essere più efficace nel ridimensionare la concorrenza fornita per ridurre al minimo gli avviamenti a freddo.

Per ulteriori informazioni sulle policy di dimensionamento con monitoraggio degli obiettivi, consulta la sezione Policy di dimensionamento con monitoraggio degli obiettivi per Application Auto Scaling.