Instalación y configuración de Kafka

...

Índice
  1. Optimización de las configuraciones del bróker de Kafka
    1. Débito
    2. Latencia
    3. Sostenibilidad
    4. Disponibilidad

Optimización de las configuraciones del bróker de Kafka

Como puede ver, tomó mucho menos tiempo lanzar una instancia de Kafka, pero a menudo necesitamos optimizar o ajustar nuestra aplicación para brindar un alto rendimiento y resistencia. Kafka es considerado uno de los sistemas más configurables. Proporciona una enorme lista de configuraciones de servidor para jugar según los diferentes casos de uso o propósitos. En un alto nivel, estas configuraciones sirven para los siguientes propósitos:

  • Débito
    • Gestión de subprocesos para mejorar el procesamiento de solicitudes
  • Latencia
    • Gestión del rendimiento para conexiones de alta latencia
  • Sostenibilidad
    • Parámetros de transacción y validación para sujetos
    • Gestión de registros con políticas de retención de datos
    • Políticas de limpieza de registros
    • Gestión de volcado de registro
    • Gestión del uso del disco
    • Reequilibrio de los grupos de consumidores
  • Disponibilidad
    • Replicación de temas
    • Creación y eliminación automática de temas
    • Reequilibrio de particiones
    • Elección impura del líder

Kafka establece sus propiedades con un valor predeterminado en el archivo server.properties abajo configuración carpetas. Sin embargo, podemos cambiar o modificar fácilmente las configuraciones predeterminadas por intermediario o para todo el clúster. Es posible que la configuración por agente y en todo el clúster no requiera el reinicio del agente y se actualice dinámicamente, mientras que algunas otras configuraciones de solo lectura requerirían un reinicio del agente.

Podemos describir la configuración actual del bróker para un bróker dado usando el siguiente comando:

$ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --describe

Podemos actualizar la configuración de un broker con el siguiente comando:

$ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --alter --add-config log.cleaner.threads=2

Si queremos eliminar o restaurar la configuración anterior, podemos probar el siguiente comando:

$ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --alter --delete-config log.cleaner.threads

Ahora veamos cada opción de configuración separada por los propósitos enumerados anteriormente.

Débito

Para optimizar la configuración del intermediario para lograr el rendimiento, debemos tener en cuenta que el flujo de datos entre productores y consumidores debe ser mayor. Por lo tanto, necesitamos maximizar la tasa de flujo de datos.

Gestión de subprocesos para mejorar el procesamiento de solicitudes

Para jugar con estas configuraciones, necesitamos recuperar métricas del agente de Kafka y comprender la cantidad promedio de tiempo que los subprocesos de la red han estado inactivos. Esto indica el porcentaje de utilización de recursos. Por lo tanto, si el tiempo de inactividad es 0 %, significa que se han utilizado todos los recursos disponibles y se requerirá una mayor asignación de subprocesos.

Echemos un vistazo a la configuración básica en y alrededor de la gestión de subprocesos:

# ...
num.network.threads=5
queued.max.requests=1000
num.io.threads=8
num.recovery.threads.per.data.dir=1
# ...
  • num.network.threads - Especifica los subprocesos de red que reciben las solicitudes de servicio de la red y envían respuestas a la red.
  • queued.max.requests - Esto indica la cantidad de solicitudes en cola permitidas para el plano de datos antes de bloquear los hilos de la red. Esta configuración ayuda a reducir la congestión y acelerar el tráfico de solicitudes.
  • num.io.threads - Indica los hilos de E/S que utiliza el servidor para procesar las solicitudes. Entonces, si agregamos más subprocesos, mejorará el rendimiento, pero también debemos considerar la cantidad de núcleos de CPU y el ancho de banda del disco. Entonces, un punto de partida ideal sería establecer un valor predeterminado de 8 multiplicado por la cantidad de discos.
  • num.recovery.threads.per.data.dir - Esto especifica la cantidad de subprocesos utilizados para cargar el registro al iniciar y vaciar al apagar.

Latencia

Kafka generalmente proporciona una latencia de extremo a extremo bastante baja para procesar grandes volúmenes de datos. Por lo tanto, el tiempo requerido para producir un juego de discos en Kafka y enviarlo al consumidor es bastante corto. Echemos un vistazo a algunas configuraciones adicionales que pueden reducir mucho más la latencia y brindar un mejor rendimiento.

Gestión del rendimiento para conexiones de alta latencia

