Arquitectura de migración de bases de datos y replicación mediante Striim

En este documento, se describe cómo usar Striim para diseñar la migración y replicación de bases de datos. Este documento se centra en los conceptos de arquitectura que se relacionan con la migración de la base de datos y la replicación continua. Está diseñado para ingenieros de bases de datos y arquitectos de bases de datos, así como para propietarios de datos que planean migrar o replicar las fuentes de datos a Google Cloud.

Introducción a la migración y replicación de las bases de datos

Muchas empresas adoptan una estrategia de aplicación centrada en la nube mediante la compilación de aplicaciones empresariales con tecnologías y servicios basados en la nube. Las empresas compiten por acortar el tiempo de salida al mercado de sus servicios y responder rápidamente a los cambios en las demandas de los clientes y las condiciones del mercado. Las aplicaciones empresariales que aprovechan al máximo la computación basada en la nube de extremo a extremo son fundamentales para el crecimiento empresarial prolongado.

Las aplicaciones de Servicio crítico heredadas presentan varios desafíos para una migración a la nube: migrar el nivel de la aplicación, migrar la base de datos subyacente y mantener el acceso de los usuarios a las aplicaciones sin interrupciones durante una migración.

Varios productos y servicios de migración pueden ayudar a migrar el nivel de aplicación empresarial, pero migrar las bases de datos subyacentes que entregan la aplicación empresarial a menudo es el desafío más difícil.

En la práctica, una migración de la base de datos a la nube puede adoptar varias formas diferentes. En el siguiente diagrama, se muestra el caso de uso más básico; una base de datos local se migra a una base de datos basada en la nube, en este caso, Cloud Spanner.

Arquitectura de la migración básica de la fuente a Cloud Spanner.

En el siguiente diagrama, se ilustra un caso de uso más complejo: mover varias bases de datos junto con una Modernización de aplicaciones.

Arquitectura de una migración compleja que involucra varias bases de datos fuente y de destino mediante un sistema de migración de bases de datos.

En esta configuración, se migran dos bases de datos de origen a dos bases de datos de destino. Una aplicación que accede a la base de datos objetivo correspondiente en forma modernizada se accede a una de las bases de datos de origen (implementada en Google Kubernetes Engine). La segunda base de datos de origen también tiene clientes (no se muestra en el diagrama).

Aunque el sistema de migración de bases de datos está instalado en Google Cloud, el sistema de migración se puede instalar en otro lugar. Por ejemplo, puede que el sistema de migración tenga que ejecutarse en la misma ubicación que la base de datos de origen por motivos de seguridad.

Migraciones de bases de datos en línea y de lift-and-shift

En un nivel alto, los dos enfoques de la migración de la base de datos son una migración lift-and-shift y una migración en línea.

En una migración lift-and-shift, por lo general, se exporta o se crea una copia de seguridad de una base de datos de origen, se mueve el archivo exportado o de copia de seguridad a la nube y, luego, se importa y se restablece el archivo en una instancia de base de datos de destino que se ejecuta en la nube. Cuando la nueva base de datos de destino esté lista, las aplicaciones empresariales se ejecutan en la nube y acceden a los datos.

Una desventaja del enfoque lift-and-shift es que requiere tiempo de inactividad para la aplicación empresarial y la base de datos. Este enfoque requiere una planificación adecuada para la migración durante períodos de baja actividad. Este enfoque también supone que puedes detener la aplicación empresarial durante la migración y reiniciarla después de que se restablezca la base de datos en la nube. Cualquier prueba de la aplicación después de que se restablezca la base de datos se agrega el tiempo de inactividad. Además, el enfoque lift-and-shift crea una copia intermedia de la base de datos que se debe proteger, mover, almacenar y, finalmente, borrar. Este aspecto agrega complejidad de costos y administración. Si bien el enfoque lift-and-shift puede funcionar para ciertas aplicaciones, los requisitos de la mayoría de las aplicaciones fundamentales para la empresa no toleran estos costos. Por estas razones, una migración de base de datos en línea es un enfoque mucho mejor.

El enfoque de la migración en línea tiene como objetivo un impacto mínimo sobre el rendimiento de la base de datos y los usuarios de las aplicaciones empresariales. El enfoque en línea te permite migrar continuamente tus bases de datos a la nube, lo que mantiene a la base de datos continuas la fuente y las bases de datos durante meses o incluso años, mientras optimizas y pruebas la aplicación empresarial para la nueva base de datos basada en la nube.

Comparación entre la migración de la base de datos y la replicación de base de datos

En una migración de base de datos a la nube, la base de datos de origen se retira cuando la migración se completa porque la base de datos en la nube ahora es la instancia de producción.

En algunos casos prácticos, la instancia de base de datos original podría continuar ejecutándose mientras se procesa el procesamiento posterior en Google Cloud. En este caso, la base de datos fuente se replica en Google Cloud. Por ejemplo, es posible que tengas una aplicación que acceda a una base de datos que depende de la tecnología que no se puede mover a Google Cloud. Al mismo tiempo, la tecnología de Google Cloud se usa para las funciones como el análisis, por ejemplo, para replicar en BigQuery. Otro ejemplo es cuando una base de datos que contiene información de identificación personal (PII) debe residir en un entorno local, mientras que el procesamiento descendente que usa información de PII ofuscada ocurre en Google Cloud.

En estos casos de uso, la base de datos original se debe replicar de forma continua en el destino operativo o analítico, como Spanner o BigQuery. La base de datos fuente no se cierra, como sí sucede con una migración de la base de datos.

Por lo general, la migración y la replicación de bases de datos en línea para bases de datos heterogéneas son complejas, lo que implica meses o incluso años de programación manual y la integración de varios servicios. Un enfoque más moderno y eficiente para las migraciones de bases de datos en línea es el uso de sistemas de integración y migración de bases de datos, como Striim.

En el siguiente diagrama, se muestra una arquitectura básica de implementación de la plataforma de integración y de inteligencia de datos de Striim con una base de datos de origen y una de destino.

Arquitectura de la migración básica con Striim

Migración y replicación de la base de datos con Striim

Striim, un socio de tecnología de Google que proporciona tecnología de migración de bases de datos, simplifica las migraciones en línea mediante una interfaz de arrastrar y soltar para configurar un movimiento de datos continuo entre bases de datos heterogéneas. Para esas migraciones a Google Cloud, Striim ofrece una plataforma no integrada, de extracción, transformación y carga (ETL) no integrada, que es más rápida de implementar y fácil de iterar que otras soluciones.

Con la captura de datos no intrusiva (CDC), Striim extrae datos en tiempo real sin ralentizar las bases de datos transaccionales de origen, lo que permite realizar migraciones de bases de datos en la nube que no generan tiempo de inactividad y riesgo mínimo. Mientras los datos están en tránsito, Striim puede filtrar, transformar, agregar y enriquecer los datos a través de consultas de SQL mediante un motor integral de estadísticas de transmisión.

Cuando replicas datos de manera continua entre las bases de datos locales y las bases de datos de Google Cloud, Striim admite la replicación en línea en la que las aplicaciones esenciales están ejecutándose sin incurrir en tiempo de inactividad. Con la validación de entrega continua integrada, la alta disponibilidad y la conmutación por error, Striim también minimiza el riesgo de pérdida de datos.

Casos de uso para la migración y replicación de la base de datos

Las migraciones de bases de datos en línea y la replicación continua se pueden aplicar a una variedad de problemas técnicos y específicos de la industria (neutrals del sector). Por ejemplo, un uso específico de la industria puede ser un servicio financiero que aprovecha los servicios de datos en la nube y los datos en tiempo real. Un caso de uso más enfocado en la tecnología podría ser migraciones de bases de datos de informes o migraciones por fases de bases de datos operativas. Striim habilita estos casos de uso mediante el suministro de canalizaciones de datos continuos que entregan datos en el formato correcto en el momento adecuado.

