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 vCPU dans le cluster. Le nombre minimal de vCPU est de 3.
Mémoire : quantité de mémoire par vCPU. Vous devez provisionner entre 1 Gio et 8 Gio par vCPU.
Vous pouvez mettre à jour ces valeurs une fois le cluster créé.
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 d'écriture : débit total auquel les producteurs envoient des données au cluster, en Mbit/s.
- Débit de lecture : débit total auquel les consommateurs lisent les données du cluster, en Mbit/s.
Pour estimer la taille d'un cluster nécessaire pour gérer ce débit, procédez comme suit :
Calculez la bande passante d'écriture totale, y compris la réplication.
Total write bandwidth = produce rate * replicasCette valeur inclut la bande passante du client au courtier principal, et du courtier principal aux courtiers répliqués. Le nombre d'instances répliquées par défaut est de 3.
Calculez la bande passante de lecture totale, 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 répliques restent synchronisées. Les réplicas se synchronisent en lisant les données du leader de partition. Le terme
(replicas - 1)est utilisé, car le leader de la partition ne lit aucune réplique.Calculez le débit de données équivalent en écriture.
En règle générale, la bande passante de lecture est quatre fois plus efficace à traiter que la bande passante d'é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 vCPU. 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.
- Pour commencer, définissez un taux d'utilisation cible de 50%.
- Si vous connaissez les modèles de trafic attendus, définissez la cible d'utilisation sur le rapport entre la bande passante moyenne équivalente en écriture et la bande passante maximale que vous devez prendre en compte.
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 vCPU peut entraîner des latences et des erreurs élevées.
Calculer le nombre de vCPU.
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 Mbit/s. Par conséquent, si les vCPU fonctionnaient à 100% d'utilisation, vous auriez besoin de
(write-equivalent rate / 20)vCPU. 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 de moins de 10 Ko réduit le débit par processeur par rapport au benchmark présenté 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 recommandons 4 Gio de RAM pour chaque vCPU.
Memory = vCPU count * 4 GiB
Pour obtenir la taille la plus précise, effectuez des tests avec votre charge de travail réelle. 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 d'écriture de 50 Mo/s et un débit de lecture de 100 Mo/s, avec trois répliques 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
Limites de réplication des partitions
Il existe des limites concernant le nombre de répliques de partition par cluster et par courtier. Il est important de les prendre en compte lorsque vous dimensionnez votre cluster.
La limite par cluster est de 100 000 répliques de partition. Il s'agit d'une limite stricte, indépendante du nombre de courtiers dans un cluster. Si votre charge de travail nécessite plus de 100 000 répliques de partition, envisagez de la répartir sur plusieurs clusters.
La limite par agent est de 4 000 répliques de partition. Il ne s'agit pas d'une limite stricte. Si vous devez gérer plus de réplicas, envisagez d'augmenter la taille du cluster pour provisionner davantage de courtiers. Pour savoir comment le service détermine le nombre de brokers, consultez Provisionnement des brokers.
Une fois que vous disposez d'un nombre suffisant de courtiers pour gérer vos partitions, vous pouvez adapter la taille des courtiers au débit.
Mettre à jour la taille du cluster
Une fois que vous avez créé un cluster Managed Service pour Apache Kafka, vous pouvez ajuster le nombre de vCPU et la mémoire en fonction de vos besoins. Pour en savoir plus, consultez Mettre à jour un cluster Managed Service pour Apache Kafka.
Lorsque vous mettez à jour un cluster existant, les règles suivantes s'appliquent :
Le ratio global processeur virtuel/mémoire du cluster doit toujours rester compris entre 1:1 et 1:8.
Chaque courtier existant doit disposer d'au moins un vCPU et 1 Gio de mémoire. Le nombre de courtiers ne diminue jamais.
Si le cluster possède une configuration de disque personnalisée, la mise à jour doit respecter les exigences de configuration de disque pour le stockage local.
Si vous augmentez la taille, la moyenne des vCPU et de la 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 de faire passer un cluster de 45 processeurs virtuels (3 brokers) à 48 processeurs virtuels (4 brokers), le nombre moyen de processeurs virtuels par broker passe de 15 à 12, soit une réduction de 20 %, ce qui dépasse la limite de 10 %.
Si vous devez réduire le nombre de processeurs virtuels 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 sûr que vos courtiers auront suffisamment de capacité après la mise à jour, vous pouvez désactiver cette vérification en exécutant la commande
gcloud managed-kafka clusters updateavec l'indicateurallow_broker_downscale_on_cluster_upscale=true. Ce signal indique que vous acceptez le risque potentiel de dégradation des performances.
Exemples d'opérations de mise à jour
Les exemples suivants commencent par un cluster comportant 75 vCPU, 130 Gio de RAM et 5 brokers.
Exemple d'opération de mise à l'échelle ayant échoué
Augmentez la taille du cluster à 80 vCPU et 140 Gio de RAM.
Le service détermine si un nouveau courtier est nécessaire.
- plafond (80 vCPU / 15) = 6 brokers
Le cluster passerait de cinq à six brokers, ce qui déclencherait le contrôle de sécurité de 10 %.
Voici les moyennes actuelles par courtier :
75 vCPU / 5 brokers = 15 vCPU par broker
130 Gio / 5 brokers = 26 Gio par broker
Avec six courtiers, les nouvelles moyennes sont les suivantes :
80 vCPU / 6 brokers = 13,33 vCPU par broker, 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 de mise à l'échelle réussie
Faites passer le cluster à 85 vCPU et 150 Gio de RAM.
Le service détermine si un nouveau courtier est nécessaire.
- plafond (85 processeurs virtuels / 15) = 6 brokers
Le cluster passerait de cinq à six brokers, ce qui déclencherait le contrôle de sécurité de 10 %.
Voici les moyennes actuelles par courtier :
75 vCPU / 5 brokers = 15 vCPU par broker
130 Gio / 5 brokers = 26 Gio par broker
Avec six courtiers, les nouvelles moyennes sont les suivantes :
85 vCPU / 6 brokers = 14,17 vCPU par broker, soit une réduction de 5,5 %
150 Gio / 6 brokers = 25 Gio par broker, soit une réduction de 3,8 %
Cette opération réussit, car la réduction du nombre moyen de processeurs virtuels et de la mémoire par courtier est inférieure à la limite de 10 %.
Estimer la taille de disque requise
Par défaut, Managed Service pour Apache Kafka alloue 100 Gio par vCPU à chaque courtier. L'allocation par défaut fournit suffisamment de stockage local pour la plupart des charges de travail, mais vous pouvez configurer la taille du disque de l'agent en fonction de vos besoins spécifiques. Cette section explique comment estimer la quantité de capacité de disque dont vous avez besoin.
Lorsqu'un courtier reçoit un message, il l'écrit dans un fichier de segment local.
Lorsque le fichier de segment atteint une taille ou un âge maximum, il est fermé (ou "roulé") et déplacé vers le stockage à distance. La taille maximale d'un fichier de segment est spécifiée par le paramètre log.roll.bytes, et l'âge maximal est spécifié par le paramètre log.segment.ms.
Lorsqu'un fichier de segment est déployé, le courtier ouvre un nouveau fichier de segment. Le segment déployé reste dans le stockage local pendant que le courtier le copie dans le stockage distant. Par conséquent, chaque partition doit disposer de suffisamment d'espace pour stocker un fichier de segment cumulé, ainsi que de l'espace pour un nouveau fichier de segment pendant que le segment cumulé est déplacé vers le stockage à distance.
Par défaut, la taille maximale d'un fichier de segment est de 230 Mio. Pour les clusters dont l'utilisation est modérée, vous pouvez supposer que 250 Mio sont nécessaires par partition, afin de disposer d'un espace tampon supplémentaire lors du déplacement d'un segment cumulé. En partant de cette hypothèse, la taille minimale du disque par courtier est la suivante :
250 MiB * partition count * replication factor / broker count
Toutefois, la taille requise dépend de facteurs tels que la taille maximale des fichiers de segment, la charge du cluster, la vitesse à laquelle de nouvelles données sont écrites et la latence des écritures dans le stockage à long terme.
Il est essentiel de conserver une certaine capacité de disque inutilisée sur chaque courtier. Le comportement d'un broker sans capacité de disque n'est pas prévisible et peut entraîner une perte de données ainsi qu'une instabilité du cluster.
Surveillez l'utilisation du disque (disk/used_bytes) par rapport à la taille totale du disque disponible (disk/limit). Si l'utilisation du disque dépasse 80% de la taille totale du disque disponible, configurez une taille de disque plus importante. Pour en savoir plus, consultez Surveiller la capacité du cluster.
Étapes suivantes
- 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
- Configurer la taille du disque de l'agent