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

Modalità di ridimensionamento del poller di eventi di Apache Kafka in Lambda

Puoi scegliere tra due modalità di scalabilità degli event poller per Amazon MSK e le mappature delle sorgenti di eventi Apache Kafka autogestite:

On-demand modalità (predefinita)

Quando si crea inizialmente la sorgente di eventi Kafka, Lambda assegna un numero predefinito di poller di eventi per elaborare tutte le partizioni nell'argomento Kafka. Lambda aumenta o diminuisce automaticamente il numero di poller di eventi in base al carico di messaggi.

In un intervallo di un minuto, Lambda valuta il ritardo dell'offset di tutte le partizioni dell'argomento. Se il ritardo dell'offset è troppo alto, lo shard sta ricevendo messaggi più velocemente di quanto Lambda possa elaborarli. Se necessario, Lambda aggiunge o rimuove i poller di eventi dall'argomento. Questo processo di dimensionamento automatico di aggiunta o rimozione dei poller degli eventi avviene entro tre minuti dalla valutazione.

Se la funzione Lambda di destinazione è limitata, Lambda riduce il numero di poller di eventi. Questa operazione riduce il carico di lavoro sulla funzione riducendo il numero di messaggi che i poller di eventi possono recuperare e inviare alla funzione.

Modalità provisioning

Per i carichi di lavoro in cui è necessario ottimizzare il throughput dello strumento di mappatura dell'origine degli eventi, è possibile utilizzare la modalità provisioning. In modalità provisioning, vengono definiti i limiti minimi e massimi per la quantità di poller di eventi assegnati. Questi poller di eventi con provisioning sono dedicati allo strumento di mappatura dell'origine degli eventi e possono gestire picchi di messaggi imprevisti tramite un dimensionamento automatico reattivo. Ti consigliamo di utilizzare la modalità provisioning per i carichi di lavoro Kafka che hanno requisiti di prestazioni rigorosi.

In Lambda, un event poller è un'unità di calcolo con capacità di throughput che variano in base al tipo di origine dell'evento. Per Amazon MSK e Apache Kafka autogestito, ogni poller di eventi può gestire fino al 5% del throughput o fino a 5 chiamate simultanee. MB/sec Ad esempio, se la sorgente dell'evento produce un payload medio di 1 MB e la durata media della funzione è di 1 secondo, un singolo poller di eventi Kafka può supportare 5 throughput e 5 invocazioni Lambda simultanee (supponendo che non vi sia alcuna trasformazione del payload). MB/sec Per Amazon SQS, ogni poller di eventi può gestire fino all'1% del throughput o fino a 10 chiamate simultanee. MB/sec L'utilizzo della modalità provisioned comporta costi aggiuntivi in base all'utilizzo del poller di eventi. Per i dettagli sui prezzi, vedere Prezzi di AWS Lambda.

In modalità provisioning, l'intervallo di valori accettati per il numero minimo di poller di event (MinimumPollers) è compreso tra 1 e 200, inclusi. L'intervallo di valori accettati per il numero massimo di poller di eventi (MaximumPollers) è compreso tra 1 e 2.000, inclusi. MaximumPollers deve essere maggiore o uguale a MinimumPollers. Inoltre, per mantenere l'elaborazione ordinata all'interno delle partizioni, Lambda limita a MaximumPollers il numero di partizioni indicato nell'argomento.

Per ulteriori informazioni sulla scelta dei valori minimi e massimi appropriati di poller di eventi, consulta Best practice.

Puoi configurare la modalità provisioned per la mappatura della sorgente degli eventi Kafka utilizzando la console o l'API Lambda.

È possibile configurare la modalità provisioning a livello di codice utilizzando l'oggetto nel ProvisionedPollerConfig file. EventSourceMappingConfiguration Ad esempio, il seguente comando UpdateEventSourceMapping CLI configura un MinimumPollers valore di 5 e un valore di 100. MaximumPollers

aws lambda update-event-source-mapping \
    --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
    --provisioned-poller-config '{"MinimumPollers": 5, "MaximumPollers": 100}'

Dopo aver configurato la modalità provisioning, puoi osservare l'utilizzo dei poller di eventi per il tuo carico di lavoro monitorando il parametro ProvisionedPollers. Per ulteriori informazioni, consulta Parametri dello strumento di mappatura dell'origine degli eventi.

Per disabilitare la modalità provisioned e tornare alla modalità predefinita (su richiesta), è possibile utilizzare il seguente comando CLI: UpdateEventSourceMapping

aws lambda update-event-source-mapping \
    --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
    --provisioned-poller-config '{}'

Funzionalità avanzate di gestione degli errori e prestazioni

Per le mappature delle sorgenti di eventi Kafka con la modalità provisioned abilitata, puoi configurare funzionalità aggiuntive per migliorare la gestione e le prestazioni degli errori:

Best practice e considerazioni sull'utilizzo della modalità provisioning

La configurazione ottimale dei poller di eventi minimi e massimi per lo strumento di mappatura dell'origine degli eventi dipende dai requisiti delle prestazioni dell'applicazione. Ti consigliamo di iniziare con i poller di eventi minimi di default per definire il profilo delle prestazioni. Modifica la configurazione in base ai modelli di elaborazione dei messaggi osservati e al profilo delle prestazioni desiderato.

Per carichi di lavoro con picchi di traffico e requisiti delle prestazioni rigorosi, aumenta il numero minimo di poller di eventi per gestire picchi improvvisi di messaggi. Per determinare il numero minimo di poller di eventi richiesti, considera i messaggi al secondo del carico di lavoro e la dimensione media del payload e utilizza la capacità effettiva di throughput di un singolo poller di eventi (fino a 5 Mbps) come riferimento.