Para manejar las comunicaciones de mensajes que tienen una latencia alta, podemos determinar el tamaño óptimo del búfer de mensajes usando un cálculo matemático llamado producto de retardo de ancho de banda. En el mundo de las comunicaciones de datos, el producto ancho de banda-retardo es el producto de la capacidad de un enlace de datos y su tiempo de retardo de ida y vuelta.

Podemos determinar la capacidad de ancho de banda y modificar los siguientes parámetros:

# ...
socket.send.buffer.bytes=1048576
socket.receive.buffer.bytes=1048576
# ...

Sostenibilidad

Para reducir el riesgo de pérdida de datos o mensajes, debemos asegurar la durabilidad del sistema. Kafka permite la personalización a nivel de tema, partición y consumidor para garantizar que no perdamos ningún dato. Echemos un vistazo rápido a cada uno de ellos.

Parámetros de transacción y validación para sujetos

A veces, para lograr la idempotencia para las transacciones, es bastante útil realizar escrituras exactamente una vez en una sola partición. Actas, a su vez, a menudo garantiza que los mensajes que usan el mismo ID transaccional se produzcan exactamente una vez. Todos los mensajes se escriben correctamente en los registros o ninguno. Así que para lograr esto, internamente __transaction_state se utiliza el sujeto, lo que requeriría un mínimo de tres intermediarios predeterminados. Por lo tanto, los siguientes parámetros ayudarían a lograr este objetivo:

# ...
transaction.state.log.replication.factor=3
transaction.state.log.min.isr=2
# ...

Las confirmaciones de cambio de partición se almacenan de forma predeterminada en __consumer_offsets sujeto. Tiene configuraciones predeterminadas para el factor de replicación y el número de particiones. A menudo se recomienda no reducir los valores de estos parámetros en la producción.

# ...
offsets.topic.num.partitions=50
offsets.topic.replication.factor=3
offsets.commit.required.acks=-1
# ...

Gestión de registros con políticas de retención de datos

Kafka almacena el mensaje en forma de registros representados por una serie de registros segmentados asociados con el índice. Estos mensajes no se modifican en absoluto. En cambio, siempre se adjunta. Dado que los consumidores leen los registros de los segmentos, Kafka proporciona una configuración para definir el tamaño máximo de un segmento de registro y el tiempo antes del cual se implementa el segmento activo. Los siguientes ajustes nos ayudan a conseguirlo:

# ...
log.segment.bytes=1073741824
log.roll.ms=604800000
# ...

También podemos establecer políticas de retención para garantizar que los registros se conserven en el sistema para referencia futura o se eliminen automáticamente después de un período determinado. Podemos establecer políticas de retención de registros basadas en el tamaño o en el tiempo. Para el proceso de retención de registros basado en el tiempo, podemos usar la siguiente configuración en milisegundos.

# ...
log.retention.ms=1680000
# ...

Para el proceso de retención de registros basado en el tamaño, podemos establecer un tamaño máximo de registro en bytes:

# ...
log.retention.bytes=1073741824
# ...

Supongamos que si queremos agregar un retraso antes de eliminar un archivo de segmento, podemos agregar un retraso para todos los temas a nivel de intermediario.

# ...
log.segment.delete.delay.ms=60000
# ...

Políticas de limpieza de registros

Kafka tiene el concepto de un limpiador de registros que eliminaría los registros antiguos. Por defecto, está activado. Si los datos no se limpian periódicamente, los archivos de registro crecerán y consumirán todo su almacenamiento o memoria. El siguiente parámetro define una política de limpieza que se puede usar para limpiar los registros.

# ...
log.cleaner.enable=true
log.cleanup.policy=compact,delete
# ...

Cuando los datos no estén destinados a ser retenidos indefinidamente, podemos elegir BORRAR política. Sin embargo, si queremos asegurarnos de que los valores del mensaje sean editables y queremos mantenerlos actualizados por última vez, debemos elegir compacto política. Los nuevos mensajes siempre se agregan a la dirigir de Diario. En el cola de un registro compactado, los registros se eliminarán si aparece otro registro con la misma clave más tarde. Entonces, si bien Kafka garantiza que se conservarán los mensajes más recientes para cada clave, no garantiza que todo el registro comprimido no contenga duplicados. También podemos establecer varios parámetros para ajustar la frecuencia de los registros que se revisarán para la limpieza.

# ...
log.retention.check.interval.ms=300000
log.cleaner.backoff.ms=15000
log.cleaner.delete.retention.ms=86400000
log.segment.delete.delay.ms=60000
# ...

Gestión de volcado de registro

