Evaluating Confluent cluster specifications - ApsaraMQ for Kafka

Aperçu de l'architecture

Un cluster ApsaraMQ for Confluent comprend sept composants. Le tableau ci-dessous liste chaque composant, son nombre de réplicas par défaut et son rôle.

Composant	Répliques par défaut	Rôle
Kafka Broker	3	Traite les requêtes de production et de consommation
ZooKeeper	3	Gère les métadonnées et la coordination du cluster
Connect	2	Exécute les connecteurs source et sink pour l'intégration des données
SchemaRegistry	2	Garantit la gestion et la compatibilité des schémas
ControlCenter	1	Offre une surveillance et une gestion via une interface web
KsqlDB	2	Traite les flux de données via une interface SQL
KafkaRestProxy	2	Expose une interface HTTP/REST pour la production et la consommation de messages

Ajustez le nombre de réplicas de chaque composant selon votre charge de travail.

Estimer les ressources des brokers Kafka

Le dimensionnement des brokers Kafka influence le plus les performances du cluster. Définissez d'abord les paramètres de votre charge de travail, puis utilisez les formules de cette section pour calculer le nombre de brokers, les unités de calcul (CU) par broker et la taille du disque.

Définir les paramètres de la charge de travail

Paramètre	Description	Valeur par défaut
Facteur de diffusion (Fan-out factor)	Nombre de groupes de consommateurs indépendants lisant les mêmes données. Exclut le trafic de réplication inter-brokers.	--
Débit entrant maximal (Peak data inflow)	Débit maximal des producteurs (Mo/s)	--
Débit entrant moyen (Average data inflow)	Débit moyen des producteurs (Mo/s)	--
Période de rétention des données	Durée de conservation des messages avant suppression	7 jours
Facteur de réplication	Nombre de copies par partition	3

Calculer le nombre de brokers

Un seul broker Kafka prend en charge un débit allant jusqu'à 100 Mo/s. Prévoyez une marge de 50 % sur la bande passante des E/S pour absorber les pics de trafic.

Les clusters de production nécessitent au moins 4 brokers :

Broker count = Max(4, peak_inflow x (fan_out + 2 x replication_factor - 1) x 2 / 400)

Les clusters de test nécessitent au moins 3 brokers :

Broker count = Max(3, peak_inflow x (fan_out + 2 x replication_factor - 1) x 2 / 300)

Les limites de partitions contraignent également le nombre de brokers :

Par broker : pas plus de 2 000 réplicas de partition
Pour l'ensemble du cluster : pas plus de 200 000 réplicas de partition

Si le nombre total de réplicas de partition est élevé, dimensionnez le nombre de brokers en fonction des limites de partition plutôt que du seul débit.

Exemple pratique

Prenons l'exemple d'une charge de travail de production avec les caractéristiques suivantes :

Débit entrant maximal : 200 Mo/s
Facteur de diffusion : 2 (deux groupes de consommateurs)
Facteur de réplication : 3 (valeur par défaut)

Broker count = Max(4, 200 x (2 + 2 x 3 - 1) x 2 / 400)
             = Max(4, 200 x 7 x 2 / 400)
             = Max(4, 7)
             = 7 brokers

Choisir le nombre d'unités de calcul (CU) par broker

Les besoins en CU dépendent de la configuration du cluster, du comportement des clients, du nombre de partitions ainsi que du nombre de producteurs et de consommateurs. Utilisez ces directives comme point de départ :

Environnement	CU par broker	Limites de partitions par broker (pour 4 CU)
Production	8 ou plus	100 réplicas leaders ou 300 réplicas de partition (y compris les leaders)
Développement et test	4	100 réplicas leaders ou 300 réplicas de partition (y compris les leaders)

Calculer la taille du disque par broker

Disk per broker = Max(1 TB, average_inflow x retention_period x replication_factor / broker_count)

Convertissez toutes les valeurs dans des unités cohérentes avant le calcul. Si average_inflow est exprimé en Mo/s, convertissez retention_period en secondes (1 jour = 86 400 secondes).

Exemple pratique

Avec les paramètres suivants :

Débit entrant moyen : 50 Mo/s
Période de rétention : 7 jours (604 800 secondes)
Facteur de réplication : 3
Nombre de brokers : 7

Disk per broker = Max(1 TB, 50 MB/s x 604,800 s x 3 / 7)
               = Max(1 TB, ~12,960,000 MB)
               = Max(1 TB, 12.4 TB)
               = 12.4 TB per broker

Estimer les ressources des autres composants

Connect

Ressource	Recommandation
Nœuds	2 ou plus pour la haute disponibilité
CU par nœud	8 ou plus

SchemaRegistry

Ressource	Recommandation
Nœuds	2
CU par nœud	2

ControlCenter

Ressource	Recommandation
Nœuds	1
CU	Plus de 4
Stockage	300 Go ou plus

KsqlDB

Ressource	Recommandation
Nœuds	2 ou plus pour la haute disponibilité
CU par nœud	5 ou plus
Stockage	100 Go (par défaut). Augmentez cette valeur selon le nombre d'instructions d'agrégation et le volume de requêtes simultanées.

KafkaRestProxy

