Ce document explique comment estimer la capacité dont vous avez besoin pour un cluster Managed Service pour Apache Kafka et comment ajuster la taille d'un cluster existant.
Lorsque vous créez un cluster Managed Service pour Apache Kafka, vous choisissez les paramètres suivants pour la taille du cluster :
vCPUs : nombre de processeurs virtuels dans le cluster. Le nombre minimal de processeurs virtuels est de 3.
Mémoire : quantité de mémoire par processeur virtuel. Vous devez provisionner entre 1 Gio et 8 Gio par processeur virtuel.
Vous pouvez modifier ces valeurs après la création du cluster.
Choisir la taille initiale du cluster
Pour choisir la taille initiale du cluster, commencez par estimer les valeurs suivantes en fonction de votre charge de travail spécifique.
- Débit en écriture : débit total auquel les producteurs envoient des données au cluster, en Mo/s.
- Débit en lecture : débit total auquel les consommateurs lisent les données du cluster, en Mo/s.
Pour estimer la taille d'un cluster nécessaire pour gérer ce débit, procédez comme suit :
Calculez la bande passante totale en écriture, y compris la réplication.
Total write bandwidth = produce rate * replicasCette valeur inclut la bande passante du client vers l'agent principal et de l'agent principal vers les agents répliqués. Le nombre d'instances répliquées par défaut est de 3.
Calculez la bande passante totale en lecture, y compris la réplication.
Total read bandwidth = consume rate + produce rate * ( replicas - 1)Cette valeur inclut la bande passante pour les opérations de lecture du client (taux de consommation), ainsi que la bande passante nécessaire pour que les instances répliquées restent synchronisées. Les instances répliquées se synchronisent en lisant les données de l'agent principal de la partition. Le
(replicas - 1)terme est utilisé, car l'agent principal de la partition ne lit aucune instance répliquée.Calculez le débit de données équivalent en écriture.
En règle générale, la bande passante en lecture est quatre fois plus efficace à traiter que la bande passante en écriture. Pour tenir compte de cette différence, calculez le débit de données équivalent en écriture comme suit :
Write-equivalent rate = (total write bandwidth) + (total read bandwidth / 4)Déterminez votre objectif d'utilisation des processeurs virtuels. Cette valeur représente l'utilisation moyenne des processeurs virtuels en pourcentage de la capacité des processeurs virtuels. L'utilisation réelle peut augmenter ou diminuer au fil du temps.
- Comme point de départ, commencez par un objectif d'utilisation de 50%.
- Si vous connaissez les modèles de trafic attendus, définissez l'objectif d'utilisation comme étant égal au rapport entre la bande passante équivalente en écriture moyenne et la bande passante maximale que vous devez prendre en charge.
En général, l'augmentation de l'utilisation réduit le coût de votre cluster en diminuant sa taille, mais elle est également plus risquée si le trafic dépasse les estimations. Une utilisation excessive des processeurs virtuels peut entraîner des latences et des erreurs élevées.
Calculez le nombre de processeurs virtuels.
vCPU count = ceiling (write-equivalent rate / 20 MBps / utilization)La capacité estimée pour un seul processeur virtuel dans une seule zone est de 20 Mo/s. Par conséquent, si les processeurs virtuels fonctionnaient à 100% d'utilisation, vous auriez besoin de
(write-equivalent rate / 20)processeurs virtuels. Pour obtenir le nombre réel, divisez cette valeur par l'utilisation cible et arrondissez au nombre entier supérieur.De plus, l'envoi de messages par lots inférieurs à 10 Ko réduit le débit par processeur par rapport à la référence ici. Dans ce cas, tenez compte de la capacité de débit réduite ou envisagez d'envoyer des lots plus volumineux.
Estimez la mémoire requise. Nous vous recommandons d'utiliser 4 Gio de RAM pour chaque processeur virtuel.
Memory = vCPU count * 4 GiB
Effectuez des tests avec votre charge de travail réelle pour obtenir une taille plus précise. Surveillez l'utilisation des ressources du cluster et augmentez-la si nécessaire.
Exemple de calcul de la taille
Supposons qu'une charge de travail ait un débit en écriture de 50 Mo/s et un débit en lecture de 100 Mo/s, avec trois instances répliquées et une utilisation cible des processeurs virtuels de 50%.
Total write bandwidth = 50 MBps * 3 replicas = 150 MBpsTotal read traffic = 100 MBps + 50 MBps * (3 - 1) = 200 MBpsWrite-equivalent rate = 150 MBps + (200 MBps / 4) = 200 MBpsTarget utilization = 0.5Number of vCPUs = ceiling (200 MBps / 20 MBps / 0.5) = 20 vCPUsMemory = 20 vCPUs * 4 GiB = 80 GiB
Agents
Lorsque vous créez un cluster, le système provisionne au moins un agent dans chacune des trois zones. Les agents sont répartis aussi uniformément que possible entre les zones, et tous les agents ont le même nombre de processeurs virtuels. Le nombre d'agents peut être calculé à l'aide de la formule suivante :
number of brokers = max(3, ceiling(vCPUs / 15))
Par exemple, un cluster avec 75 processeurs virtuels commence avec cinq agents.
Si vous modifiez le nombre de processeurs virtuels, ils sont répartis entre les agents existants, jusqu'à un maximum de 15 processeurs virtuels par agent. Si vous augmentez la taille du cluster au-delà de 15 processeurs virtuels par agent, le système provisionne un nouvel agent. Une fois qu'un nouvel agent est provisionné, il peut être réduit à un processeur virtuel, mais il ne peut pas être supprimé.
Limites des instances répliquées de partition
Il existe des limites concernant le nombre d'instances répliquées de partition par cluster et par agent, qu'il est important de prendre en compte lors du dimensionnement de votre cluster.
La limite par cluster est de 100 000 instances répliquées de partition. Il s'agit d'une limite stricte, indépendante du nombre d'agents dans un cluster. Si votre charge de travail nécessite plus de 100 000 instances répliquées de partition, envisagez de la répartir entre deux clusters ou plus.
La limite par agent est de 4 000 instances répliquées de partition. Il ne s'agit pas d'une limite stricte. Si vous devez gérer plus de ce nombre d'instances répliquées, envisagez de provisionner davantage d'agents. Vous pouvez augmenter le nombre d' agents en augmentant la taille du cluster en processeurs virtuels de la taille maximale de l'agent. Une fois que vous disposez d'un nombre suffisant d'agents pour gérer vos partitions, vous pouvez mettre à l'échelle la taille des agents pour tenir compte du débit.
Modifier la taille du cluster
Après avoir créé un cluster Managed Service pour Apache Kafka, vous pouvez ajuster le nombre de processeurs virtuels et la mémoire en fonction de vos besoins. Lorsque vous mettez à jour un cluster existant, les règles suivantes s'appliquent :
Le ratio global processeurs virtuels/mémoire du cluster doit toujours rester compris entre 1:1 et 1:8.
Si vous réduisez la taille, il doit y avoir au moins un processeur virtuel et 1 Gio de mémoire pour chaque agent existant. Le nombre d'agents ne diminue jamais.
Si vous augmentez la taille et que la modification entraîne l'ajout de nouveaux agents, la moyenne de processeurs virtuels et de mémoire par agent ne peut pas diminuer de plus de 10% par rapport aux moyennes avant la mise à jour.
Par exemple, si vous essayez d'augmenter la taille d'un cluster de 45 processeurs virtuels (trois agents) à 48 processeurs virtuels (quatre agents), l'opération échoue. En effet, la moyenne de processeurs virtuels par agent passe de 15 à 12, ce qui représente une réduction de 20 %, dépassant la limite de 10 %.
Si vous devez réduire le nombre de processeurs de plus de 10%, nous vous recommandons de le faire en plusieurs étapes. Après chaque mise à jour, surveillez l'utilisation des ressources et rééquilibrez les partitions si nécessaire.
Toutefois, si vous êtes certain que vos agents disposeront d'une capacité suffisante après la mise à jour, vous pouvez désactiver cette vérification. Pour désactiver la vérification, définissez l'option allow_broker_downscale_on_cluster_upscale sur true dans la commande gcloud managed-kafka clusters update. Cette option indique que vous acceptez le risque potentiel de dégradation des performances.
Pour mettre à jour un cluster, consultez Mettre à jour un cluster Managed Service pour Apache Kafka.
Exemples d'opérations de mise à jour
Les exemples suivants commencent par un cluster comportant 75 processeurs virtuels, 130 Gio de RAM et cinq agents.
Exemple d'opération d'augmentation de taille ayant échoué
Augmentez la taille du cluster à 80 processeurs virtuels et 140 Gio de RAM.
Le service détermine si un nouvel agent est nécessaire.
- plafond (80 processeurs virtuels / 15) = 6 agents
Le cluster passerait de cinq à six agents. La vérification de sécurité à 10% est donc déclenchée.
Les moyennes actuelles par agent sont les suivantes :
75 processeurs virtuels / 5 agents = 15 processeurs virtuels par agent
130 Gio / 5 agents = 26 Gio par agent
Avec six agents, les nouvelles moyennes sont les suivantes :
80 processeurs virtuels / 6 agents = 13,33 processeurs virtuels par agent, soit une réduction de 11,1 %
140 Gio / 6 agents = 23,33 Gio par agent, soit une réduction de 10,2 %
L'opération échoue, car ces moyennes dépassent 10%.
Exemple d'opération d'augmentation de taille réussie
Augmentez la taille du cluster à 85 processeurs virtuels et 150 Gio de RAM.
Le service détermine si un nouvel agent est nécessaire.
- plafond (85 processeurs virtuels / 15) = 6 agents
Le cluster passerait de cinq à six agents. La vérification de sécurité à 10% est donc déclenchée.
Les moyennes actuelles par agent sont les suivantes :
75 processeurs virtuels / 5 agents = 15 processeurs virtuels par agent
130 Gio / 5 agents = 26 Gio par agent
Avec six agents, les nouvelles moyennes sont les suivantes :
85 processeurs virtuels / 6 agents = 14,17 processeurs virtuels par agent, soit une réduction de 5,5 %
150 Gio / 6 agents = 25 Gio par agent, soit une réduction de 3,8 %
Cette opération réussit, car la réduction de la moyenne de processeurs virtuels et de mémoire par agent est inférieure à la limite de 10 %.
Étape suivante
- Créer un cluster Managed Service pour Apache Kafka
- Surveiller un cluster Managed Service pour Apache Kafka
- Mettre à jour un cluster Managed Service pour Apache Kafka