Arquitectura de migración y replicación de la base de datos mediante Striim

En este documento, se describe cómo usar Striim para diseñar la migración y replicación de la base 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á destinada a ingenieros de bases de datos y arquitectos de base de datos, así como a propietarios de datos que planean migrar o replicar las fuentes de datos en 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 reducir el tiempo de salida al mercado de sus servicios y responder con rapidez a los cambios en las demandas del cliente y las condiciones del mercado. Las aplicaciones empresariales que aprovechan al máximo el procesamiento basado en la nube de principio a fin son esenciales para el crecimiento empresarial de larga duración.

Las aplicaciones de servicio crítico heredados 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 suele ser 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. El siguiente diagrama muestra el caso práctico 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 migración básica de fuente a Cloud Spanner

En el siguiente diagrama, se ilustra un caso práctico 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 objetivo 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 de destino correspondiente en forma moderna (implementada en Google Kubernetes Engine) accede a una de las bases de datos de origen. La segunda base de datos de origen también tiene clientes (no se muestran en el diagrama).

Aunque el sistema de migración de bases de datos está instalado en Google Cloud, el sistema de migración puede instalarse en otro lugar. Por ejemplo, es posible que el sistema de migración se ejecute 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 para la migración de bases de datos son una migración de extracción y cambio 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 fuente, 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 nube. Cuando la base de datos de destino nueva está lista, las aplicaciones empresariales se ejecutan en la nube y acceden a los datos.

Una desventaja del enfoque de 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 cuidadosa para migrar durante los 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 restablecer la base de datos en la nube. Cualquier prueba de la aplicación después del restablecimiento de la base de datos aumenta el tiempo de inactividad. Además, el enfoque lift-and-shift crea una copia intermedia de la base de datos que necesita proteger, mover, almacenar y, finalmente, borrar. Este aspecto agrega complejidad de costos y administración. Si bien el enfoque de efectividad puede cambiar para ciertas aplicaciones, los requisitos de la mayoría de las aplicaciones esenciales no toleran estos costos. Por estos motivos, 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 las fuentes de origen y objetivo completas por meses, o incluso años, mientras optimizas y pruebas la aplicación empresarial para la nueva base de datos basada en base.

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 fuente se retira cuando se completa la migración 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 prácticos, la base de datos original debe replicarse continuamente en el objetivo operativo o analítico, como Spanner o BigQuery. La base de datos fuente no se cierra como lo es con una migración de base de datos.

Las migraciones y réplicas de bases de datos en línea para bases de datos homogéneas suelen ser complejas y requieren meses o incluso años de codificación manual e 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 un sistema de integración y migración de bases de datos, como Striim.

En el siguiente diagrama, se muestra una arquitectura de implementación básica de la plataforma de inteligencia y de integración 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 bases 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 el movimiento continuo de datos entre bases de datos heterogéneas. Para las migraciones a Google Cloud, Striim ofrece una plataforma de extracción, transmisión, transformación y carga (ETL) no intrusiva, que es más rápida de implementar y iterar que otras soluciones.

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

Con la replicación continua de datos 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 una validación de entrega continua integrada, alta disponibilidad y conmutación por error, Striim también minimiza el riesgo de pérdida de datos.

Casos prácticos 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 tecnológicos y específicos de la industria (neutrales). Por ejemplo, un uso específico del sector puede ser un servicio financiero que aprovecha los servicios de datos en la nube y los datos en tiempo real. Un caso práctico más centrado en la tecnología podría ser migraciones de bases de datos de informes o migraciones en etapas de bases de datos operativas. Striim permite estos casos prácticos mediante canalizaciones de datos continuas que entregan datos en el formato correcto en el momento oportuno.

En esta sección, se analiza el uso de Striim para migrar bases de datos en un caso práctico específico de la industria y dos casos prácticos 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 prestatarios y los prestamistas quieren ahorrar tiempo con las originaciones de préstamos. Las empresas de tecnología financiera pueden usar Striim para abordar varios requisitos comerciales como estos.

