Replicando datos en tiempo real II: diseñando nuestra solución.

De acuerdo, ya sé que en el post anterior Replicando datos en tiempo real: ¿qué vas a hacer con tus datos, si no los usas? no ofrecimos ninguna opción viable para implementar el proceso de replicación que planteamos. Y además, no dimos ninguna solución alternativa ni hicimos hincapié en los inconvenientes de las soluciones más habituales.

La razón no era otra que no alargar demasiado el anterior post. En este nuevo artículo vamos a empezar a diseñar nuestra solución, y qué mejor manera de empezar que echando mano de esos conceptos teóricos que nos resultan tan prácticos en tantas ocasiones, (y además, otros ya se han molestado en pensar por nosotros): los patrones de diseño.

Event Sourcing y CDC

Si abordamos nuestro problema desde un punto de vista un poco más conceptual, buscando una aproximación desde un punto de vista teórico, podemos llegar a la conclusión de que el patrón de diseño que nos soluciona buena parte de nuestra problemática inicial es el patrón conocido como Event Sourcing. Martin Fowler lo define de la siguiente forma:

“The fundamental idea of Event Sourcing is that of ensuring every change to the state of an application is captured in an event object, and that these event objects are themselves stored in the sequence they were applied for the same lifetime as the application state itself.”

Resumiendo bastante, podríamos decir que el espíritu de este patrón es el de persistir el estado de un sistema como una secuencia ordenada de eventos.

La aplicación de este patrón de diseño presenta diversas ventajas:

• Facilita la resolución de incidencias (bugs), ya que disponemos de todas las operaciones que se han ejecutado sobre un determinado elemento de nuestro sistema.
• Facilita la resiliencia (tolerancia a fallos) de nuestras aplicaciones, ya que tenemos la capacidad de volver a procesar los eventos en cualquier momento en caso de error.
• Facilita la implementación de soluciones con mayor rendimiento, ya que podemos tener procesos de escritura/lectura independientes y escalables.

Por contra, también hay que tener en cuenta que, la aplicación de este patrón de diseño, nos obliga a realizar un paso intermedio adicional para expresar los cambios ocurridos en nuestro sistema en forma de evento.

Extrapolando esta idea a nuestro problema, podemos diseñar nuestra solución en base a ejecutar dos pasos:

1. Hacer un volcado inicial de la base de datos origen.
2. Ir aplicando los cambios ocurridos, a partir de los logs transaccionales de la base de datos origen, en tiempo real, a nuestro sistema destino.

Esta aproximación también es conocida como CDC (Change Data Capture) y parece que nos encaja mejor que las aproximaciones anteriores:

• Al ir procesando las transacciones de forma continua, no es tan complicado obtener latencias rápidas de procesado, cercanas al tiempo real.
• Podemos ubicar como pieza central de nuestra solución una cola de mensajería, o incluso una plataforma de streaming, como Apache Kafka, haciendo así independiente y más flexible la integración con otros sistemas de persistencia.

Arquitectura general de la solución

Siguiendo los principios que hemos presentado antes, la arquitectura de nuestra solución podría quedar esquematizada de la siguiente forma:

Sistema Legacy

Sistema que queremos replicar (ej: base de datos relacional).

Agente Ingestor

Proceso encargado de procesar el sistema de logs de nuestro sistema legacy, para, a continuación, hacer el volcado de la información recuperada a nuestra cola de mensajería o plataforma de streaming. Lógicamente, la implementación de esta pieza depende mucho del sistema a replicar, por lo que en el siguiente apartado daremos una comparativa entre diferentes opciones que cubren muchos de los casos que nos podemos encontrar en los proyectos actuales de nuestros clientes.

Cola Mensaje

Elemento que almacena la secuencia de eventos de forma ordenada. Es importante que este elemento sea capaz de persistir el histórico completo de los eventos generados, así como de mantener y servir estos eventos de una manera ordenada. Aunque existen varias alternativas que pueden cumplir con estos requerimientos, la opción que nos ha parecido más interesante ha sido la plataforma de streaming distribuida Apache Kafka. Sus principales características son:

• Permite publicar flujos de datos y suscribirse a ellos.
• Es tolerante a fallos.
• Permite procesar el flujo de datos en orden, tal y como han ocurrido.

ETL (Extract - Transform - Load)

Esta es la pieza que deberá recoger los eventos, procesarlos, e insertar la información en el sistema de persistencia elegido. Algunas de las características de esta pieza son:

Podemos tener varios ETL’s distintos dentro de nuestro sistema: Esta capacidad es interesante en el caso de que necesitemos realizar diferentes transformaciones para nuestros eventos, o necesitemos almacenar la información en distintos sistemas de persistencia.

Podemos ir incorporando nuevos ETL’s a nuestro sistema dinámicamente: Debido a que tenemos todo nuestro sistema descrito como una secuencia ordenada de eventos en nuestra cola o plataforma de streaming, cualquier nueva necesidad de transformación o persistencia (que nos surgiera más adelante en el tiempo), podría ser implementada como un nuevo proceso ETL, independiente y desacoplado del resto del ecosistema que ya tuviéramos funcionando.

Cada proceso ETL sólo debe consumir lo que necesite: Esto significa que en un proceso de replicación completo, el proceso ETL sólo necesitaría recuperar todos los eventos almacenados en la cola de mensajería la primera vez que se iniciase (snapshot). A partir de este momento, en futuras reconexiones a la cola, o por creación de nuevas instancias del mismo proceso, nuestro ETL sólo necesitaría consumir los eventos que no hubiera procesado todavía.

Sistema de persistencia

Representa el sistema destino que tiene nuestros datos replicados (MongoDB, Couchbase, HDFS, HBase, etc).

Agente Ingestor: Comparativa tecnologías actuales

A primera vista, la pieza de nuestra arquitectura que quizá nos pueda plantear un mayor número de dudas es la pieza “Agente Ingestor”, sobre todo si tenemos en cuenta que vamos a tener que ir adaptándonos al sistema de logs de cada sistema legacy que queramos replicar.

Si no queremos “pelearnos” con cada sistema de logs que nos podemos encontrar en los proyectos, e ir implementando soluciones a medida por nuestra cuenta, el panorama tecnológico actual nos ofrece algunas alternativas interesantes, más o menos genéricas y/o fáciles de usar.

Además, algunas de ellas no sólo nos sirve como Agente Ingestor, sino como solución completa.

No obstante, todas las opciones que comentamos a continuación cumplen, al menos, con las siguientes características comunes:

• Replicación en tiempo real (near real time).
• Se basan en el procesamiento de logs transaccionales, por lo que apenas impactan sobre el rendimiento de las base de datos originales.

Soluciones comerciales

El catálogo de soluciones comerciales es bastante grande y el abanico de posibles opciones puede cambiar bastante dependiendo del sistema a replicar. Algunos de los que nos han parecido más interesantes son:

Oracle Golden Gate

Este producto de pago de Oracle nos ofrece alta disponibilidad flexible, evita y/o gestiona conflictos, permite transformaciones y la configuración de diversas topologías. Soporta las siguientes tecnologías:

• Fuente: Oracle, DB2, Microsoft SQL Server, y MySQL, entre algunas otras.
• Destino: Todas las anteriores más alguna tecnología más, como por ejemplo PostgreSQL (sí, esta base de datos solo está soportada como destino de datos, no como fuente).

Además, este producto cuenta con un producto alternativo, Oracle Golden Gate Big Data, especializado en la integración del proceso de replicación con sistemas de Big Data: HDFS, Apache Kafka, HBase, etc.

Este producto es especialmente interesante si se quiere replicar una base de datos Oracle. No obstante, y aunque cuenta con un IDE que permite configurar los procesos de replicación de una forma gráfica, no es trivial realizar este tipo de configuraciones, por lo que un inconveniente de este producto podría ser la necesidad de contar con soporte de Oracle para configurar los procesos de replicación.

En cualquier caso, se trata de un producto bastante maduro por lo que, si podemos afrontar los costes, es una alternativa muy a tener en cuenta.

CR8

Este producto de pago de la empresa DBS-H soporta las siguientes tecnologías:

• Fuente: Oracle, MSSQL, DB2 e Ingres.
• Destino: MongoDB, Hadoop, Kafka, Amazon S3, Google Cloud y diversas colas de mensajerías son las tecnologías más interesantes con las que no podemos integrar.

Este producto presenta una sistema de configuración (vía archivos Json) sencillo y flexible. Aunque no alcanza el nivel de madurez de otros productos, como Oracle Golden Gate, se postula también como una opción bastante interesante a tener en cuenta dentro de las opciones de pago.

Otros: Shareplex

Este producto de pago de la empresa Quest se anuncia de la siguiente forma en su propia web, “a mitad del precio de GoldenGate® de Oracle®”. Soporta las siguientes tecnologías:

• Fuente: Oracle.
• Destino: SAP, Oracle, SQL Server, EDB Postgres Advanced Server, JMS y archivos planos.

Soluciones Open Source

En pocas palabras, las soluciones Open Source son aquellas que publican su código fuente a la comunidad mediante una licencia que establece las condiciones de uso, modificación y/o distribución a terceros.

Dentro de este marco, las opciones que nos han parecido más interesantes para resolver nuestro problema son:

Debezium

Este software open source se basa en el registro de conectores Kafka, (además de algún que otro plugin según qué base de datos), que se encargan de procesar los logs transaccionales. Este proyecto se encuentra en un estado bastante activo. Y la última versión, en el momento de escribir este artículo, es la versión 0.5, liberada recientemente.

Está licenciado bajo Apache 2.0 y soporta las siguientes tecnologías:

• Fuente: PostgreSQL, MongoDB, MySQL, y actualmente se encuentra en desarrollo el conector para Oracle.
• Destino: Apache Kafka.

Es, sin duda, una de las principales alternativas para implementar nuestro proceso ingestor dentro del mundo Open Source. Además, la conectividad con Kafka lo hace fácilmente integrable con cualquier otra tecnología existente en el mercado.

BottledWater

Este proyecto open source se basa en una premisas bastante parecidas a las del anterior software, aunque en este caso sólo cubre el caso de PostgreSQL. Está licenciado bajo Apache 2.0.

• Fuente: PostgreSQL. e
• Destino: Apache Kafka.

Cabe destacar que no se encuentra en un estado muy activo en los últimos meses. Además, sólo cubre un subconjunto de los casos que cubre el framework anterior, Debezium, por lo que no sería la principal alternativa Open Source a tener en cuenta.

LinkedIn’s DataBus

Este software de código abierto, creado por LinkedIn para el procesamiento sus propias bases de datos, se basa en la publicación de los eventos leídos de la base de datos origen en un bus centralizado en memoria, ofreciendo de esta manera un punto único donde las aplicaciones clientes se pueden suscribir. Aunque el repositorio de este software se encuentra algo inactivo, podemos leer que se liberará bajo la licencia Apache 2.0.

Por último, reseñar que existen otros productos que también pueden resultar interesantes, pero que han sido obviados en este análisis debido a la forma de enfocar su implementación. Sirva como ejemplo el caso de SymmetricDS, el cual se basa en la creación de triggers sobre la base de datos original.

Conclusiones

En resumen, una alternativa viable para solucionar la problemática de la replicación de datos pasa por la aplicación del patrón de diseño Event Sourcing, ya que nos permite implementar soluciones resilientes, de alto rendimiento, desacopladas y escalables.

No obstante, la implementación no es sencilla, y además debemos tener en cuenta la complejidad añadida que nos supone el procesamiento de cada sistema de logs (de cada una de las fuentes de datos que queramos replicar), de una manera particular y diferente.