En esta sección, se analiza el uso de Striim para migrar bases de datos en un caso de uso específico de la industria y dos casos de uso tecnológicos.

Tecnología financiera

Las empresas de tecnología financiera (fintech) requieren datos rápidos y precisos. Por ejemplo, los clientes bancarios quieren ver transacciones y saldos nuevos publicados en sus cuentas de inmediato. Los prestamistas desean ahorrar tiempo con las fuentes de préstamos. Las empresas de tecnología financiera pueden usar Striim para abordar varios requisitos empresariales como estos.

Considera un empleado automatizado y un servicio de verificación de ingresos que aceleran las relaciones de origen. En este caso de uso, Striim integra datos en tiempo real de varias fuentes locales a Google Cloud. Esta automatización reduce los retrasos en el proceso de verificación de empleo. En el siguiente diagrama, se ilustra la arquitectura para este caso de uso.

Caso práctico de Fintech que transmite datos a Google Cloud mediante Striim

Esta arquitectura aprovecha la integración de datos de transmisión en tiempo real de Striim. Striim recopila de forma continua datos de varias fuentes internas y externas, por ejemplo, nóminas de procesadores, como ADP, y datos demográficos y de empleados de otros proveedores. Striim envía los datos a varios servicios de Google Cloud. Striim transfiere de forma continua los datos de bases de datos relacionales con los CDC basados en registros, a los que acceden los archivos de senderos de Oracle® GoldenGate, cuando corresponda, e incluso desde archivos sin formato. Striim entrega los datos agregados y transformados de manera continua a Cloud Storage para potenciar las aplicaciones y servicios empresariales compilados para la nube.

Descarga de informes

En algunos casos de uso tecnológicos, se distingue entre cargas de trabajo transaccionales y cargas de trabajo analíticas. Debido al aumento del rendimiento que proviene de tu base de datos transaccional de origen y el aumento de la latencia cuando se muestran consultas analíticas, no tiene sentido ejecutar consultas analíticas en bases de datos transaccionales.

Para abordar esta distinción, puedes entregar de manera continua un subconjunto de tus datos transaccionales a Google Cloud para ejecutar más análisis e informes en BigQuery. En el siguiente diagrama, se muestra un ejemplo de arquitectura.

Arquitectura que divide las cargas de trabajo entre bases de datos transaccionales y de datos.

Con la capacidad de transformar y normalizar datos en canalizaciones de datos de transmisión, Striim puede integrar un subconjunto seleccionado de datos transaccionales de origen a plataformas de análisis mientras los datos restantes se mueven continuamente a uno o más objetivos de datos de Google Cloud.

Migración por fases

Las grandes empresas tienen bases de datos locales enormes que contienen datos valiosos de años. Migrar estas bases de datos a la nube es una tarea considerable que puede tardar años. Mantener las bases de datos heredadas también genera un costo, por ejemplo, porque se perdió la oportunidad de las tecnologías de bases de datos en la nube nuevas, como BigQuery, Cloud Spanner y Pub/Sub.

Para encontrar un equilibrio entre mantener los sistemas heredados y aprovechar las últimas tecnologías de bases de datos en la nube, puedes migrar subconjuntos de datos a bases de datos de Google Cloud mediante Striim en un enfoque por fases y, aun así, mantener las bases de datos de producción de origen en ejecución. Comenzar con un subconjunto pequeño también permite a los desarrolladores probar el nivel de la aplicación en la nueva base de datos en la nube sin afectar la base de datos local de producción.

Después de asegurarte de que el nivel de aplicación sea compatible, puedes aumentar gradualmente los subconjuntos que migras hasta que se migre toda la base de datos. Esta migración progresiva te permite administrar riesgos y migrar tus sistemas de producción con un tiempo de inactividad mínimo.

Arquitectura de implementación