Ressource	Recommandation
Nœuds	2 ou plus pour la haute disponibilité
CU par nœud	8 ou plus pour les charges de travail continues de production/consommation ; 4 pour une utilisation légère

Benchmarks de performance

Les benchmarks suivants ont été mesurés sur un cluster de 4 brokers avec un seul topic, 300 partitions, 60 producteurs et des messages de 1 Ko.

Débit et latence selon le nombre d'unités de calcul (CU)

Spécification du broker	Débit total du cluster (sans limitation)	Débit moyen du producteur (sans limitation)	Latence moyenne (sans limitation)	Débit total (latence < 100 ms)
4 CU par broker	370 Mo/s	5,95 Mo/s	9 718 ms	130 Mo/s
8 CU par broker	400 Mo/s	7,33 Mo/s	8 351 ms	195 Mo/s
12 CU par broker	400 Mo/s	7,39 Mo/s	8 343 ms	240 Mo/s
16 CU par broker	400 Mo/s	7,47 Mo/s	8 335 ms	290 Mo/s
20 CU par broker	400 Mo/s	7,58 Mo/s	8 237 ms	305 Mo/s

Avec 4 brokers disposant chacun de 8 CU ou plus, le cluster atteint un débit de base de 400 Mo/s. L'ajout d'unités de calcul améliore principalement le débit sous contrainte de latence plutôt que le débit de pointe.

Remarque

Les performances réelles varient selon la taille des messages, le nombre de partitions, le nombre de consommateurs et la configuration du client. Utilisez ces benchmarks comme référence de base, non comme une garantie.

Mise à l'échelle horizontale avec des brokers supplémentaires

Chaque broker supplémentaire ajoute environ 100 Mo/s de débit. Allouez au moins 8 CU par broker lors de la mise à l'échelle horizontale pour éviter que le calcul ne devienne un goulot d'étranglement.

Brokers	Débit du cluster	Messages par heure	Partitions prises en charge (à 1 Mo/s par partition)
4	400 Mo/s	14,7 milliards	400
8	800 Mo/s	29,5 milliards	800
12	1 200 Mo/s	44,2 milliards	1 200
16	1 600 Mo/s	59 milliards	1 600
20	2 000 Mo/s	73,7 milliards	2 000

Remarque

Le débit recommandé par partition est de 1 à 5 Mo/s. Pour les charges de travail à faible latence, maintenez le débit par partition à la borne inférieure. À mesure que le nombre de partitions augmente, le débit du cluster diminue et la latence de queue (tail latency) augmente.

Spécifications de cluster recommandées

Les tableaux ci-dessous fournissent des spécifications de départ pour les environnements de production et de test. Ajustez-les selon les caractéristiques de votre charge de travail.

Environnement de production

Débit total du cluster : 400 Mo/s (hors trafic de réplication).

Composant	CU par nœud	Disque par nœud	Nœuds
Kafka Broker	12	2 400 Go	4
ZooKeeper	4	100 Go	3
Connect	12	--	2
ControlCenter	12	300 Go	1
SchemaRegistry	2	--	2
KafkaRestProxy	16	--	2
KsqlDB	5	100 Go	2

Environnement de test

Débit total du cluster : 300 Mo/s (hors trafic de réplication).

Composant	CU par nœud	Disque par nœud	Nœuds
Kafka Broker	4	800 Go	3
ZooKeeper	2	100 Go	3
Connect	4	--	2
ControlCenter	4	300 Go	1
SchemaRegistry	2	--	2
KafkaRestProxy	4	--	2
KsqlDB	5	100 Go	2

Remarque

Après la création d'un cluster, vous pouvez ajuster les configurations de ressources en augmentant la capacité (scale up) ou le nombre d'instances (scale out) des composants individuels.

Plages de ressources des composants

Le tableau suivant liste les plages de configuration prises en charge pour chaque composant.

Composant	Édition	Répliques (par défaut / min / max)	CU par nœud (par défaut / min / max)	Disque par nœud (par défaut ; plage)
Kafka Broker	Professional, Enterprise	3 / 3 / 20	4 / 4 / 20	800 Go ; 800–30 000 Go
ZooKeeper	Professional, Enterprise	3 / 3 / 3	2 / 2 / 20	100 Go ; 100–30 000 Go
ControlCenter	Professional, Enterprise	1 / 1 / 1	8 / 8 / 20	300 Go ; 300–30 000 Go
SchemaRegistry	Professional, Enterprise	2 / 2 / 3	1 / 1 / 20	Pas de stockage
Connect	Professional, Enterprise (facultatif)	2 / 1 / 20	4 / 1 / 20	Pas de stockage
KsqlDB	Professional, Enterprise (facultatif)	2 / 1 / 20	5 / 5 / 20	100 Go ; 100–30 000 Go
KafkaRestProxy	Professional, Enterprise (facultatif)	2 / 2 / 20	4 / 4 / 20	Pas de stockage

Références

Calculateur de dimensionnement pour Apache Kafka et Confluent Platform – modélisez votre charge de travail spécifique avec le calculateur interactif de Confluent.
Configuration système requise pour Confluent Platform – conseils matériels supplémentaires fournis par Confluent.