Despliegue de una carga de trabajo MongoDB migrada a Oracle Autonomous Transaction Processing Serverless

Migre una carga de trabajo existente que utilice una base de datos de documentos, en este caso MongoDB, a la base de datos de Oracle Autonomous Transaction Processing Serverless (ATP Serverless) en Oracle Cloud Infrastructure (OCI) para modernizar el desarrollo de sus aplicaciones centradas en JSON junto con otras cargas de trabajo de varios modelos.

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 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 de referencia asume que tiene una carga de trabajo con una aplicación y una base de datos MongoDB, ya sea local o en la nube, y migrará a OCI. Describe la arquitectura de estado futura, sus ventajas, cómo puede desplegarla y qué funciones adicionales puede utilizar para aumentar la carga de trabajo existente.

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.

Uno de los productos 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 MongoDB. Esto permite que el código de aplicación existente funcione con datos almacenados en Autonomous Transaction Processing Serverless (ATP Serverless) sin necesidad de refactorizar el código.

En el siguiente diagrama se muestra una aplicación típica compuesta por una base de datos, niveles de backend y front-end.


A continuación se describe mongodb-atp-s-logical-arch-migration.png
Descripción de la ilustración mongodb-atp-s-logical-arch-migration.png

mongodb-atp-s-logical-arch-migration-oracle.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

En este ejemplo, se utiliza una pila MEAN para migrar un despliegue existente a OCI y ATP Serverless.

La migración de esta carga de trabajo a OCI y ATP Serverless es sencilla y consta, en general, de los siguientes pasos:

  1. Despliegue una instancia ATP sin servidor y active en el momento de la creación la API de base de datos de Oracle Database Mongo.
  2. Migre metadatos y datos de MongoDB a ATP Serverless.
  3. Despliegue servidores de aplicaciones para ejecutar Node.js y Express mediante máquinas virtuales, contenedores o Kubernetes en la misma región y dominio de disponibilidad que ATP Serverless.
  4. Despliegue el código de la aplicación backend en los servidores de aplicaciones.
  5. Conecte la aplicación backend a ATP Serverless utilizando las mismas herramientas y controladores MongoDB que se utilizan en la aplicación actual.
  6. Conectar usuarios al nuevo URI de aplicación.

Después de migrar la carga de trabajo a ATP Serverless, hay varias funciones disponibles para aumentar la funcionalidad existente, ya sea para 1) admitir 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 de Oracle Real Application Clusters (Oracle RAC) para una alta disponibilidad. Para el nivel de backend, utilice grupos de instancias informáticas con reglas de ampliación automática para permitir una alta disponibilidad y escalabilidad de las aplicaciones.

Dado que Autonomous Transaction Processing 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 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 OCI Web Application Firewall.
    • La conexión del usuario a la aplicación se equilibra con la carga para aumentar la resiliencia y las posibilidades de ampliación.
    • 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 una escalabilidad horizontal.
    • El pool de instancias está configurado para desplegar instancias en el mismo dominio de disponibilidad que ATP Serverless, para que la aplicación y la base de datos se coloquen, optimizando así 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 ATP Serverless, a fin de aumentar la resiliencia de la carga de trabajo.
  • 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 para MongoDB activada en ATP Serverless permite utilizar el código de aplicación existente sin cambios.
    • La API de Oracle Database para MongoDB es muy resistente y la 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 con la recuperación ante desastres entre regiones basada en Oracle Autonomous Data Guard.
    • El objetivo de tiempo de recuperación en espera (RTO) de Oracle Autonomous Data Guard entre regiones es de quince minutos y el objetivo de punto de recuperación (RPO) es de un minuto.
  • Recuperación ante desastres
    • Dos regiones soportan la recuperación ante desastres entre regiones para todo el despliegue en la nube.
    • La región en espera soporta una base de datos en espera activa en la que las instancias en la nube se despliegan previamente para reducir el objetivo de tiempo de recuperación total (RTO).
    • ATP Serverless en la región principal tiene un peer entre regiones de Oracle Autonomous Data Guard en la región en espera
    • El pool de instancias de nivel de backend está preconfigurado con una cantidad mínima de instancias en el pool, y el plan de DR de OCI Full Stack Disaster Recovery, que automatiza cada paso del failover, puede cambiar el número de instancias informáticas que se deben ejecutar después del failover. La configuración de escala automática basada en métricas se define para determinar el número mínimo y máximo de instancias del pool, así como las métricas utilizadas para la ampliación horizontal y horizontal.
    • La región en espera se despliega con una topología similar para reducir el objetivo de tiempo de recuperación general.
    • OCI Full Stack Disaster Recovery automatiza el failover de toda la pila a la región en espera y las reservas a la región principal.
  • Red
    • Los gateways de enrutamiento dinámico desplegados en ambas regiones se intercambian tráfico.
    • La conectividad local aprovecha tanto Oracle Cloud Infrastructure FastConnect como 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.

