¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
Conoce nuestra marca.¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
Conoce nuestra marca.dev
Daniel Colina 01/10/2018 Cargando comentarios…
Cuando trabajamos con un sistema de colas implementado a través de Kafka, muchas veces nos encontramos con la necesidad de hacer una réplica de datos o simplemente hacer un traspaso de información de un cluster a otro.
En ese momento nos preguntamos, ¿cómo podemos llevar esto a cabo sin rompernos la cabeza y que el resultado sea eficaz y eficiente?
Kafka, en sí, nos provee de una herramienta bastante útil para hacer replicado de datos sin que esto suponga un gran esfuerzo más que el coste de la configuración inicial. Esta herramienta es Kafka Mirror Maker.
Es una herramienta (script) diseñada para transferir datos de uno o más tópicos entre un cluster origen y otro destino. Dicho script se encarga de levantar un proceso que hace las veces de consumidor y productor a la vez (recolectando los mensajes de los tópicos indicados en el cluster origen y llevándolos al cluster destino).
Como hemos dicho el script tiene la responsabilidad de desempeñar tanto de consumidor como de productor, por este motivo es imprescindible indicar la configuración de cada una de estas piezas para llevar a cabo la ejecución del mismo.
Lo que sigue a continuación es una muestra de arquitectura básica para la utilización de la herramienta Kafka Mirror Maker.
A continuación mostramos un ejemplo básico de configuración para conectar replicar datos de un cluster a otro mediante Kafka Mirror Maker.
Primero definimos los parámetros de configuración el hilo consumidor:
# sourceClusterConsumer.config file #
zookeeper.connect=:\[,:\]\*
group.id=mirror-maker-group
En la propiedad zookeeper.connect debe indicarse la o las direcciones IP’s y puertos del zookeeper en el cluster origen.
El group.id será utilizado por consumidor para gestionar el offset en los tópicos a replicar.
Ahora definimos los parámetros de configuración para el hilo productor:
#targetClusterProducer.config file #
bootstrap.servers=:\[,:\]\*
La propiedad bootstrap.servers debe indicar la o las direcciones ip’s y puertos del zookeeper (kafka broker) en el cluster destino.
Finalmente, para lanzar el script basta con indicar las rutas de los ficheros de configuración que hemos definido previamente, así como también el valor para la propiedad --whitelist, en la cual indicaremos los tópicos a ser replicados (esta puede ser una lista separada por comas o bien puede definirse como un patrón de una expresión regular).
$ bin/kafka-mirror-maker.sh --consumer.config sourceClusterConsumer.config
\--producer.config targetClusterProducer.config --whitelist=".\*"
El script lo encontraremos en el directorio bin dentro de la ruta de instalación de kafka.
Voilà! Ya podemos iniciar nuestro proceso de replicación de tópicos entre dos clusters kafka.
Como hemos podido observar anteriormente, la comunicación entre dos brokers de kafka a través de Mirror Maker es muy sencilla de conseguir, ya que basta con conocer las direcciones IP y puertos de los servidores (origen y destino), conjuntamente con el listado de los tópicos (colas) que se desea replicar.
Sin embargo cuando hablamos de entornos productivos, es importante tener en cuenta una serie de criterios que nos permitirán hacer una correcta configuración de la herramienta (script) y que a su vez vaya acorde a nuestras necesidades. Todo lo anterior nos genera la siguiente interrogante: ¿cómo saber cuál es la mejor configuración?
Pues, la respuesta es, depende, ya que la mejor solución va directamente relacionado a nuestras prioridades. Es decir, si necesitamos explotar el rendimiento (esto en aplicaciones donde la transferencia de datos se debe hacer en tiempo real), o bien tener máxima fiabilidad y consistencia de datos, entre otros aspectos.
En la siguiente sección hablaremos sobre un conjunto de consideraciones y buenas prácticas a tener en cuenta al momento de realizar replicación de tópicos sin dejar de lado la calidad y el buen desempeño.
Existe una serie de propiedades relevantes con las que podemos jugar para intentar mejorar el rendimiento o bien para bajar la tasa de pérdida de mensajes, pero como sabemos, no se puede tener todo lo en la vida, con cual cualquier cambio para mejorar el rendimiento puede afectar a la integridad de los datos y viceversa.
Por ejemplo, sobre la configuración del consumidor es posible establecer la propiedad auto.commit.enabled=false, la cual asegura que los mensajes se marcarán como procesados únicamente cuando se haya recibido el respectivo ACK. Este atributo es fundamental para minimizar el porcentaje de pérdida de mensajes. Sin embargo desde el punto de vista del rendimiento, no es la configuración más recomendada, ya que aumenta el tráfico de paquetes en la red y añade latencia.
Con respecto al productor, a continuación listamos las propiedades que pueden tener mayor impacto sobre el desempeño y tratamiento de datos:
La selección del tipo de compresión dependerá de nuestra necesidad, es decir, con gzip ganamos en tasa de compresión, pero perdemos en rendimiento.
Por otro lado, si usamos lz4 obtendremos mejor rendimiento, pero la capacidad de compresión será más baja. También se puede configurar un tipo de compresión media como la snappy, la cual nos ofrece un balance entre la capacidad de compresión el rendimiento. Cuando no tenemos claro qué es lo que más nos conviene es una buena alternativa porque la penalización en cualquiera de los dos casos es mucho menor.
Siempre es recomendable usar algún tipo de compresión, ya que con ello haremos un mejor uso del espacio de almacenamiento de datos. Además de sacar mayor provecho del ancho de banda de la red.
Como ya mencionamos, la compresión va directamente relacionada a la capacidad de realizar envíos por lotes, es decir, a mayor cantidad de lotes, conseguiremos una compresión eficiente.
Una forma de mejorar el proceso de compresión es incrementando el número de hilos productores, esto a su vez se verá reflejado de forma positiva en el rendimiento del proceso de réplica de datos.
Es un proceso bastante empírico que consiste en ir realizando con diversas combinaciones de los parámetros de configuración y volumen de datos hasta dar con los valores que se ajusten mejor a nuestras necesidades.
En dicho proceso de selección nos puede ser bastante útil el uso de la herramienta kafka-producer-perf-test.sh, la cual nos permitirá medir el rendimiento y el comportamiento general de la aplicación. Dicha herramienta la podemos encontrar dentro de la suite de comandos de Kafka.
Podría ser una buena alternativa tener algún proceso (demonio watchdog) que monitorice el estado del Kafka Mirror Maker y en caso de que éste por alguna razón se cayera, el demonio se encargaría de restablecer el servicio.
Lo recomendable es que dicho número no supere al número de particiones por tópico, de otra forma el excedente serían hilos sin carga de trabajo o mejor dicho workers ociosos. En caso de que el número fuese menor, no habría ningún problema, ya que los hilos o consumidores se repartirán la carga entre sí.
El número de hilos para los consumidores se define a través de la propiedad num.streams, la misma debe ser indicada como parámetro del script. Por ejemplo, si el número de consumidores deseados es 4 entonces la propiedad se establecerá a --num.streams=4.
Recuerda: Por temas de mejor rendimiento, siempre se recomienda que el proceso Kafka Mirror resida en el cluster destino. Esto permitiría reducir la latencia.
Esta configuración dependerá siempre de lo que se considere más conveniente, acorde a la necesidad del negocio, velocidad y continuidad de trabajo vs. persistencia y consistencia de datos**.**
Hemos conocido una herramienta bastante útil y potente en lo que respecta al proceso de replicación de datos de una cola Kafka de un cluster a otro.
Es un proceso, a mi parecer, bastante sencillo de configurar y de usar, que no supone mayores dolores de cabeza, cosa que se agradece muchísimo.
El truco para hallar la mejor configuración radica en evaluar cuáles son nuestras prioridades: preservación de datos, alto rendimiento, además del tipo de entorno al que vaya a ser aplicado.
Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.
Cuéntanos qué te parece.