Confluent Replicator, más allá de replicar datos.

Cada vez son más las empresas que implementan soluciones con la tecnología Apache Kafka como epicentro tecnológico de sus sistemas, ya que les permite potenciar su negocio dadas las posibilidades que ofrece a la hora de integrar, gestionar y procesar la información.

Dentro de las distribuciones existentes para implementar un cluster de Apache Kafka, en artículos anteriores hemos hablado de la plataforma Confluent, un ecosistema que facilita en gran medida la gestión e implementación de este tipo de soluciones, dotando de funcionalidades adicionales que aportan un valor extra.

Pues bien, en muchas de las soluciones de este tipo es habitual encontrarse, por diversos motivos, con la necesidad de emplear más de un cluster de Apache Kafka, por lo que de forma inevitable, se va a tener la necesidad de comunicar los clusters entre sí. Debido a ello, surge la necesidad de replicar topics y mensajes de un cluster a otro de manera rápida y fiable.

Durante el desarrollo del artículo se va a mostrar cómo se puede replicar información en tiempo real de un cluster de Kafka a otro echando un vistazo a una de las herramientas que proporciona el ecosistema Confluent para tal cometido, como es Confluent Replicator. Para ello, se va a analizar en qué consiste, sus características y se va a definir e implementar un caso de uso que permita mostrar las posibilidades que ofrece la replicación con esta herramienta, más allá de la simple replicación de datos.

¿Qué es Confluent Replicator?

Confluent Replicator es una herramienta que proporciona la plataforma Confluent, que permite replicar topics y los mensajes asociados a estos de una manera sencilla, fiable y en tiempo real.

Se incluye en Confluent Enterprise Platform, o se puede descargar e instalar por separado, según convenga.

Principales carcterísticas

Uno de los aspectos clave de esta herramienta es que, al estar totalmente integrado en la plataforma Confluent, se aprovecha de las características de alto rendimiento, resiliencia y seguridad de la plataforma, además de potenciar su funcionalidad gracias a los otros servicios existentes dentro del ecosistema.

Es importante puntualizar que esta herramienta no solo se dedica a copiar los mensajes, sino que también crea los topics que sean necesarios preservando la configuración del topic en el cluster de origen, como puede ser la configuración del factor de replicación o del número de particiones.

También es capaz de gestionar otros aspectos importantes a tener en cuenta a la hora de realizar una replicación, como puede ser el cambio de nombre de un topic, la posibilidad de transformar los mensajes, la gestión de la migración de los esquemas de los topics (schema-registry) o la capacidad para evitar mensajes duplicados y bucles entre clusters.

Todas las características están destinadas a optimizar la tarea de replicación y construir replicadores con un alto rendimiento. Toda la información sobre las distintas posibilidades que te ofrece Confluent Replicator se puede encontrar aquí.

¿Dónde se puede aplicar?

Como se ha mencionado anteriormente, otro aspecto que ha motivado la creación de este artículo es el mostrar que la replicación puede enfocarse no solo como una herramienta para implementar soluciones resilientes, sino como pieza clave para implementar y mejorar otras líneas de negocio dentro de una empresa.

Cuando hablamos de replicación de datos entre clusters, lo más habitual es pensar en usarlo como herramienta para implementar soluciones de recuperación ante desastres (disaster recovery). En esta solución, se tendría un cluster en modo activo y otro cluster en modo pasivo de manera que, en caso de un desastre total o parcial en el centro de datos donde se encuentre la plataforma Confluent activa, permita que las aplicaciones puedan conmutar y utilizar la plataforma Confluent pasiva en un centro de datos diferente, evitando problemas en el servicio.

Pero existe otro tipo de casos de uso en los que replicar datos entre clusters podría resultar muy interesante.

Uno de estos casos de uso puede darse a la hora del análisis de datos. En ciertas ocasiones, se tiene la necesidad de que procesos que sirvan para el análisis de datos no interfieran en la operativa de la plataforma principal, ya que no se quiere que dichos procesos consuman capacidad de cómputo o memoria que son necesarios para la parte más operativa. Por ello, se pueden replicar los datos del cluster principal a un cluster secundario para poder mover la carga de trabajo analítica en él y no afectar al cluster principal.

De esta manera, se tienen dos cluster en modo activo-activo.