Por lo general, para controlar las escrituras periódicas de datos de mensajes almacenados en caché en el disco, profundizamos en el concepto de administración de vaciado de registros. Podemos controlar la frecuencia de vaciado en función del tiempo máximo que el mensaje se mantiene en la memoria y la cantidad máxima de mensajes en el registro antes de escribir en el disco.

# ...
log.flush.scheduler.interval.ms=2000
log.flush.interval.ms=50000
log.flush.interval.messages=100000
# ...

Gestión del uso del disco

Además de las diversas políticas de limpieza de registros que hemos analizado, existen muchas otras configuraciones que principalmente nos ayudan a administrar la asignación de memoria. Algunas configuraciones de ejemplo se parecen a las siguientes:

# ...
log.cleaner.dedupe.buffer.size=134217728
log.cleaner.io.buffer.load.factor=0.9
log.cleaner.threads=8
log.cleaner.io.max.bytes.per.second=1.7976931348623157E308
# ...

Reequilibrio de los grupos de consumidores

Por lo general, cuando un consumidor deja de funcionar o se agrega un nuevo consumidor, Kafka intenta reequilibrar los grupos de consumidores. Podemos intentar evitar el reequilibrio innecesario del grupo de consumidores introduciendo tiempos de espera para que el coordinador del grupo pueda esperar a que se una el nuevo miembro.

# ...
group.initial.rebalance.delay.ms=3000
# ...

Disponibilidad

Para lograr una alta disponibilidad en nuestro clúster, debemos intentar ajustar nuestra configuración para que pueda recuperarse lo más rápido posible de los escenarios de falla. Pero todavía se recomienda cierto nivel de evaluación comparativa para un mejor rendimiento.

Replicación de temas

Por lo general, cuando configuramos temas en Kafka, se solicita establecer de antemano la cantidad de particiones, la cantidad mínima de réplicas sincronizadas y el factor de replicación de la partición. Pero en caso de que alguien quiera aumentar/disminuir estos valores, puede cambiarlos fácilmente más adelante.

# ...
num.partitions=1
default.replication.factor=3
min.insync.replicas=2
# ...

Para lograr una alta disponibilidad, a menudo se recomienda establecer un factor de replicación de 3 y un número mínimo de réplicas sincronizadas que sea 1 menos que el factor de replicación establecido. El concepto de replicación de temas sigue siendo crucial para la confiabilidad y la durabilidad de los datos de Kafka. Un intermediario fallido puede recuperar réplicas sincronizadas de otros intermediarios disponibles mediante la replicación.

Creación y eliminación automática de temas

La creación y eliminación automática de temas está habilitada de forma predeterminada. Pero a menudo notamos que los usuarios tienden a desactivarlo en producción para poder controlar la creación y gestión aleatoria de temas. Estos parámetros pueden ser modificados por los siguientes parámetros:

# ...
auto.create.topics.enable=true
delete.topic.enable=true
# ...

Reequilibrio de particiones

En el caso de la replicación de datos, un líder de fragmentos en un intermediario maneja todas las escrituras de registro, mientras que los seguidores de fragmentos en los otros intermediarios replican los datos fragmentados del líder. Si el líder deja de funcionar o ya no está disponible, una de las réplicas sincronizadas se selecciona automáticamente como el nuevo líder. Así, podemos gestionar o controlar la frecuencia de las comprobaciones automáticas de líder y el porcentaje máximo de desequilibrio siguiendo los parámetros:

#...
auto.leader.rebalance.enable=true
leader.imbalance.check.interval.seconds=300
leader.imbalance.per.broker.percentage=10
#...

Elección impura del líder

El proceso de elección del líder de una réplica sincronizada siempre garantiza que no haya pérdida de datos. Entonces, cuando el líder anterior deja de funcionar y el corredor ya no tiene una réplica sincronizada, Kafka espera hasta que el líder vuelva a estar en línea antes de que se puedan leer o escribir nuevos mensajes. Kafka proporciona una configuración para la elección de líderes impuros, lo que significa que las réplicas no sincronizadas ahora pueden convertirse en líderes, pero en este caso puede haber riesgo de pérdida de datos. Entonces, si queremos priorizar la disponibilidad sobre la durabilidad, podemos permitir la elección de un líder impuro.

# ...
unclean.leader.election.enable=false
# ...

Si quieres conocer otros artículos parecidos a Instalación y configuración de Kafka puedes visitar la categoría Código.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Subir

Esta página web utiliza cookies para analizar de forma anónima y estadística el uso que haces de la web, mejorar los contenidos y tu experiencia de navegación. Para más información accede a la Política de Cookies . Ver mas