Gestión de bases de datos multinube: arquitecturas, casos prácticos y prácticas recomendadas

En este documento se describen las arquitecturas de implementación, los casos prácticos y las prácticas recomendadas para la gestión de bases de datos multinube. Está dirigido a arquitectos e ingenieros que diseñan e implementan aplicaciones con estado en varias nubes.

Las arquitecturas de aplicaciones multinube que acceden a bases de datos dependen del caso práctico. Ninguna arquitectura de aplicación con estado puede admitir todos los casos prácticos multicloud. Por ejemplo, la mejor solución de base de datos para un caso práctico de picos de carga en la nube es diferente de la mejor solución de base de datos para una aplicación que se ejecuta simultáneamente en varios entornos de nube.

En las nubes públicas, como Google Cloud, hay varias tecnologías de bases de datos que se adaptan a casos prácticos multicloud específicos. Para desplegar una aplicación en varias regiones de una sola nube pública, una opción es usar una base de datos multirregional gestionada por un proveedor de nube pública, como Spanner. Para desplegar una aplicación que se pueda usar en varias nubes públicas, puede ser mejor opción una base de datos independiente de la plataforma, como AlloyDB Omni o PostgreSQL.

En este documento se presenta una definición de aplicación de base de datos con estado, seguida de un análisis de un caso práctico de base de datos multinube. A continuación, se muestra una categorización detallada de los sistemas de bases de datos para arquitecturas de implementación multicloud en función de los casos prácticos.

El documento también incluye un árbol de decisiones para seleccionar bases de datos, que describe los puntos clave para elegir una tecnología de base de datos adecuada. El curso termina con un debate sobre las prácticas recomendadas para gestionar bases de datos multinube.

Términos y definiciones clave

En esta sección se proporciona una terminología y se define la aplicación genérica de base de datos con estado que se usa en este documento.

Terminología

• Nube pública. Una nube pública proporciona una infraestructura multiinquilino (normalmente global) y servicios que los clientes pueden usar para ejecutar sus cargas de trabajo de producción. Google Cloud es una nube pública que proporciona muchos servicios gestionados, como GKE, GKE Enterprise y bases de datos gestionadas.
• Nube híbrida. Una nube híbrida es una combinación de una nube pública con uno o varios centros de datos on-premise. Los clientes de nubes híbridas pueden combinar sus servicios locales con servicios adicionales proporcionados por una nube pública.
• Multinube. Una multinube es una combinación de varias nubes públicas y centros de datos on-premise. Una nube híbrida es un subconjunto de la multicloud.
• Ubicación de la implementación. Una ubicación de infraestructura es una ubicación física que puede desplegar y ejecutar cargas de trabajo, incluidas aplicaciones y bases de datos. Por ejemplo, en Google Cloud, las ubicaciones de implementación son zonas y regiones. A nivel abstracto, una región o una zona de nube pública y un centro de datos on‐premise son ubicaciones de implementación.

Aplicaciones de bases de datos con reconocimiento del estado

Para definir los casos prácticos de multinube, en este documento se usa una arquitectura de aplicación de base de datos genérica con estado, tal como se muestra en el siguiente diagrama.

En el diagrama se muestran los siguientes componentes:

• Base de datos. Una base de datos puede ser una instancia única, una instancia múltiple o una base de datos distribuida, desplegada en nodos de computación o disponible como servicio gestionado en la nube.
• Servicios de aplicaciones. Estos servicios se combinan en una aplicación que implementa la lógica empresarial. Los servicios de aplicaciones pueden ser cualquiera de los siguientes:
  • Microservicios en Kubernetes.
  • Procesos de grano grueso que se ejecutan en una o varias máquinas virtuales.
  • Una aplicación monolítica en una máquina virtual grande.
  • Código sin servidor en Cloud Run Functions o Cloud Run. Algunos servicios de aplicaciones pueden acceder a la base de datos. Es posible desplegar cada servicio de aplicación varias veces. Cada despliegue de un servicio de aplicación es una instancia de ese servicio de aplicación.
• Clientes de aplicaciones. Los clientes de aplicaciones acceden a las funciones que proporcionan los servicios de aplicaciones. Los clientes de aplicaciones pueden ser uno de los siguientes:
  • Clientes implementados, donde el código se ejecuta en un ordenador, un portátil o un teléfono móvil.
  • Clientes no implementados, en los que el código de cliente se ejecuta en un navegador. Las instancias de cliente de la aplicación siempre acceden a una o varias instancias del servicio de la aplicación.

En el contexto de una conversación sobre bases de datos multicloud, la abstracción arquitectónica de una aplicación con estado consta de una base de datos, servicios de aplicaciones y clientes de aplicaciones. En una implementación de una aplicación, pueden variar factores como el uso de sistemas operativos o los lenguajes de programación que se utilicen. Sin embargo, estos detalles no afectan a la gestión de bases de datos multicloud.

Colas y archivos como servicios de almacenamiento de datos

Hay muchos recursos de persistencia disponibles para que los servicios de aplicaciones conserven los datos. Entre estos recursos se incluyen bases de datos, colas y archivos. Cada recurso de persistencia proporciona modelos de datos de almacenamiento y patrones de acceso especializados para estos modelos. Aunque las aplicaciones usan colas, sistemas de mensajería y sistemas de archivos, en la siguiente sección nos centraremos específicamente en las bases de datos.

Aunque las mismas consideraciones sobre factores como la ubicación del despliegue, el uso compartido del estado y la replicación síncrona y asíncrona de las bases de datos multinube se aplican a las colas y los archivos, este tema no se aborda en este documento.

Redes

En la arquitectura de una aplicación con estado genérica (que se muestra de nuevo en el diagrama siguiente), cada flecha entre los componentes representa una relación de comunicación a través de una conexión de red. Por ejemplo, un cliente de aplicación que accede a un servicio de aplicación.

Una conexión puede estar en una zona o en varias zonas, regiones o nubes. Las conexiones pueden establecerse entre cualquier combinación de ubicaciones de implementación. En los entornos multicloud, la conexión en red entre nubes es un aspecto importante que debes tener en cuenta. Hay varias opciones que puedes usar. Para obtener más información sobre las redes entre nubes, consulta Red multinube para aplicaciones distribuidas y Conectarse a Google Cloud: explicación de las opciones de redes.

En los casos prácticos de este documento, se da por supuesto lo siguiente:

• Existe una conexión de red segura entre las nubes.
• Las bases de datos y sus componentes pueden comunicarse entre sí.

Desde una perspectiva no funcional, el tamaño de la red, es decir, el rendimiento y la latencia, puede afectar a la latencia y al rendimiento de la base de datos. Desde el punto de vista funcional, las redes no suelen tener ningún efecto.

Casos prácticos de bases de datos multinube

En esta sección se presenta una selección de los casos prácticos más habituales de la gestión de bases de datos multicloud. En estos casos prácticos, se presupone que hay una conectividad de red segura entre las nubes y los nodos de la base de datos.

Migración de aplicaciones

En el contexto de la gestión de bases de datos multicloud, la migración de aplicaciones se refiere a la migración de una aplicación, todos los servicios de la aplicación y la base de datos de la nube actual a una nube de destino. Hay muchos motivos por los que una empresa puede decidir migrar una aplicación, por ejemplo, para evitar una situación competitiva con el proveedor de servicios en la nube, modernizar la tecnología o reducir el coste total de propiedad.

En la migración de aplicaciones, el objetivo es detener la producción en la nube actual y continuar la producción en la nube de destino una vez que se haya completado la migración. Los servicios de aplicaciones deben ejecutarse en la nube de destino. Para implementar los servicios, se puede usar un enfoque de migración directa. Con este enfoque, el mismo código se despliega en la nube de destino. Para volver a implementar el servicio, se pueden usar las tecnologías de nube modernas que estén disponibles en la nube de destino.

Desde el punto de vista de la base de datos, puedes elegir entre las siguientes alternativas para migrar la aplicación:

• Lift and shift de bases de datos: si el mismo motor de base de datos está disponible en la nube de destino, es posible migrar la base de datos para crear una implementación idéntica en la nube de destino.
• Migración de bases de datos a un equivalente gestionado: una base de datos autogestionada se puede migrar a una versión gestionada del mismo motor de base de datos si la nube de destino la proporciona.
• Modernización de bases de datos: las diferentes nubes ofrecen distintas tecnologías de bases de datos. Las bases de datos gestionadas por un proveedor de servicios en la nube pueden tener ventajas, como acuerdos de nivel de servicio (SLAs) más estrictos, escalabilidad y recuperación automática ante desastres.

Independientemente de la estrategia de implementación, la migración de bases de datos es un proceso que lleva tiempo, ya que es necesario mover los datos de la nube actual a la nube de destino. Aunque es posible seguir un enfoque de exportación e importación que implique un tiempo de inactividad, es preferible una migración con un tiempo de inactividad mínimo o nulo. Este enfoque minimiza el tiempo de inactividad de las aplicaciones y tiene el menor efecto en una empresa y sus clientes. Sin embargo, normalmente requiere una configuración de migración más compleja, ya que implica una carga inicial, una replicación continua, una monitorización, una validación granular y una sincronización al cambiar. Para admitir escenarios de fallback, debes implementar un mecanismo de replicación inversa para sincronizar los cambios en la base de datos de origen después de cambiar a la base de datos de destino.

Recuperación tras fallos

La recuperación tras desastres se refiere a la capacidad de una aplicación para seguir proporcionando servicios a los clientes de la aplicación durante una interrupción de la región. Para asegurar la recuperación ante desastres, una aplicación debe desplegarse en al menos dos regiones y estar lista para ejecutarse en cualquier momento. En producción, la aplicación se ejecuta en la región principal. Sin embargo, si se produce una interrupción, una región secundaria se convierte en la región principal. Estos son los distintos modelos de preparación para la recuperación tras fallos:

• Espera activa. La aplicación se implementa en dos o más regiones (primaria y secundaria) y funciona correctamente en todas las regiones. Si la región principal falla, la aplicación de la región secundaria puede asumir el tráfico de los clientes de la aplicación inmediatamente.
• Standby en frío. La aplicación se está ejecutando en la región principal, pero está lista para iniciarse en una región secundaria (aunque no se esté ejecutando). Si la región principal falla, la aplicación se inicia en la región secundaria. Se produce una interrupción de la aplicación hasta que esta puede ejecutarse y proporcionar todos los servicios de la aplicación a los clientes de la aplicación.
• Sin espera. En este modelo, el código de la aplicación está listo para el despliegue, pero aún no se ha desplegado en la región secundaria (por lo que no usa ningún recurso desplegado). Si una región principal sufre una interrupción, la primera implementación de la aplicación debe realizarse en la región secundaria. Esta implementación pone la aplicación en el mismo estado que una espera fría, lo que significa que debe iniciarse. Con este enfoque, la interrupción de la aplicación es más larga que en el caso de la espera pasiva, ya que primero se debe llevar a cabo la implementación de la aplicación, lo que incluye la creación de recursos en la nube.

Desde el punto de vista de las bases de datos, los modelos de disponibilidad que se han descrito en la lista anterior corresponden a los siguientes enfoques de bases de datos:

• Base de datos sincronizada transaccionalmente. Esta base de datos corresponde al modelo de espera activa. Cada transacción de la región principal se confirma en coordinación síncrona en una región secundaria. Cuando la región secundaria se convierte en la principal durante una interrupción, la base de datos es coherente y está disponible inmediatamente. En este modelo, el objetivo de punto de recuperación (RPO) y el objetivo de tiempo de recuperación (RTO) son cero.
• Base de datos replicada de forma asíncrona. Esta base de datos también se corresponde con el modelo de espera activa. Como la replicación de la base de datos de la región primaria a la secundaria es asíncrona, es posible que, si la región primaria falla, algunas transacciones se repliquen en la región secundaria. Aunque la base de datos de la región secundaria esté lista para la carga de producción, es posible que no tenga los datos más recientes. Por este motivo, la aplicación podría perder transacciones que no se pueden recuperar. Debido a este riesgo, este enfoque tiene un tiempo de inactividad cero, pero el RPO es superior a cero.
• Base de datos inactiva. Esta base de datos corresponde al modelo de espera pasiva. La base de datos se crea sin ningún dato. Si la región principal falla, los datos se deben cargar en la base de datos inactiva. Para habilitar esta acción, se debe crear una copia de seguridad normal en la región principal y transferirla a la región secundaria. La copia de seguridad puede ser completa o incremental, según lo que admita el motor de base de datos. En ambos casos, la base de datos se restaura a la última copia de seguridad y, desde el punto de vista de la aplicación, se pueden perder muchas transacciones en comparación con la región principal. Aunque este enfoque puede ser rentable, el valor se reduce por el riesgo de que se pierdan todas las transacciones desde la última copia de seguridad disponible debido a que el estado de la base de datos no está actualizado.
• No hay base de datos. Este modelo equivale al caso sin espera. La región secundaria no tiene ninguna base de datos instalada y, si la región principal falla, se debe crear una base de datos. Una vez creada la base de datos, como en el caso de la base de datos inactiva, se deben cargar los datos antes de que la aplicación pueda usarla.

Los enfoques de recuperación tras desastres que se describen en este documento también se aplican si se usan una nube principal y una secundaria en lugar de una región principal y una secundaria. La principal diferencia es que, debido a la heterogeneidad de la red entre las nubes, la latencia entre las nubes puede aumentar en comparación con la distancia de la red entre las regiones de una nube. Otras discrepancias pueden deberse a las diferentes funciones y ajustes predeterminados de las bases de datos gestionadas de distintos proveedores de servicios en la nube.

La probabilidad de que falle toda una nube es menor que la de que falle una región. Sin embargo, puede que a las empresas les siga resultando útil tener una aplicación implementada en dos nubes. Este enfoque podría ayudar a proteger a una empresa frente a los fallos o a cumplir las normativas empresariales o del sector.

Otro enfoque de recuperación tras desastres es tener una región principal y una secundaria, así como una nube principal y una secundaria. Este enfoque permite a las empresas elegir el mejor proceso de recuperación tras un desastre para hacer frente a una situación de fallo. Para que una aplicación pueda ejecutarse, se puede usar una región secundaria o una nube secundaria, en función de la gravedad de la interrupción.

Cloud bursting

El cloud bursting es una configuración que permite aumentar el tráfico de clientes de aplicaciones en diferentes ubicaciones de implementación. Una aplicación entra en ráfaga cuando aumenta la demanda de capacidad y una ubicación de reserva proporciona capacidad adicional. Una ubicación principal admite el tráfico habitual, mientras que una ubicación de reserva puede proporcionar capacidad adicional en caso de que el tráfico de clientes de la aplicación aumente más allá de lo que puede admitir la ubicación principal. Tanto la ubicación principal como la de espera tienen instancias de servicio de aplicación desplegadas.

El cloud bursting se implementa en varias nubes, donde una es la nube principal y otra es la de reserva. Se usa en un contexto de nube híbrida para aumentar un número limitado de recursos de computación en centros de datos locales con recursos de computación en la nube elásticos en una nube pública.

Para obtener asistencia con la base de datos, tienes las siguientes opciones:

• Despliegue de la ubicación principal. En esta implementación, la base de datos solo se implementa en la ubicación principal y no en la de espera. Cuando una aplicación tiene un pico de actividad, la aplicación de la ubicación de reserva accede a la base de datos de la ubicación principal.
• Implementación de ubicaciones principales y de reserva. Esta implementación admite tanto la ubicación principal como la de reserva. Una instancia de base de datos se despliega en ambas ubicaciones y las instancias del servicio de aplicación de esa ubicación acceden a ella, sobre todo en el caso de los picos de actividad. Al igual que en la sección Recuperación tras desastres en la nube y entre nubes, las dos bases de datos se pueden sincronizar de forma transaccional o asíncrona. En la sincronización asíncrona, puede haber un retraso. Si se están realizando actualizaciones en la ubicación de espera, estas actualizaciones deben propagarse de nuevo a la ubicación principal. Si se pueden realizar actualizaciones simultáneas en ambas ubicaciones, se debe implementar la resolución de conflictos.

El cloud bursting es un caso práctico habitual en las nubes híbridas para aumentar la capacidad de los centros de datos on‐premise. También es un enfoque que se puede usar en nubes públicas cuando los datos deben permanecer en un país. En situaciones en las que una nube pública solo tiene una región en un país, es posible pasar a una región de otra nube pública en el mismo país. De esta forma, los datos permanecen en el país y, al mismo tiempo, se abordan las limitaciones de recursos en la región de las regiones de la nube pública.

Uso de servicios en la nube de primer nivel

Algunas aplicaciones requieren servicios y productos de nube especializados que no están disponibles en una sola nube. Por ejemplo, una aplicación puede realizar el procesamiento de la lógica empresarial de los datos empresariales en una nube y las analíticas de los datos empresariales en otra nube. En este caso práctico, las partes de procesamiento de la lógica empresarial y las partes analíticas de la aplicación se implementan en nubes diferentes.

Desde el punto de vista de la gestión de datos, los casos prácticos son los siguientes:

• Datos con particiones. Cada parte de la aplicación tiene su propia base de datos (partición independiente) y ninguna de las bases de datos está conectada directamente entre sí. La aplicación que gestiona los datos escribe dos veces los datos que deben estar disponibles en ambas bases de datos (particiones).
• Base de datos replicada de forma asíncrona. Si los datos de una nube deben estar disponibles en otra, puede ser adecuada una relación de replicación asíncrona. Por ejemplo, si una aplicación de analíticas requiere el mismo conjunto de datos o un subconjunto de datos para una aplicación empresarial, esta última se puede replicar entre las nubes.
• Base de datos sincronizada transaccionalmente. Este tipo de bases de datos te permite poner datos a disposición de ambas partes de la aplicación. Cada actualización de cada una de las aplicaciones es coherente desde el punto de vista transaccional y está disponible para ambas bases de datos (particiones) de inmediato. Las bases de datos sincronizadas transaccionalmente actúan como una única base de datos distribuida.

Servicios distribuidos

Un servicio distribuido se despliega y se ejecuta en dos o más ubicaciones de despliegue. Es posible implementar todas las instancias de servicio en todas las ubicaciones de implementación. También puedes implementar algunos servicios en todas las ubicaciones y otros solo en una de ellas, en función de factores como la disponibilidad del hardware o la carga limitada prevista.

Los datos de una base de datos sincronizada transaccionalmente son coherentes en todas las ubicaciones. Por lo tanto, esta base de datos es la mejor opción para implementar instancias de servicio en todas las ubicaciones de implementación.

Si usas una base de datos replicada de forma asíncrona, existe el riesgo de que se modifique el mismo elemento de datos en dos ubicaciones de implementación simultáneamente. Para determinar cuál de los dos cambios conflictivos es el estado final coherente, se debe implementar una estrategia de resolución de conflictos. Aunque es posible implementar una estrategia de resolución de conflictos, no siempre es sencillo y hay casos en los que es necesario intervenir manualmente para restaurar los datos a un estado coherente.

Reubicación y conmutación por error de servicios distribuidos

Si falla toda una región de la nube, se inicia la recuperación tras fallos. Si falla un solo servicio de una aplicación de base de datos con estado (no la región ni toda la aplicación), el servicio debe recuperarse y reiniciarse.

Una estrategia inicial para la recuperación tras fallos es reiniciar el servicio fallido en su ubicación de implementación original (una estrategia de reinicio in situ). Tecnologías como Kubernetes reinician automáticamente un servicio en función de su configuración.

Sin embargo, si este enfoque de reinicio in situ no funciona, puedes reiniciar el servicio en una ubicación secundaria. El servicio pasa de su ubicación principal a una secundaria. Si la aplicación se despliega como un conjunto de servicios distribuidos, la conmutación por error de un solo servicio puede producirse de forma dinámica.

Desde el punto de vista de la base de datos, reiniciar el servicio en su ubicación de implementación original no requiere una implementación de base de datos específica. Cuando un servicio se traslada a una ubicación de implementación alternativa y accede a la base de datos, se aplican los mismos modelos de disponibilidad que se han descrito en la sección Servicios distribuidos de este documento.

Si un servicio se traslada temporalmente y una empresa puede tolerar latencias más altas durante el traslado, el servicio podría acceder a la base de datos en diferentes ubicaciones de implementación. Aunque el servicio se haya trasladado, sigue accediendo a la base de datos de la misma forma que lo haría desde su ubicación de implementación original.

Despliegue dependiente del contexto

Por lo general, una sola implementación de la aplicación para dar servicio a todos los clientes de la aplicación incluye todos sus servicios y bases de datos. Sin embargo, hay casos excepcionales. Una sola implementación de aplicación solo puede atender a un subconjunto de clientes (en función de criterios específicos), lo que significa que se necesita más de una implementación de aplicación. Cada implementación sirve a un subconjunto diferente de clientes y, en conjunto, todas las implementaciones sirven a todos los clientes.

Estos son algunos ejemplos de casos prácticos de una implementación dependiente del contexto:

• Cuando se implementa una aplicación multiinquilino para la que se implementa una aplicación para todos los inquilinos pequeños, otra aplicación para cada 10 inquilinos medianos y una aplicación para cada inquilino premium.
• Cuando sea necesario separar a los clientes, por ejemplo, a los clientes empresariales y a los clientes de la Administración pública.
• Cuando sea necesario separar los entornos de desarrollo, staging y producción.

Desde el punto de vista de la base de datos, es posible desplegar una base de datos por cada despliegue de aplicación en una estrategia de despliegue individual. Como se muestra en el diagrama siguiente, esta estrategia es un enfoque sencillo en el que se crean datos particionados porque cada implementación tiene su propio conjunto de datos.

En el diagrama anterior se muestra lo siguiente:

• Una configuración con tres implementaciones de una aplicación.
• Cada conjunto de datos tiene su propia base de datos.
• No se comparten datos entre las implementaciones.

En muchas situaciones, una implementación individual es la estrategia más adecuada, pero hay alternativas.

En el caso de la arquitectura multiempresa, es posible que se reubiquen los inquilinos. Un pequeño arrendatario puede convertirse en un arrendatario mediano y tener que trasladarse a otra aplicación. En este caso, las implementaciones de bases de datos independientes requieren una migración de bases de datos. Si se implementa una base de datos distribuida y la usan todas las implementaciones al mismo tiempo, todos los datos de los inquilinos residen en un único sistema de base de datos. Por este motivo, para mover un arrendatario entre bases de datos no es necesario migrar la base de datos. En el siguiente diagrama se muestra un ejemplo de este tipo de base de datos:

En el diagrama anterior se muestra lo siguiente:

• Tres implementaciones de una aplicación.
• Todos los despliegues comparten una única base de datos distribuida.
• Las aplicaciones pueden acceder a todos los datos de cada implementación.
• No se ha implementado ninguna partición de datos.

Si una empresa suele cambiar la ubicación de los inquilinos como parte de las operaciones del ciclo de vida, la replicación de bases de datos puede ser una alternativa útil. Con este método, los datos del inquilino se replican entre bases de datos antes de la migración del inquilino. En este caso, se usan bases de datos independientes para diferentes implementaciones de aplicaciones y solo se configuran para la replicación inmediatamente antes y durante la migración del arrendatario. El siguiente diagrama muestra una replicación temporal entre dos implementaciones de aplicaciones durante una migración de inquilino.

En el diagrama anterior se muestran tres implementaciones de una aplicación con tres bases de datos independientes que contienen los datos asociados a cada implementación. Para migrar datos de una base de datos a otra, se puede configurar una migración temporal de la base de datos.

Portabilidad de aplicaciones

La portabilidad de las aplicaciones asegura que una aplicación se pueda implementar en diferentes ubicaciones, especialmente en diferentes nubes. Esta portabilidad asegura que una aplicación se pueda migrar en cualquier momento, sin necesidad de rediseño específico para la migración ni de desarrollo de aplicaciones adicionales para preparar la migración.

Para asegurar la portabilidad de las aplicaciones, puedes usar uno de los siguientes enfoques, que se describen más adelante en esta sección:

• Portabilidad basada en el sistema
• Compatibilidad con APIs
• Portabilidad basada en la funcionalidad

