Planifier la taille de votre cluster Managed Service pour Apache Kafka

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 :

  1. Calculez la bande passante totale en écriture, y compris la réplication.

    Total write bandwidth = produce rate * replicas

    Cette valeur inclut la bande passante du client vers l'agent principal et de l'agent principal vers les agents dupliqués. Le nombre d'instances dupliquées par défaut est de 3.

  2. 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 dupliquées restent synchronisées. Les instances dupliqué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 dupliquée.

  3. 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)

  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 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 réduisant 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.

  5. 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 indiquée ici. Dans ce cas, tenez compte de la capacité de débit réduite ou envisagez d'envoyer des lots plus volumineux.

  6. 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 dupliquées et un objectif d'utilisation des processeurs virtuels de 50%.

  1. Total write bandwidth = 50 MBps * 3 replicas = 150 MBps
  2. Total read traffic = 100 MBps + 50 MBps * (3 - 1) = 200 MBps
  3. Write-equivalent rate = 150 MBps + (200 MBps / 4) = 200 MBps
  4. Target utilization = 0.5
  5. Number of vCPUs = ceiling (200 MBps / 20 MBps / 0.5) = 20 vCPUs
  6. Memory = 20 vCPUs * 4 GiB = 80 GiB

Limites des instances dupliquées de partition

Il existe des limites concernant le nombre d'instances dupliquées de partition par cluster et par agent. Il est important d'en tenir compte lorsque vous dimensionnez votre cluster.

La limite par cluster est de 100 000 instances dupliqué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 dupliquées de partition, envisagez de la répartir sur deux clusters ou plus.

La limite par agent est de 4 000 instances dupliquées de partition. Il ne s'agit pas d'une limite stricte. Si vous devez gérer un nombre d'instances dupliquées supérieur à cette limite, envisagez d'augmenter la taille du cluster pour provisionner davantage d'agents. Pour savoir comment le service détermine le nombre d'agents, consultez Provisionnement des agents.

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.

Mettre à jour 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. 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 rapport global entre les processeurs virtuels et la mémoire du cluster doit toujours rester compris entre 1:1 et 1:8.

  • 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 le cluster dispose d'une configuration de disque personnalisée, la mise à jour doit répondre aux exigences de configuration de disque pour le stockage local.

  • Si vous effectuez une mise à l'échelle, la moyenne des processeurs virtuels 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 mettre à l'échelle un cluster de 45 processeurs virtuels (3 agents) à 48 processeurs virtuels (4 agents), la moyenne des 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 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 certain que vos agents disposeront d'une capacité suffisante après la mise à jour, vous pouvez désactiver cette vérification en exécutant la gcloud managed-kafka clusters update commande avec l'indicateur allow_broker_downscale_on_cluster_upscale=true. Cet indicateur signale 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 processeurs virtuels, 130 Gio de RAM et 5 agents.

Exemple d'opération de mise à l'échelle ayant échoué

Mettez à l'échelle le 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 5 à 6 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 6 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 de mise à l'échelle réussie

Mettez à l'échelle le 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 5 à 6 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 6 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 des processeurs virtuels et de la mémoire par agent 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 processeur virtuel à chaque agent. 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 agent reçoit un message, il l'écrit dans un fichier de segment local. Lorsque le fichier de segment atteint une taille ou un âge maximal, il est fermé (ou "renversé") et déplacé vers un stockage distant. 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 renversé, l'agent ouvre un nouveau fichier de segment. Le segment renversé reste dans le stockage local pendant que l'agent le copie dans le stockage distant. Par conséquent, chaque partition a besoin de suffisamment d'espace pour stocker un fichier de segment renversé, ainsi que de l'espace pour un nouveau fichier de segment pendant que le segment renversé est déplacé vers le stockage distant.

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 renversé. En partant de cette hypothèse, la taille minimale du disque par agent est la suivante :

250 MiB * partition count * replication factor / broker count

Toutefois, la taille requise dépend de facteurs tels que la taille maximale du fichier de segment, la charge du cluster, le débit d'écriture des nouvelles données et la latence des écritures dans le stockage à long terme.

Il est essentiel de conserver une certaine capacité de disque inutilisée sur chaque agent. Le comportement d'un agent 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.

Étape suivante