En este documento, se describe cómo estimar la capacidad que necesitas para un clúster de Managed Service para Apache Kafka y cómo ajustar el tamaño de un clúster existente.
Cuando creas un clúster de Managed Service para Apache Kafka, eliges los siguientes parámetros para el tamaño del clúster:
vCPUs: Es la cantidad de CPU virtuales en el clúster. La cantidad mínima de CPU virtuales es 3.
Memoria: Es la cantidad de memoria por CPU virtual. Debes aprovisionar entre 1 GiB y 8 GiB por CPU virtual.
Puedes actualizar estos valores después de crear el clúster.
Elige el tamaño inicial del clúster
Para elegir el tamaño inicial del clúster, comienza por estimar los siguientes valores según tu carga de trabajo específica.
- Capacidad de procesamiento de escritura: Es la tasa total a la que los productores envían datos al clúster, en MB/s.
- Capacidad de procesamiento de lectura: Es la tasa total a la que los consumidores leen datos del clúster, en MBps.
Para estimar el tamaño de un clúster necesario para controlar este procesamiento, sigue estos pasos:
Calcula el ancho de banda de escritura total, incluida la replicación.
Total write bandwidth = produce rate * replicasEste valor incluye el ancho de banda del cliente al broker líder y del líder a los brokers de réplica. La cantidad predeterminada de réplicas es 3.
Calcula el ancho de banda de lectura total, incluida la replicación.
Total read bandwidth = consume rate + produce rate * ( replicas - 1)Este valor incluye el ancho de banda para las operaciones de lectura del cliente (tasa de consumo) y el ancho de banda necesario para que las réplicas permanezcan sincronizadas. Las réplicas se sincronizan leyendo datos del líder de la partición. Se usa el término
(replicas - 1)porque el líder de la partición no lee de ninguna réplica.Calcula la tasa de datos equivalente a la escritura.
Como regla general, el ancho de banda de lectura es 4 veces más eficiente de procesar que el ancho de banda de escritura. Para tener en cuenta esta diferencia, calcula la tasa de datos equivalente a la escritura de la siguiente manera:
Write-equivalent rate = (total write bandwidth) + (total read bandwidth / 4)Determina el uso de CPU virtual objetivo. Este valor representa el uso promedio de la CPU virtual como un porcentaje de la capacidad de la CPU virtual. La utilización real puede aumentar o disminuir con el tiempo.
- Como referencia, comienza con un objetivo de utilización del 50%.
- Si conoces los patrones de tráfico esperados, establece el objetivo de utilización en el mismo valor que la proporción entre el ancho de banda promedio equivalente a escritura y el ancho de banda máximo que debes admitir.
En general, aumentar la utilización reduce el costo del clúster, ya que disminuye su tamaño, pero también es más riesgoso si el tráfico supera las estimaciones. El uso excesivo de CPU virtuales puede causar latencias y errores altos.
Calcula la cantidad de CPU virtuales.
vCPU count = ceiling (write-equivalent rate / 20 MBps / utilization)La capacidad estimada para una sola CPU virtual en una sola zona es de 20 MBps. Por lo tanto, si las CPU virtuales se ejecutaran con un 100% de utilización, necesitarías
(write-equivalent rate / 20)CPU virtuales. Para obtener la cantidad real, divide ese valor por el uso objetivo y redondea hacia arriba.Además, enviar mensajes en lotes de menos de 10 KB reduce el rendimiento por CPU en relación con la comparativa aquí. En ese caso, ten en cuenta la capacidad de procesamiento reducida o considera enviar lotes más grandes.
Estima la memoria requerida. Recomendamos 4 GiB de RAM por cada CPU virtual.
Memory = vCPU count * 4 GiB
Realiza pruebas con tu carga de trabajo real para obtener el tamaño más preciso. Supervisa el uso de recursos del clúster y aumenta la escala si es necesario.
Cálculo del tamaño de la muestra
Supongamos que una carga de trabajo tiene una tasa de escritura de 50 MB/s y una tasa de lectura de 100 MB/s, con 3 réplicas y una utilización objetivo de CPU virtual del 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
Límites de réplicas de partición
Existen límites en la cantidad de réplicas de particiones por clúster y por agente que son importantes tener en cuenta cuando se determina el tamaño del clúster.
El límite por clúster es de 100,000 réplicas de partición. Este es un límite estricto y es independiente de la cantidad de intermediarios en un clúster. Si tu carga de trabajo requiere más de 100,000 réplicas de partición, considera dividirla entre dos o más clústeres.
El límite por agente es de 4,000 réplicas de partición. Este no es un límite estricto. Si necesitas controlar más de esta cantidad de réplicas, considera aumentar el tamaño del clúster para aprovisionar más intermediarios. Para obtener información sobre cómo el servicio determina la cantidad de intermediarios, consulta Aprovisionamiento de intermediarios.
Una vez que tengas una cantidad suficiente de intermediarios para controlar tus particiones, puedes ajustar el tamaño de los intermediarios para que se adapten a la capacidad de procesamiento.
Actualiza el tamaño del clúster
Después de crear un clúster de Managed Service para Apache Kafka, puedes ajustar la cantidad de CPU virtuales y la memoria para satisfacer tus necesidades. Para obtener más información, consulta Cómo actualizar un clúster de Managed Service para Apache Kafka.
Cuando actualizas un clúster existente, se aplican las siguientes reglas:
La proporción general de CPU virtuales a memoria del clúster siempre debe permanecer entre 1:1 y 1:8.
Debe haber al menos 1 CPU virtual y 1 GiB de memoria para cada agente existente. La cantidad de agentes nunca disminuye.
Si el clúster tiene una configuración de disco personalizada, la actualización debe cumplir con los requisitos de configuración de disco para el almacenamiento local.
Si aumentas la escala, el promedio de CPU virtuales y memoria por agente no puede disminuir en más del 10% en comparación con los promedios anteriores a la actualización. Por ejemplo, si intentas aumentar la escala de un clúster de 45 CPU virtuales (3 intermediarios) a 48 CPU virtuales (4 intermediarios), la CPU virtual promedio por intermediario disminuye de 15 a 12, lo que representa una reducción del 20%, que supera el límite del 10%.
Si necesitas reducir el recuento de CPU virtuales en más de un 10%, te recomendamos que lo hagas en varias etapas. Después de cada actualización, supervisa el uso de recursos y reequilibra las particiones si es necesario.
Sin embargo, si tienes la certeza de que tus intermediarios tendrán capacidad suficiente después de la actualización, puedes inhabilitar esta verificación ejecutando el comando
gcloud managed-kafka clusters updatecon la marcaallow_broker_downscale_on_cluster_upscale=true. Esta marca indica que aceptas el posible riesgo de rendimiento.
Ejemplo de operaciones de actualización
En los siguientes ejemplos, se comienza con un clúster que tiene 75 CPU virtuales, 130 GiB de RAM y 5 intermediarios.
Ejemplo de una operación de aumento de resolución fallida
Aumenta la capacidad del clúster a 80 CPU virtuales y 140 GiB de RAM.
El servicio determina si se necesita un nuevo agente.
- techo (80 CPU virtuales / 15) = 6 intermediarios
El clúster crecería de 5 a 6 intermediarios, por lo que se activaría la verificación de seguridad del 10%.
Los promedios actuales por corredor son los siguientes:
75 CPUs virtuales / 5 intermediarios = 15 CPUs virtuales por intermediario
130 GiB / 5 agentes = 26 GiB por agente
Con 6 corredores, los nuevos promedios son los siguientes:
80 CPU virtuales / 6 intermediarios = 13.33 CPU virtuales por intermediario, una reducción del 11.1%
140 GiB / 6 agentes = 23.33 GiB por agente, una reducción del 10.2%
La operación falla porque estos promedios superan el 10%.
Ejemplo de una operación de aumento de resolución exitosa
Aumenta la capacidad del clúster a 85 CPU virtuales y 150 GiB de RAM.
El servicio determina si se necesita un nuevo agente.
- techo (85 CPU virtuales / 15) = 6 intermediarios
El clúster crecería de 5 a 6 intermediarios, por lo que se activaría la verificación de seguridad del 10%.
Los promedios actuales por corredor son los siguientes:
75 CPUs virtuales / 5 intermediarios = 15 CPUs virtuales por intermediario
130 GiB / 5 agentes = 26 GiB por agente
Con 6 corredores, los nuevos promedios son los siguientes:
85 CPU virtuales / 6 intermediarios = 14.17 CPU virtuales por intermediario, una reducción del 5.5%
150 GiB / 6 agentes = 25 GiB por agente, una reducción del 3.8%
Esta operación se realiza correctamente porque la reducción en la CPU virtual y la memoria promedio por agente se encuentra dentro del límite del 10%.
Estima el tamaño de disco requerido
De forma predeterminada, Managed Service para Apache Kafka asigna 100 GiB por CPU virtual a cada agente. La asignación predeterminada proporciona suficiente almacenamiento local para la mayoría de las cargas de trabajo, pero puedes configurar el tamaño del disco del agente para tus requisitos específicos. En esta sección, se describe cómo estimar la cantidad de capacidad de disco que necesitas.
Cuando un agente recibe un mensaje, lo escribe en un archivo de segmento local.
Cuando el archivo de segmento alcanza un tamaño o una antigüedad máximos, se cierra (o "rota") y se mueve al almacenamiento remoto. El tamaño máximo de un archivo de segmento se especifica con el parámetro de configuración log.roll.bytes, y la antigüedad máxima se especifica con el parámetro de configuración log.segment.ms.
Cuando se lanza un archivo de segmento, el agente abre un archivo de segmento nuevo. El segmento acumulado permanece en el almacenamiento local mientras el agente lo copia en el almacenamiento remoto. Por lo tanto, cada partición necesita espacio suficiente para almacenar un archivo de segmento rotado, además de espacio para un archivo de segmento nuevo mientras el segmento rotado se mueve al almacenamiento remoto.
De forma predeterminada, el tamaño máximo de un archivo de segmento es de 230 MiB. En el caso de los clústeres con una utilización moderada, puedes suponer que se necesitan 250 MiB por partición para proporcionar espacio de búfer adicional mientras se mueve un segmento rotado. Con esta suposición, el tamaño mínimo del disco por agente es el siguiente:
250 MiB * partition count * replication factor / broker count
Sin embargo, el tamaño requerido depende de factores como el tamaño máximo del archivo de segmento, la carga en el clúster, la velocidad a la que se escriben los datos nuevos y la latencia de las escrituras en el almacenamiento a largo plazo.
Es fundamental mantener cierta capacidad de disco sin usar en cada agente. El comportamiento de un agente sin capacidad de disco no es predecible y puede provocar la pérdida de datos, así como la inestabilidad del clúster.
Supervisa el uso del disco (disk/used_bytes) en comparación con el tamaño total disponible del disco (disk/limit). Si el uso del disco supera el 80% del tamaño total disponible del disco, configura un tamaño de disco más grande. Para obtener más información, consulta Supervisa la capacidad del clúster.
¿Qué sigue?
- Crea un clúster de Managed Service para Apache Kafka
- Supervisa un clúster de Managed Service para Apache Kafka
- Actualiza un clúster de Managed Service para Apache Kafka
- Configura el tamaño del disco del agente