Per mantenere l'elaborazione ordinata all'interno di uno shard, Lambda limita il numero massimo di poller di eventi al numero di shard nell'argomento. Inoltre, il numero massimo di poller di eventi a cui lo strumento di mappatura dell'origine degli eventi può scalare dipende dalle impostazioni di simultaneità della funzione.

Quando attivi la modalità provisioned, aggiorna le impostazioni di rete per rimuovere gli endpoint VPC e le autorizzazioni associate. AWS PrivateLink

Ottimizzazione dei costi per la modalità Provisioned

Prezzi in modalità provvisoria

La modalità con provisioning viene addebitata in base ai poller di eventi minimi assegnati e ai poller di eventi utilizzati durante la scalabilità automatica. Gli addebiti vengono calcolati utilizzando un'unità di fatturazione denominata Event Poller Unit (EPU). Il pagamento viene calcolato in base al numero e alla durata delle EPU utilizzate, misurati in. Event-Poller-Unit-hours

È possibile utilizzare la modalità Provisioned con un singolo ESM per applicazioni sensibili alle prestazioni oppure è possibile raggruppare più ESM all'interno dello stesso VPC per condividere capacità e costi dell'EPU. Le sezioni seguenti descrivono due funzionalità che consentono di ottimizzare i costi della modalità Provisioned. Per i dettagli sui prezzi, consulta i prezzi di AWS Lambda.

Utilizzo migliorato dell'EPU

Ogni EPU supporta fino a 20 capacità di MB/s throughput per il polling degli eventi e supporta un valore predefinito di 10 poller di eventi. Quando si crea una modalità Provisioned per Kafka ESM impostando i poller minimi e massimi, viene utilizzato un numero minimo di poller per il provisioning delle EPU in base all'impostazione predefinita di 10 poller di eventi per EPU. Tuttavia, ogni event poller può scalare in modo indipendente per supportare fino al 5% MB/s della capacità di throughput, il che potrebbe richiedere una minore densità di event poller su una specifica EPU e può innescare il ridimensionamento delle EPU. Il numero di event poller allocati su un'EPU dipende dalla capacità di calcolo consumata da ciascun event poller. Questo approccio di utilizzo avanzato dell'EPU consente ai poller di eventi con requisiti di throughput variabili di utilizzare la capacità EPU in modo efficace, riducendo i costi per tutti gli ESM.

Raggruppamento ESM

Per ottimizzare ulteriormente i costi della modalità Provisioned, puoi raggruppare più ESM Kafka per condividere la capacità EPU. Con il raggruppamento ESM e l'utilizzo avanzato dell'EPU, puoi ridurre i costi della modalità Provisioned fino al 90% per i carichi di lavoro a bassa produttività rispetto all'esecuzione in modalità ESM singola. Tutti gli ESM che richiedono meno di una capacità EPU traggono vantaggio dal raggruppamento ESM. Questi ESM richiedono in genere un numero minimo di poller di eventi per supportare le loro esigenze di throughput. Grazie a questa funzionalità, puoi adottare la modalità Provisioned per tutti i tuoi carichi di lavoro Kafka e beneficiare di funzionalità come la convalida dello schema, il filtraggio Avro/Protobuf degli eventi, le chiamate a bassa latenza e una migliore gestione degli errori, disponibili solo in modalità Provisioned.

Quando configuri il PollerGroupName parametro con lo stesso valore per più ESM all'interno dello stesso Amazon VPC, tali ESM condividono le risorse EPU anziché richiedere ciascuna una capacità EPU dedicata. È possibile raggruppare fino a 100 ESM per gruppo di poller e aggregare il numero massimo di poller tra tutti gli ESM di un gruppo non può superare i 2000.

Per configurare il raggruppamento ESM (console)

Per configurare il raggruppamento ESM (AWS CLI)

L'esempio seguente crea un ESM con un gruppo di poller denominato: production-app-group

aws lambda create-event-source-mapping \
  --function-name myFunction1 \
  --event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster/abcd1234 \
  --topics topic1 \
  --starting-position LATEST \
  --provisioned-poller-config '{
    "MinimumPollers": 1, 
    "MaximumPollers": 10, 
    "PollerGroupName": "production-app-group"
  }'

Per aggiungere un altro ESM allo stesso gruppo (condividendo la capacità EPU), usa lo stesso: PollerGroupName

aws lambda create-event-source-mapping \
  --function-name myFunction2 \
  --event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster/abcd1234 \
  --topics topic2 \
  --starting-position LATEST \
  --provisioned-poller-config '{
    "MinimumPollers": 1, 
    "MaximumPollers": 10, 
    "PollerGroupName": "production-app-group"
  }'

# Move ESM to a different group
aws lambda update-event-source-mapping \
  --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
  --provisioned-poller-config '{
    "MinimumPollers": 1, 
    "MaximumPollers": 10, 
    "PollerGroupName": "new-group-name"
  }'

# Remove ESM from group (use dedicated resources)
aws lambda update-event-source-mapping \
  --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
  --provisioned-poller-config '{
    "MinimumPollers": 1, 
    "MaximumPollers": 10, 
    "PollerGroupName": ""
  }'

Considerazioni sulla strategia di raggruppamento

Esempio di ottimizzazione dei costi

Considerate uno scenario in cui avete 10 ESM, ciascuno configurato con un poller di eventi e un throughput inferiore a 2: MB/s

Senza raggruppamento:

Con raggruppamento: