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à.
Le migliori pratiche per i broker Express
Questo argomento illustra alcune best practice da seguire quando si utilizzano i broker Express. I broker Express sono preconfigurati per garantire elevata disponibilità e durata. Per impostazione predefinita, i dati sono distribuiti in tre zone di disponibilità, la replica è sempre impostata su 3 e la replica sincronizzata minima è sempre impostata su 2. Tuttavia, ci sono ancora alcuni fattori da considerare per ottimizzare l'affidabilità e le prestazioni del cluster.
Client-side considerazioni
La disponibilità e le prestazioni dell'applicazione dipendono non solo dalle impostazioni lato server ma anche dalle impostazioni del client.
Configura i tuoi clienti per l'alta disponibilità. In un sistema distribuito come Apache Kafka, garantire un'elevata disponibilità è fondamentale per mantenere un'infrastruttura di messaggistica affidabile e tollerante ai guasti. I broker passeranno offline sia per eventi pianificati che non pianificati, ad esempio aggiornamenti, patch, guasti hardware e problemi di rete. Un cluster Kafka è tollerante nei confronti di un broker offline, pertanto i clienti Kafka devono anche gestire il failover del broker con garbo. Scopri tutti i dettagli nelle raccomandazioni sulle migliori pratiche per i clienti Apache Kafka. Procedure consigliate per i clienti Apache Kafka
Esegui test delle prestazioni per verificare che le configurazioni dei tuoi clienti ti consentano di raggiungere i tuoi obiettivi di performance anche quando riavviamo i broker durante i picchi di carico. Puoi riavviare i broker del tuo cluster dalla console MSK o utilizzando le API MSK.
Server-side considerazioni
Argomenti
Right-size il tuo cluster: numero di broker per cluster
Scegliere il numero di broker per il tuo Express-based cluster è facile. Ogni broker Express è dotato di una capacità di throughput definita per l'ingresso e l'uscita. È consigliabile utilizzare questa capacità di throughput come mezzo principale per dimensionare il cluster (e quindi considerare altri fattori come il numero di partizioni e connessioni, descritti di seguito).
Ad esempio, se la tua applicazione di streaming richiede 45 MBps di capacità di ingresso (scrittura) e 90 MBps di dati in uscita (lettura), puoi semplicemente utilizzare 3 broker express.m7g.large per soddisfare le tue esigenze di throughput. Ogni broker express.m7g.large gestirà 15 MBps di ingresso e 30 MBps di uscita. Consulta la tabella seguente per i nostri limiti di throughput consigliati per ogni dimensione di broker Express. Se il throughput supera i limiti consigliati, potresti riscontrare un calo delle prestazioni e dovresti ridurre il traffico o scalare il cluster. Se il throughput supera i limiti consigliati e raggiunge la quota per broker, MSK limiterà il traffico dei clienti per evitare un ulteriore sovraccarico.
Puoi anche utilizzare il nostro foglio di calcolo
La tabella seguente elenca il throughput massimo consigliato per broker per ogni dimensione dell'istanza.
| Dimensioni istanza | Ingresso (MBps) | Uscita (MBps) |
|---|---|---|
|
|
15.6 | 31,2 |
|
|
31.2 | 62,5 |
|
|
62,5 | 125,0 |
|
|
124,9 | 249,8 |
|
|
250,0 | 500,0 |
|
|
375,0 | 750,0 |
|
|
500,0 | 1000,0 |
Monitoraggio dell'utilizzo della CPU
Ti consigliamo di mantenere l'utilizzo totale della CPU per i tuoi broker (definito come utente CPU + sistema CPU) 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. Ciò può essere necessario a causa di eventi pianificati o non pianificati. Un esempio di evento pianificato è un aggiornamento della versione del cluster durante il quale MSK aggiorna i broker in un cluster riavviandoli uno alla volta. Un esempio di evento non pianificato è un guasto hardware in un broker o, nel peggiore dei casi, un guasto AZ in cui sono interessati tutti i broker di un AZ. Quando i broker con repliche di partition lead vanno offline, Apache Kafka riassegna la leadership delle partizioni per ridistribuire il lavoro ad altri broker del cluster. Seguendo questa best practice, puoi assicurarti di avere abbastanza spazio per la CPU nel cluster per tollerare eventi operativi come questi.
Puoi utilizzare Using math expressions with CloudWatch metrics nella Amazon CloudWatch User Guide per creare una metrica composita composta da 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: aggiorna la dimensione del tuo broker alla dimensione successiva più grande. Tieni presente che quando aggiorni la dimensione del broker nel cluster, Amazon MSK mette i broker offline in modo continuativo e riassegna temporaneamente la leadership delle partizioni ad altri broker.
Opzione 2: espandi il cluster aggiungendo broker, quindi riassegnando le partizioni esistenti utilizzando lo strumento di riassegnazione delle partizioni denominato.
kafka-reassign-partitions.sh
Altri consigli
Monitora l'utilizzo totale della CPU per broker come proxy per la distribuzione del carico. Se i broker hanno un utilizzo della CPU costantemente disomogeneo, potrebbe essere un segno che il carico non è distribuito uniformemente all'interno del cluster. Consigliamo 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 utilizzo può aumentare linearmente con l'utilizzo della CPU.
Intervallo di scrape JMX: se si abilita il monitoraggio aperto con la funzione Prometheus, si consiglia di utilizzare un intervallo di scrape di 60 secondi o superiore () per la configurazione host Prometheus (
scrape_interval: 60s).prometheus.ymlLa riduzione dell'intervallo di scrape può comportare un utilizzo elevato della CPU sul cluster.
Right-size il tuo cluster: numero di partizioni per broker Express
Se hai un numero di partizioni elevato e un throughput basso, in cui hai un numero di partizioni più elevato, ma non invii traffico su tutte le partizioni, puoi comprimere più partizioni per broker, a condizione che tu abbia eseguito test e test delle prestazioni sufficienti per convalidare che il cluster rimanga integro anche con un numero di partizioni più elevato. Se il numero di partizioni per broker supera il valore massimo consentito e il cluster si sovraccarica, ti verrà 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 dotato di SASL/SCRAM autenticazione
Un cluster sovraccarico con un numero elevato di partizioni può inoltre comportare la mancanza delle metriche di Kafka su e sullo CloudWatch scraping di Prometheus. Questo effetto è aggravato dall'elevato numero di gruppi di consumatori, poiché ogni combinazione di gruppo di consumatori, argomento e partizione dà luogo a una voce di offset tracciata. Anche i gruppi di consumatori vuoti (gruppi senza consumatori attivi) contribuiscono a questo costo generale. Apache Kafka conserva gli offset per questi gruppi fino alla offsets.retention.minutes scadenza del periodo di conservazione definito da o fino all'eliminazione esplicita del gruppo. Per ovviare a questo problema, monitorate il numero totale dei gruppi di consumatori ed eliminate i gruppi di consumatori inutilizzati.
Per informazioni sulla scelta del numero di partizioni, consulta Apache Kafka Supports 200K Partitions Per Cluster
Per informazioni sul numero consigliato di partizioni (incluse le repliche leader e follower) per ogni broker Express, consulta. Quota di partizione di Express Broker Il numero di partizioni consigliato non viene applicato e rappresenta una procedura consigliata per gli scenari in cui si invia traffico attraverso tutte le partizioni tematiche assegnate.
Monitora il numero di connessioni
Le connessioni dei client ai tuoi broker consumano risorse di sistema come memoria e CPU. A seconda del meccanismo di autenticazione, è necessario monitorare per assicurarsi di rispettare i limiti applicabili. Per gestire i tentativi di connessione non riusciti, puoi impostare il parametro di configurazione reconnect.backoff.ms sul lato client. Ad esempio, se desideri che un client ritenti le connessioni dopo 1 secondo, imposta sureconnect.backoff.ms. 1000 Per ulteriori informazioni sulla configurazione dei tentativi, consultate la documentazione di Apache Kafka.
| Dimensione | Quota |
|---|---|
|
Numero massimo di connessioni TCP per broker (controllo degli accessi IAM) Controllo degli accessi IAM |
3000 |
|
Numero massimo di connessioni TCP per broker (IAM) |
100 al secondo |
|
Numero massimo di connessioni TCP per broker (non IAM) |
MSK non impone limiti di connessione per l'autenticazione non IAM. Tuttavia, dovresti monitorare altre metriche come l'utilizzo della CPU e della memoria per assicurarti di non sovraccaricare il cluster a causa di connessioni eccessive. |
Riassegnazione delle partizioni
Per spostare le partizioni su broker diversi sullo stesso cluster MSK Provisioned, è possibile utilizzare lo strumento di riassegnazione delle partizioni denominato. kafka-reassign-partitions.sh Ti consigliamo di non riassegnare più di 20 partizioni in una singola chiamata per operazioni sicure. kafka-reassign-partitions 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 MSK Provisioned, vedere. Espandi il numero di broker in un cluster Amazon MSK Per informazioni su come rimuovere i broker da un cluster MSK Provisioned, 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
