Migración de base de datos en la nube de AWS a Gcp acompañada de PgAudit

En uno de los desafíos más recientes que he tenido en el concepto de migraciones, surgió un caso donde la transaccionalidad y consistencia de datos se veía afectada por una migración de nube-nube, el plan se veía sólido, pero las restricciones del software legacy nos impedía romper los id-autoincrementales, por lo tanto el riesgo de inconsistencias se convirtió en un factor de riesgo, dado lo interesante de esto, escribiré algunas de las estrategias que nos sirvieron como red de seguridad al momento de migrar.

Iniciando la aventura

Una migración siempre es compleja, en especial con software legacy o sistemas que no fueron diseñados para escalar de manera distribuida o alguna otra estrategia de esa índole.

El desafío en sí era simple, cambiar de una nube a otra, por lo tanto a nivel de sistemas, redes e infraestructura la tarea estaba altamente estudiada, no así, los problemas de consistencia entre cambiar de bbdd con un mínimo downtime y transmitir a lo menos 1 terabyte de información en menos de 2 horas.

Ahora, profundizando debido a la naturaleza de los sistemas a migrar y que estos dependen de bases de datos transaccionales de nivel regional ( Postgresql ), aquí es donde empieza la aventura en los ámbitos de data, migración y lograr los objetivos de una bbdd ACID.

En concreto, ACID que es un acrónimo en inglés de Atomicity, Consistency, Isolation and Durability: Atomicidad, Consistencia, Aislamiento y Durabilidad. para aquellos sistemas.

Ahora los Problemas

Existen varias herramientas para generar ETL de una bbdd hacia otra, se han probado un variadas, Airbyte, Google Dataflow, DMS (google y aws), pero los planes de rollback, fueron una obligación, debido a que no fue aceptado tener pérdidas de información.

Iniciare con algunos planteamientos para esta migración.

Diagrama AWS a GCP

• Inicialmente se pensó crear un flujo de CDC entre ambas nubes, para mantener un flujo constante de actualizaciones entre ambos motores de bbdd, se generó un CDC mediante DMS de aws hacia GCP
• El resultado de esto fue exitoso, se logró enviar información de AWS hacia GCP en menos de 36hrs, luego de estar sincronizadas ambas bbdd, la actualización de GCP casi fue en tiempo real.

Diagrama CDC Bidireccional

• Con el fin de probar la migración para algunos clientes, se intentó sincronizar ambas bases de datos en tiempo real por lo tanto sería llamado CDC Bidireccional.
• Luego de muchas pruebas, búsqueda de recursos y poc realizadas, se desestimó esta opción como “utilizable” principalmente el problema radicó en los campos Auto-Incrementables.

Algunas de estas pruebas, fueron.

1. Implementar CDC de GCP a AWS al momento en que algún cliente operará sobre GCP
2. Utilizar Debezium como operador CDC Bidireccional
3. Ciertas herramientas en la Web de pago que prometen realizar estos servicios, de las cuales ninguna funcionó realmente.

Dejando la exploración y vamos al a solución.

Luego de muchas iteraciones, el arquitecto de la empresa dió con una extensión que presentó un cambio en el planteamiento, y me dirigí a hacer una POC que se transformaría en la opción viable en caso de rollback en los casos de fallar la migración de nube.

pgaudit icon

PostgreSQL Audit Extension

The PostgreSQL Audit Extension (or pgaudit) provides detailed session and/or object audit logging via the standard logging facility provided by PostgreSQL. The goal of PostgreSQL Audit to provide the tools needed to produce audit logs required to pass certain government, financial, or ISO certification audits.

For purposes of this the pgaudit project, the term “audit” refers to an official inspection of an individual’s or organization’s accounts, typically by an independent body.

The pgaudit project builds on the work done by members of the PostgreSQL Development Community in support of an open source audit capability for PostgreSQL. The source code associated with pgaudit is available under the PostgreSQL License.

Esta extensión, nos permitió auditar las transacciones que realizó la bbdd objetivo ( gcp ) por lo tanto toda operación que fuera realizada en gcp podría ser replicada a posteriori en nuestra bbdd líder (aws).

Nueva Estrategia

La estrategia con pgaudit nos permite almacenar en la herramienta logging de gcp, la cual nos dejaba un json de no menos 300 caracteres por cada acción ( de todas formas se pueden limitar las interacciones con la bbdd al momento de auditar, solo dejar los write y update por ejemplo). Pero de todas maneras se volvió poco manejable, el hecho de extraer con una query sobre logging, limita nuestra capacidad de hacer un rollback en un tiempo reducido, dado que habría que extraer caso a caso la data.

Básicamente la experiencia en gcp permitió solucionar de manera rápida y prácticamente desatendida nuestro reciente problema. El apoyo de la herramienta sink de GCP la cual permite enviar logs a otro tipo de storage, nos permitió mover data sin mayores gestiones.

Finalmente nuestra arquitectura de solución (y solución de facto) la podemos ver en la siguiente imagen.

Final Solution

Este flujo nos permitió registrar/auditar los eventos de manera tabular, y posteriormente extraer la query realizada desde el payload sin mayores dolores de cabeza, es más extraer esto a un csv o un archivo tipo script sql, el cual ejecutaría en el orden de llegada (según pub/sub) los comandos aplicados en nuestra migrada bbdd.

bigquery view of sink for cloud sql

Resultados finales

No llegamos a utilizar este camino, dado que la migración resultó sin incidencias relevantes a nivel de bbdd y no fue necesario realizar un rollback.

La experiencia y la seguridad que nos proporcionó tener esta red de seguridad, nos permitió solucionar problemas relacionados a sistemas con la seguridad de que teníamos la posibilidad de mantener nuestras transacciones consistentes en cualquier momento.

Para cerrar

Los invito a experimentar soluciones “fuera de la caja” en mi vida laboral he estado en al menos 8 migraciones, siendo 3 a gran escala (migración y fusión de 2 bancos) dado esto siento que la solución descrita aquí permite cierta libertad para los sistemas/nubes que presentan lock-in hoy en dia.

Los invito a visitar mi web https://feedingthemachine.store/ o https://www.feedingthemachine.ai/ y mi linkedin

Proximamente en https://www.youtube.com/playlist?list=PLEPrRvB1uAOBSxuq6jWLt2HONrB0U4SbG mas contenido practico :)