Despliegue de una carga de trabajo migrada de MongoDB en Oracle Autonomous Transaction Processing Serverless@Azure
Las cargas de trabajo y las aplicaciones que utilizan documentos y bases de datos de documentos para desarrollar esquemas y aplicaciones de datos son populares debido a la flexibilidad que ofrecen a los desarrolladores. La flexibilidad del esquema, el desarrollo rápido y la escalabilidad permiten acelerar la creación de prototipos de funciones de aplicaciones, facilitar la evolución de las aplicaciones y la capacidad de crear 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 pueden beneficiarse de las ventajas de las bases de datos de documentos tradicionales y aprovechar las ventajas de las bases de datos relacionales? Por ejemplo, tienen garantías transaccionales más sólidas y funcionalidades agregadas, como análisis y aprendizaje automático, sin la necesidad de replicar datos en otra base de datos o sistema.
Autonomous Transaction Processing (ATP) Serverless es un servicio de base de datos totalmente automatizado optimizado para ejecutar cargas de trabajo transaccionales, analíticas y por lotes simultáneamente. Para acelerar el rendimiento, está preconfigurado para el formato de fila, los índices y el almacenamiento en caché de datos, al tiempo que proporciona escalabilidad, disponibilidad, seguridad transparente y análisis operativos en tiempo real. Los desarrolladores y administradores de bases de datos (DBA) pueden desarrollar y desplegar aplicaciones de forma rápida y rentable sin renunciar a las propiedades de funcionalidad, atomicidad, consistencia, aislamiento y durabilidad (ACID).
Arquitectura funcional
Esta arquitectura supone, como punto de partida, que existe una carga de trabajo con una aplicación y una base de datos MongoDB, ya sea un despliegue local o en la nube, y se migrará a Azure y Oracle Database@Azure. Describe la arquitectura de estado futura, sus ventajas, cómo se puede desplegar y qué funciones adicionales puede utilizar para aumentar la carga de trabajo existente.
Una de las funciones clave utilizadas en esta arquitectura es Oracle Database API for MongoDB, que permite a las aplicaciones interactuar con recopilaciones de documentos JSON en Oracle Database mediante controladores, herramientas y SDK MongoDB. El código de aplicación existente puede funcionar con datos almacenados en Oracle Autonomous Transaction Processing sin servidor, sin necesidad de refactorizar el código.
En el siguiente diagrama se muestra una aplicación típica compuesta por niveles de base de datos, backend y front-end.
mongodb-atp-s-azure-logical-arch-migration.zip
La pila MEAN es una pila popular que se utiliza para implementar este patrón:
- MongoDB: base de datos de documentos
- Express: marco de backend
- Angular: Marco frontal
Node.js: servidor backend
Este documento utiliza una pila MEAN como ejemplo de un despliegue existente que se migrará a Azure y ATP Serverless.
La migración de esta carga de trabajo a Azure y ATP Serverless es sencilla y consta, en general, de los siguientes pasos:
- Despliegue una instancia sin servidor ATP, lo que permite en el momento de la creación la API MongoDB de Oracle Database.
- Migre metadatos y datos de MongoDB a ATP sin servidor.
- Despliegue servidores de aplicaciones para ejecutar
Node.jsy Express mediante el servicio de aplicaciones de Azure, las máquinas virtuales, los contenedores o Kubernetes en la misma región y dominio de disponibilidad que ATP Serverless. - Despliegue el código de la aplicación backend en los servidores de aplicaciones.
- Conecte la aplicación backend a ATP Serverless mediante las mismas herramientas y controladores MongoDB utilizados en la aplicación actual.
- Conectar usuarios 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 ATP Serverless, hay varias funciones disponibles para aumentar la funcionalidad existente, ya sea para 1) soportar requisitos no funcionales adicionales, como mejorar fácilmente la escalabilidad, la resiliencia o la alta disponibilidad, o 2) tener 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 sin servidor de Autonomous Transaction Processing. Con un solo clic o llamada de API, permite que la carga de trabajo utilice hasta 3 veces la capacidad base sin ningún tiempo de inactividad. Tenga en cuenta que Autonomous Transaction Processing Serverless utiliza la tecnología Oracle Real Application Clusters (Oracle RAC) para una alta disponibilidad. Para el nivel de backend, utilice juegos de escala de máquina virtual de Azure con configuración de escala automática o un servicio PaaS, como el servicio de aplicaciones con configuración de escala automática, para activar la alta disponibilidad y escalabilidad de la aplicación.
Dado que ATP Serverless se basa en la tecnología de base de datos multimodelo y multicarga de trabajo, puede agregar funciones que se basan en tipos de datos relacionales, espaciales, gráficos o vectoriales que funcionan junto con la aplicación existente.
Arquitectura Física
La arquitectura física incluye Autonomous Transaction Processing Serverless desplegado mediante subredes delegadas en dos regiones de 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 Azure Front Door.
- La conexión de usuario está protegida mediante el firewall de aplicaciones web de Azure.
- 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 el servicio de aplicaciones de Azure.
- El servicio de aplicaciones de Azure AutoScale se utiliza para lograr escalabilidad horizontal.
- Nivel de base de datos
- ATP Serverless 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 API for MongoDB activada en ATP Serverless permite utilizar el código de aplicación existente sin cambios.
- Oracle Database API for MongoDB es altamente resistente y esa resiliencia está garantizada internamente por ATP Serverless.
- ATP Serverless puede utilizar la escala automática, ajustándose a los aumentos y disminuciones de la carga del sistema.
- La continuidad del negocio sin servidor ATP se logra a través de Autonomous Data Guard entre regiones.
- Recuperación ante desastres
- 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 DR activa, los recursos en la nube de nivel backend ya están aprovisionados junto con la base de datos en espera ATP Serverless.
- 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 el entorno local y desde Internet es enrutado por Azure Front Door.
- ATP Serverless se despliega con un punto final privado para aumentar la estrategia de seguridad.
- La aplicación web Azure App Service se despliega mediante una subred de integración y VNet para acceder a la instancia sin servidor ATP.
- La aplicación VNet se conecta con la base de datos VNet y el tráfico puede fluir entre la aplicación web y ATP Serverless.
- Seguridad
- Todos los datos son seguros en tránsito y en reposo.
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.
mongodb-atp-s-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 las aplicaciones web, 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 Microsoft Azure
Microsoft Azure App Service permite crear, alojar y escalar aplicaciones web, API y back-ends 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).
- Oracle Autonomous Database
Oracle Autonomous Database es un entorno de base de datos preconfigurado y totalmente gestionado que puede utilizar para cargas de trabajo de procesamiento de transacciones y almacenamiento de datos. No necesita configurar ni gestionar ningún hardware, ni instalar ningún software. OCI gestiona la creación, la copia de seguridad, la aplicación de parches, la actualización y el ajuste de la base de datos.
- Oracle Autonomous Data Guard
Oracle Autonomous Data Guard permite que una base de datos en espera (peer) proporcione protección de datos y recuperación ante desastres para la instancia de Autonomous Database. Proporciona un completo juego de servicios que permiten crear, mantener, gestionar y controlar una o más bases en espera para permitir que las bases de datos Oracle de producción puedan sobrevivir ante desastres y corrupciones de datos sin interrupción. Oracle Data Guard mantiene estas bases del sistema en espera como copias de la base de datos en producción. A continuación, si la base de datos de producción deja de estar disponible debido a una interrupción planificada o no planificada, puede cambiar cualquier base de datos en espera al rol de producción, lo que minimiza el tiempo de inactividad asociado a la interrupción.
- 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
Esta variante de la arquitectura física propuesta utiliza un despliegue de Oracle REST Data Services gestionado por el cliente que se ejecuta en cada servidor de aplicaciones. Sin embargo, la API MongoDB totalmente gestionada proporcionada por ATP Serverless es la mejor solución para la mayoría de las cargas de trabajo, ya que es más fácil de gestionar.
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 mayor simplicidad, solo se representan los recursos en la nube desplegados en la VCN de carga de trabajo JSON, ya que el resto del despliegue es el mismo que el resto de la arquitectura física descrita anteriormente.
mongodb-atp-s-azure-arch-variant.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.
- Capacidad de observación
- Considere el uso de Azure Monitor, para supervisar las métricas ATP Serverless 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 sin servidor ATP forma parte de un conjunto de bases de datos más amplio, considere el uso de agrupaciones elásticas para aumentar la rentabilidad.
- Considere 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 sin servidor ATP.
- Evolución de la aplicación
- Considere la posibilidad de desplegar análisis operativos e informes en tiempo real en ATP Serverless mediante SQL y un front-end como APEX o PowerBI, sin mover datos de la base de datos, para un análisis de datos de confianza y en tiempo real.
- Considere el uso de ATP Serverless 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 ATP Serverless Select AI y vistas de base de datos que consultan JSON y contienen metadatos, para que los usuarios puedan consultar datos JSON mediante lenguaje natural.
- Considere el uso de ATP Serverless para almacenar tipos de datos adicionales (relacionales, vectoriales, espaciales o gráficos) para agregar funcionalidad y flexibilidad de carga de trabajo.
Explorar más
Obtenga más información sobre las funciones de esta arquitectura:
Revise estos recursos adicionales:
- Plataforma de datos de Oracle
- Documentación de Oracle Autonomous Transaction Processing Serverless
- Servicios de Autonomous Database para Azure
- API de Oracle Database para MongoDB
- Uso Oracle Autonomous Database Serverless
Revise estos recursos adicionales: