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à.

Node.js runtime per le istanze gestite Lambda

Per i Node.js runtime, Lambda Managed Instances utilizza thread di lavoro con esecuzione await basata suasync/per gestire le richieste simultanee. L'inizializzazione della funzione avviene una volta per thread di lavoro. Le chiamate simultanee vengono gestite su due dimensioni: i thread di lavoro forniscono il parallelismo tra le vCPU e l'esecuzione asincrona fornisce la concorrenza all'interno di ciascun thread. Ogni richiesta simultanea gestita dallo stesso thread di lavoro condivide lo stesso oggetto gestore e lo stesso stato globale, richiedendo una gestione sicura in caso di più richieste simultanee.

Simultaneità massima

Il numero massimo di richieste simultanee che Lambda invia a ciascun ambiente di esecuzione è controllato dall'impostazione nella configurazione della PerExecutionEnvironmentMaxConcurrency funzione. Questa è un'impostazione opzionale e il valore predefinito varia a seconda del runtime. Per i Node.js runtime, l'impostazione predefinita è 64 richieste simultanee per vCPU, oppure è possibile configurare un valore personalizzato. Lambda regola automaticamente il numero di richieste simultanee fino al numero massimo configurato in base alla capacità di ciascun ambiente di esecuzione di assorbire tali richieste.

Infatti Node.js, il numero di richieste simultanee che ogni ambiente di esecuzione può elaborare è determinato dal numero di thread di lavoro e dalla capacità di ciascun thread di lavoro di elaborare le richieste simultanee in modo asincrono. Il numero predefinito di thread di lavoro è determinato dal numero di vCPU disponibili oppure è possibile configurare il numero di thread di lavoro impostando la variabile di ambiente. AWS_LAMBDA_NODEJS_WORKER_COUNT Si consiglia di utilizzare gestori di funzioni asincroni poiché ciò consente l'elaborazione di più richieste per thread di lavoro. Se il gestore di funzioni è sincrono, ogni thread di lavoro può elaborare una sola richiesta alla volta.

Creazione di funzioni per la multi-concorrenza

Con un gestore di funzioni asincrone, ogni runtime worker elabora più richieste contemporaneamente. Gli oggetti globali sono condivisi tra più richieste simultanee. Per gli oggetti mutabili, evita di utilizzare lo stato o l'uso globali. AsyncLocalStorage

AWS I client SDK sono asincroni e non richiedono una gestione speciale.

Esempio: stato globale

Il codice seguente utilizza un oggetto globale che è mutato all'interno del gestore della funzione. Questo non è asincrono.

let state = {
    currentUser: null,
    requestData: null
};

export const handler = async (event, context) => {
    state.currentUser = event.userId;
    state.requestData = event.data;

    await processData(state.requestData);

    // state.currentUser might now belong to a different request
    return { user: state.currentUser };
};

L'inizializzazione dell'stateoggetto all'interno del gestore di funzioni evita lo stato globale condiviso.

export const handler = async (event, context) => {
    let state = {
        currentUser: event.userId,
        requestData: event.data
    };
    
    await processData(state.requestData);

    return { user: state.currentUser };
};

Esempio: connessioni al database

Il codice seguente utilizza un oggetto client condiviso condiviso tra più invocazioni. A seconda della libreria di connessione utilizzata, questa potrebbe non essere sicura per la concorrenza.

const { Client } = require('pg');

// Single connection created at init time
const client = new Client({
  host: process.env.DB_HOST,
  database: process.env.DB_NAME,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD
});

// Connect once during cold start
client.connect();

exports.handler = async (event) => {
  // Multiple parallel invocations share this single connection = BAD
  // With multi-concurrent Lambda, queries will collide
  const result = await client.query('SELECT * FROM users WHERE id = $1', [event.userId]);
  
  return {
    statusCode: 200,
    body: JSON.stringify(result.rows[0])
  };
};

Un approccio sicuro per la concorrenza consiste nell'utilizzare un pool di connessioni. Il pool utilizza una connessione separata per ogni interrogazione simultanea del database.

const { Pool } = require('pg');

// Connection pool created at init time
const pool = new Pool({
  host: process.env.DB_HOST,
  database: process.env.DB_NAME,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  max: 20,  // Max connections in pool
  idleTimeoutMillis: 30000,
  connectionTimeoutMillis: 2000
});

exports.handler = async (event) => {
  // Pool gives each parallel invocation its own connection
  const result = await pool.query('SELECT * FROM users WHERE id = $1', [event.userId]);
  
  return {
    statusCode: 200,
    body: JSON.stringify(result.rows[0])
  };
};

Node.js 22 gestori basati su callback

Quando si utilizza Node.js 22, non è possibile utilizzare un gestore di funzioni basato su callback con Lambda Managed Instances. Callback-based i gestori sono supportati solo per le funzioni Lambda (predefinite). Per i runtime Node.js 24 e successivi, i gestori di funzioni basati su callback sono obsoleti sia per le istanze Lambda (impostazione predefinita) che per le istanze gestite Lambda.

Utilizza invece un gestore di funzioni quando usi Lambda Managed Instances. async Per ulteriori informazioni, consulta Define Lambda function handler in. Node.js

Directory /tmp condivisa

La /tmp directory è condivisa tra tutte le richieste simultanee nell'ambiente di esecuzione. Le scritture simultanee sullo stesso file possono causare il danneggiamento dei dati, ad esempio se un altro processo sovrascrive il file. Per risolvere questo problema, implementa il blocco dei file condivisi o utilizza nomi di file univoci per richiesta per evitare conflitti. Ricordati di pulire i file non necessari per evitare di esaurire lo spazio disponibile.

Registrazione dei log

L'interlacciamento dei log (voci di log provenienti da richieste diverse che vengono interlacciate nei log) è normale nei sistemi con più concorrenti. Le funzioni che utilizzano Lambda Managed Instances utilizzano sempre il formato di registro JSON strutturato introdotto con controlli di registrazione avanzati. Configurazione dei controlli di registrazione avanzati per le funzioni Lambda Questo formato include ilrequestId, che consente di correlare le voci di registro a una singola richiesta. Quando si utilizza il console logger, requestId viene automaticamente incluso in ogni voce di registro. Per ulteriori informazioni, vedereUtilizzo dei controlli di registrazione avanzati Lambda con Node.js.

Le librerie di registrazione di terze parti più diffuse, come Winston, in genere includono il supporto per l'utilizzo della console per l'output dei log.

Contesto della richiesta

L'utilizzo context.awsRequestId fornisce un accesso asincrono sicuro all'ID della richiesta corrente.

Utilizzare context.xRayTraceId per accedere all'ID di traccia. X-Ray Ciò fornisce un accesso sicuro in caso di concorrenza all'ID di traccia per la richiesta corrente. Lambda non supporta la variabile di _X_AMZN_TRACE_ID ambiente con Lambda Managed Instances. L'ID di X-Ray traccia viene propagato automaticamente quando si utilizza l'SDK. AWS

Utilizzato context.getRemainingTimeInMillis() per rilevare i timeout. Per ulteriori informazioni, consulta Gestione e ripristino degli errori.

Esempio: gestione dei timeout

Controlla il tempo rimanente prima di ogni unità di lavoro e interrompi l'elaborazione prima che scada il timeout. Configura in BUFFER_MS base alla durata prevista della prossima parte di lavoro.

const BUFFER_MS = 2000; // Configure based on your next chunk of work

exports.handler = async (event, context) => {
    for (const item of event.items) {
        if (context.getRemainingTimeInMillis() < BUFFER_MS)
            return { statusCode: 206, body: "Timeout approaching, stopping early" };
        await processItem(item);
    }
    return { statusCode: 200, body: "Done" };
};

Esempio: propagazione delle scadenze alle chiamate a valle

Quando effettui chiamate ai servizi downstream, propaga il tempo rimanente sotto forma di timeout per evitare il blocco delle chiamate di rete che sopravviverebbero alla chiamata:

const { S3Client, GetObjectCommand } = require("@aws-sdk/client-s3");
const client = new S3Client({});

exports.handler = async (event, context) => {
    const timeout = Math.max(1000, context.getRemainingTimeInMillis() - 500);
    const response = await client.send(
        new GetObjectCommand({ Bucket: "my-bucket", Key: "my-key" }),
        { abortSignal: AbortSignal.timeout(timeout) }
    );
    return { statusCode: 200, body: "Done" };
};

Inizializzazione e arresto

L'inizializzazione della funzione avviene una volta per thread di lavoro. Potresti visualizzare voci di registro ripetute se la tua funzione emette log durante l'inizializzazione.

Per le funzioni Lambda con estensioni, l'ambiente di esecuzione emette un segnale SIGTERM durante l'arresto. Questo segnale viene utilizzato dalle estensioni per attivare attività di pulizia, come lo svuotamento dei buffer. Le funzioni Lambda (predefinite) con estensioni possono anche sottoscrivere il segnale SIGTERM utilizzando. process.on() Questo non è supportato per le funzioni che utilizzano Lambda Managed Instances poiché process.on() non può essere utilizzato con thread di lavoro. Per ulteriori informazioni sul ciclo di vita dell'ambiente di esecuzione, consulta Comprendere il ciclo di vita dell’ambiente di esecuzione Lambda.

Versioni di dipendenza

Lambda Managed Instances richiede le seguenti versioni minime del pacchetto:

Powertools per AWS Lambda () TypeScript

Powertools for AWS Lambda (TypeScript) è compatibile con Lambda Managed Instances e fornisce utilità per la registrazione, la traccia, le metriche e altro ancora. Per ulteriori informazioni, vedere Powertools for Lambda (). AWS TypeScript

Fasi successive