Best practice

In questo argomento vengono illustrate alcune best practice da seguire quando si utilizza Amazon MSK.

Dimensionamento corretto del cluster: numero di partizioni per broker

Nella tabella seguente viene illustrato il numero consigliato di partizioni (incluse le repliche leader e follower) per broker.

Dimensioni del broker	Numero consigliato di partizioni (incluse le repliche leader e follower) per broker
kafka.t3.small	300
kafka.m5.large o kafka.m5.xlarge	1000
kafka.m5.2xlarge	2000
kafka.m5.4xlarge, kafka.m5.8xlarge, kafka.m5.12xlarge, kafka.m5.16xlarge oppure kafka.m5.24xlarge	4000
kafka.m7g.large o kafka.m7g.xlarge	1000
kafka.m7g.2xlarge	2000
kafka.m7g.4xlarge, kafka.m7g.8xlargekafka.m7g.12xlarge, o kafka.m7g.16xlarge	4000

Se il numero di partizioni per broker supera il valore consigliato e il cluster si sovraccarica, è possibile che venga impedito di eseguire le seguenti operazioni:

• Aggiornamento della configurazione del cluster

• Aggiorna il cluster a un broker di dimensioni inferiori

• Associa un AWS Secrets Manager segreto a un cluster con autenticazione SASL/SCRAM

Un numero elevato di partizioni può inoltre comportare la mancanza delle metriche di Kafka CloudWatch su e sullo scraping di Prometheus.

Per informazioni sulla scelta del numero di partizioni, consulta Apache Kafka Supports 200K Partitions Per Cluster. Ti consigliamo inoltre di eseguire i tuoi test per determinare la dimensione giusta per i tuoi broker. Per ulteriori informazioni sulle diverse dimensioni dei broker, consultaDimensioni dei broker.

Dimensionamento corretto del cluster: numero di broker per cluster

Per determinare il numero corretto di broker per il cluster MSK e comprendere i costi, consulta il foglio di calcolo MSK Sizing and Pricing. Questo foglio di calcolo fornisce una stima delle dimensioni di un cluster MSK e dei costi associati di Amazon MSK rispetto a un cluster Apache Kafka simile basato su EC2 e autogestito. Per ulteriori informazioni sui parametri di input nel foglio di calcolo, passare il mouse sulle descrizioni dei parametri. Le stime fornite da questo foglio sono conservative e forniscono un punto di partenza per un nuovo cluster. Le prestazioni, le dimensioni e i costi del cluster dipendono dal caso d'uso e consigliamo di verificarli con test ad hoc.

Per capire in che modo l'infrastruttura sottostante influisce sulle prestazioni di Apache Kafka, consulta le migliori pratiche per il corretto dimensionamento dei cluster Apache Kafka per ottimizzare prestazioni e costi nel Big Data Blog. AWS Il post del blog fornisce informazioni su come dimensionare i cluster per soddisfare i requisiti di velocità di trasmissione effettiva, disponibilità e latenza. Fornisce inoltre risposte a domande quali quando è necessario aumentare o ridurre la capacità e indicazioni su come verificare continuamente le dimensioni dei cluster di produzione.

Ottimizza la velocità effettiva del cluster per istanze m5.4xl, m7g.4xl o più grandi

Quando si utilizzano istanze m5.4xl, m7g.4xl o più grandi, è possibile ottimizzare il throughput del cluster ottimizzando le configurazioni num.io.threads e num.network.threads.

Il valore num.io.threads è il numero di thread utilizzati da un broker per l'elaborazione delle richieste. L'aggiunta di più thread, fino al numero di core CPU supportati per la dimensione dell'istanza, può contribuire a migliorare il throughput del cluster.

Il valore num.network.threads è il numero di thread utilizzati dal broker per ricevere tutte le richieste in arrivo e restituire le risposte. I thread di rete inseriscono le richieste in entrata in una coda di richieste per l'elaborazione da parte di io.threads. L'impostazione di num.network.threads sulla metà del numero di core CPU supportati per la dimensione dell'istanza consente l'utilizzo completo della nuova dimensione dell'istanza.

Importante

Non aumentare num.network.threads senza prima aumentare num.io.threads, in quanto ciò può causare una congestione legata alla saturazione della coda.

Impostazioni consigliate
Dimensioni istanza	Valore consigliato per num.io.threads	Valore consigliato per num.network.threads
m5.4xl	16	8
m5.8xl	32	16
m5.12xl	48	24
m5.16xl	64	32
m5.24xl	96	48
m7g.4xlarge	16	8
m7g.8xlarge	32	16
m7g.12xlarge	48	24
m7g.16xlarge	64	32

Usa l'ultima versione di Kafka per evitare problemi di mancata corrispondenza tra gli ID degli argomenti AdminClient

L'ID di un argomento viene perso (Errore: non corrisponde all'ID dell'argomento per la partizione) quando si utilizza una versione di Kafka AdminClient precedente alla 2.8.0 con il flag per aumentare o riassegnare le partizioni degli argomenti --zookeeper per un cluster utilizzando la versione di Kafka 2.8.0 o successiva. Nota che il flag --zookeeper è obsoleto in Kafka 2.5 ed è stato rimosso a partire da Kafka 3.0. Consulta la pagina Upgrading to 2.5.0 from any version 0.8.x through 2.4.x.

Per evitare la mancata corrispondenza degli ID degli argomenti, utilizza una versione del client Kafka 2.8.0 o successiva per le operazioni di amministrazione di Kafka. In alternativa, i client 2.5 e versioni successive possono utilizzare il flag --bootstrap-servers al posto del flag --zookeeper.

Creazione di cluster a disponibilità elevata

Utilizza i seguenti consigli in modo che il tuo cluster MSK possa essere altamente disponibile durante un aggiornamento (ad esempio quando aggiorni le dimensioni del broker o la versione di Apache Kafka, ad esempio) o quando Amazon MSK sostituisce un broker.

• Configura un cluster con tre zone di disponibilità.

• Assicurati che il fattore di replica (RF) sia almeno 3. Tieni presente che un valore di RF pari a 1 può portare a partizioni offline durante un aggiornamento in sequenza, mentre un RF pari a 2 può causare la perdita di dati.

• Impostare le repliche in sinc minime (minISR) su al massimo RF - 1. Un minISR uguale a RF può impedire la produzione nel cluster durante un aggiornamento in sequenza. Un minISR di 2 consente di rendere disponibili argomenti replicati a tre vie quando una replica è offline.

• Assicurati che le stringhe di connessione del client includano almeno un broker per ogni zona di disponibilità. La presenza di più broker nella stringa di connessione di un client consente il failover quando un broker specifico è offline a seguito di un aggiornamento. Per informazioni su come ottenere una stringa di connessione con più broker, consulta Recupero dei broker di bootstrap per un cluster Amazon MSK.

Monitoraggio dell'utilizzo della CPU

Amazon MSK consiglia vivamente di mantenere l'utilizzo totale della CPU per i broker (definito come CPU User + CPU System) al di sotto del 60%. Quando hai a disposizione almeno il 40% della CPU totale del cluster, Apache Kafka può ridistribuire il carico della CPU tra i broker del cluster, se necessario. Ad esempio, ciò si rende necessario quando Amazon MSK rileva e ripristina un errore del broker; in questo caso, Amazon MSK esegue la manutenzione automatica, ad esempio l'applicazione di patch. Un altro esempio è quando un utente richiede una modifica delle dimensioni del broker o un aggiornamento di versione; in questi due casi, Amazon MSK implementa flussi di lavoro continui che portano offline un broker alla volta. Quando i broker con partizioni leader vanno offline, Apache Kafka riassegna la leadership delle partizioni per ridistribuire il lavoro agli altri broker del cluster. Seguendo questa best practice, puoi assicurarti di avere abbastanza margine nella CPU nel cluster per tollerare eventi operativi come questi.

Puoi utilizzare Amazon CloudWatch Metric Math per creare una metrica composita. CPU User + CPU System Imposta un allarme che si attiva quando il parametro composito raggiunge un utilizzo medio della CPU del 60%. Quando viene attivato questo allarme, dimensiona il cluster utilizzando una delle seguenti opzioni:

• Opzione 1 (consigliata): aggiorna la dimensione del broker alla dimensione successiva più grande. Ad esempio, se la dimensione corrente èkafka.m5.large, aggiorna il cluster da utilizzarekafka.m5.xlarge. Tieni presente che quando aggiorni le dimensioni dei broker nel cluster, Amazon MSK disconnette i broker in modo continuativo e riassegna temporaneamente la leadership delle partizioni ad altri broker. Un aggiornamento delle dimensioni richiede in genere 10-15 minuti per broker.

• Opzione 2: se ci sono argomenti in cui tutti i messaggi sono stati acquisiti da produttori che utilizzano scritture ininterrotte (in altre parole, i messaggi non sono codificati e l'ordinamento non è importante per i consumatori), espandi il cluster aggiungendo altri broker. Inoltre, aggiungi partizioni agli argomenti esistenti con la velocità di trasmissione effettiva più elevata. Successivamente, utilizza kafka-topics.sh --describe per assicurarti che le partizioni appena aggiunte vengano assegnate ai nuovi broker. Il vantaggio principale di questa opzione rispetto alla precedente è la possibilità di gestire risorse e costi in modo più granulare. Inoltre, è possibile utilizzare questa opzione se il carico della CPU supera in modo significativo il 60%, poiché questa forma di dimensionamento in genere non comporta un aumento del carico per i broker esistenti.

• Opzione 3: espandi il cluster aggiungendo broker, quindi riassegna le partizioni esistenti utilizzando lo strumento di riassegnazione delle partizioni denominato kafka-reassign-partitions.sh. Tuttavia, se utilizzi questa opzione, il cluster dovrà spendere risorse per replicare i dati da broker a broker dopo la riassegnazione delle partizioni. Rispetto alle due opzioni precedenti, questa opzione può inizialmente aumentare in modo significativo il carico sul cluster. Di conseguenza, Amazon MSK sconsiglia di utilizzare questa opzione quando l'utilizzo della CPU è superiore al 70%, perché la replica causa un carico aggiuntivo della CPU e del traffico di rete. Amazon MSK consiglia di utilizzare questa opzione solo se le due opzioni precedenti non sono percorribili.

Altre raccomandazioni:

• Monitora l'utilizzo totale della CPU per broker come proxy per la distribuzione del carico. Se i broker hanno un utilizzo della CPU costantemente irregolare, potrebbe essere un segno che il carico non è distribuito uniformemente all'interno del cluster. Amazon MSK consiglia di utilizzare Cruise Control per gestire in modo continuo la distribuzione del carico tramite l'assegnazione delle partizioni.

• Monitora la latenza di produzione e utilizzo. La latenza di produzione e utilizzo può aumentare linearmente con l'utilizzo della CPU.

• Intervallo di scrape JMX: se si abilita il monitoraggio aperto con la funzionalità Prometheus, si consiglia di utilizzare un intervallo di scrape di 60 secondi o superiore (scrape_interval: 60s) per la configurazione dell'host Prometheus (prometheus.yml). La riduzione dell'intervallo di scrape può comportare un utilizzo elevato della CPU sul cluster.

Monitoraggio dello spazio su disco

Per evitare di esaurire lo spazio su disco per i messaggi, crea un CloudWatch allarme che controlli la metrica. KafkaDataLogsDiskUsed Quando il valore di questo parametro raggiunge o supera l'85%, esegui una o più delle seguenti operazioni:

• Utilizza Scalabilità automatica. Puoi anche aumentare manualmente lo spazio di archiviazione del broker come descritto nella sezione Dimensionamento manuale.

• Riduci il periodo di conservazione dei messaggi o la dimensione del log. Per informazioni su come eseguire queste operazioni, consulta Regolazione dei parametri di conservazione dei dati.

• Elimina argomenti non utilizzati.

Per informazioni su come configurare e utilizzare gli allarmi, consulta Using Amazon CloudWatch Alarms. Per un elenco completo di parametri di Amazon MSK, consulta la sezione Monitoraggio di un cluster Amazon MSK.

Regolazione dei parametri di conservazione dei dati

Il consumo di messaggi non li rimuove dal log. Per liberare regolarmente spazio su disco, puoi specificare in modo esplicito un periodo di conservazione, ovvero il periodo di permanenza dei messaggi nel log. Puoi inoltre specificare una dimensione del log di conservazione. Quando viene raggiunto il periodo di conservazione o la dimensione del log di conservazione, Apache Kafka inizia a rimuovere i segmenti inattivi dal log.

Per specificare una policy di conservazione a livello di cluster, imposta uno o più dei seguenti parametri: log.retention.hours, log.retention.minutes, log.retention.ms o log.retention.bytes. Per ulteriori informazioni, consulta Configurazioni MSK personalizzate.

Puoi anche specificare i parametri di conservazione a livello di argomento:

• Per specificare un periodo di conservazione per argomento, utilizza il comando seguente.

  kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-name TopicName --add-config retention.ms=DesiredRetentionTimePeriod

• Per specificare una dimensione del log di conservazione per argomento, utilizza il comando seguente.

  kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-name TopicName --add-config retention.bytes=DesiredRetentionLogSize

I parametri di conservazione specificati a livello di argomento hanno la precedenza sui parametri a livello di cluster.

Accelerazione del ripristino dei log dopo un arresto non corretto

Dopo un arresto non corretto, un broker può impiegare del tempo per riavviarsi poiché esegue il ripristino dei log. Per impostazione predefinita, Kafka utilizza solo un thread per directory di log per eseguire questo ripristino. Ad esempio, se si dispone di migliaia di partizioni, il completamento del ripristino dei log può richiedere ore. Per velocizzare il ripristino dei log, si consiglia di aumentare il numero di thread utilizzando la proprietà di configurazione num.recovery.threads.per.data.dir. È possibile impostarlo sul numero di core CPU.

Monitoraggio della memoria di Apache Kafka

Ti consigliamo di monitorare la memoria utilizzata da Apache Kafka. In caso contrario, il cluster potrebbe diventare non disponibile.

Per determinare la quantità di memoria utilizzata da Apache Kafka, puoi monitorare il parametro HeapMemoryAfterGC. HeapMemoryAfterGC è la percentuale di memoria heap totale utilizzata dopo la rimozione di oggetti inutili (garbage collection). Ti consigliamo di creare un CloudWatch allarme che agisca quando un HeapMemoryAfterGC aumento supera il 60%.

Le operazioni che è possibile eseguire per ridurre l'utilizzo della memoria variano. Dipendono dal modo in cui si configura Apache Kafka. Ad esempio, se si utilizza la consegna transazionale dei messaggi, è possibile ridurre il valore transactional.id.expiration.ms nella configurazione di Apache Kafka da 604800000 ms a 86400000 ms (da 7 giorni a 1 giorno). Ciò riduce l'ingombro di memoria di ciascuna transazione.

Non aggiungere broker non MSK

Per i cluster ZooKeeper basati, se si utilizzano ZooKeeper i comandi Apache per aggiungere broker, questi broker non vengono aggiunti al cluster MSK e Apache ZooKeeper conterrà informazioni errate sul cluster. Ciò potrebbe comportare la perdita di dati. Per le operazioni cluster supportate, consulta Amazon MSK: come funziona.

Abilitazione della crittografia dei dati in transito

Per informazioni sulla crittografia dei dati in transito e su come abilitarla, consulta Crittografia in transito.

Riassegnazione delle partizioni

Per spostare le partizioni in broker diversi sullo stesso cluster, puoi utilizzare lo strumento di riassegnazione delle partizioni denominato kafka-reassign-partitions.sh. Ad esempio, dopo aver aggiunto nuovi broker per espandere un cluster o aver spostato le partizioni per rimuovere i broker, è possibile ribilanciare il cluster riassegnando le partizioni ai nuovi broker. Per informazioni su come aggiungere broker a un cluster, consulta Espansione di un cluster Amazon MSK. Per informazioni su come rimuovere i broker da un cluster, vedere. Rimuovere un broker da un cluster Amazon MSK Per informazioni sullo strumento di riassegnazione delle partizioni, consulta la sezione relativa all'espansione del cluster nella documentazione di Apache Kafka.