Despliegue de una carga de trabajo MongoDB migrada en Oracle Autonomous JSON Database
Migre una carga de trabajo existente que utilice una base de datos de documentos, en este caso MongoDB, a Oracle Autonomous JSON Database en Oracle Cloud Infrastructure (OCI) para modernizar el 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 (Acceso simple a documentos de Oracle (SODA) y API de Oracle Database para MongoDB), escalado sin servidor, transacciones ACID de alto rendimiento, seguridad completa y precios de pago por uso bajos. 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 que se utilizan 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 Autonomous JSON Database, sin necesidad de refactorizarlo.
En el siguiente diagrama se muestra una aplicación típica compuesta por una base de datos, un nivel de backend y un nivel de frontend.
mongodb-json-logical-arch-migration-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 OCI y Autonomous JSON Database.
La migración de esta carga de trabajo a OCI y Autonomous JSON Database es sencilla y consta, en general, de los siguientes pasos:
- Despliegue una instancia de Autonomous JSON Database, activando en el momento de la creación la API de base de datos de Oracle Database Mongo
- Migre metadatos y datos de MongoDB a Autonomous JSON Database.
- Despliegue servidores de aplicaciones para ejecutar
Node.jsy Express mediante máquinas virtuales, 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, que 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 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 de varios modelos y cargas de trabajo, se pueden agregar funciones adicionales que se basan en tipos de datos relacionales, espaciales, gráficos o vectoriales, trabajando junto con la aplicación existente. Es común que los usuarios deseen realizar análisis sobre datos JSON y utilizar 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, pero se puede convertir fácilmente a Autonomous Transaction Processing sin servidor, con las mismas funciones, si cambian los requisitos de volumen de datos. Tenga en cuenta que 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 subredes públicas y privadas en OCI con una región de copia de seguridad secundaria para admitir una alta disponibilidad.
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 está protegida mediante Web Application Firewall
- La conexión del usuario a la aplicación se equilibra con la carga para aumentar la resiliencia y la escalabilidad
- El equilibrador de carga se despliega con alta disponibilidad
- Nivel de backend
- Los servidores de aplicaciones se despliegan de forma de alta disponibilidad mediante un pool de instancias
- El pool de instancias se utiliza con la escala automática para lograr la escalabilidad horizontal
- El pool de instancias está configurado para desplegar instancias en el mismo dominio de disponibilidad que Autonomous JSON Database, con la colocación de aplicaciones y bases de datos, lo que optimiza la latencia de conexión
- El pool de instancias está configurado para distribuir instancias entre dominios de errores en el mismo dominio de disponibilidad donde se coloca Autonomous JSON Database, a fin de aumentar la resiliencia de la carga de trabajo
- 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.
- Para reducir el RTO general, puede utilizar una estrategia de recuperación ante desastres activa, donde 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.
- Entre las posibles mejoras de diseño que no se muestran en este despliegue por el bien de la simplicidad, se incluye el uso de OCI Full Stack Disaster Recovery para automatizar la recuperación ante desastres para el equilibrador de carga y el nivel de backend.
- Red
- Los gateways de direccionamiento dinámico desplegados en ambas regiones se intercambian tráfico.
- La conectividad local aprovecha OCI FastConnect y la VPN de sitio a sitio para la redundancia.
- Todo el tráfico entrante desde la ubicación local y desde Internet se enruta primero a la VCN de hub y, a continuación, a la VCN de carga de trabajo.
- Utiliza un diseño de red de hub y radios para aumentar la postura de seguridad y adaptarse a otras redes virtuales en la nube de carga de trabajo.
- Los servicios se despliegan con puntos finales privados para aumentar la estrategia de seguridad.
- La VCN de carga de trabajo JSON se divide en varias subredes privadas para aumentar la estrategia de seguridad.
- Seguridad
Todos los datos son seguros en tránsito y en reposo.
- Las posibles mejoras de diseño que no se muestran en este despliegue por simplicidad incluyen el uso de una zona de llegada compatible con CIS completa y el uso de un firewall de red desplegado en la VCN de hub. Un firewall de red 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.
mongodb-json-physical-arch-oracle.zip
La arquitectura tiene los siguientes componentes:
- Región
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).
- Red virtual en la nube (VCN) y subredes
Una VCN es una red personalizable y definida por software que se configura en una región de OCI. Al igual que las Redes de los Centros de Datos Tradicionales, las Redes Virtuales le proporcionan el control sobre su entorno de red. Una VCN puede tener varios bloques de CIDR no superpuestos que puede cambiar después de crear la VCN. Puede segmentar una VCN en subredes, las cuales se pueden acotar a una región o a un dominio de disponibilidad. Cada subred está formada por un rango contiguo de direcciones que no se solapan con las demás subredes de la VCN. Puede cambiar el tamaño de una subred después de la creación. Una subred puede ser pública o privada.
- FastConnect
Oracle Cloud Infrastructure FastConnect crea una conexión dedicada y privada entre tu centro de datos y OCI. FastConnect ofrece opciones de un Gran Ancho de Banda y una Experiencia de Red más fiable en comparación con la conexión basada en Internet.
- Gateway de enrutamiento dinámico (DRG)
The DRG is a virtual router that provides a path for private network traffic between VCNs in the same region, between a VCN and a network outside the region, such as a VCN in another OCI region, an on-premises network, or a network in another cloud provider.
- Gateway de traducción de direcciones de Red (NAT)
Un gateway de NAT permite que los recursos privados de una VCN accedan a los hosts de Internet, sin exponer dichos recursos a conexiones de Internet entrantes.
- Gateway de servicio
Un gateway de servicios proporciona acceso desde una VCN a otros servicios, como Oracle Cloud Infrastructure Object Storage. El tráfico desde la VCN al servicio Oracle recorre el tejido de red de la Oracle y no atraviesa Internet.
- Gateway de Internet
Un gateway de Internet permite el tráfico entre las subredes públicas de una VCN y la red pública de Internet.
- Equilibrador de carga
Oracle Cloud Infrastructure Load Balancing proporciona la distribución automatizada de tráfico desde un único punto a varios servidores.
- Firewall de Aplicación Web
Oracle Cloud Infrastructure Web Application Firewall (WAF) es una aplicación de perímetro, regional y compatible con el sector de tarjetas de pago (PCI) que se asocia a un punto de cumplimiento, como un equilibrador de carga o un nombre del dominio del aplicación web. WAF protege las aplicaciones frente al tráfico de Internet no deseado y malicioso. WAF puede proteger cualquier punto final orientado a internet, proporcionando un cumplimiento coherente de las reglas en todas sus aplicaciones.
- Servidor de aplicaciones
Los servidores de aplicaciones utilizan un par secundario que, al igual que la base de datos, se hará cargo del procesamiento en caso de desastre. Los servidores de aplicaciones utilizan la configuración y los metadatos que se almacenan en la base de datos y en el sistema de archivos. Los clusters del servidor de aplicaciones proporcionan protección en el ámbito de una sola región, pero las modificaciones continuas y los nuevos despliegues se deben replicar en la ubicación secundaria de forma continua para una recuperación ante desastres consistente.
- API de Oracle Database para MongoDB
La API de Oracle Database para MongoDB permite a las aplicaciones interactuar con recopilaciones de documentos JSON en Oracle Database mediante controladores, herramientas y SDK de MongoDB.
- Autonomous JSON Database
Oracle Autonomous JSON Database es un servicio en la nube de base de datos de documentos que facilita el desarrollo en aplicaciones centradas en JSON. Cuenta con API de documentos simples, escalado sin servidor, transacciones ACID de alto rendimiento, seguridad integral y bajos precios de pago por uso. Autonomous JSON Database automatiza el aprovisionamiento, la configuración, el ajuste, la escala, la aplicación de parches, el cifrado y las reparaciones de la base de datos.
- Almacenamiento de objetos
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 y directa desde Internet 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.
Variante de arquitectura
La API MongoDB totalmente gestionada proporcionada por Autonomous JSON Database 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.
El siguiente diagrama de arquitectura 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 resto del despliegue es el mismo que se ha descrito anteriormente.
mongodb-json-arch-variant-oracle.zip
- El código de aplicación backend se despliega en servidores de aplicaciones que forman parte de un pool de instancias.
- El equilibrador de carga distribuye las solicitudes de usuario entrantes, por lo que el nivel de frontend es escalable horizontalmente y no tiene un único punto de fallo.
- Oracle REST Data Services gestionado por el cliente se instala en cada servidor de aplicaciones y se configura 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 el uso de 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 configuración de instancia utilizada por el pool, de modo que cada vez que se agrega una instancia al pool, puede ejecutar el backend y conectarse a la base de datos, después del aprovisionamiento de la instancia.
Recomendaciones
- VCN
Al crear una VCN, determine el número de bloques CIDR necesarios y el tamaño de cada bloque en función del número de recursos que tenga previsto asociar a las subredes de la VCN. Utilice bloques CIDR que se encuentren dentro del espacio de direcciones IP privadas estándar.
Seleccione bloques CIDR que no se solapen con ninguna otra red (en Oracle Cloud Infrastructure, su centro de datos local u otro proveedor en la nube) en la que desee configurar conexiones privadas.
Después de crear una VCN, puede cambiar, agregar y eliminar sus bloques CIDR.
Al diseñar las subredes, tenga en cuenta los requisitos de seguridad y el flujo de tráfico. Asocie todos los recursos de un nivel o rol específico a la misma subred, lo que puede servir como límite de seguridad.
- Despliegue de Aplicación
Considere el uso de un despliegue basado en contenedor con Oracle Kubernetes Engine (OKE) si la aplicación se puede ejecutar en contenedores.
- Seguridad
Considere el uso de Data Safe para aumentar aún más la estrategia de seguridad de la carga de trabajo y poder realizar auditorías de la base de datos.
- Observabilidad
- Considera el uso de OCI Audit para realizar auditorías forenses para todos los servicios de OCI más allá de Autonomous JSON Database.
- Considere el uso de Monitoring, Logging y Logging Analytics para tener una visibilidad completa del estado operativo del entorno.
- Recuperación ante desastres
Considera el uso de OCI Full Stack Disaster Recovery para automatizar y orquestar el desastre y la recuperación de todas las capas de la pila.
- Eficiencia operativa
- Considere el uso de pools elásticos si la carga de trabajo de Autonomous JSON forma parte de un conjunto de bases de datos más amplio para aumentar la rentabilidad.
- Considere la posibilidad de activar 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 instancias de AJD.
- 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 u Oracle Analytics Cloud, 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 desplegar los modelos junto con la carga de trabajo existente para una inferencia eficiente
- Para casos de uso adicionales más allá del núcleo de la aplicación, considere el uso de Autonomous JSON Database. Seleccionar 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), 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
- API de Oracle Database para MongoDB
- Migración de una base de datos MongoDB que se ejecuta en MongoDB Atlas o local a Oracle Autonomous JSON Database (tutorial)
- Acerca de Oracle REST Data Services gestionado por el cliente en Autonomous Database
Revise estos recursos adicionales: