Despliegue de una carga de trabajo MongoDB migrada en Oracle Autonomous JSON Database@Azure
Migre una carga de trabajo existente que utilice una base de datos de documentos, en este caso MongoDB, a Azure y a Oracle Autonomous JSON Database desplegado en Azure, un servicio de base de datos de documentos en la nube que facilita la modernización del desarrollo de sus aplicaciones centradas en JSON.
Las cargas de trabajo y las aplicaciones que utilizan documentos y bases de datos de documentos para desarrollar esquemas y aplicaciones de datos son muy populares debido a la flexibilidad que ofrecen a los desarrolladores. La flexibilidad del esquema, el desarrollo rápido y la escalabilidad permiten crear prototipos rápidos de las funciones de la aplicación, facilitar la evolución de la aplicación y garantizar la creación de aplicaciones y funciones iterativamente más pequeñas que los desarrolladores pueden escalar para abordar una gran base de usuarios. Sin embargo, estos tipos de cargas de trabajo tienen sus desafíos, como garantías transaccionales más débiles, versatilidad de consultas de datos y la incapacidad de soportar otras cargas de trabajo en documentos, como análisis o aprendizaje automático.
¿Y si estas cargas de trabajo pudieran beneficiarse de todas las ventajas de las bases de datos de documentos tradicionales, pero al mismo tiempo, aprovechar las ventajas de las bases de datos relacionales? Por ejemplo, contar con garantías transaccionales más sólidas y utilizar funcionalidades adicionales como análisis y aprendizaje automático, sin necesidad de replicar datos en otra base de datos o sistema.
Autonomous JSON Database cuenta con API de documentos de estilo NoSQL (Oracle Simple Oracle Document Access (SODA) y API de Oracle Database para MongoDB), escalado sin servidor, transacciones ACID de alto rendimiento, seguridad completa y precios bajos de pago por uso. Autonomous JSON Database automatiza el aprovisionamiento, la configuración, el ajuste, la ampliación, la aplicación de parches, el cifrado y la reparación de bases de datos, eliminando la gestión de bases de datos y ofreciendo una disponibilidad del 99,95 %.
Arquitectura funcional
Una de las funciones clave utilizadas en esta arquitectura es la API de Oracle Database para MongoDB, que permite a las aplicaciones interactuar con recopilaciones de documentos JSON en Oracle Database mediante controladores, herramientas y SDK de MongoDB. El código de las aplicaciones existentes puede funcionar con datos almacenados en Oracle Autonomous JSON Database sin necesidad de refactorizarlo.
En el siguiente diagrama se muestra una aplicación típica compuesta por niveles de base de datos, backend y front-end.
mongodb-ajd-azure-logical-arch-oracle.zip
Una pila popular, que se utiliza para implementar este patrón, es la pila MEAN, que utiliza MongoDB como base de datos de documentos, Express como marco de backend, Angular como marco de front-end y Node.js como servidor de backend. En este documento se utiliza una pila MEAN como ejemplo de un despliegue existente que se migrará a Azure y Autonomous JSON Database.
La migración de esta carga de trabajo a Azure y Autonomous JSON Database es sencilla y consta, en general, de los siguientes pasos:
- Despliegue una instancia de Autonomous JSON Database, lo que permite al crear la API MongoDB de Oracle Database.
- Migre metadatos y datos de MongoDB a Autonomous JSON Database.
- Despliegue servidores de aplicaciones para ejecutar
Node.jsy Express mediante Azure App Service, VM, contenedores o Kubernetes en la misma región y dominio de disponibilidad que Autonomous JSON Database. - Despliegue el código de la aplicación backend en los servidores de aplicaciones.
- Conecte la aplicación backend a Autonomous JSON Database mediante las mismas herramientas y controladores MongoDB que se utilizan en la aplicación actual.
- Haga que los usuarios se conecten al nuevo URI de aplicación.
Tenga en cuenta que esta arquitectura de referencia se centra en el despliegue de la carga de trabajo migrada y no en el propio proceso de migración. Para obtener más información sobre el proceso de migración, consulte la sección Explorar más.
Después de migrar la carga de trabajo a Autonomous JSON Database, puede utilizar varias funciones para aumentar la funcionalidad existente, ya sea para 1) soportar requisitos no funcionales adicionales, como la facilidad de uso. mejorar la escalabilidad, la resiliencia o la alta disponibilidad, o 2) disponer de funciones funcionales adicionales, como informes operativos, análisis y aprendizaje automático, sin necesidad de copiar datos de la base de datos.
Para mejorar la escalabilidad y la alta disponibilidad, utilice la función de escala automática de Autonomous JSON Database. Una sola llamada de API o clic permite que la carga de trabajo utilice hasta 3 veces la capacidad base sin tiempo de inactividad. Tenga en cuenta que Autonomous JSON Database utiliza la tecnología Oracle Real Application Clusters (Oracle RAC) para la alta disponibilidad. Para el nivel backend, utilice pools de instancias informáticas con reglas de ampliación automática, lo que permite una alta disponibilidad y escalabilidad de la aplicación.
Dado que Autonomous JSON Database se basa en una tecnología de base de datos multimodelo y de carga de trabajo múltiple, puede agregar funciones que se basan en tipos de datos relacionales, espaciales, gráficos o vectoriales que funcionan junto con la aplicación existente. Es común que los usuarios deseen realizar análisis sobre datos JSON. El uso de SQL en Autonomous JSON Database simplifica la creación de informes operativos y analíticos, utilizando el mismo motor y datos.
Autonomous JSON Database tiene un límite de 20 Gb de datos que no son JSON. Si cambian los requisitos de volumen de datos, puede convertir fácilmente a Oracle Autonomous Database Serverless, que soporta las mismas funciones. El almacenamiento de vistas y vistas materializadas no cuenta para el límite de datos no JSON de 20 Gb de Autonomous JSON Database, por lo que se pueden crear y utilizar fácilmente, por ejemplo, para soportar análisis operativos mediante SQL sobre documentos JSON.
Arquitectura Física
La arquitectura física incluye Autonomous JSON Database desplegada mediante subredes delegadas en dos regiones de Microsoft Azure para admitir la alta disponibilidad. Los servicios de OCI admiten la copia de seguridad automática en Oracle Cloud Infrastructure Object Storage.
La arquitectura admite lo siguiente:
- Nivel de frontend
- Los usuarios de la aplicación pueden conectarse desde Internet o desde la red corporativa.
- La conexión de usuario se enruta a la región activa que está ejecutando la aplicación mediante la puerta frontal de Microsoft Azure.
- La conexión de usuario está protegida mediante Azure Web Application Firewall.
- La conexión del usuario a la aplicación se equilibra con la carga mediante el servicio de aplicación.
- Nivel de backend
- La aplicación se despliega de forma de alta disponibilidad mediante Azure App Service.
- El servicio de aplicaciones de Azure AutoScale se utiliza para lograr escalabilidad horizontal.
- Nivel de base de datos
- Autonomous JSON Database proporciona alta disponibilidad, ya que Oracle Real Application Clusters (Oracle RAC) y varios nodos de base de datos apuntalan la instancia de servicio. Por lo tanto, por defecto, el nivel de base de datos es resistente y de alta disponibilidad.
- La API de Oracle Database para MongoDB activada en Autonomous JSON Database permite utilizar el código de aplicación existente sin cambios.
- La API de Oracle Database para MongoDB es muy resistente y Autonomous JSON Database garantiza internamente esa resiliencia.
- Autonomous JSON Database puede utilizar la escala automática, ajustándose a aumentos y disminuciones de la carga del sistema.
- La continuidad del negocio de Autonomous JSON Database se logra mediante la recuperación ante desastres entre regiones basada en copias de seguridad. También puede utilizar clonaciones de refrescamiento.
- Recuperación ante desastres
- Dos regiones soportan la recuperación ante desastres entre regiones para todo el despliegue en la nube.
- La base de datos JSON autónoma de la región principal tiene un peer entre regiones basado en copia de seguridad en la región secundaria.
- La segunda región se despliega con una topología similar para reducir el objetivo de tiempo de recuperación general.
- Utilice una estrategia de recuperación ante desastres activa para reducir el RTO general. En una estrategia de recuperación ante desastres activa, los recursos en la nube de nivel backend ya están aprovisionados junto con la base de datos en espera de Autonomous JSON Database.
- También puede aprovisionar los recursos de nivel backend en caso de fallo, lo que reduce el costo de ejecución de los recursos de DR, pero aumenta el RTO general.
- Red
- Todo el tráfico entrante de la aplicación desde las instalaciones y desde Internet es enrutado por Azure Front Door.
- Autonomous JSON Database se despliega con un punto final privado para aumentar la estrategia de seguridad.
- Azure App Service es una aplicación web que se despliega mediante una subred de integración y VNet para acceder a la instancia de Autonomous JSON Database.
- La aplicación VNet se conecta con la base de datos VNet y el tráfico puede fluir entre la aplicación web y la base de datos JSON autónoma.
- Seguridad
- Todos los datos son seguros en tránsito y en rest.
- Las siguientes mejoras de diseño potenciales no se muestran en este despliegue por simplicidad:
- Automatice la recuperación ante desastres de la aplicación mediante los runbooks de Azure Automation para cambiar los puntos finales de la puerta delantera y validar el estado posterior a la conmutación por error de la aplicación.
- Aproveche la topología de hub y radio para aplicar la seguridad de red centralizada.
- Aproveche un firewall de red, desplegado en el hub VNet, para mejorar la estrategia de seguridad general mediante la inspección de todo el tráfico y la aplicación de políticas.
El siguiente diagrama ilustra esta arquitectura de referencia.
mongodb-ajd-azure-physical-arch.zip
La arquitectura tiene los siguientes componentes de Microsoft:
- Administrador de firewall de Azure
Azure Firewall Manager es un servicio centralizado de gestión de seguridad que simplifica el despliegue y la configuración de Azure Firewall en varias regiones y suscripciones. Permite la gestión de políticas jerárquicas, lo que permite que las políticas de firewall locales y globales se apliquen de forma coherente. Cuando se integra con Azure Virtual WAN (vWAN) y un hub seguro, Azure Firewall Manager mejora la seguridad al automatizar el enrutamiento y el filtrado del tráfico sin la necesidad de rutas definidas por el usuario. Esta integración garantiza que el tráfico entre redes virtuales, sucursales e Internet se gestione y controle de forma segura, proporcionando una solución de seguridad de red robusta y optimizada.
- Puerta frontal de Azure
Azure Front Door es un servicio basado en la nube que actúa como punto de entrada global para aplicaciones web, que proporciona entrega de contenido de alto rendimiento, equilibrio de carga inteligente de capa 7 y funciones de seguridad integradas como Web Application Firewall (WAF) y protección DDoS para garantizar experiencias de usuario rápidas, confiables y seguras.
- Región de Azure
Una región de Azure es un área geográfica en la que residen uno o más centros de datos físicos de Azure, denominados zonas de disponibilidad. Las regiones son independientes de otras regiones y pueden haber grandes distancias que las separan (entre países o incluso continentes).
Las regiones de Azure y OCI son áreas geográficas localizadas. Para Oracle Database@Azure, una región de Azure está conectada a una región de OCI, con zonas de disponibilidad (AZ) en Azure conectadas a dominios de disponibilidad (AD) en OCI. Los pares de regiones de Azure y OCI se seleccionan para minimizar la distancia y la latencia.
- Zona de disponibilidad de Azure
Las zonas de disponibilidad de Azure son ubicaciones físicamente separadas dentro de una región de Azure, diseñadas para garantizar una alta disponibilidad y resiliencia al proporcionar energía, refrigeración y redes independientes.
- Red virtual de Azure (VNet)
Azure Virtual Network (VNet) es el componente fundamental de su red privada en Azure. VNet permite que muchos tipos de recursos de Azure, como las máquinas virtuales (VM) de Azure, se comuniquen de forma segura entre sí, Internet y las redes locales.
- Servicio de aplicaciones de Azure
Azure App Service es una plataforma como servicio totalmente gestionada (PaaS) que permite crear, alojar y escalar aplicaciones web, API y backends móviles sin gestionar la infraestructura subyacente.
- Subred de integración de Azure App Service
Una subred dedicada dentro de una red virtual de Azure que se delega específicamente para su uso por parte de los planes de servicio de aplicaciones, lo que permite que las aplicaciones web realicen conexiones salientes a recursos privados dentro de la red virtual o sus redes de intercambio de tráfico, pero no para recibir tráfico entrante de VNet.
- subred delegada de Azure
Una subred delegada permite insertar un servicio gestionado, específicamente un servicio de plataforma como servicio (PaaS), directamente en la red virtual como recurso. Tiene una gestión de integración completa de los servicios PaaS externos en sus redes virtuales.
La arquitectura tiene los siguientes componentes de Oracle:
- Región OCI
Una región de OCI es un área geográfica localizada que contiene uno o más centros, denominados dominios de disponibilidad. Las regiones son independientes de otras regiones y pueden haber grandes distancias que las separan (entre países o incluso continentes).
- OCI Object Storage
OCI Object Storage proporciona acceso a grandes cantidades de datos estructurados y no estructurados de cualquier tipo de contenido, incluidas copias de seguridad en bases de datos, datos analíticos y contenido enriquecido como imágenes y vídeos. Puede almacenar datos de forma segura directamente desde las aplicaciones o desde la plataforma en la nube. Puedes ampliar el almacenamiento sin experimentar ninguna degradación del rendimiento o la fiabilidad del servicio.
Utilice el almacenamiento estandar para el almacenamiento "caliente" al que debe acceder de forma rápida, inmediata y frecuente. Utilice este tipo de almacenamiento para el almacenamiento "frío" que conserva durante largos períodos de tiempo y a los a los que rara vez accede.
- Punto final privado de OCI
OCI Private Endpoint proporciona acceso seguro, privado y sin costo a uno de los muchos servicios de OCI desde una red virtual en la nube (VCN) o una red local.
Variante de arquitectura
Si hay requisitos para controlar manualmente la configuración y la gestión de Oracle REST Data Services, es una opción utilizar Oracle REST Data Services gestionado por el cliente. Por ejemplo, para permitir que la aplicación utilice pools de conexiones más grandes.
Note:
Utilice esta variante de arquitectura si hay un requisito de carga de trabajo específico para hacerlo. Solo los usuarios avanzados deben desplegar esta variante de arquitectura.Esta sección sólo describe las diferencias en comparación con la arquitectura física descrita anteriormente, por lo que todos los principios de diseño de arquitectura física son válidos a menos que se indique lo contrario.
En el siguiente diagrama de arquitectura se muestra cómo se despliega la variante. Para simplificarlo, solo se representan los recursos en la nube desplegados en la VCN de carga de trabajo JSON, ya que el rest del despliegue es el mismo que la arquitectura física descrita anteriormente.
mongodb-ajd-azure-arch-variant-oracle.zip
- Las solicitudes de usuario entrantes las distribuye el equilibrador de carga del servicio de aplicación, por lo que el nivel de front-end es horizontalmente escalable y no tiene un único punto de fallo.
- La aplicación backend se despliega en los trabajadores de la unidad de escala de servicio de aplicación.
- La aplicación se despliega utilizando el contenedor como método de publicación.
- Cree, instale y configure el contenedor con la aplicación y Oracle REST Data Services, lo que permite que ambos se ejecuten en el mismo contenedor.
- Cada trabajador ejecuta la imagen de contenedor que coloca la aplicación y Oracle REST Data Services en el mismo entorno de tiempo de ejecución.
- Los trabajadores de Oracle REST Data Services gestionados por el cliente están configurados para activar la API MongoDB, de modo que la aplicación se pueda conectar a la base de datos mediante herramientas y controladores MongoDB.
- Los Oracle REST Data Services gestionados por el cliente están configurados para ajustarse a los requisitos no funcionales de la carga de trabajo, por ejemplo, mediante la configuración de pools de conexiones más grandes o mediante un servicio de base de datos diferente.
- Tanto el código de backend como el Oracle REST Data Services gestionado por el cliente están preinstalados y preconfigurados en la imagen de contenedor utilizada en los trabajadores. Cuando el servicio de aplicaciones se escala horizontalmente, los nuevos trabajadores pueden ejecutar la aplicación backend y conectarse a la base de datos después del aprovisionamiento.
Recomendaciones
- Despliegue de Aplicación
- Considere el uso de un despliegue basado en contenedores con Azure Kubernetes Service (AKS) si necesita funciones avanzadas de orquestación, redes y seguridad que podrían no estar disponibles en el servicio de aplicaciones.
- Seguridad
- Considere el uso de Oracle Data Safe para aumentar aún más la estrategia de seguridad de la carga de trabajo y realizar la auditoría de la base de datos.
- Observabilidad
- Considera usar Azure Monitor para supervisar las métricas de Autonomous JSON Database junto con todos los demás datos de supervisión de servicios de Azure.
- Recuperación ante desastres
- Considere la posibilidad de automatizar y organizar el desastre y la recuperación para todas las capas de la pila utilizando Azure Site Recovery o scripts personalizados que detecten fallos e inicien procesos de failover.
- Eficiencia operativa
- Si la carga de trabajo de Autonomous JSON Database forma parte de un conjunto de bases de datos más amplio, considere el uso de pools elásticos para aumentar la rentabilidad.
- Considera la posibilidad de activar Oracle Cloud Infrastructure Database Management, un servicio de OCI que proporciona un conjunto completo de funciones de gestión y supervisión del rendimiento de la base de datos, para optimizar la gestión de la instancia de Autonomous JSON Database.
- Evolución de la aplicación
- Considere la posibilidad de desplegar análisis operativos e informes en tiempo real en Autonomous JSON Database mediante SQL y un front-end como APEX o PowerBI, sin mover datos de la base de datos para un análisis de datos en tiempo real y de confianza.
- Considera el uso de Autonomous JSON Database para el aprendizaje automático mediante Oracle Machine Learning (OML), para crear y entrenar modelos con datos JSON sin necesidad de movimiento de datos y para desplegar los modelos junto con la carga de trabajo existente para realizar inferencias eficientes.
- Para casos de uso adicionales más allá del núcleo de la aplicación, considere el uso de Autonomous JSON Database. Seleccione las vistas de IA y base de datos que consultan JSON y que contienen metadatos, para que los usuarios puedan consultar datos JSON mediante lenguaje natural.
- Considere el uso de Autonomous JSON Database para almacenar tipos de datos adicionales (relacionales, vectoriales, espaciales o gráficos) de hasta 20 Gb para agregar funcionalidad y flexibilidad a la carga de trabajo.
Explorar más
Obtenga más información sobre las funciones de esta arquitectura:
- Plataforma de datos de Oracle
- Documentación de Autonomous JSON Database
- Servicios de Autonomous Database para Azure
- API de Oracle Database para MongoDB
- Uso Oracle Autonomous Database Serverless
- Migración de una base de datos MongoDB que se ejecuta en MongoDB Atlas o local a Oracle Autonomous JSON Database (tutorial)
Revise estos recursos adicionales: