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à.
Best practice
Questo argomento descrive alcune best practice da seguire quando si utilizza AmazonMSK. Per informazioni sulle best practice di Amazon MSK Replicator, consultaLe migliori pratiche per l'utilizzo di MSK Replicator.
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 SCRAM autenticazioneSASL/
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
Dimensionamento corretto del cluster: numero di broker per cluster
Per determinare il numero giusto di broker per il tuo MSK cluster e comprendere i costi, consulta il foglio di calcolo sulle MSKdimensioni e sui prezzi
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
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 supportati per la dimensione dell'istanza, può contribuire a migliorare il throughput del cluster. CPU
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 CPU core supportati per la dimensione dell'istanza consente di utilizzare appieno la 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 MSK cluster 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.
-
Imposta un numero minimo di repliche sincronizzate (minISR) su RF - 1 al massimo. Un minimo ISR uguale alla RF può impedire la produzione verso il cluster durante un aggiornamento continuo. Un minimo ISR 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 Ottieni i broker bootstrap per un cluster Amazon MSK.
Monitora l'utilizzo CPU
Amazon consiglia MSK vivamente di mantenere l'CPUutilizzo totale dei broker (definito comeCPU User + CPU System) al di sotto del 60%. Se disponi di almeno il 40% del totale CPU del cluster, Apache Kafka può ridistribuire il CPU carico tra i broker del cluster, se necessario. Un esempio di quando ciò è necessario è quando Amazon MSK rileva e recupera un guasto del broker; in questo caso, Amazon MSK esegue la manutenzione automatica, come 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 mettono 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 CPU spazio di crescita nel tuo 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 la metrica composita raggiunge un utilizzo medio del 60%. CPU 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 del broker nel cluster, Amazon MSK mette i broker offline 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 --describeper 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, puoi utilizzare questa opzione se il CPU carico supera in modo significativo il 60%, poiché questa forma di scalabilità 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 non consiglia di utilizzare questa opzione quando l'CPUutilizzo è superiore al 70% perché la replica causa CPU carico e traffico di rete aggiuntivi. Amazon consiglia di utilizzare questa opzione MSK solo se le due opzioni precedenti non sono possibili.
Altre raccomandazioni:
-
Monitora CPU l'utilizzo totale per broker come proxy per la distribuzione del carico. Se i broker hanno un CPU utilizzo costantemente disomogeneo, potrebbe essere un segno che il carico non è distribuito uniformemente all'interno del cluster. Amazon MSK consiglia di utilizzare Cruise Control per gestire continuamente la distribuzione del carico tramite l'assegnazione delle partizioni.
-
Monitora la latenza di produzione e utilizzo. La latenza di produzione e consumo può aumentare linearmente con l'utilizzo. CPU
-
JMXscrape interval: se si abilita il monitoraggio aperto con la funzione 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 CPU di scrape può portare a un utilizzo elevato del 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 per i cluster Amazon MSK. 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 dei MSK parametri di Amazon, consultaMonitora un MSK cluster Amazon.
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 MSKConfigurazioni Amazon 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-nameTopicName--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-nameTopicName--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. Puoi impostarlo sul numero di CPU core.
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 supera HeapMemoryAfterGC 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 non MSK broker
Per i cluster ZooKeeper basati, se utilizzi ZooKeeper i comandi Apache per aggiungere broker, questi broker non vengono aggiunti al MSK cluster e Apache ZooKeeper conterrà informazioni errate sul cluster. Ciò potrebbe comportare la perdita di dati. Per le operazioni cluster supportate, consulta AmazonMSK: come funziona.
Abilitazione della crittografia dei dati in transito
Per informazioni sulla crittografia dei dati in transito e su come abilitarla, consulta MSKCrittografia Amazon 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, puoi ribilanciare il cluster riassegnando le partizioni ai nuovi broker. Per informazioni su come aggiungere broker a un cluster, consulta Espandi il numero di broker in un cluster Amazon MSK. Per informazioni su come rimuovere i broker da un cluster, vedere. Rimuovi un broker da un MSK cluster Amazon Per informazioni sullo strumento di riassegnazione delle partizioni, consulta la sezione relativa all'espansione del cluster
