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.
En este tema se describen algunas de las mejores prácticas que se deben seguir al utilizar corredores de Express. Los corredores Express vienen preconfigurados para ofrecer una alta disponibilidad y durabilidad. De forma predeterminada, sus datos se distribuyen en tres zonas de disponibilidad, la replicación siempre se establece en 3 y la réplica sincronizada mínima siempre se establece en 2. Sin embargo, aún hay algunos factores que se deben tener en cuenta para optimizar la confiabilidad y el rendimiento del clúster.
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 las recomendaciones de mejores prácticas para los clientes de Apache Kafka.
Realice pruebas de rendimiento para comprobar que las configuraciones de sus clientes le permiten cumplir sus objetivos de rendimiento incluso cuando reiniciamos los corredores en momentos de máxima carga. Puede reiniciar los corredores de su clúster desde la consola MSK o mediante APIs MSK.
Consideraciones del lado del servidor
Ajuste el tamaño correcto de su clúster: número de agentes por clúster
Elegir el número de corredores para su clúster basado en Express es fácil. Cada bróker Express viene con una capacidad de rendimiento definida para la entrada y la salida. Debe utilizar esta capacidad de rendimiento como medio principal para dimensionar el clúster (y, a continuación, tener en cuenta otros factores, como el número de particiones y conexiones, que se analizan a continuación).
Por ejemplo, si su aplicación de streaming necesita un 45% MBps de capacidad de entrada (escritura) de datos y un 90% de salida (lectura) de MBps datos, simplemente puede utilizar 3 corredores express.m7g.large para satisfacer sus necesidades de rendimiento. Cada bróker de express.m7g.large gestionará el 15% de las entradas y el 30% de las salidas. MBps MBps Consulte en la siguiente tabla nuestros límites de rendimiento recomendados para cada tamaño de bróker Express. Si su rendimiento supera los límites recomendados, es posible que experimente una disminución del rendimiento y que deba reducir el tráfico o escalar el clúster. Si su rendimiento supera los límites recomendados y alcanza la cuota por intermediario, MSK reducirá el tráfico de sus clientes para evitar una mayor sobrecarga.
También puede utilizar nuestra hoja de cálculo de tamaño y precios de MSK para evaluar varios escenarios y
| Tamaño de instancia | Entrada () MBps | Salida () MBps |
|---|---|---|
|
|
15.6 | 31,2 |
|
|
31,2 | 62,5 |
|
|
62,5 | 125,0 |
|
|
124,9 | 249,8 |
|
|
250,0 | 500,0 |
|
|
375,0 | 750,0 |
|
|
500,0 | 1000,0 |
Supervisisión del uso de CPU
Le recomendamos que mantenga el uso total de la CPU de sus corredores (definido como usuario de CPU más sistema de CPU) 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. Esto puede ser necesario debido a eventos planificados o imprevistos. Un ejemplo de evento planificado es una actualización de la versión de un clúster durante la cual MSK actualiza los corredores de un clúster reiniciándolos uno por uno. Un ejemplo de evento no planificado es un fallo de hardware en un bróker o, en el peor de los casos, un fallo en una zona de disponibilidad que afecte a todos los agentes de una zona de disponibilidad. Cuando los corredores con réplicas de leads de partición se desconectan, Apache Kafka reasigna el liderazgo de la partición para redistribuir el trabajo entre los demás corredores del clúster. Si sigue esta práctica recomendada, puede asegurarse de tener suficiente espacio de CPU en su clúster para tolerar eventos operativos como estos.
Puedes usar el uso de expresiones matemáticas con CloudWatch métricas en la Guía del CloudWatch usuario de Amazon para crear una métrica compuesta que sea Usuario de CPU y Sistema de CPU. 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: actualice el tamaño de su corredor al tamaño siguiente más grande. 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.
Opción 2: Amplíe su clúster añadiendo intermediarios y, a continuación, reasignando las particiones existentes mediante la herramienta de reasignación de particiones denominada.
kafka-reassign-partitions.sh
Otras recomendaciones
Supervise el uso total de la CPU por agente como proxy para la distribución de la carga. Si los intermediarios utilizan la CPU de manera uniforme, podría ser una señal de que la carga no está distribuida uniformemente dentro del clúster. Recomendamos utilizar 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 el uso de la CPU.
Intervalo de raspado de JMX: 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: 60spara la configuración de su host de Prometheus ().prometheus.ymlReducir el intervalo de raspado puede provocar un uso elevado de la CPU en el clúster.
Ajuste el tamaño correcto de su clúster: número de particiones por broker Express
La siguiente tabla muestra la cantidad recomendada de particiones (incluidas las réplicas líder y seguidora) por agente de Express. 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 |
|---|---|---|
|
|
1 000 | 1500 |
|
|
2000 | 3 000 |
|
|
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ón SASL/SCRAM
Un clúster sobrecargado con un gran número de particiones también puede hacer que falten métricas de Kafka en el CloudWatch raspado de Prometheus.
Para obtener instrucciones acerca de cómo elegir el número de particiones, consulte Apache Kafka Supports 200K Partitions Per Cluster
Supervise el recuento de conexiones
Las conexiones de los clientes con sus corredores consumen recursos del sistema, como la memoria y la CPU. En función de su mecanismo de autenticación, debe realizar un seguimiento para asegurarse de que se encuentra dentro de los límites aplicables. Para gestionar los reintentos en caso de conexiones fallidas, puede configurar el parámetro de configuración reconnect.backoff.ms en el lado del cliente. Por ejemplo, si desea que un cliente vuelva a intentar conectarse después de 1 segundo, reconnect.backoff.ms configúrelo en. 1000 Para obtener más información sobre la configuración de los reintentos, consulte la documentación de Apache Kafka.
| Dimensión | Cuota |
|---|---|
|
Número máximo de conexiones TCP por intermediario (control de acceso de IAM) |
3 000 |
|
Número máximo de conexiones TCP por intermediario (IAM) |
100 por segundo |
|
Número máximo de conexiones TCP por intermediario (no IAM) |
MSK no impone límites de conexión para la autenticación que no sea de IAM. Sin embargo, debe supervisar otras métricas, como el uso de la CPU y la memoria, para asegurarse de no sobrecargar el clúster debido a un exceso de conexiones. |
Reasignar particiones
Para mover particiones a distintos agentes del mismo clúster aprovisionado por MSK, puedes usar la herramienta de reasignación de particiones denominada. kafka-reassign-partitions.sh Le recomendamos que no reasigne más de 20 particiones en una sola kafka-reassign-partitions llamada para garantizar la seguridad de las operaciones. 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 aprovisionado de MSK, consulte. Expansión de la cantidad de agentes en un clúster de Amazon MSK Para obtener información sobre cómo eliminar intermediarios de un clúster aprovisionado de MSK, 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
