Prácticas recomendadas para agentes Standard - Transmisión administrada de Amazon para Apache Kafka
Consideraciones del clienteConsideraciones del servidor

Prácticas recomendadas para agentes Standard

En este tema se describen algunas de las prácticas recomendadas que debe seguir al utilizar Amazon MSK. Para obtener información sobre las prácticas recomendadas del Replicador Amazon MSK, consulte Prácticas recomendadas para utilizar el Replicador MSK.

Consideraciones del cliente

La disponibilidad y el rendimiento de la aplicación no dependen únicamente de la configuración del lado del servidor, sino también de la configuración del lado del cliente.

  • Configure los clientes para lograr alta disponibilidad. En un sistema distribuido como Apache Kafka, garantizar una alta disponibilidad es fundamental para mantener una infraestructura de mensajería fiable y tolerante a errores. Los agentes pueden quedar fuera de servicio tanto por eventos planificados como no planificados, por ejemplo, actualizaciones, aplicación de parches, fallas de hardware y problemas de red. Un clúster de Kafka tolera la presencia de un agente fuera de línea, por lo que los clientes de Kafka también deben administrar la conmutación por error de un agente sin problemas. Consulte Prácticas recomendadas para clientes de Apache Kafka para ver los detalles completos.

  • Asegúrese de que las cadenas de conexión del cliente incluyan al menos un agente de cada zona de disponibilidad. Tener varios agentes en la cadena de conexión de un cliente permite la conmutación por error cuando un agente específico está sin conexión para una actualización. Para obtener información acerca de cómo obtener una cadena de conexión con varios corredores, consulte Obtención de agentes de arranque para un clúster de Amazon MSK.

  • Ejecute pruebas de rendimiento para verificar que las configuraciones del cliente permiten cumplir los objetivos de rendimiento.

Consideraciones del servidor

Dimensione correctamente el clúster: número de particiones por agente Standard

La siguiente tabla muestra el número recomendado de particiones (incluidas las réplicas líder y seguidoras) por agente Standard. El número recomendado de particiones no se aplica de forma obligatoria y constituye una práctica recomendada para escenarios en los que se envía tráfico a todas las particiones de los temas aprovisionados.

Tamaño del agente Número recomendado de particiones (incluidas las réplicas de seguidor y líder) por agente Número máximo de particiones que admiten las operaciones de actualización
kafka.t3.small 300 300
kafka.m5.large or kafka.m5.xlarge 1 000 1500
kafka.m5.2xlarge 2000 3 000
kafka.m5.4xlarge kafka.m5.8xlarge kafka.m5.12xlarge, kafka.m5.16xlarge o kafka.m5.24xlarge 4000 6000
kafka.m7g.large or kafka.m7g.xlarge 1 000 1500
kafka.m7g.2xlarge 2000 3 000
kafka.m7g.4xlarge, kafka.m7g.8xlarge, kafka.m7g.12xlarge o kafka.m7g.16xlarge 4000 6000

Si tiene casos de uso con muchas particiones y bajo rendimiento, en los que el número de particiones es elevado pero no se envía tráfico a todas estas, puede agrupar más particiones por agente, siempre que haya realizado pruebas suficientes (incluidas pruebas de rendimiento) para validar que el clúster se mantiene en buen estado con un mayor número de particiones. Si el número de particiones por agente supera el valor máximo permitido y el clúster se sobrecarga, no podrá realizar las siguientes operaciones:

  • Actualizar la configuración de un clúster

  • Actualización del clúster a un tamaño más pequeño del agente

  • Asocie un secreto de AWS Secrets Manager a un clúster que tenga autenticación SASL/SCRAM

Un número elevado de particiones también puede hacer que falten métricas de Kafka en CloudWatch y en el raspado de Prometheus.

Para obtener instrucciones acerca de cómo elegir el número de particiones, consulte Apache Kafka Supports 200K Partitions Per Cluster. Sin embargo, también se recomienda que realice sus propias pruebas para determinar el tamaño de instancia adecuado para sus agentes. Para obtener más información sobre los distintos tamaños de agente, consulte Tipos de agentes de Amazon MSK.

Dimensione correctamente el clúster: número de agentes Standard por clúster

Para determinar el número adecuado de agentes Standard para el clúster de MSK aprovisionado y comprender los costos, consulte la hoja de cálculo de dimensionamiento y precios de MSK. Esta hoja de cálculo proporciona una estimación para dimensionar un clúster de MSK aprovisionado y los costos asociados de Amazon MSK, en comparación con un clúster de Apache Kafka autoadministrado similar basado en EC2. Para obtener más información acerca de los parámetros de entrada en la hoja de cálculo, pasa el puntero del ratón por encima de las descripciones de los parámetros. Las estimaciones proporcionadas por esta hoja son conservadoras y ofrecen un punto de partida para un nuevo clúster de MSK aprovisionado. El rendimiento, el tamaño y los costos del clúster dependen del caso de uso, por lo que le recomendamos que los compruebe realizando pruebas reales.

Para entender cómo la infraestructura subyacente afecta al rendimiento de Apache Kafka, consulte Best practices for right-sizing your Apache Kafka clusters to optimize performance and cost en el Blog de macrodatos de AWS. La entrada del blog proporciona información sobre cómo dimensionar los clústeres para cumplir con los requisitos de rendimiento, disponibilidad y latencia. También proporciona respuestas a preguntas como cuándo conviene escalar verticalmente frente a escalar horizontalmente, así como orientación sobre cómo verificar de forma continua el tamaño de los clústeres de producción. Para obtener información sobre clústeres basados en almacenamiento por niveles, consulte Prácticas recomendadas para ejecutar cargas de trabajo de producción con almacenamiento por niveles de Amazon MSK.

Optimización del rendimiento de los clústeres para instancias m5.4xl, m7g.4xl o más grandes

Al utilizar instancias m5.4xlarge, m7g.4xlarge o superiores, puede optimizar el rendimiento del clúster de MSK aprovisionado si ajusta las configuraciones num.io.threads y num.network.threads.

Num.io.threads es el número de subprocesos que un agente Standard utiliza para procesar solicitudes. Si se agregan más subprocesos, hasta el número de núcleos de CPU compatibles con el tamaño de la instancia, se mejora el rendimiento del clúster.

Num.network.threads es el número de subprocesos que el agente Standard utiliza para recibir todas las solicitudes entrantes y devolver las respuestas. Los subprocesos de red colocan las solicitudes entrantes en una cola de solicitudes para que io.threads las procese. Si se configura num.network.threads en la mitad del número de núcleos de CPU compatibles con el tamaño de instancia, se podrá utilizar al máximo el nuevo tamaño de instancia.

importante

No aumente num.network.threads sin aumentar primero num.io.threads, ya que esto puede provocar una congestión relacionada con la saturación de las colas.

En la siguiente tabla, se describe la configuración recomendada para cada tamaño de instancia.

Tamaño de instancia Valor recomendado para num.io.threads Valor recomendado para num.network.threads

m5.4xl

16

8

m5.8xl

32

16

m5.12xl

48

24

m5.16xl

64

32

m5.24xl

96

48

m7g.4xlarge

16

8

m7g.8xlarge

32

16

m7g.12xlarge

48

24

m7g.16xlarge

64

32

Utilice la última versión de Kafka AdminClient para evitar problemas de discordancia en los ID de los temas

El ID de un tema se pierde (error: no coincide el ID del tema con el ID de la partición) cuando se utiliza una versión de Kafka AdminClient inferior a la 2.8.0 con la marca --zookeeper para aumentar o reasignar particiones de temas en un clúster de MSK aprovisionado que usa Kafka versión 2.8.0 o posterior. Tenga en cuenta que el indicador --zookeeper está obsoleto en la versión 2.5 de Kafka y se elimina a partir de la versión 3.0 de Kafka. Consulte Upgrading to 2.5.0 from any version 0.8.x through 2.4.x.

Para evitar problemas de discordancia en los ID de los temas, utilice un cliente de la versión 2.8.0 o superior de Kafka para las operaciones de administración de Kafka. Como alternativa, los clientes de la versión 2.5 y posterior pueden usar el indicador --bootstrap-servers en lugar del indicador --zookeeper.

Crear clústeres de alta disponibilidad

Utilice las siguientes recomendaciones para que los clústeres de MSK aprovisionados mantengan una alta disponibilidad durante una actualización (por ejemplo, al actualizar el tamaño del agente o la versión de Apache Kafka) o cuando Amazon MSK reemplaza un agente.

  • Configure un clúster con tres zonas de disponibilidad.

  • Asegúrese de que el factor de replicación (RF) sea de al menos 3. Tenga en cuenta que un RF de 1 puede provocar que las particiones estén sin conexión durante una actualización sucesiva, y un RF de 2 puede provocar la pérdida de datos.

  • Establezca el mínimo de réplicas en sincronización (MiniSR) como máximo RF - 1. Un miniSR igual a RF puede impedir que se produzca en el clúster durante una actualización sucesiva. Un miniSR de 2 permite que los temas replicados de tres vías estén disponibles cuando una réplica está fuera de línea.

Supervisisión del uso de CPU

Amazon MSK recomienda firmemente mantener la utilización de CPU de los agentes (definida como CPU User + CPU System) por debajo del 60 %. Esto garantiza que el clúster retenga suficiente margen de CPU para manejar eventos operativos, como fallas de agentes, aplicación de parches y actualizaciones graduales.

Apache Kafka puede redistribuir la carga de CPU entre los agentes del clúster cuando resulta necesario. Por ejemplo, cuando Amazon MSK detecta y se recupera de una falla en un agente, realiza tareas de mantenimiento automático, como la aplicación de parches. De forma similar, cuando un usuario solicita un cambio en el tamaño del agente o una actualización de versión, Amazon MSK inicia flujos de trabajo graduales que dejan fuera de servicio un agente a la vez. Cuando los agentes con particiones principales se desconectan, Apache Kafka reasigna el liderazgo de la partición para redistribuir el trabajo entre los demás agentes del clúster. Al seguir esta práctica recomendada, se garantiza un margen de CPU suficiente para tolerar estos eventos operativos.

nota

Al supervisar la utilización de la CPU, tenga en cuenta que el uso total de CPU incluye más componentes que CPU User y CPU System. Otras categorías, como iowait, irq, softirq y steal, también contribuyen a la actividad total de la CPU. En consecuencia, CPU inactiva no siempre es igual a 100% - CPU User - CPU System.

Puede usar la Calculadora de métricas matemáticas de Amazon CloudWatch para crear una métrica compuesta (CPU User + CPU System) y configurar una alarma que se active cuando el uso promedio supere el 60 %. Cuando se active la alarma, considere escalar el clúster mediante una de las siguientes opciones:

  • Opción 1 (recomendada): actualice el tamaño de su agente al siguiente tamaño más grande. Por ejemplo, si el tamaño actual es kafka.m5.large, actualice el clúster para que utilice kafka.m5.xlarge. Tenga en cuenta que, al actualizar el tamaño del agente del clúster, Amazon MSK desconecta a los agentes de forma continua y reasigna temporalmente el liderazgo de la partición a otros agentes. Por lo general, una actualización de tamaño tarda entre 10 y 15 minutos por agente.

  • Opción 2: si hay temas en los que todos los mensajes provienen de productores que realizan escrituras siguiendo un sistema rotativo (en otras palabras, los mensajes no están codificados y el orden no es importante para los consumidores), amplíe su clúster agregando agentes. Agregue también particiones a los temas existentes con el mayor rendimiento. A continuación, use kafka-topics.sh --describe para asegurarse de que las particiones recién agregadas se asignen a los nuevos agentes. La principal ventaja de esta opción en comparación con la anterior es que permite administrar los recursos y los costos de forma más detallada. Además, puede utilizar esta opción si la carga de la CPU supera con creces el 60 %, ya que esta forma de escalado no suele provocar un aumento de la carga para los agentes existentes.

  • Opción 3: amplíe el clúster de Amazon MSK aprovisionado. Para ello, agregue agentes y, a continuación, reasigne las particiones existentes mediante la herramienta de reasignación de particiones denominada kafka-reassign-partitions.sh. Sin embargo, si usa esta opción, el clúster necesitará gastar recursos para replicar los datos de un agente a otro después de reasignar las particiones. En comparación con las dos opciones anteriores, esto puede aumentar significativamente la carga del clúster al principio. En consecuencia, Amazon MSK no recomienda usar esta opción cuando el uso de la CPU sea superior al 70 %, ya que la replicación provoca una carga de CPU y tráfico de red adicionales. Amazon MSK solo recomienda usar esta opción si las dos opciones anteriores no son factibles.

Otras recomendaciones:

  • Supervise el uso total de la CPU por agente como proxy para la distribución de la carga. Si los agentes utilizan la CPU de manera uniforme, podría ser una señal de que la carga no está distribuida de manera uniforme dentro del clúster. Recomendamos usar Cruise Control para administrar de forma continua la distribución de la carga mediante la asignación de particiones.

  • Supervise la latencia de producción y consumo. La latencia de producción y consumo puede aumentar linealmente con el uso de la CPU.

  • Intervalo de raspado de JMX: si habilita la supervisión abierta con la característica Prometheus, se recomienda utilizar un intervalo de raspado de 60 segundos o más (scrape_interval: 60s) para la configuración de su host de Prometheus (prometheus.yml). Reducir el intervalo de raspado puede provocar un uso elevado de la CPU en el clúster.

Monitorear el espacio en disco

Para evitar quedarse sin espacio en disco para los mensajes, cree una alarma de CloudWatch que vigile la métrica KafkaDataLogsDiskUsed. Cuando el valor de esta métrica alcance o supere el 85 %, realice una o varias de las siguientes acciones:

Para obtener información sobre cómo configurar y utilizar las alarmas, consulte Uso de las alarmas de Amazon CloudWatch. Para obtener una lista completa de las métricas de Amazon MSK, consulte Supervisión de un clúster de Amazon MSK aprovisionado.

Ajuste los parámetros de retención de datos

El consumo de los mensajes no los elimina del registro. Para liberar espacio en disco de manera regular, puede especificar explícitamente un periodo de retención, que es el tiempo que permanecen los mensajes en el registro. También puede especificar el tamaño del registro de una retención. Cuando se alcanza el periodo de retención o el tamaño del registro de retención, Apache Kafka comienza a eliminar los segmentos inactivos del registro.

Para especificar una política de retención en el nivel del clúster, establezca uno o varios de los siguientes parámetros: log.retention.hours, log.retention.minutes, log.retention.ms o log.retention.bytes. Para obtener más información, consulte Configuraciones personalizadas de Amazon MSK.

También puede especificar los parámetros de retención en el nivel de tema:

  • Para especificar un periodo de retención por tema, utilice el siguiente comando.

    kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-name TopicName --add-config retention.ms=DesiredRetentionTimePeriod

  • Para especificar un tamaño de registro de retención por tema, utilice el siguiente comando.

    kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-name TopicName --add-config retention.bytes=DesiredRetentionLogSize

Los parámetros de retención que especifique en el nivel del tema tienen preferencia sobre los parámetros del nivel del clúster.

Aceleración de la recuperación de registros después de un cierre incorrecto

Tras un cierre incorrecto, un agente puede tardar un poco en reiniciarse, al igual que hace con la recuperación de registros. De forma predeterminada, Kafka solo usa un subproceso por directorio de registro para realizar esta recuperación. Por ejemplo, si tiene miles de particiones, la recuperación del registro puede tardar horas en completarse. Para acelerar la recuperación de registros, se recomienda aumentar el número de subprocesos mediante la propiedad de configuración num.recovery.threads.per.data.dir. Puede configurarla en el número de núcleos de CPU.

Supervisión de la memoria de Apache Kafka

Se recomienda supervisar la memoria que utiliza Apache Kafka. De lo contrario, es posible que el clúster deje de estar disponible.

Para determinar la cantidad de memoria que utiliza Apache Kafka, puede supervisar la métrica HeapMemoryAfterGC. HeapMemoryAfterGC es el porcentaje de la memoria dinámica total que se utiliza después de la recopilación de elementos no utilizados. Le recomendamos que cree una alarma de CloudWatch que actúe cuando HeapMemoryAfterGC aumente por encima del 60 %.

Los pasos que puede realizar para reducir el uso de memoria varían. Dependen de la forma en que se configure Apache Kafka. Por ejemplo, si utiliza la entrega transaccional de mensajes, puede reducir el valor de transactional.id.expiration.ms de la configuración de Apache Kafka de 604800000 ms a 86400000 ms (de 7 días a 1 día). Esto reduce la huella de memoria de cada transacción.

No agregue a agentes que no sean de MSK

Para los clústeres de Amazon MSK aprovisionados basados en ZooKeeper, si utiliza comandos de Apache ZooKeeper para agregar agentes, estos agentes no se agregan al clúster de Amazon MSK aprovisionado y Apache ZooKeeper contendrá información incorrecta sobre el clúster. Esto podría provocar la pérdida de datos. Para conocer las operaciones compatibles de un clúster de MSK aprovisionado, consulte Características y conceptos clave de Amazon MSK.

Habilitar el cifrado en tránsito

Para obtener información sobre el cifrado en tránsito y cómo habilitarlo, consulte Cifrado en tránsito de Amazon MSK.

Reasignar particiones

Para mover particiones a distintos agentes dentro del mismo clúster de MSK aprovisionado, puede usar la herramienta de reasignación de particiones denominada kafka-reassign-partitions.sh. Se recomienda no reasignar más de 10 particiones en una sola llamada kafka-reassign-partitions para realizar operaciones seguras. Por ejemplo, después de agregar nuevos agentes para expandir un clúster o para mover las particiones y eliminar agentes, puede reequilibrar el clúster reasignando las particiones a los nuevos agentes. Para obtener información sobre cómo agregar agentes a un clúster de MSK aprovisionado, consulte Expansión de la cantidad de agentes en un clúster de Amazon MSK. Para obtener información sobre cómo eliminar agentes de un clúster de MSK aprovisionado, consulte Eliminación de un agente de un clúster de Amazon MSK. Para obtener información acerca de la herramienta de reasignación de particiones, consulte Expansión de su clúster en la documentación de Apache Kafka.