Prácticas recomendadas para agentes Express
Este tema describe algunas prácticas recomendadas que se deben seguir cuando se utilizan agentes Express. Los agentes Express vienen preconfigurados para ofrecer alta disponibilidad y durabilidad. De forma predeterminada, los datos se distribuyen en tres zonas de disponibilidad; la replicación siempre se establece en 3 y el mínimo de réplicas en sincronía siempre se establece en 2. Sin embargo, aún hay algunos factores que debe tener en cuenta para optimizar la confiabilidad y el rendimiento del clúster.
Consideraciones del cliente
La disponibilidad y el rendimiento de la aplicación dependen no solo 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 los detalles completos en recomendaciones de prácticas recomendadas para clientes de Apache Kafka.
Ejecute pruebas de rendimiento para verificar que las configuraciones del cliente permitan cumplir los objetivos de rendimiento incluso cuando se reinicien los agentes bajo carga máxima. Puede reiniciar los agentes del clúster desde la consola de MSK o mediante las API de MSK.
Consideraciones del servidor
Temas
Ajuste el tamaño correcto de su clúster: número de agentes por clúster
Elegir la cantidad de agentes para el clúster basado en Express es sencillo. Cada agente Express incluye una capacidad de rendimiento definida para el ingreso y la salida. Debe utilizar esta capacidad de rendimiento como el principal medio para dimensionar el clúster (y luego considerar otros factores, como la cantidad de particiones y de conexiones, que se describen más adelante).
Por ejemplo, si la aplicación de transmisión necesita 45 Mbps de capacidad de ingreso de datos (escritura) y 90 Mbps de capacidad de salida de datos (lectura), puede simplemente usar 3 agentes express.m7g.large para cubrir las necesidades de rendimiento. Cada agente express.m7g.large gestionará 15 Mbps de ingreso y 30 Mbps de salida. Consulte la siguiente tabla para conocer nuestros límites de rendimiento recomendados para cada tamaño de agente Express. Si el rendimiento supera los límites recomendados, puede experimentar una degradación del rendimiento y debería reducir el tráfico o escalar el clúster. Si el rendimiento supera los límites recomendados y alcanza la cuota por agente, MSK aplicará una limitación controlada al tráfico de cliente para evitar una sobrecarga adicional.
También puede consultar la hoja de cálculo Dimensionamiento y precios de MSK
La siguiente tabla enumera el rendimiento máximo recomendado por agente para cada tamaño de instancia.
| Tamaño de instancia | Ingreso (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
Recomendamos que mantenga la utilización total de la CPU de los agentes (definida como CPU de usuario + CPU del sistema) 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 no planificados. Un ejemplo de un evento planificado es una actualización de la versión del clúster, durante la cual MSK actualiza los agentes del clúster reiniciándolos uno a uno. Un ejemplo de un evento no planificado es una falla de hardware en un agente o, en el peor de los casos, una falla de una zona de disponibilidad (AZ) en la que se ven afectados todos los agentes de esa AZ. Cuando los agentes con réplicas líderes de partición quedan fuera de línea, Apache Kafka reasigna el liderazgo de las particiones para redistribuir el trabajo a otros agentes del clúster. Al seguir esta práctica recomendada, puede asegurarse de que el clúster tenga suficiente margen de CPU para tolerar eventos operativos como estos.
Puede recurrir a Uso de expresiones matemáticas con métricas de CloudWatch en la Guía del usuario de Amazon CloudWatch para crear una métrica compuesta que sea CPU de usuario + CPU del sistema. 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 del agente al siguiente tamaño mayor. 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 el clúster mediante la adición de agentes, y luego reasigne las particiones existentes mediante la herramienta de reasignación de particiones llamada
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 agentes presentan de forma constante una utilización desigual de la CPU, podría ser un indicio de que la carga no se distribuye 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 recopilación de JMX. Si habilita la supervisión abierta con la característica de Prometheus, se recomienda usar un intervalo de recopilación de 60 segundos o superior (
scrape_interval: 60s) para la configuración del host de Prometheus (prometheus.yml). Reducir el intervalo de raspado puede provocar un uso elevado de la CPU en el clúster.
Dimensione correctamente el clúster: número de particiones por agente Express
Si tiene casos de uso con muchas particiones y bajo rendimiento, en los que el número de particiones es alto pero no se envía tráfico a todas estas, puede concentrar 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 clúster sobrecargado con un número elevado de particiones también puede provocar la ausencia de métricas de Kafka en CloudWatch y en la recopilación de Prometheus.
Para obtener instrucciones acerca de cómo elegir el número de particiones, consulte Apache Kafka Supports 200K Partitions Per Cluster
Para obtener información sobre el número recomendado de particiones (incluidas las réplicas líder y seguidoras) para cada agente Express, consulte Cuota de particiones de agentes Express. 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.
Supervisión del número de conexiones
Las conexiones de los clientes a los agentes consumen recursos del sistema, como memoria y CPU. Según el mecanismo de autenticación que utilice, debe supervisar para asegurarse de que se mantenga 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 reintente las conexiones después de 1 segundo, establezca reconnect.backoff.ms en 1000. Para obtener más información sobre cómo configurar los reintentos, consulte la documentación de Apache Kafka.
| Dimensión | Cuota |
|---|---|
|
Máximo de conexiones TCP por agente (control de acceso de IAM) |
3 000 |
|
Máximo de conexiones TCP por agente (IAM) |
100 por segundo |
|
Máximo de conexiones TCP por agente (sin IAM) |
MSK no aplica límites de conexión para la autenticación sin IAM. No obstante, debe supervisar otras métricas, como el uso de CPU y memoria, para asegurarse de no sobrecargar el clúster debido a un número excesivo de conexiones. |
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. Recomendamos no reasignar más de 20 particiones en una sola llamada kafka-reassign-partitions, a fin de 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