Las arquitecturas de implementación de esta sección muestran las diversas bases de datos, aplicaciones y servicios en la nube involucrados en diversos casos de uso para la migración y replicación de la base de datos.

Arquitectura de implementación básica

En el siguiente diagrama, se muestra una arquitectura de implementación simple: el sistema de base de datos de origen se migra al sistema de base de datos basado en la nube, Cloud Spanner. Esta arquitectura se usa en todo este documento y funciona para la replicación continua y las migraciones por fases o completas.

Arquitectura de la migración básica con Striim

En esta arquitectura, el sistema de base de datos de origen se migra al sistema de base de datos basado en la nube, que en este caso es Cloud Spanner. El sistema de migración de la base de datos, Striim, está conectado a ambos sistemas y migra los datos del origen al sistema de base de datos de destino.

Arquitectura de implementación de complejidad media

En el siguiente diagrama, se muestra una arquitectura que involucra dos sistemas de bases de datos de origen. Esta arquitectura es más compleja que la arquitectura anterior y funciona para la migración de la base de datos y la replicación de la base de datos.

Migración de bases de datos locales y de origen en la nube a bases de datos de destino transaccionales y analíticas.

En el diagrama, se muestra la arquitectura inicial con dos sistemas de bases de datos de origen. Una fuente es un sistema de base de datos (S1) que se ejecuta en una nube pública que debe migrarse. La segunda fuente es un sistema de base de datos (S2) que se ejecuta en un centro de datos local, que permanece en las instalaciones, mientras que sus datos y cambios posteriores se replican en BigQuery para las estadísticas. Se implementan dos sistemas de bases de datos objetivo: Cloud Spanner con el fin de recibir los datos de S1 (migración) y BigQuery para recibir transmisiones continuas de datos de S2.

En el siguiente diagrama, se representa la arquitectura de implementación una vez que se completa la migración de la base de datos. S1 se finaliza, y el objetivo correspondiente de Cloud Spanner ya no se conecta a Striim.

Arquitectura después de la migración completa en la que la base de datos transaccional se desconecta de Striim

Esta situación demuestra que la arquitectura de implementación no es necesariamente estática. Algunos casos de uso, como una migración de base de datos única, requieren que el sistema de migración esté conectado a los sistemas o servicios hasta que se complete la migración. Otros casos de uso son más estáticos, como en el caso de la replicación de bases de datos. En esta arquitectura, se muestra cómo una arquitectura puede entregar varios casos de uso.

Arquitectura de implementación compleja

En esta sección, se describe una migración que se diseñó como resguardo. Puede ser necesario usar un resguardo cuando los errores que ocurren después de la migración requieren que regreses al procesamiento en la fuente. La configuración de resguardo garantiza que, cuando se revierta una migración, los cambios en el objetivo se comuniquen con la fuente.

Esta arquitectura de implementación implica la replicación y la migración, y es la más compleja de las tres arquitecturas analizadas en este documento.

En esta arquitectura, también se muestra cómo Striim puede operar en un entorno agrupado para admitir una mayor capacidad de procesamiento. El clúster en la siguiente arquitectura consta de tres instancias de Compute Engine para proporcionar capacidad suficiente. Cada instancia de Compute Engine se coloca en una zona diferente, que proporciona alta disponibilidad para la protección contra fallas zonales y de instancias.

En este caso, dos bases de datos de origen ubicadas en un centro de datos local se replican en la nube. Una base de datos se replica en Cloud Spanner y la otra en BigQuery. Además, la migración mueve datos de una base de datos en una nube pública a una instancia de Cloud SQL.

En el siguiente diagrama, se muestra la arquitectura de implementación antes de que se complete la migración.

Arquitectura de varias bases de datos fuente y objetivo con el sistema de migración Striim

Tres bases de datos de origen están conectadas a Striim, y Striim migra y replica los datos en tres bases de datos de destino. Las dos bases de datos de origen en el centro de datos local se replican en BigQuery y Cloud Spanner, y la base de datos de origen en la nube se migra a Cloud SQL.

Una vez que se completa la migración, se pasa el flujo de Cloud SQL a la base de datos en la nube a fin de prepararse para un posible resguardo. Para garantizar que los cambios en el destino también estén disponibles en la fuente, la migración inversa se debe configurar después de la migración original.

En el siguiente diagrama, se muestra el cambio de configuración para un posible resguardo.

Arquitectura de resguardo a la base de datos de origen mediante el sistema de migración de Striim.

La dirección del flujo de datos se invierte entre la base de datos de nube de origen original y Cloud SQL. Después de que se complete la migración y se elimina la necesidad de realizar un resguardo, se desconectan los sistemas relacionados en la migración, incluidos Cloud SQL y la base de datos de origen en el centro de datos local.

En el siguiente diagrama, se muestra cómo esta arquitectura de implementación admite el caso de uso de replicación continua.

Arquitectura de replicación continua desde dos bases de datos de origen locales a varios objetivos con Striim.

Las dos bases de datos de origen en el centro de datos local se replican de manera continua en BigQuery y Cloud Spanner.

Como se muestra en este debate, esta arquitectura de implementación puede admitir varios casos de uso, sin importar la complejidad. La configuración también puede cambiarse de forma dinámica, por ejemplo, cuando se invierte la dirección del movimiento de datos.

Esta arquitectura también se puede escalar para que admita un aumento o una mayor carga.

Complejidad de arquitectura de implementación en comparación con especificación de migración

En las arquitecturas anteriores, las dos dimensiones de complejidad incluyen lo siguiente:

  • Cantidad de sistemas de bases de datos conectados a Striim
  • Cambio en la arquitectura de implementación a lo largo del tiempo a medida que se completan los casos de uso

La complejidad también se puede considerar en el contexto de las especificaciones de la migración, independientemente de la arquitectura de implementación.

Por ejemplo, si una base de datos MySQL local se migra a una base de datos de MySQL en la nube y, si el esquema y los datos son idénticos, la especificación de migración es sencilla, porque la especificación es una copia. Sin embargo, si la migración es de una base de datos de Oracle a una base de datos de Cloud Spanner, la complejidad de la migración aumenta significativamente, ya que los esquemas de origen y objetivo son diferentes y los datos deben transformarse durante la migración.

En la siguiente tabla, se proporciona un enfoque de alto nivel para determinar la complejidad de una especificación de migración. Las funciones se enumeran junto con una indicación de la complejidad de la migración o la replicación. Puedes usar la columna titulada Tu caso de uso para evaluar tus requisitos.

Función Similares Diferentes Tu caso de uso
Sistema de base de datos de origen y de destino Complejidad baja Complejidad alta
Esquema de base de datos de origen y de destino Complejidad baja Complejidad alta
Datos de origen y de base de datos de destino Complejidad baja Complejidad alta
Partición de datos (si está presente) Complejidad baja Complejidad alta
Separación de datos o consolidación Complejidad alta Complejidad alta

La complejidad de la migración es un espectro basado en el caso de uso que se implementa. Para tu caso de uso, puedes determinar la complejidad general según la proporción de complejidad baja a alta complejidad para las funciones de tu caso de uso.

Otras consideraciones pueden determinar una función para determinar la complejidad, en especial en casos de uso avanzados. Por ejemplo:

  • ¿Algunas de tus bases de datos de origen se consolidarán en una sola base de datos de destino?
  • ¿Los datos de varias de tus bases de datos fuente se redistribuirán en un conjunto de bases de datos de destino, por ejemplo, la refragmentación o la repartición?
  • ¿Los datos se enriquecerán o se reducirán durante la migración para proporcionar un conjunto de datos bien seleccionado en el sistema de destino?

Cada función que agregas a tu caso de uso aumenta la complejidad, que un sistema como Striim está compilado para brindar compatibilidad.

¿Qué sigue?