Por otro lado, puede surgir la necesidad contraria, que es la de centralizar los datos en un mismo cluster para realizar un análisis de los datos completo de toda la organización. En este caso, la replicación permitirá que se agreguen datos de diferentes clusters a un mismo cluster y ejecutar en él los procesos de análisis que se necesiten.

Aprovechando la posibilidad de tener varios cluster en modo activo, puede verse la necesidad de replicar datos de un cluster a otro más cercano a nivel geográfico para optimizar la arquitectura y evitar problemas de latencia, consiguiendo así un rendimiento adecuado.

Utilizaremos este caso de uso en particular más adelante como ejemplo para mostrar cómo se puede implementar una solución con Confluent Replicator.

Para finalizar, hay que destacar la posibilidad que ofrece la replicación para modernizar las plataformas o realizar una migración a la nube, ya que nos permite sincronizar datos entre plataformas y aplicaciones on-premise con implementaciones en la nube.

Hemos mostrado algunos casos de uso en los que la replicación puede ayudar a implementar distintas soluciones, aunque no se ha entrado en detalle sobre algunas cuestiones más complejas, como la posible replicación bidireccional que se puede implementar en algún caso de uso, etc.

Estos casos de uso pueden combinarse entre sí para dar lugar a soluciones más sofisticadas, por lo que el abanico de posibilidades es amplio.

Arquitectura y funcionamiento

Una vez se han visto algunas de las características y casos de uso donde se aprecia que Confluent Replicator es una muy buena opción para implementar una solución con el objetivo de replicar datos de un cluster a otro, es interesante ver cómo está diseñado para entender su funcionamiento.

Su diseño a alto nivel es bastante sencillo, ya que Confluent Replicator es un componente basado en Kafka Connect, que permite replicar la información entre clusters apoyándose en la funcionalidad que ofrece este servicio para transmitir datos (API connect, workers, etc.).

La manera en la que Confluent proporciona esta herramienta a los usuarios es a través de un conector, lo que resulta muy sencillo a la hora de usar y configurar, permitiendo la posibilidad de aprovecharse de las ventajas de Kafka Connect respecto a la alta disponibilidad y el balanceo de carga a la hora de replicar los datos.

Otro aspecto a tener en cuenta es en qué lugar implementar el conector. Puede darse el caso de que se quiera replicar datos de un cluster a otro, y exista la posibilidad de que en ambas plataformas haya configurado un Kafka Connect distinto. ¿En cuál de los dos se implementa el conector?

En realidad, se puede implementar tanto cerca del cluster origen como cerca del cluster destino y funcionará de igual manera. Sin embargo, es una mejor práctica intentar implementar el replicador Confluent Replicator más cerca del cluster destino, ya que se va a lograr mayor fiabilidad y rendimiento de la red.

Los beneficios de esta buena práctica son más evidentes cuando ambos clusters se encuentran en regiones diferentes, ya que en esa situación la replicación puede verse afectada por la red.

A continuación, mostramos un ejemplo donde se detalla cómo implementar un caso de uso con Confluent Replicator, donde entraremos en detalles sobre su instalación y configuración. Durante el transcurso del ejemplo, no se detalla información sobre el uso de conectores dentro de la plataforma Confluent, pero en el siguiente artículo se explica con más detalle cómo hacerlo.

Manos a la obra

Durante el desarrollo del artículo, hemos comentado algunos casos de estudio interesantes donde replicar información en tiempo real entre distintos clusters de Apache Kafka puede resultar muy interesante.

Para entender mejor cómo puede ayudar Confluent Kafka Replicator en este tipo de situaciones, desarrollaremos un caso de uso en el que se va a mostrar cómo se implementa dicho conector y cómo ayuda a resolver los problemas de latencia y proximidad del dato a la hora de internacionalizar una aplicación.

¿Cuál es el punto de partida?

Una startup de nueva creación implementa una solución que consiste en proporcionar una plataforma web diferencial en el ámbito del entretenimiento.

En un primer momento, y dada la naturaleza y las expectativas de la empresa, se decide acotar la disponibilidad del servicio a Europa, por lo que solo los usuarios de dicha región van a poder hacer uso de él.

A nivel técnico, la arquitectura de la solución tiene, como elemento principal, una plataforma Confluent, alojada y configurada en Alemania, que les permite alcanzar unas cotas de rendimiento muy atractivas en el manejo y procesado de la información, con la finalidad de ofrecer un servicio diferencial respecto a la competencia.