La portabilidad basada en el sistema usa los mismos componentes técnicos que se utilizan en todas las implementaciones posibles. Para asegurar la portabilidad basada en el sistema, cada tecnología debe estar disponible en todas las ubicaciones de implementación posibles. Por ejemplo, si una base de datos como PostgreSQL es candidata, se debe verificar su disponibilidad en todas las ubicaciones de implementación posibles durante el periodo previsto. Lo mismo ocurre con todas las demás tecnologías, como los lenguajes de programación y las tecnologías de infraestructura. Como se muestra en el siguiente diagrama, este enfoque establece un conjunto de funcionalidades comunes en todas las ubicaciones de implementación basadas en la tecnología.

El diagrama anterior muestra una implementación de una aplicación portátil en la que la aplicación espera el mismo sistema de base de datos en todas las ubicaciones en las que se implementa. Como se usa el mismo sistema de base de datos en cada ubicación, la aplicación es portátil. La aplicación puede esperar que se utilice el mismo sistema de base de datos en toda la implementación. Por lo tanto, se puede asumir que la interfaz y el comportamiento del sistema de base de datos son exactamente los mismos.

En el contexto de las bases de datos, en el sistema de compatibilidad con APIs, el cliente usa una biblioteca de acceso a bases de datos específica (por ejemplo, una biblioteca de cliente de MySQL) para asegurarse de que puede conectarse a cualquier implementación compatible que pueda estar disponible en un entorno de nube. En el siguiente diagrama se muestra la compatibilidad de la API.

En el diagrama anterior se muestra la portabilidad de las aplicaciones basada en la API del sistema de base de datos en lugar de en el sistema de base de datos. Aunque los sistemas de bases de datos pueden ser diferentes en cada una de las ubicaciones, la API es la misma y expone la misma funcionalidad. La aplicación es portátil porque puede asumir la misma API en cada ubicación, aunque el sistema de base de datos subyacente sea una tecnología de base de datos diferente.

En la portabilidad basada en la funcionalidad, se pueden usar diferentes tecnologías en diferentes nubes que proporcionen la misma funcionalidad. Por ejemplo, se podría restringir el uso de bases de datos al modelo relacional. Como cualquier sistema de base de datos relacional puede admitir la aplicación, se pueden usar diferentes sistemas de base de datos en diferentes versiones en distintas nubes sin que esto afecte a la portabilidad de la aplicación. Un inconveniente de la portabilidad basada en la funcionalidad es que solo puede usar las partes del modelo de base de datos que admiten todos los sistemas de bases de datos relacionales. En lugar de un sistema de base de datos compatible con todas las nubes, se debe usar un modelo de base de datos. En el siguiente diagrama se muestra un ejemplo de arquitectura para la portabilidad basada en funciones.

Como se muestra en el diagrama anterior, la API del sistema de base de datos y el sistema de base de datos pueden ser diferentes en cada ubicación. Para garantizar la portabilidad, la aplicación solo debe usar las partes de cada sistema de base de datos y de cada API que estén disponibles en cada ubicación. Como solo suele haber disponible un subconjunto de cada sistema de base de datos en cada ubicación, la aplicación debe restringir su uso a ese subconjunto.

Para asegurar la portabilidad de todas las opciones de esta sección, la arquitectura completa debe implementarse continuamente en todas las ubicaciones de destino. Todos los casos de prueba de unidades y sistemas deben ejecutarse en estas implementaciones. Estos son requisitos esenciales para detectar y abordar los cambios en las infraestructuras y las tecnologías en una fase temprana.

Prevención de la dependencia de proveedores

La prevención de la dependencia de proveedores ayuda a mitigar el riesgo de depender de una tecnología y un proveedor específicos. Es superficialmente similar a la portabilidad de aplicaciones. La prevención de la dependencia de proveedores se aplica a todas las tecnologías que se utilizan, no solo a los servicios en la nube. Por ejemplo, si MySQL se usa como sistema de base de datos y se instala en máquinas virtuales en nubes, no hay ninguna dependencia desde el punto de vista de la nube, pero sí hay una dependencia de MySQL. Una aplicación que se pueda trasladar entre nubes puede seguir dependiendo de tecnologías proporcionadas por proveedores distintos a la nube.

Para evitar la dependencia de los proveedores, todas las tecnologías deben poder sustituirse. Por este motivo, es necesario que se haga una abstracción exhaustiva y estructurada de todas las funciones de la aplicación para que cada servicio de la aplicación se pueda volver a implementar en una base tecnológica diferente sin que afecte a la forma en que se implementa la aplicación. Desde el punto de vista de la base de datos, esta abstracción se puede llevar a cabo separando el uso de un modelo de base de datos de un sistema de gestión de bases de datos concreto.

Sistema de gestión de bases de datos de producción

Aunque muchas aplicaciones multinube se desarrollan con sistemas de bases de datos como parte de su diseño, muchas empresas desarrollan aplicaciones multinube como parte de su esfuerzo de modernización de aplicaciones. Estas aplicaciones se desarrollan con la suposición de que la aplicación recién diseñada e implementada accede a las bases de datos existentes.

Hay muchos motivos por los que no se incorporan las bases de datos a una modernización. Puede que haya funciones específicas en uso que no estén disponibles en otros sistemas de bases de datos. Una empresa puede tener bases de datos con procesos de gestión complejos y bien establecidos, lo que hace que el cambio a otro sistema sea poco práctico o poco económico. O bien, una empresa puede optar por modernizar una aplicación en la primera fase y la base de datos en la segunda.

Cuando una empresa usa un sistema de base de datos, el diseñador de la aplicación multicloud tiene que decidir si será la única base de datos que se utilice o si se debe añadir otro sistema de base de datos para diferentes ubicaciones de implementación. Por ejemplo, si una base de datos se usa de forma local y la aplicación también debe ejecutarse en Google Cloud, se debe tener en cuenta si los servicios de la aplicación implementados en Google Cloud acceden a la base de datos de forma local. O bien, si se debe implementar una segunda base de datos tanto enGoogle Cloud como en los servicios de aplicaciones que se ejecutan localmente.

Si se implementa una segunda base de datos en Google Cloud, el caso práctico podría ser el mismo que los que se describen en Cloud bursting o Servicios distribuidos. En ambos casos, se aplica la misma discusión sobre la base de datos que en estas secciones. Sin embargo, se limita a la funcionalidad entre ubicaciones que puede admitir la base de datos local, como la sincronización y la replicación.

Patrones de despliegue

Los casos prácticos que se describen en este documento plantean una pregunta habitual desde la perspectiva de las bases de datos: si las bases de datos se encuentran en más de una ubicación de implementación, ¿cuál es su relación?

Los principales tipos de relaciones (patrones de implementación), que se describen en la siguiente sección, son los siguientes:

• Particionada sin dependencia entre bases de datos
• Replicación unidireccional asíncrona
• Replicación bidireccional con resolución de conflictos
• Sistema distribuido totalmente sincronizado activo-activo

Es posible asignar cada caso práctico de este documento a uno o varios de los cuatro patrones de implementación.

En la siguiente conversación, se da por hecho que los clientes acceden directamente a los servicios de la aplicación. En función del caso práctico, es posible que se necesite un balanceador de carga para dirigir dinámicamente el acceso de los clientes a las aplicaciones, como se muestra en el siguiente diagrama.

En el diagrama anterior, un balanceador de carga en la nube dirige las llamadas de los clientes a una de las ubicaciones disponibles. El balanceador de carga se asegura de que se apliquen las políticas de balanceo de carga y de que los clientes se dirijan a la ubicación correcta de la aplicación y su base de datos.

Particionada sin dependencia entre bases de datos

Este patrón de implementación es el más sencillo de todos los que se describen en este documento: cada ubicación o nube tiene una base de datos y las bases de datos contienen conjuntos de datos particionados que no dependen entre sí. Un elemento de datos se almacena en una sola base de datos. Cada partición de datos se encuentra en su propia base de datos. Un ejemplo de este patrón es una aplicación multiinquilino en la que un conjunto de datos se encuentra en una u otra base de datos. En el siguiente diagrama se muestran dos aplicaciones totalmente particionadas.

Como se muestra en el diagrama anterior, una aplicación se implementa en dos ubicaciones, cada una de las cuales es responsable de una partición del conjunto de datos completo. Cada elemento de datos reside en una sola de las ubicaciones, lo que asegura que el conjunto de datos esté particionado y no haya replicación entre las dos.

Un patrón de implementación alternativo para las bases de datos particionadas es aquel en el que el conjunto de datos está completamente particionado, pero sigue almacenado en la misma base de datos. Solo hay una base de datos que contiene todos los conjuntos de datos. Aunque los conjuntos de datos se almacenan en la misma base de datos, están completamente separados (particionados) y los cambios que se hagan en uno no afectarán a los demás. En el siguiente diagrama se muestran dos aplicaciones que comparten una misma base de datos.

En el diagrama anterior se muestra lo siguiente:

• Dos implementaciones de aplicaciones que comparten una base de datos común, que se encuentra en la primera ubicación.
• Cada aplicación puede acceder a todos los datos de la implementación porque el conjunto de datos no está particionado.

Replicación unidireccional asíncrona

Este patrón de implementación tiene una base de datos principal que se replica en una o varias bases de datos secundarias. La base de datos secundaria se puede usar para el acceso de lectura, pero la aplicación debe tener en cuenta el posible retraso de la replicación. Un ejemplo de este patrón es cuando se usa la mejor base de datos para un caso práctico concreto como base de datos principal y la base de datos secundaria se usa para analíticas. En el siguiente diagrama se muestran dos aplicaciones que acceden a bases de datos replicadas unidireccionalmente.

Como se muestra en el diagrama anterior, una de las dos bases de datos es una réplica de la otra. La flecha del diagrama indica la dirección de la replicación: los datos del sistema de base de datos de la ubicación 1 se replican en el sistema de base de datos de la ubicación 2.

Replicación bidireccional con resolución de conflictos

Este patrón de implementación tiene dos bases de datos principales que se replican entre sí de forma asíncrona. Si se escriben los mismos datos al mismo tiempo en cada base de datos (por ejemplo, la misma clave principal), se puede producir un conflicto de escritura. Debido a este riesgo, debe haber una resolución de conflictos para determinar cuál es el último estado durante la replicación. Este patrón se puede usar en situaciones en las que la probabilidad de que se produzca un conflicto de escritura es baja. En el siguiente diagrama se muestran dos aplicaciones que acceden a bases de datos replicadas bidireccionalmente.

Como se muestra en el diagrama anterior, cada base de datos se replica en la otra. Las dos replicaciones son independientes entre sí, tal como se indica en el diagrama con dos flechas azules separadas. Como las dos replicaciones son independientes, puede surgir un conflicto si, por casualidad, cada una de las aplicaciones cambia el mismo elemento de datos y se replica simultáneamente. En este caso, debe resolverse el conflicto.

Sistema distribuido totalmente sincronizado activo-activo

Este patrón de implementación tiene una sola base de datos con una configuración activa-activa (también principal-principal). En una configuración activo-activo, una actualización de los datos de cualquier base de datos principal es coherente desde el punto de vista de las transacciones y se replica de forma síncrona. Un ejemplo de caso práctico de este patrón es la computación distribuida. En el siguiente diagrama se muestran dos aplicaciones que acceden a una base de datos principal-principal totalmente sincronizada.

Como se muestra en el diagrama anterior, esta configuración asegura que cada aplicación siempre acceda al último estado coherente, sin retrasos ni riesgos de conflicto. Un cambio en una base de datos está disponible inmediatamente en la otra. Cualquier cambio se refleja en ambas bases de datos cuando se confirma una transacción de cambio.

Categorización de sistemas de bases de datos

No todos los sistemas de gestión de bases de datos se pueden usar con la misma eficacia para los patrones de implementación que se describen en este documento. En función del caso de uso, puede que solo se pueda implementar un patrón de implementación o una combinación de patrones de implementación con un subconjunto de sistemas de bases de datos.

En la siguiente sección, se clasifican los diferentes sistemas de bases de datos y se asignan a los cuatro patrones de implementación.

Las bases de datos se pueden clasificar según diferentes dimensiones, como el modelo de datos, la arquitectura interna, el modelo de implementación y los tipos de transacciones. En la siguiente sección, se usan dos dimensiones para gestionar bases de datos multicloud:

• Arquitectura de implementación. La arquitectura de cómo se implementa un sistema de gestión de bases de datos en los recursos de las nubes (por ejemplo, los motores de computación o la gestión en la nube).
• Modelo de distribución. El modelo de distribución que admite un sistema de base de datos (por ejemplo, una sola instancia o totalmente distribuido).

Estas dos dimensiones son las más relevantes en el contexto de los casos prácticos multinube y pueden admitir los cuatro patrones de implementación derivados de los casos prácticos de bases de datos multinube. Una categorización habitual se basa en los modelos de datos que admite un sistema de gestión de bases de datos. Algunos sistemas solo admiten un modelo (por ejemplo, un modelo de gráfico). Otros sistemas admiten varios modelos de datos al mismo tiempo (por ejemplo, modelos relacionales y de documentos). Sin embargo, en el contexto de la gestión de bases de datos multinube, esta categorización no es relevante porque las aplicaciones multinube pueden usar cualquier modelo de datos para su implementación multinube.

Sistema de base de datos por arquitectura de implementación

La gestión de bases de datos multicloud incluye las cuatro clases principales de arquitectura de implementación de sistemas de gestión de bases de datos:

• Bases de datos en la nube integradas. Las bases de datos en la nube integradas se han diseñado, creado y optimizado para funcionar con la tecnología de la nube. Por ejemplo, algunos sistemas de bases de datos usan Kubernetes como plataforma de implementación y utilizan la funcionalidad de Kubernetes. CockroachDB y YugaByte son ejemplos de este tipo de base de datos. Se pueden desplegar en cualquier nube que admita Kubernetes.
• Bases de datos gestionadas por proveedores de servicios en la nube. Las bases de datos gestionadas por proveedores de servicios en la nube se basan en tecnología específica de cada proveedor y son un servicio de base de datos gestionado por un proveedor de servicios en la nube concreto. Spanner, Bigtable, Firestore y AlloyDB para PostgreSQL son ejemplos de este tipo de base de datos. Las bases de datos gestionadas por proveedores de servicios en la nube solo están disponibles en la nube del proveedor y no se pueden instalar ni ejecutar en otro lugar. Sin embargo, AlloyDB para PostgreSQL es totalmente compatible con PostgreSQL.
• Bases de datos previas a la nube. Las bases de datos previas a la nube existían antes del desarrollo de la tecnología de la nube (a veces, durante mucho tiempo) y suelen ejecutarse en hardware de metal desnudo y máquinas virtuales. PostgreSQL, MySQL y SQL Server son ejemplos de este tipo de bases de datos. Estos sistemas se pueden ejecutar en cualquier nube que admita las máquinas virtuales o el hardware dedicado necesarios.
• Bases de datos gestionadas por partners de Cloud. Algunas nubes públicas tienen partners de bases de datos que instalan y gestionan las bases de datos de los clientes en la nube pública. Por este motivo, los clientes no tienen que gestionar estas bases de datos por sí mismos. MongoDB Atlas, MariaDB y ScyllaDB son ejemplos de este tipo de bases de datos.

Hay algunas variantes de estas categorías principales. Por ejemplo, un proveedor de bases de datos que implemente una base de datos diseñada para la nube también puede ofrecer una instalación en una tecnología creada para la nube y una oferta gestionada a los clientes en la nube que proporciona el proveedor. Este enfoque equivale a que el proveedor proporcione una nube pública que solo admita su base de datos como único servicio.

Las bases de datos anteriores a la nube también pueden estar en contenedores y desplegarse en un clúster de Kubernetes. Sin embargo, estas bases de datos no usan funciones específicas de Kubernetes, como el escalado, el servicio múltiple o la implementación de varios pods.

Los proveedores de bases de datos pueden colaborar con más de un proveedor de nube pública al mismo tiempo y ofrecer su base de datos como una base de datos gestionada por un partner en la nube en más de una nube pública.

Sistema de base de datos por modelo de distribución

Los diferentes sistemas de gestión de bases de datos se implementan según los modelos de distribución de la arquitectura de una base de datos. Los modelos de bases de datos son los siguientes:

