Prácticas recomendadas

En este tema se describen algunas de las prácticas recomendadas que debe seguir al utilizar Amazon MSK.

Dimensionamiento correcto del clúster: número de particiones por agente

La siguiente tabla muestra el número recomendado de particiones (incluidas las réplicas de seguidor y líder) por agente.

Tamaño del bróker	Número recomendado de particiones (incluidas las réplicas de seguidor y líder) por agente
kafka.t3.small	300
kafka.m5.large o kafka.m5.xlarge	1 000
kafka.m5.2xlarge	2000
kafka.m5.4xlarge kafka.m5.8xlarge kafka.m5.12xlarge, kafka.m5.16xlarge o kafka.m5.24xlarge	4000
kafka.m7g.large o kafka.m7g.xlarge	1 000
kafka.m7g.2xlarge	2000
kafka.m7g.4xlarge, kafka.m7g.8xlargekafka.m7g.12xlarge, o kafka.m7g.16xlarge	4000

Si el número de particiones por agente supera el valor recomendado y el clúster se sobrecarga, es posible que no pueda realizar las siguientes operaciones:

• Actualizar la configuración de un clúster

• Actualice el clúster a un tamaño de corredor más pequeño

• Asocie un AWS Secrets Manager secreto 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 sobre 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. También le recomendamos que realice sus propias pruebas para determinar el tamaño adecuado para sus corredores. Para obtener más información sobre los diferentes tamaños de corredores, consulteTamaños de bróker.

Ajuste el tamaño correcto de su clúster: número de agentes por clúster

Para determinar el número adecuado de agentes de su clúster de MSK y comprender los costos, consulte la hoja de cálculo MSK Sizing and Pricing. Esta hoja de cálculo proporciona una estimación del tamaño de un clúster de MSK y los costos asociados de Amazon MSK en comparación con un clúster Apache Kafka similar, administrado por cuenta propia, 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 en esta hoja son moderadas y proporcionan un punto de partida para un nuevo clúster. 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 las prácticas recomendadas para ajustar el tamaño de los clústeres de Apache Kafka a fin de optimizar el rendimiento y los costes en el AWS blog sobre macrodatos. 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 se debe escalar o desescalar verticalmente, así como también orientación sobre cómo verificar continuamente el tamaño de los clústeres de producción.

Optimice el rendimiento del clúster para instancias m5.4xl, m7g.4xl o superiores

Cuando utilice instancias m5.4xl, m7g.4xl o de mayor tamaño, puede optimizar el rendimiento del clúster ajustando las configuraciones num.io.threads y num.network.threads.

Num.io.threads es el número de subprocesos que utiliza un agente para procesar las solicitudes. Añadir más subprocesos, hasta el número de núcleos de CPU compatibles con el tamaño de la instancia, puede ayudar a mejorar el rendimiento del clúster.

Num.network.threads es el número de subprocesos que el agente 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 la instancia, se podrá aprovechar al máximo el nuevo tamaño de la 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.

Configuración recomendada
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

Usa la versión más reciente de Kafka para evitar un problema de discordancia en AdminClient los identificadores de

El identificador de un tema se pierde (error: no coincide con el identificador del tema de la partición) cuando se utiliza una AdminClient versión de Kafka anterior a la 2.8.0 con la marca para aumentar o reasignar las particiones de temas --zookeeper para un clúster que utilice la versión 2.8.0 o superior de Kafka. 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

Siga las siguientes recomendaciones para que su clúster de MSK tenga 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 sustituya a 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.

• 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.

Supervisisión del uso de CPU

Amazon MSK recomienda encarecidamente que mantenga el uso total de la CPU por parte de sus agentes (definido como CPU User + CPU System) por debajo del 60 %. Cuando tenga disponible al menos el 40 % de la CPU total del clúster, Apache Kafka podrá redistribuir la carga de la CPU entre los agentes del clúster cuando sea necesario. Un ejemplo de cuando esto es necesario es cuando Amazon MSK detecta un error de un agente y lo resuelve; en este caso, Amazon MSK realiza un mantenimiento automático, como la aplicación de parches. Otro ejemplo es cuando un usuario solicita un cambio del tamaño de un agente o una actualización de versión; en estos dos casos, Amazon MSK implementa flujos de trabajo continuos que desconectan a 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. Si sigue esta práctica recomendada, podrá garantizar que haya suficiente espacio de CPU en su clúster para tolerar eventos operativos como estos.

Puede utilizar las matemáticas CloudWatch métricas de Amazon para crear una métrica compuesta, es decirCPU User + CPU System. Configure una alarma que se active cuando la métrica compuesta alcance una utilización media de la CPU del 60 %. Cuando se active esta alarma, escale el clúster mediante una de las siguientes opciones:

• Opción 1 (recomendada): actualice el tamaño de su corredor al tamaño siguiente más grande. Por ejemplo, si el tamaño actual eskafka.m5.large, actualice el clúster que desee utilizarkafka.m5.xlarge. Tenga en cuenta que, al actualizar el tamaño del bróker en el clúster, Amazon MSK desconecta a los corredores de forma continua y reasigna temporalmente el liderazgo de la partición a otros corredores. 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 su clúster agregando 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. Amazon MSK recomienda utilizar 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 CloudWatch alarma que controle la KafkaDataLogsDiskUsed métrica. Cuando el valor de esta métrica alcance o supere el 85 %, realice una o varias de las siguientes acciones:

• Utilice Escalado automático. También puede aumentar manualmente el almacenamiento del agente, tal y como se describe en Escalado manual.

• Reduzca el período de retención de mensajes o el tamaño del registro. Para obtener información sobre cómo hacerlo, consulte Ajuste los parámetros de retención de datos.

• Elimine los temas que no se utilicen.

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

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 período 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 período 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 MSK.

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

• Para especificar un período 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 CloudWatch alarma que actúe cuando los HeapMemoryAfterGC aumentos superen el 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

En el caso de los clústeres ZooKeeper basados, si utilizas ZooKeeper comandos de Apache para añadir agentes, estos agentes no se añadirán a tu clúster de MSK y tu Apache ZooKeeper contendrá información incorrecta sobre el clúster. Esto podría provocar la pérdida de datos. Para obtenerlas operaciones del clúster admitidas, consulte Funcionamiento 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.

Reasignar particiones

Para mover las particiones a agentes diferentes en el mismo clúster, puede utilizar la herramienta de reasignación de particiones denominada kafka-reassign-partitions.sh. Por ejemplo, después de añadir nuevos corredores para expandir un clúster o de mover particiones para eliminarlos, puede reequilibrar ese clúster reasignando las particiones a los nuevos corredores. Para obtener información acerca de cómo agregar agentes a un clúster, consulte Expansión de un clúster de Amazon MSK. Para obtener información sobre cómo eliminar corredores de un clúster, consulte. Eliminar un bróker 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.