Poco tiempo después del lanzamiento, el éxito del servicio es tan grande que empieza a existir demanda en otras regiones, principalmente en América del Norte, por lo que la empresa toma la decisión de abrir fronteras y permitir la posibilidad de acceder al servicio a usuarios pertenecientes a esa localización.

Una vez integrados todos los usuarios en el sistema, se detecta que el uso del servicio por parte de los usuarios de América del Norte tiene algunos problemas, ya que la latencia provocada por la distancia geográfica entre usuarios y sistemas (recordad que el CPD está en Europa Central) afecta a la disponibilidad del dato y penaliza el rendimiento, lo que da lugar a usuarios insatisfechos que optan por los servicios de la competencia.

Entonces, dada la necesidad de evitar estos inconvenientes y de proporcionar las mejores prestaciones a todos los usuarios independientemente de su localización, ¿cómo es posible solucionar este problema?

La replicación como solución

Este problema alerta sobre la necesidad de que los datos, necesarios para gestionar correctamente el servicio a los usuarios, se encuentren próximos geográficamente a ellos.

Existen varias alternativas para solventar este tipo de problemas. En este caso, y aprovechando el uso de la plataforma Confluent, se va a crear otro cluster, localizado en Canadá, que sea capaz de gestionar los datos relevantes a los usuarios de América del Norte y permita cumplir con las expectativas de rendimiento para estos usuarios, eliminando la penalización debida a la latencia.

Como dato interesante, vemos que resulta relativamente sencillo crear distintos clusters de Apache Kafka en distintas localizaciones con el uso de Confluent Cloud en los principales proveedores gracias a toda la tecnología que existe en la nube (excluyendo costes), aunque utilicemos distintas localizaciones.

Teniendo claro que este modelo multi-localización va a permitir que se eliminen los problemas de latencia y rendimiento que hemos visto anteriormente, ¿estaría todo visto para sentencia?

La realidad es que no. En este tipo de situaciones, es normal encontrarse con la necesidad de que los clusters necesiten disponer de información procesada y gestionada por otro cluster.

En este caso, el nuevo cluster (Canadá) requiere de ciertos datos de un topic que han sido procesados y enriquecidos por el primer cluster (Alemania) debido a su mayor capacidad de cómputo y rendimiento. Si esta información no estuviera disponible en ambos clusters, no se podría gestionar la operativa actual y, por lo tanto, no se podría dar el servicio a los usuarios.

Hay varias formas de poder realizar esto. Unas que se adaptan mejor que otras, aunque lo más habitual (dentro de una arquitectura de gran magnitud) es mediante la replicación.

Confluent Kafka Replicator al rescate

En esta ocasión, aprovechando las posibilidades y características de escalado y tolerancia a fallos que nos ofrece la plataforma Confluent, vamos a ver cómo el conector Confluent Kafka Replicator nos permite realizar la replicación de datos entre los dos clusters de una manera muy sencilla, fiable y, sobre todo, en tiempo real.

Bien, una vez configurados y disponibles los dos clusters en sus respectivas zonas geográficas, vamos a usar el servicio de Kafka Connect donde se va a registrar el conector para crear la solución. ¿Cómo podemos configurar el conector para poder replicar topics y la información de un cluster a otro?

En primer lugar, hay que asegurarse de instalar las librerías del conector en Kafka Connect para su posterior uso.

confluent-hub install confluentinc/kafka-connect-replicator:6.1.1

A continuación, hay que crear una configuración donde se definan las características y el comportamiento del conector.

{
   "name": "cluster-to-cluster",
   "config": {
      "connector.class": "io.confluent.connect.replicator.ReplicatorSourceConnector",
      "key.converter": "io.confluent.connect.replicator.util.ByteArrayConverter",
      "value.converter": "io.confluent.connect.replicator.util.ByteArrayConverter",
      "src.kafka.request.timeout.ms": "20000",
      "src.kafka.bootstrap.servers": "broker-europe:29094",
      "dest.kafka.sasl.mechanism": "PLAIN",
      "dest.kafka.request.timeout.ms": "20000",
      "dest.kafka.bootstrap.servers": "broker-north-america:29092",
      "dest.kafka.retry.backoff.ms": "500",
      "topic.regex": "europe.*",
      "tasks.max":"1",
      "topic.rename.format":"${topic}-replica"
   }
}

Y donde tienen mayor relevancia los siguientes parámetros:

