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:
+ [On-demand modalità (predefinita)](#kafka-default-mode)
+ [Modalità provisioning](#kafka-provisioned-mode)
## On-demand modalità (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 diminuisce automaticamente il numero di [poller di eventi](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode) 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 Event Function target è limitata, Lambda riduce il numero di event poller. 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](https://aws.amazon.com/lambda/pricing/).
**Nota**
Quando si utilizza la modalità provisioned, non è necessario creare endpoint AWS PrivateLink VPC o concedere le autorizzazioni associate come parte della configurazione di rete.
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](#kafka-provisioned-mode-bp).
Puoi configurare la modalità provisioning per la mappatura delle sorgenti degli eventi Kafka utilizzando la console o l'API Lambda.
**Per configurare la modalità provisioning per una mappatura delle sorgenti di eventi esistente (console)**
1. Apri la [pagina Event Functions](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegli la funzione con la mappatura delle sorgenti degli eventi per cui desideri configurare la modalità provisioned.
1. Scegli la scheda **Configurazione**, quindi scegli **Trigger**.
1. **Scegli la mappatura delle sorgenti degli eventi per cui desideri configurare la modalità di provisioning, quindi scegli Modifica.**
1. **In **modalità Provisioned**, seleziona Configura.**
+ Per **Numero minimo di poller di eventi**, inserisci un valore compreso tra 1 e 200. Se non si specifica un valore, Lambda assegna il valore predefinito 1.
+ Per **Numero massimo di poller di eventi**, inserisci un valore compreso tra 1 e 2.000. Questo valore deve essere maggiore o uguale al valore specificato in **Numero minimo di poller di eventi**. Se non si specifica un valore, Lambda assegna il valore predefinito 200.
1. Selezionare **Salva**.
È possibile configurare la modalità di provisioning a livello di codice utilizzando l'oggetto presente nel [ProvisionedPollerConfig](https://docs.aws.amazon.com/lambda/latest/api/API_ProvisionedPollerConfig.html)file. [ EventSourceMappingConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_EventSourceMappingConfiguration.html) Ad esempio, il seguente comando [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)CLI 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](monitoring-metrics-types.md#event-source-mapping-metrics).
Per disabilitare la modalità provisioning e tornare alla modalità predefinita (su richiesta), puoi utilizzare il seguente comando CLI [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html):
```
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:
+ [Configurazioni di](kafka-retry-configurations.md) nuovi tentativi: controlla il modo in cui Lambda gestisce i record non riusciti con il numero massimo di tentativi di ripetizione, limiti di età dei record, suddivisione in batch e risposte batch parziali.
+ [Destinazioni Kafka in caso di errore: invia i](kafka-on-failure-destination.md) record non riusciti a un argomento di Kafka per elaborarli o analizzarli in un secondo momento.
## 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 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). Paghi in base al numero e alla durata delle EPU utilizzate, misurate 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 la capacità e i costi dell'EPU. Le sezioni seguenti descrivono due funzionalità che aiutano a ottimizzare i costi della modalità Provisioned. Per i dettagli sui prezzi, consulta i prezzi di [AWS Lambda](https://aws.amazon.com/lambda/pricing/).
### 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 fornire le EPU 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 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 migliorato dell'EPU consente ai poller di eventi con requisiti di throughput diversi 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, è possibile raggruppare più Kafka ESM 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. Tutti gli ESM che richiedono meno di 1 capacità EPU traggono vantaggio dal raggruppamento ESM. Tali ESM in genere richiedono un numero minimo di event poller per supportare le proprie esigenze di throughput. Con 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 la gestione avanzata 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 ciascuno 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)
1. Apri la [pagina Event Functions](https://console.aws.amazon.com/lambda/home#/functions) della console Lambda.
1. Scegliere la funzione.
1. Scegli **Configurazione**, quindi scegli **Trigger**.
1. **Quando crei una nuova mappatura della sorgente degli eventi Kafka o ne modifichi una esistente, seleziona **Configura** in modalità Provisioned.**
1. Per **Numero minimo di poller di eventi**, inserisci un valore compreso tra 1 e 200.
1. Per **Numero massimo di poller di eventi**, inserisci un valore compreso tra 1 e 2.000.
1. Per il **nome del gruppo Poller**, inserisci un identificatore per il gruppo. Usa lo stesso nome per gli altri ESM che desideri raggruppare.
1. Selezionare **Salva**.
#### 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"
}'
```
**Nota**
È possibile aggiornare il file `PollerGroupName` per spostare un ESM in un gruppo diverso o rimuovere un ESM da un gruppo passando una stringa vuota («») per: `PollerGroupName`
```
# 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
+ **Limiti delle applicazioni**: raggruppa gli ESM che appartengono alle stesse applicazioni o servizi per una migliore allocazione e gestione dei costi. Prendi in considerazione l'utilizzo di convenzioni di denominazione come `app-name-environment` (ad esempio,). `order-processor-prod`
+ **Schema di traffico**: evita di raggruppare gli ESM con un throughput elevato e un andamento di traffico intenso, poiché ciò potrebbe portare a un conflitto di risorse.
+ **Blast radius**: considera l'impatto se l'infrastruttura condivisa presenta problemi. Tutti gli ESM dello stesso gruppo sono interessati dalle limitazioni delle risorse condivise. Per i carichi di lavoro mission critical, potresti voler utilizzare gruppi separati o ESM dedicati.
#### Esempio di ottimizzazione dei costi
Consideriamo uno scenario in cui disponi di 10 ESM, ciascuno configurato con 1 event poller e un throughput inferiore a 2: MB/s
**Senza raggruppamento:**
+ Ogni ESM richiede la propria EPU
+ Numero totale di EPU necessarie: 10
+ Costo per EPU: 0 USD. 185/hour negli Stati Uniti orientali (Virginia settentrionale)
+ Costo mensile EPU (720 ore): 10 × 720 × 0,185 USD = 1.332 USD
**Con raggruppamento:**
+ Tutti i 10 ESM condividono la capacità EPU
+ 10 sondaggi di eventi rientrano in 1 EPU (con nuovi 10 sondaggi per ogni supporto EPU)
+ Numero totale di EPU necessarie: 1
+ Costo mensile dell'EPU (720 ore): 1 × 720 × 0,185 USD = 133,20 USD
+ **Risparmio sui costi: 90% (1.198,80$ di risparmio al mese**)