• Una sola instancia. Una sola instancia de base de datos se ejecuta en una máquina virtual o en un contenedor y actúa como un sistema centralizado. Este sistema gestiona todo el acceso a la base de datos. Como la instancia única no se puede conectar a ninguna otra instancia, el sistema de base de datos no admite la replicación.
• Activo-pasivo de varias instancias. En esta arquitectura habitual, se vinculan varias instancias de base de datos. La vinculación más habitual es una relación activo-pasivo en la que una instancia es la instancia de base de datos activa que admite ambas instancias y escribe y lee datos. Uno o varios sistemas pasivos son de solo lectura y reciben todos los cambios de la base de datos del sistema principal de forma síncrona o asíncrona. Los sistemas pasivos pueden proporcionar acceso de lectura. La configuración activo-pasiva también se conoce como primaria-secundaria o origen-réplica.
• Activo-activo de varias instancias. En esta arquitectura relativamente poco común, cada instancia es una instancia activa. En este caso, cada instancia puede ejecutar transacciones de lectura y escritura, y proporcionar coherencia de datos. Por este motivo, para evitar incoherencias en los datos, todas las instancias se sincronizan siempre.
• Activo-activo de varias instancias con resolución de conflictos. También es un sistema relativamente poco común. Cada instancia está disponible para acceso de lectura y escritura, pero las bases de datos se sincronizan en modo asíncrono. Se permiten las actualizaciones simultáneas del mismo elemento de datos, lo que provoca un estado incoherente. Una política de resolución de conflictos debe decidir cuál de los estados es el último estado coherente.
• Partición de instancias múltiples. La fragmentación se basa en la gestión de particiones de datos (disjuntas). Una instancia de base de datos independiente gestiona cada partición. Esta distribución es escalable porque se pueden añadir más fragmentos de forma dinámica con el tiempo. Sin embargo, es posible que no se puedan realizar consultas entre fragmentos, ya que no todos los sistemas admiten esta función.

Todos los modelos de distribución que se describen en esta sección admiten el particionado y pueden ser sistemas particionados. Sin embargo, no todos los sistemas están diseñados para ofrecer una opción de partición. El particionamiento es un concepto de escalabilidad y, por lo general, no es relevante para la selección de bases de datos de arquitectura en entornos multicloud.

Los modelos de distribución son diferentes para las bases de datos gestionadas en la nube y por partners. Como estas bases de datos están vinculadas a la arquitectura de un proveedor de servicios en la nube, estos sistemas implementan arquitecturas basadas en las siguientes ubicaciones de implementación:

• Sistema zonal. Un sistema de base de datos gestionado por zonas está vinculado a una zona. Cuando la zona está disponible, el sistema de base de datos también lo está. Sin embargo, si la zona deja de estar disponible, no se podrá acceder a la base de datos.
• Sistema regional. Una base de datos gestionada regional está vinculada a una región y se puede acceder a ella cuando al menos una zona está accesible. Cualquier combinación de zonas puede dejar de estar accesible.
• Sistema multirregional. Un sistema multirregional está vinculado a dos o más regiones y funciona correctamente cuando al menos una de ellas está disponible.

Un sistema multirregional también puede admitir un sistema multicloud si la base de datos se puede instalar en todas las nubes que una empresa quiera usar.

Hay otras alternativas posibles a las arquitecturas de bases de datos gestionadas que se describen en esta sección. Un sistema regional puede compartir un disco entre dos zonas. Si no se puede acceder a una de las dos zonas, el sistema de base de datos puede seguir funcionando en la zona restante. Sin embargo, si una interrupción afecta a ambas zonas, el sistema de bases de datos no estará disponible aunque otras zonas sigan estando totalmente online.

Asignación de sistemas de bases de datos a patrones de implementación

En la siguiente tabla se describe cómo se relacionan entre sí los patrones y las arquitecturas de implementación que se explican en este documento. Los campos indican las condiciones necesarias para que una combinación sea posible, en función del patrón y la arquitectura de la implementación.

Arquitectura de despliegue	Patrón de implementación
	Particionada sin dependencia entre bases de datos	Replicación unidireccional asíncrona	Replicación bidireccional con resolución de conflictos	Sistema distribuido totalmente sincronizado activo-activo
Bases de datos en la nube integradas	Posible para todas las nubes que proporcionan tecnología en la nube integrada utilizada por los sistemas de bases de datos. Si la misma base de datos no está disponible, se pueden usar diferentes sistemas de bases de datos.	Base de datos en la nube que proporciona replicación.	Base de datos en la nube que proporciona replicación bidireccional.	Base de datos en la nube que proporciona sincronización primaria-primaria.
Bases de datos gestionadas por proveedores de servicios en la nube	Los sistemas de bases de datos pueden ser diferentes en distintas nubes.	La réplica no tiene por qué ser la base de datos gestionada por el proveedor de la nube (consulta El papel de la tecnología de migración de bases de datos en los patrones de implementación).	Solo en una nube, no en varias, si la base de datos proporciona replicación bidireccional.	Solo en una nube, no en varias, si la base de datos proporciona sincronización primaria-primaria.
Bases de datos previas a la nube	Los sistemas de bases de datos pueden ser iguales o diferentes en distintas nubes.	La replicación es posible en varias nubes.	El sistema de base de datos proporciona replicación bidireccional y resolución de conflictos.	El sistema de base de datos proporciona sincronización principal-principal.
Bases de datos gestionadas por partners de Cloud	Los sistemas de bases de datos pueden ser diferentes en distintas nubes. Si el partner proporciona un sistema de base de datos gestionado en todas las nubes necesarias, se puede usar la misma base de datos.	No es necesario que la réplica sea la base de datos gestionada por el proveedor de la nube. Si el partner proporciona un sistema de base de datos gestionado en todas las nubes necesarias, se puede usar la misma base de datos.	El sistema de base de datos proporciona replicación bidireccional y resolución de conflictos.	El sistema de base de datos proporciona sincronización principal-principal.

Si un sistema de base de datos no proporciona replicación integrada, es posible que se pueda usar la tecnología de replicación de bases de datos. Para obtener más información, consulta El papel de la tecnología de migración de bases de datos en los patrones de implementación.

En la siguiente tabla se relacionan los patrones de implementación con los modelos de distribución. Los campos indican las condiciones en las que es posible la combinación, dado un patrón de implementación y un modelo de distribución.

Modelo de distribución	Patrón de implementación
	Particionada sin dependencia entre bases de datos	Replicación unidireccional asíncrona	Replicación bidireccional con resolución de conflictos	Sistema distribuido totalmente sincronizado activo-activo
instancia única	Es posible hacerlo con el mismo sistema de base de datos o con uno diferente en las nubes implicadas.	No aplicable	No aplicable	No aplicable
Activo-pasivo multiinstancia	Es posible con el mismo sistema de base de datos o con uno diferente en las nubes implicadas.	La replicación es posible entre nubes.	La replicación es posible entre nubes.	No aplicable
Activo-activo multiinstancia	Es posible con el mismo sistema de base de datos o con uno diferente en las nubes implicadas.	No aplicable	No aplicable	La sincronización es posible entre nubes.
Activo-activo de varias instancias con resolución de conflictos	Es posible con el mismo sistema de base de datos o con uno diferente en las nubes implicadas.	No aplicable	No aplicable	Se aplica si es posible la replicación bidireccional entre nubes.

Algunas implementaciones de modelos de distribución que añaden abstracción adicional basada en la tecnología de la base de datos subyacente no tienen un modelo de distribución integrado, como Postgres-BDR, un sistema activo-activo. Estos sistemas se incluyen en la tabla anterior, en la categoría correspondiente. Desde una perspectiva multinube, no importa cómo se implemente un modelo de distribución.

Migración y replicación de bases de datos

En función del caso práctico, una empresa puede necesitar migrar una base de datos de una ubicación de implementación a otra. Por otro lado, para el procesamiento posterior, puede que necesite replicar los datos de una base de datos en otra ubicación. En la sección siguiente, se explica con más detalle la migración y la réplica de bases de datos.

Migración de bases de datos

La migración de bases de datos se usa cuando una base de datos se traslada de una ubicación de implementación a otra. Por ejemplo, una base de datos que se ejecuta en un centro de datos local se migra para que se ejecute en la nube. Una vez completada la migración, la base de datos se cierra en el centro de datos local.

Estos son los principales enfoques para migrar bases de datos:

• Migrar mediante lift and shift. La máquina virtual y los discos que ejecutan las instancias de la base de datos se copian en el entorno de destino tal cual. Una vez copiados, se iniciarán y la migración se completará.
• Exportar, importar, crear copias de seguridad y restaurar. Ambos enfoques usan la funcionalidad del sistema de bases de datos para externalizar una base de datos y volver a crearla en la ubicación de destino. La exportación o importación suele basarse en un formato ASCII, mientras que la copia de seguridad y la restauración se basan en un formato binario.
• Migración sin tiempo de inactividad. Con este enfoque, se migra una base de datos mientras los sistemas de aplicaciones acceden al sistema de origen. Después de una carga inicial, los cambios se transmiten de la base de datos de origen a la de destino mediante tecnologías de captura de datos de cambios (CDC). La aplicación sufre un tiempo de inactividad desde el momento en que se detiene en el sistema de base de datos de origen hasta que se reinicia en el sistema de base de datos de destino una vez completada la migración.

La migración de bases de datos es relevante en los casos prácticos multicloud cuando se traslada una base de datos de una nube a otra o de un tipo de motor de base de datos a otro.

La migración de bases de datos es un proceso complejo. Para obtener más información, consulta los artículos Migración de bases de datos: conceptos y principios (parte 1) y Migración de bases de datos: conceptos y principios (parte 2).

Las tecnologías de bases de datos integradas se pueden usar para migrar bases de datos. Por ejemplo, se pueden exportar e importar, crear copias de seguridad y restaurarlas, o usar protocolos de replicación integrados. Si los sistemas de origen y de destino son sistemas de bases de datos diferentes, las tecnologías de migración son la mejor opción para migrar bases de datos. Database Migration Service, Striim y Debezium son ejemplos de tecnologías de migración de bases de datos.

Replicación de bases de datos

La replicación de bases de datos es similar a la migración de bases de datos. Sin embargo, durante la replicación de la base de datos, el sistema de la base de datos de origen permanece en su sitio mientras se transmite cada cambio a la base de datos de destino.

La replicación de bases de datos es un proceso continuo que envía cambios de la base de datos de origen a la de destino. Cuando este proceso es asíncrono, los cambios llegan a la base de datos de destino con un breve retraso. Si el proceso es síncrono, los cambios en el sistema de origen se aplican al sistema de destino al mismo tiempo y a las mismas transacciones.

Además de replicar una base de datos de origen en una de destino, es habitual replicar datos de una base de datos de origen en un sistema de analíticas de destino.

Al igual que con la migración de bases de datos, si hay protocolos de replicación disponibles, se puede usar la tecnología de bases de datos integrada para la replicación de bases de datos. Si no hay protocolos de replicación integrados, puedes usar tecnologías de replicación como Datastream, Striim o Debezium.

El papel de la tecnología de migración de bases de datos en los patrones de implementación

La tecnología de base de datos integrada para habilitar la replicación no suele estar disponible cuando se usan diferentes sistemas de bases de datos en patrones de implementación, como la replicación asíncrona (heterogénea). En su lugar, se puede implementar tecnología de migración de bases de datos para habilitar este tipo de replicación. Algunos de estos sistemas de migración también implementan la replicación bidireccional.

Si la tecnología de migración o replicación de bases de datos está disponible para los sistemas de bases de datos utilizados en las combinaciones marcadas como "No aplicable" en la tabla 1 o en la tabla 2 de Asignación de sistemas de bases de datos a patrones de implementación, es posible que se pueda usar para la replicación de bases de datos. En el siguiente diagrama se muestra un enfoque para la replicación de bases de datos mediante una tecnología de migración.

En el diagrama anterior, la base de datos de la ubicación 1 se replica en la base de datos de la ubicación 2. En lugar de replicar directamente el sistema de bases de datos, se implementa un servidor de migración para llevar a cabo la replicación. Este enfoque se usa en sistemas de bases de datos que no tienen una función de replicación de bases de datos integrada en su implementación y que necesitan depender de un sistema independiente del sistema de bases de datos para implementar la replicación.

Selección de bases de datos multinube

Los casos prácticos de bases de datos multinube, combinados con la categorización del sistema de bases de datos, te ayudan a decidir qué bases de datos son las más adecuadas para un caso práctico concreto. Por ejemplo, para implementar el caso práctico de portabilidad de aplicaciones, hay dos opciones. La primera opción es asegurarse de que el mismo motor de base de datos esté disponible en todas las nubes. Este enfoque asegura la portabilidad del sistema. La segunda opción es asegurarse de que todos los servicios en la nube tengan el mismo modelo de datos y la misma interfaz de consulta. Aunque los sistemas de bases de datos pueden ser diferentes, la portabilidad se proporciona en una interfaz funcional.

Los árboles de decisión de las siguientes secciones muestran los criterios de toma de decisiones para los casos prácticos de bases de datos multicloud de este documento. Los árboles de decisión sugieren la mejor base de datos para cada caso práctico.

Prácticas recomendadas para sistemas de bases de datos

Si un sistema de base de datos está en producción, se debe decidir si se mantiene o se sustituye. En el siguiente diagrama se muestran las preguntas que debes hacerte durante el proceso de toma de decisiones:

Las preguntas y respuestas del árbol de decisiones son las siguientes:

• ¿Hay un sistema de base de datos en producción?
  • Si no hay ningún sistema de base de datos en producción, selecciona un sistema de base de datos (ve a la sección Decisión sobre la gestión de bases de datos multicloud).
  • Si un sistema de base de datos está en producción, evalúa si se debe conservar.
• Si un sistema de base de datos está en producción, evalúa si debe conservarse.
  • Si el sistema de base de datos se debe conservar, se toma la decisión y el proceso se completa.
  • Si se debe cambiar el sistema de base de datos o si aún no se ha tomado una decisión, selecciona un sistema de base de datos (ve a la sección Decisión sobre la gestión de bases de datos multicloud).

Decisión sobre la gestión de bases de datos multinube

El siguiente diagrama de toma de decisiones corresponde a un caso práctico con un requisito de base de datos multilocación (incluida una implementación de base de datos multinube). Usa el patrón de implementación como base para los criterios de toma de decisiones.

Las preguntas y respuestas del árbol de decisiones son las siguientes:

• ¿Los datos están particionados en diferentes bases de datos sin ninguna dependencia entre bases de datos?
  • Si es así, se pueden seleccionar sistemas de bases de datos iguales o diferentes para cada ubicación.
  • Si no es así, continúa con la siguiente pregunta.
• ¿Se requiere la replicación unidireccional asíncrona?
  • Si es así, evalúa si un sistema de replicación de bases de datos es aceptable.
    • Si es así, selecciona los mismos sistemas de bases de datos u otros que sean compatibles con el sistema de replicación.
    • Si no es así, selecciona un sistema de base de datos que pueda implementar un modelo de distribución activo-pasivo.
    • Si no es así, continúa con la siguiente pregunta.
• Selecciona un sistema de base de datos con instancias sincronizadas.
  • ¿Es aceptable la resolución de conflictos?
    • Si es así, selecciona un sistema de base de datos de replicación bidireccional o un sistema de base de datos activo-activo.
    • Si no es así, selecciona un sistema activo-activo.

Si se implementan varios casos prácticos de multinube, una empresa debe decidir si quiere usar un sistema de base de datos para todos los casos prácticos o varios sistemas de base de datos.

Si una empresa quiere usar un sistema de base de datos para todos los casos prácticos, la mejor opción es el sistema con la mejor sincronización. Por ejemplo, si se requiere la replicación unidireccional, así como las instancias sincronizadas, la mejor opción son las instancias sincronizadas.

La jerarquía de calidad de la sincronización es la siguiente (de menor a mayor): particionada, replicación unidireccional, replicación bidireccional y replicación totalmente sincronizada.

Recomendaciones para la implementación

En esta sección se destacan las prácticas recomendadas que se deben seguir al elegir una base de datos para la migración o el desarrollo de aplicaciones multinube.

Sistema de gestión de bases de datos actual

Es recomendable conservar una base de datos y no hacer cambios en el sistema de base de datos a menos que sea necesario para un caso práctico específico. En el caso de una empresa con un sistema de gestión de bases de datos establecido y que tenga procesos de desarrollo, operativos y de mantenimiento eficaces, puede ser mejor no hacer cambios.