Considera un servicio automatizado de verificación de ingresos y empleados que acelera los orígenes de macrodatos. En este caso práctico, Striim integra datos en tiempo real de varias fuentes locales a Google Cloud. Esta automatización reduce las demoras en el proceso de verificación de empleo. En el siguiente diagrama, se ilustra la arquitectura para este caso práctico.

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 continuamente datos de varias fuentes internas y externas, como la nómina de los procesadores, como ADP, y los datos demográficos y de los empleados de otros proveedores. Striim alimenta los datos a varios servicios de Google Cloud. Striim transfiere de forma continua datos de bases de datos relacionales con CDC basadas en registros, en las que se accede a los archivos de recorrido de Oracle® GoldenGate cuando corresponda, y incluso desde archivos planos. Striim entrega los datos agregados y transformados de manera continua a Cloud Storage para potenciar las aplicaciones y servicios empresariales creados para la nube.

Descarga de informes

Para algunos casos prácticos de tecnología, se distingue entre cargas de trabajo transaccionales y cargas de trabajo analíticas. Debido al aumento del rendimiento en tu base de datos transaccional de origen y mayor latencia al mostrar consultas analíticas, no tiene sentido ejecutar consultas analíticas en bases de datos transaccionales.

Para abordar esta distinción, puedes enviar un subconjunto de tus datos transaccionales a Google Cloud de forma continua a fin de ejecutar análisis e informes adicionales en BigQuery. En el siguiente diagrama, se muestra un ejemplo de arquitectura.

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

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 empresas grandes tienen bases de datos locales masivas que conservan años de datos valiosos. La migración de estas bases de datos a la nube es una tarea grande que puede llevar años. Mantener las bases de datos heredadas también tiene un costo, por ejemplo, la pérdida de oportunidades de las nuevas tecnologías de bases de datos en la nube, 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 para crear el adjunto de VLAN de supervisión. Comenzar con un subconjunto pequeño también permite que los desarrolladores prueben el nivel de aplicación en la base de datos nueva 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 el riesgo 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 varios casos prácticos de migración y replicación de bases 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 fuente 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 completas o por fases.

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 bases de datos, Striim, está conectado a ambos sistemas y migra los datos del sistema de base de datos de destino al 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 base de datos de destino: Cloud Spanner para 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 después de 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 completada, 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 prácticos, 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 prácticos son más estáticos, como en el caso de la replicación de la base de datos. En esta arquitectura, se muestra cómo una arquitectura puede entregar varios casos prácticos.

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.

Esta arquitectura también demuestra cómo Striim puede operar en un entorno en clústeres 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 ubica en una zona diferente, lo 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 a 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 este migra y replica datos a 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, el flujo se revierte de Cloud SQL a la base de datos en la nube a fin de prepararse para un posible resguardo. Para garantizar que cualquier cambio en el destino también esté disponible en la fuente, la migración inversa debe configurarse después de la migración original.

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

Arquitectura del resguardo a la base de datos fuente mediante el sistema de migración 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 una reserva, 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 diagrama siguiente, se muestra cómo esta arquitectura de implementación admite el caso práctico de replicación continua.

Arquitectura de replicación continua de 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 forma continua en BigQuery y Cloud Spanner.

Como se muestra en este debate, esta arquitectura de implementación puede admitir varios casos prácticos, sin importar la complejidad. La configuración también se puede cambiar de forma dinámica, por ejemplo, cuando se revierte 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 la arquitectura de implementación en comparación con la especificación de migración

En las arquitecturas anteriores, las dos dimensiones de complejidad incluyen las siguientes:

  • Cantidad de sistemas de bases de datos conectados a Striim
  • Cambio de arquitectura de implementación con el tiempo a medida que se completen los casos prácticos

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

Por ejemplo, si una base de datos de MySQL local se migra a una base de datos 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 proviene 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 de destino 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 Tu caso práctico para evaluar tus requisitos.

Función Similares Diferentes Tu caso práctico
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 la base de datos de origen y de destino Complejidad baja Complejidad alta
Partición de datos (si está presente) Complejidad baja Complejidad alta
Separación o separación de datos Complejidad alta Complejidad alta

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

Otras consideraciones pueden desempeñar una función para determinar la complejidad, en especial en casos prácticos avanzados. Por ejemplo:

  • ¿Se consolidarán varias de tus bases de datos de origen en una base de datos de destino única?
  • ¿Se redistribuirán los datos de varias de tus bases de datos fuente a un conjunto de bases de datos de destino, por ejemplo, de nuevo refragmentar o volver a particionar?
  • ¿Los datos se enriquecerán o se reducirá 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 práctico aumenta la complejidad, que un sistema como Striim está compilado para brindar compatibilidad.

¿Qué sigue?