A continuación se describe mongodb-atp-s-physical-arch.png
Descripción de la ilustración mongodb-atp-s-physical-arch.png

mongodb-atp-s-physical-arch-oracle.zip

La arquitectura tiene los siguientes componentes principales:

  • 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.

  • Oracle Autonomous Transaction Processing Serverless

    Oracle Autonomous Transaction Processing 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, sencilla y rentable sin renunciar a las propiedades de funcionalidad o atomicidad, consistencia, aislamiento y durabilidad (ACID).

  • Full Stack Disaster Recovery

    Oracle Cloud Infrastructure Full Stack Disaster Recovery es un servicio de gestión y orquestación de recuperación ante desastres que proporciona completas funciones de recuperación ante desastres para todas las capas de una pila de aplicación, incluidas las capas de infraestructura, el middleware, la base de información y las aplicaciones.

  • 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.

  • 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.

Variante de arquitectura física

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. Esta variante de arquitectura física utiliza un despliegue de Oracle REST Data Services gestionado por el cliente que se ejecuta en cada servidor de aplicaciones.

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.


A continuación se describe mongodb-atp-s-arch-variant.png
Descripción de la ilustración mongodb-atp-s-arch-variant.png

mongodb-atp-s-arch-variant-oracle.zip

A continuación, se muestra el nivel de frontend para la variante:
  • 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 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

Utilice las siguientes recomendaciones como punto de partida para mejorar y desarrollar aún más la carga de trabajo. Sus requisitos pueden diferir de la arquitectura que se describe aquí.

Tenga en cuenta lo siguiente:

  • Despliegue de Aplicación

    Utilice un despliegue basado en contenedor con Oracle Cloud Infrastructure Kubernetes Engine (OKE) si la aplicación se puede ejecutar en contenedores.

  • Seguridad
    • Utilice Oracle 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.
  • Capacidad de Observación
    • Utiliza OCI Audit para realizar auditorías forenses para todos los servicios de OCI más allá de Oracle Autonomous Database Serverless.
    • Utilice OCI Monitoring, OCI Logging y OCI Logging Analytics para tener una visibilidad completa del estado operativo del entorno.
  • Eficiencia operativa
    • Utilice las agrupaciones elásticas si la carga de trabajo JSON sin servidor ATP forma parte de un conjunto de bases de datos más amplio para aumentar la rentabilidad.
    • Active Oracle Cloud Infrastructure Database Management. Este servicio proporciona un conjunto completo de funciones de gestión y supervisión del rendimiento de la base de datos, para optimizar la instancia sin servidor ATP.
  • Evolución de la aplicación
    • Despliegue análisis operativos e informes en tiempo real en ATP Serverless mediante SQL y una interfaz, 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.
    • Utiliza ATP Serverless y Oracle Machine Learning para crear y entrenar modelos con datos JSON sin mover datos y 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 Oracle Autonomous Database Select AI y las vistas de base de datos que consultan JSON y contienen metadatos. Esto permite a los usuarios consultar datos JSON mediante lenguaje natural.
    • Utilice 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 características de esta arquitectura y sobre las arquitecturas relacionadas.

Revise estos recursos adicionales:

Acuses de recibo

  • Autores: José Cruz
  • Contributors: Massimo Castelli, Simon Griffith, Hermann Baer, Matt DeMarco, Julian Dontcheff