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à.
Questo argomento descrive alcune best practice da seguire quando si utilizzano i broker Express. I broker Express sono preconfigurati per garantire disponibilità e durabilità elevate. Per impostazione predefinita, i dati sono distribuiti su tre zone di disponibilità, la replica è sempre impostata su 3 e la replica minima sincronizzata è sempre impostata su 2. Tuttavia, ci sono ancora alcuni fattori da considerare per ottimizzare l'affidabilità e le prestazioni del cluster.
Considerazioni sul lato client
La disponibilità e le prestazioni dell'applicazione dipendono non solo dalle impostazioni lato server ma anche dalle impostazioni client.
Configura i tuoi client per un'elevata 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 andranno offline per eventi pianificati e 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 dei broker con garbo. Consulta i dettagli completi nelle raccomandazioni sulle migliori pratiche per i clienti Apache Kafka.
Esegui test delle prestazioni per verificare che le configurazioni dei tuoi client ti consentano di raggiungere i tuoi obiettivi prestazionali anche quando riavviamo i broker in condizioni di picco. È possibile riavviare i broker del cluster dalla console MSK o utilizzando MSK. APIs
Considerazioni sul lato server
Dimensionamento corretto del cluster: numero di broker per cluster
Scegliere il numero di broker per il cluster basato su Express è semplice. 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 il 45% MBps della capacità di ingresso (scrittura) e il 90% MBps dei 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à il 15% dell'ingresso e il 30% dell'uscita. MBps MBps Consulta la tabella seguente per i limiti di throughput consigliati per ogni dimensione del broker Express. Se il throughput supera i limiti consigliati, potresti riscontrare un peggioramento delle prestazioni e dovresti ridurre il traffico o scalare il cluster. Se la velocità effettiva supera i limiti consigliati e raggiunge la quota per broker, MSK limiterà il traffico dei clienti per evitare ulteriori sovraccarichi.
Puoi anche utilizzare il nostro foglio di calcolo (vedi MSK Sizing and Pricing) per valutare diversi scenari e
| 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 più 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 è l'aggiornamento di una versione del cluster durante il quale MSK aggiorna i broker di 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 tutti i broker di una AZ sono interessati. Quando i broker con partition lead repliche vanno offline, Apache Kafka riassegna la leadership delle partizioni per ridistribuire il lavoro agli altri broker del cluster. Seguendo questa best practice, potete assicurarvi di avere abbastanza spazio di crescita della CPU nel cluster per tollerare eventi operativi come questi.
Puoi usare Using math expression with CloudWatch metrics nella Amazon CloudWatch User Guide per creare una metrica composita che sia 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 broker alla dimensione successiva più grande. 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.
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 utilizzano costantemente la CPU in modo disomogeneo, è possibile che il carico non sia distribuito in modo uniforme 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: 60sprometheus.ymlLa riduzione dell'intervallo di scrape può comportare un utilizzo elevato della CPU sul cluster.
Dimensioni corrette del cluster: numero di partizioni per broker Express
La tabella seguente mostra il numero consigliato di partizioni (incluse le repliche leader e follower) per broker Express. Il numero consigliato di partizioni non viene applicato e rappresenta una procedura ottimale per gli scenari in cui si invia traffico su tutte le partizioni tematiche assegnate.
| Dimensioni del broker | Numero consigliato di partizioni (incluse le repliche leader e follower) per broker | Numero massimo di partizioni che supportano le operazioni di aggiornamento |
|---|---|---|
|
|
1000 | 1500 |
|
|
2000 | 3000 |
|
|
4000 | 6000 |
Se si utilizzano partizioni elevate e un throughput ridotto in cui il numero di partizioni è più elevato, ma non si invia traffico su tutte le partizioni, è possibile comprimere più partizioni per broker, purché siano stati eseguiti test e test delle prestazioni sufficienti per verificare che il cluster rimanga integro con il 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 con autenticazione SASL/SCRAM
Un cluster sovraccarico con un numero elevato di partizioni può inoltre comportare la mancanza dei parametri di Kafka sullo scraping di Prometheus e CloudWatch su Prometheus.
Per informazioni sulla scelta del numero di partizioni, consulta Apache Kafka Supports 200K Partitions Per Cluster
Monitora il numero di connessioni
Le connessioni dei client ai broker consumano risorse di sistema come memoria e CPU. A seconda del meccanismo di autenticazione utilizzato, è necessario effettuare un monitoraggio 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 riprovi a connettersi dopo 1 secondo, imposta sureconnect.backoff.ms. 1000 Per ulteriori informazioni sulla configurazione dei nuovi tentativi, consulta la documentazione di Apache Kafka.
| Dimensione | Quota |
|---|---|
|
Numero massimo di connessioni TCP per broker (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 necessario monitorare altre metriche come l'utilizzo della CPU e della memoria per assicurarsi 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 Si consiglia 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, è possibile 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 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
