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 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 fiabilidad 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 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 corredores de su clúster desde la consola MSK o mediante APIs 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 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 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 | MBpsEntrada () | 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.
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 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
-
Asocia un AWS Secrets Manager secreto a un clúster que tenga SASL/SCRAM autenticación
Un clúster sobrecargado con un número elevado de particiones también puede hacer que falten métricas de Kafka durante 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
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
