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 ridimensionamento dei poller degli eventi per Amazon MSK e mappature delle sorgenti di eventi Apache Kafka autogestite:

Modalità on-demand (impostazione predefinita)

Quando crei inizialmente l'origine degli eventi Kafka, Lambda assegna un numero predefinito di poller di eventi per elaborare tutte le partizioni nell'argomento Kafka. Lambda aumenta o riduce automaticamente il numero di sondaggi di eventi in base al caricamento dei 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 funzionalità di throughput che variano in base al tipo di origine dell'evento. Per Amazon MSK e Apache Kafka autogestito, ogni event poller può gestire fino al 5% MB/sec del throughput o fino a 5 chiamate simultanee. Ad esempio, se la fonte dell'evento produce un payload medio di 1 MB e la durata media della funzione è di 1 secondo, un singolo event poller di eventi Kafka può supportare 5 MB/sec velocità effettiva e 5 chiamate Lambda simultanee (presupponendo che non vi sia alcuna trasformazione del payload). Per Amazon SQS, ogni event poller può gestire fino all'1% MB/sec del throughput o fino a 10 chiamate simultanee. L'utilizzo della modalità provisioned comporta costi aggiuntivi in base all'utilizzo dell'event poller. 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à di provisioning per la mappatura delle sorgenti degli eventi Kafka utilizzando la console o l'API Lambda.

È possibile configurare la modalità di provisioning a livello di codice utilizzando l'ProvisionedPollerConfigoggetto presente in. EventSourceMappingConfiguration Ad esempio, il seguente comando UpdateEventSourceMappingCLI configura un MinimumPollers valore di 5 e un MaximumPollers valore di 100.

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à provisioning e tornare alla modalità predefinita (su richiesta), puoi 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à provisioning 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 i poller di eventi minimi richiesti, considerate i messaggi al secondo del carico di lavoro e la dimensione media del payload e utilizzate la capacità di throughput di un singolo event poller (fino a 5) come riferimento. MBps

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 AWS PrivateLink VPC e le autorizzazioni associate.

Ottimizzazione dei costi per la modalità Provisioned

Prezzi in modalità provisioned

La modalità Provisioned viene addebitata in base ai poller di eventi minimi forniti e ai poller di eventi utilizzati durante la scalabilità automatica. Gli addebiti vengono calcolati utilizzando un'unità di fatturazione denominata Event Poller Unit (EPU). Si paga in base al numero e alla durata dell' EPUs utilizzo, misurati in. Event-Poller-Unit-hours È possibile utilizzare la modalità Provisioned con un singolo ESM per applicazioni sensibili alle prestazioni oppure è possibile raggrupparne più di uno all'interno dello stesso VPC per condividere ESMs la capacità e i costi dell'EPU. Approfondiremo due funzionalità che ti aiutano a 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 un numero minimo e massimo di poller, viene utilizzato il numero minimo di poller per il provisioning EPUs in base all'impostazione predefinita di 10 poller di eventi per EPU. Tuttavia, ogni event poller può scalare in modo indipendente fino a 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 innescare la scalabilità di. EPUs Il numero di event poller allocati su un'EPU dipende dalla capacità di calcolo consumata da ciascun event poller. Questo approccio di utilizzo migliorato dell'EPU consente ai poller di eventi con requisiti di throughput diversi di utilizzare la capacità dell'EPU in modo efficace, riducendo i costi per tutti. ESMs

Raggruppamento ESM

Per ottimizzare ulteriormente i costi della modalità Provisioned, è possibile raggruppare più sistemi Kafka ESMs per condividere la capacità EPU. Con il raggruppamento ESM e l'utilizzo avanzato dell'EPU, è possibile ridurre i costi della modalità Provisioned fino al 90% per carichi di lavoro a basso throughput rispetto all'esecuzione in modalità ESM singola. Tutto ciò ESMs che richiede meno di 1 capacità EPU trarrà vantaggio dal raggruppamento ESM. Ciò richiede ESMs in genere un numero minimo di event poller per supportare le proprie esigenze di throughput. Questa funzionalità ti consentirà di adottare la modalità Provisioned per tutti i tuoi carichi di lavoro Kafka e di beneficiare di funzionalità come la convalida dello schema, il filtraggio Avro/Protobuf degli eventi, le chiamate a bassa latenza e la gestione avanzata degli errori disponibili solo in modalità Provisioned.

Quando configuri il PollerGroupName parametro con lo stesso valore per più utenti ESMs all'interno dello stesso Amazon VPC, questi ESMs condividono le risorse EPU anziché richiedere una capacità EPU dedicata. Puoi raggruppare fino a 100 ESMs per gruppo di poller e il numero massimo di poller aggregato per tutti ESMs i membri di un gruppo non può superare i 2000.

Per configurare il raggruppamento ESM (console)

Per configurare il raggruppamento ESM (CLI AWS )

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 ne avete 10 ESMs, ciascuno configurato con 1 event poller e un throughput inferiore a 2 MB/s:

Senza raggruppamento:

Con raggruppamento: