Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Prácticas recomendadas para los corredores de Standard
En este tema se describen algunas de las prácticas recomendadas que se deben seguir al utilizar AmazonMSK. Para obtener información sobre las prácticas recomendadas de Amazon MSK Replicator, consultePrácticas recomendadas para usar MSK Replicator.
Consideraciones del lado del cliente
La disponibilidad y el rendimiento de su aplicación dependen no solo de la configuración del lado del servidor, sino también de la configuración del cliente.
-
Configure sus clientes para una 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 corredores se desconectarán por eventos planificados y no planificados, por ejemplo, por actualizaciones, parches, fallas de hardware o 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 todos los detalles en. Mejores prácticas para los clientes de Apache Kafka
-
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 Obtenga los agentes de arranque para un clúster de Amazon MSK.
-
Realice pruebas de rendimiento para comprobar que las configuraciones de sus clientes le permiten cumplir sus objetivos de rendimiento.
Consideraciones del lado del servidor
Asigne el tamaño correcto a su clúster: número de particiones por agente estándar
La siguiente tabla muestra el número recomendado de particiones (incluidas las réplicas líder y seguidora) por agente estándar. El número recomendado de particiones no se aplica y es una práctica recomendada en situaciones en las que se envía tráfico a todas las particiones temáticas aprovisionadas.
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 operaciones de actualización |
---|---|---|
kafka.t3.small |
300 | 300 |
kafka.m5.large o 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 o 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 un número elevado de particiones y un rendimiento reducido en los que tiene un mayor número de particiones, pero no envía tráfico a todas las particiones, puede empaquetar más particiones por agente, siempre y cuando haya realizado suficientes pruebas y pruebas de rendimiento para comprobar 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 AWS Secrets Manager secreto a un clúster que tenga autenticaciónSASL/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
Asigne el tamaño adecuado a su clúster: número de corredores estándar por clúster
Para determinar el número correcto de agentes estándar para su clúster MSK aprovisionado y comprender los costos, consulte la hoja de cálculo de MSKtamaño y
Para comprender cómo afecta la infraestructura subyacente 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
Optimización del rendimiento de los clústeres para instancias m5.4xl, m7g.4xl o más grandes
Cuando utilice instancias m5.4xl, m7g.4xl o de mayor tamaño, puede optimizar el rendimiento del clúster aprovisionado ajustando las configuraciones num.io.threads y num.network.threadsMSK.
Num.io.Threads es el número de subprocesos que utiliza un agente estándar para procesar las solicitudes. Añadir más subprocesos, hasta el número de CPU núcleos admitidos para 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 bróker estándar 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 CPU núcleos admitidos para 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.
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 el indicador para aumentar o reasignar las particiones de los temas --zookeeper
para un clúster MSK aprovisionado 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 sus clústeres MSK aprovisionados estén altamente disponibles 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 número mínimo de réplicas sincronizadas (mínimoISR) en RF - 1 como máximo. Un mínimo ISR igual a la RF puede impedir la producción en el clúster durante una actualización sucesiva. Un mínimo ISR de 2 permite que los temas replicados en tres direcciones estén disponibles cuando una réplica está fuera de línea.
Supervise el uso CPU
Amazon recomienda MSK encarecidamente que mantengas la CPU utilización total de tus agentes (definida comoCPU User + CPU System
) por debajo del 60%. Cuando tenga CPU disponible al menos el 40% del total de su clúster, Apache Kafka podrá redistribuir la CPU carga entre los agentes del clúster cuando sea necesario. Un ejemplo de cuando esto es necesario es cuando Amazon MSK detecta y se recupera de un error de un corredor; 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, puede asegurarse de tener suficiente CPU espacio 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 CPU utilización media 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 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 utilicekafka.m5.xlarge
. Ten en cuenta que cuando actualizas 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, puedes utilizar esta opción si la CPU carga supera con creces el 60%, ya que esta forma de escalamiento no suele implicar un aumento de la carga para los corredores existentes. -
Opción 3: Amplíe su clúster MSK aprovisionado añadiendo agentes y, a continuación, reasigne las particiones existentes mediante la herramienta de reasignación de particiones denominada así.
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. Como resultado, Amazon MSK no recomienda usar esta opción cuando el uso sea superior CPU al 70%, ya que la replicación genera CPU carga 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 CPU la utilización total por intermediario como indicador de la distribución de la carga. Si los corredores tienen un CPU uso uniforme y constante, podría ser una señal de que la carga no está distribuida de manera uniforme dentro del clúster. Recomendamos utilizar el Cruise Control para gestionar 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 CPU la utilización.
-
JMXintervalo de raspado: si habilita la supervisión abierta con la función 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 extracción puede provocar un uso elevado del clúster. CPU
Monitorear el espacio en disco
Para evitar quedarte sin espacio en disco para los mensajes, crea 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 para MSK clústeres de Amazon. También puede aumentar manualmente el almacenamiento del agente, tal y como se describe en Escalado manual para corredores estándar.
-
Reduzca el periodo 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 ver una lista completa de MSK las métricas de Amazon, consultaSupervise un clúster de Amazon MSK Provisioned.
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 MSKConfiguraciones personalizadas de Amazon.
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 configurarlo en función del número de CPU núcleos.
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 añada a agentes que no sean MSK corredores
En el caso de los clústeres MSK aprovisionados ZooKeeper basados, si utilizas ZooKeeper comandos de Apache para añadir agentes, estos agentes no se añadirán a tu clúster MSK aprovisionado y tu Apache ZooKeeper contendrá información incorrecta sobre el clúster. Esto podría provocar la pérdida de datos. Para obtener información sobre las operaciones de clústeres MSK aprovisionados compatibles, consulte. Características y conceptos MSK clave de Amazon
Habilitar el cifrado en tránsito
Para obtener información sobre el cifrado en tránsito y cómo habilitarlo, consulte MSKCifrado de Amazon en tránsito.
Reasignar particiones
Para mover particiones a distintos agentes del mismo clúster MSK aprovisionado, puede usar la herramienta de reasignación de particiones denominada. kafka-reassign-partitions.sh
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 añadir agentes a un clúster MSK aprovisionado, consulte. Ampliar el número de agentes en un MSK clúster de Amazon Para obtener información sobre cómo eliminar agentes de un clúster MSK aprovisionado, consulte. Eliminar un bróker de un MSK clúster de Amazon Para obtener información acerca de la herramienta de reasignación de particiones, consulte Expansión de su clúster