"connector.class" -> Tipo de conector

"src.kafka.bootstrap.servers" -> Cluster origen (Alemania)

"dest.kafka.bootstrap.servers" -> Cluster destino (Canadá)

"topic.regex" -> Expresión regular que define los topics a replicar

"topic.rename.format" -> Nombre de los topics generados en el destino

En la documentación propia de Confluent Replicator se puede ver más información sobre las distintas configuraciones disponibles para este tipo de conectores.

Para finalizar, el último paso sería registrar el conector con la configuración definida.

curl -i -X POST -H "Accept:application/json" -H  "Content-Type:application/json" http://<connect-url>:8083/connectors/ -d @replicator.json

¡Y ya está! De esta forma tan sencilla somos capaces de tener configurada una replicación entre los dos clusters en tiempo real, y con la posibilidad de disponer de los datos que se necesiten en ambos lados.

De esta forma, se solucionan los problemas de latencia y proximidad del dato que se tenían en un primer momento, por lo que todos los usuarios de América del Norte podrán beneficiarse de las mismas prestaciones.

La implementación de la solución al detalle

En el siguiente repositorio se puede ver un ejemplo básico en el que se simula este caso de uso, donde ejecutando el siguiente script se inicializan una serie de contenedores Docker con dos clusters (simulando los clusters de Alemania y Canadá) y los demás componentes del ecosistema Confluent necesarios para implementar la solución.

Además, se implementa el conector de forma que, a partir de un productor (datagen) que genera datos en un topic del primer cluster, se replique dicha información de un cluster a otro.

La arquitectura de la solución sería la siguiente, donde quedan reflejados los distintos componentes que se usan.

Por otro lado, la solución implementada viene con una aplicación UI para Apache Kafka que permite visualizar información de los topics y mensajes, de modo que se pueda verificar su funcionamiento.

La idea que se busca tras este ejemplo es mostrar la sencillez de realizar una replicación entre clusters y que sirva como inspiración y conocimiento base para poder implementar soluciones mucho más sofisticadas en las que se pueda hacer uso de la replicación.

¿Confluent Replicator es la única alternativa?

Uno de los aspectos a tener en cuenta a la hora de implementar una solución con Confluent Replicator es la licencia. El uso de esta herramienta requiere de una licencia Enterprise, aunque se puede usar de forma gratuita por un período de 30 días.

Entonces, ¿si no se usa una plataforma Confluent o no se quiere pagar una licencia, no se puede replicar un cluster de Apache Kafka? Claro que se puede, hay otras alternativas.

En primer lugar, siempre se pueden implementar consumidores y productores externos que sean capaces de mover la información entre clusters, aunque esa solución suele suponer un gran esfuerzo.

Por otro lado, Apache Kafka proporciona otra herramienta para hacer el replicado de datos de una manera sencilla con un rendimiento bastante eficiente. Esta herramienta es Apache Kafka MirrorMaker y, como dato interesante, en su nueva versión también usa API connect para crear los replicadores.

Descartando la replicación mediante consumidores y productores externos, ¿qué diferencia hay entre usar Kafka Mirror Maker y Confluent Replicator? ¿Cuál utilizar?

Bueno, la gran diferencia entre ambas herramientas es el conjunto de posibilidades que ofrece una y otra. Si bien ambas sirven para el mismo fin y, además, usan API connect para poder crear sus replicadores de forma eficiente, Confluent Replicator ofrece la posibilidad de beneficiarse de otros servicios de la plataforma Confluent, tanto a nivel de gestión como de operabilidad. Eso sí, el uso de una herramienta u otra depende de muchos factores, no hay una buena o mala, sino que depende de aspectos como la complejidad de la solución o los requerimientos necesarios.

Para finalizar, y como lectura recomendada, la plataforma Confluent facilita otras herramientas para realizar la réplica entre clusters que pueden resultar interesantes según el caso de uso que se quiera implementar: Multi-Region Clusters y Cluster Linking.

Si necesitas más información...

Si quieres seguir profundizado sobre el tema, no te pierdas este podcast en el que veremos casos de uso en los que la tecnología Kafka nos puede ayudar y veremos qué beneficios aporta Confluent con respecto a otras distribuciones.

Referencias:

• Documentación Confluent Replicator
• Documentación Kafka Connect
• Documentación Confluent
• Documentación Confluent Hub
• Documentación Confluent Cloud