En un caso práctico de cloud bursting que no requiera un sistema de base de datos en la nube, puede que no sea necesario cambiar la base de datos. Otro caso práctico es la replicación asíncrona en una ubicación de implementación diferente dentro de la misma nube o en otra nube. En estos casos, una buena opción es implementar una prueba comparativa y verificar que la comunicación entre ubicaciones y la latencia cumplan los requisitos de la aplicación al acceder a la base de datos.

Sistema de base de datos como servicio de Kubernetes

Si una empresa se plantea ejecutar un sistema de base de datos en Kubernetes como un servicio basado en StatefulSets, debe tener en cuenta los siguientes factores:

• Si la base de datos proporciona el modelo de base de datos que necesita la aplicación.
• Factores no funcionales que determinan cómo se implementa la operativización en un sistema de base de datos como servicio de Kubernetes. Por ejemplo, cómo se realiza el escalado (vertical y horizontal), cómo se gestionan las copias de seguridad y la restauración, y cómo el sistema ofrece la monitorización. Para ayudarles a comprender los requisitos de un sistema de base de datos basado en Kubernetes, las empresas deben usar sus experiencias con bases de datos como punto de comparación.
• Alta disponibilidad y recuperación tras desastres. Para ofrecer alta disponibilidad, el sistema debe seguir funcionando cuando falle una zona de una región. La base de datos debe poder conmutar por error rápidamente de una zona a otra. En el mejor de los casos, la base de datos tiene una instancia en ejecución en cada zona que está totalmente sincronizada para que el tiempo de inactividad y la pérdida de datos sean nulos.
• Recuperación tras fallos para hacer frente a los fallos de una región (o una nube). En un escenario ideal, la base de datos sigue funcionando en una segunda región con un RPO y un RTO de cero. En un caso menos ideal, es posible que la base de datos de la región secundaria no haya completado todas las transacciones de la base de datos principal.

Para determinar la mejor forma de ejecutar una base de datos en Kubernetes, es recomendable realizar una evaluación completa de la base de datos, sobre todo cuando el sistema debe ser comparable a un sistema de producción fuera de Kubernetes.

Sistema de base de datos independiente de Kubernetes

No siempre es necesario que una aplicación implementada como servicios en Kubernetes tenga la base de datos ejecutándose en Kubernetes al mismo tiempo. Hay muchos motivos por los que un sistema de base de datos debe ejecutarse fuera de Kubernetes. Por ejemplo, procesos establecidos, conocimientos de productos en una empresa o falta de disponibilidad. En esta categoría se incluyen tanto los proveedores de servicios en la nube como las bases de datos gestionadas por partners de la nube.

Es igual de posible y viable ejecutar una base de datos en Compute Engine. Al seleccionar un sistema de base de datos, es recomendable hacer una evaluación completa de la base de datos para asegurarse de que se cumplen todos los requisitos de una aplicación.

Desde el punto de vista del diseño de aplicaciones, la agrupación de conexiones es un aspecto importante. Un servicio de aplicación que acceda a una base de datos puede usar un pool de conexiones internamente. Usar un grupo de conexiones es una buena opción para mejorar la eficiencia y reducir la latencia. Las solicitudes se toman del grupo sin necesidad de iniciarlas y no hay que esperar a que se creen las conexiones. Si la aplicación se escala añadiendo instancias de servicio de aplicación, cada instancia crea un grupo de conexiones. Si se siguen las prácticas recomendadas, cada grupo precrea un conjunto mínimo de conexiones. Cada vez que se crea otra instancia de servicio de aplicación para escalar la aplicación, se añaden conexiones a la base de datos. Desde el punto de vista del diseño, como las bases de datos no pueden admitir un número ilimitado de conexiones, la adición de conexiones debe gestionarse para evitar la sobrecarga.

Mejor sistema de base de datos frente a portabilidad del sistema de base de datos

Al seleccionar sistemas de bases de datos, es habitual que las empresas elijan el mejor sistema de bases de datos para satisfacer los requisitos de una aplicación. En un entorno multinube, se puede seleccionar la mejor base de datos de cada nube y conectarlas entre sí en función del caso práctico. Si estos sistemas son diferentes, cualquier replicación (unidireccional o bidireccional) requiere un esfuerzo considerable. Este enfoque puede justificarse si las ventajas de usar el mejor sistema superan el esfuerzo necesario para implementarlo.

Sin embargo, es recomendable considerar y evaluar simultáneamente un enfoque para un sistema de base de datos que esté disponible en todas las nubes necesarias. Aunque esta base de datos no sea la opción ideal, puede ser mucho más fácil implementar, operar y mantener un sistema de este tipo.

Una evaluación simultánea del sistema de bases de datos demuestra las ventajas y desventajas de ambos sistemas, lo que proporciona una base sólida para la selección.

Replicación de bases de datos integrada frente a replicación de bases de datos externas

La replicación es una función importante en los casos prácticos que requieren un sistema de base de datos en todas las ubicaciones de implementación (zonas, regiones o nubes). La replicación puede ser asíncrona, bidireccional o de replicación activa-activa totalmente sincronizada. No todos los sistemas de bases de datos admiten todas estas formas de replicación.

En los sistemas que no admiten la replicación como parte de su implementación, se pueden usar sistemas como Striim para complementar la arquitectura (como se explica en Migración de bases de datos).

Una práctica recomendada es evaluar sistemas de gestión de bases de datos alternativos para determinar las ventajas y desventajas de un sistema que tenga replicación integrada o de un sistema que requiera tecnología de replicación.

En este caso, también influye un tercer tipo de tecnología. Esta clase proporciona complementos a los sistemas de bases de datos para ofrecer replicación. Un ejemplo es MariaDB Galera Cluster. Si el proceso de evaluación lo permite, es recomendable evaluar estos sistemas.

Bases de datos multimodelos

Las bases de datos multimodo ofrecen una gestión de datos flexible y escalable en la nube y en aplicaciones en tiempo real. Las bases de datos multimodelos admiten varios modelos de datos, como documentos, gráficos, pares clave-valor, familias de columnas y datos relacionales, en una interfaz de consulta y un motor de almacenamiento unificados. Estas funciones ofrecen ventajas como las siguientes:

• Gestión simplificada: los desarrolladores gestionan varios tipos de datos en un único sistema de base de datos, lo que ayuda a reducir la complejidad operativa y la sobrecarga.
• Desarrollo más rápido: las bases de datos multimodelos ofrecen la flexibilidad de usar el modelo de datos óptimo para diferentes necesidades. Esta flexibilidad puede acelerar el desarrollo y ayudarte a adaptarte más rápido a los cambios en los requisitos.
• Integración más sencilla: una interfaz de consulta y un motor de almacenamiento unificados minimizan la complejidad de conectar y sincronizar bases de datos dispares.
• Consultas mejoradas: los desarrolladores pueden consultar y combinar datos de diferentes modelos, lo que permite obtener estadísticas más valiosas y funciones de aplicaciones más sofisticadas.
• Ahorro de costes: al haber menos sistemas de bases de datos, se reducen los costes de licencias, hardware y gastos operativos.
• Rendimiento optimizado: si eliges el modelo de datos más adecuado para tareas específicas, puedes mejorar el rendimiento de la aplicación.

Por ejemplo, Spanner ofrece funciones multimodelos con compatibilidad con el dialecto PostgreSQL. Esta función te permite crear aplicaciones inteligentes basadas en IA que usen datos relacionales y NoSQL, consultar relaciones complejas con Spanner Graph y usar la búsqueda vectorial para realizar búsquedas semánticas.

Siguientes pasos

• Consulta información sobre los patrones de arquitectura híbrida y multinube.
• Consulta información sobre los patrones para conectar otros proveedores de servicios en la nube con Google Cloud.
• Consulta información sobre las arquitecturas de monitorización y de almacenamiento de registros de los despliegues en entornos híbridos y multinube en Google Cloud.
• Para ver más arquitecturas de referencia, diagramas y prácticas recomendadas, consulta el centro de arquitectura de Cloud.

Colaboradores

Autor: Alex Cârciu | Arquitecto de soluciones