Implante uma Carga de Trabalho Migrada do MongoDB no Oracle Autonomous Transaction Processing Serverless

Migre uma carga de trabalho existente que use um banco de dados de documentos, neste caso MongoDB, para o banco de dados Oracle Autonomous Transaction Processing Serverless (ATP Serverless) na Oracle Cloud Infrastructure (OCI) para modernizar o desenvolvimento de seus aplicativos centrados em JSON juntamente com outras cargas de trabalho multimodelo.

Cargas de trabalho e aplicativos que usam documentos e bancos de dados de documentos para evoluir esquemas de dados e aplicativos são populares devido à flexibilidade que oferecem aos desenvolvedores. A flexibilidade do esquema, o desenvolvimento rápido e a escalabilidade permitem a prototipagem acelerada de recursos de aplicativos, a evolução mais fácil dos aplicativos e a capacidade de criar aplicativos e recursos iterativamente menores que os desenvolvedores podem dimensionar para atender a uma grande base de usuários. No entanto, esses tipos de cargas de trabalho têm seus desafios, incluindo garantias transacionais mais fracas, versatilidade de consulta de dados e incapacidade de suportar outras cargas de trabalho em documentos, como análise ou machine learning.

E se essas cargas de trabalho puderem se beneficiar das vantagens dos bancos de dados de documentos tradicionais e aproveitar os benefícios dos bancos de dados relacionais? Por exemplo, tenha garantias transacionais mais fortes e funcionalidades adicionais, como análise e machine learning, sem a necessidade de replicar dados para outro banco de dados ou sistema.

O Autonomous Transaction Processing Serverless é um serviço de banco de dados totalmente automatizado otimizado para executar cargas de trabalho transacionais, analíticas e em lote simultaneamente. Para acelerar o desempenho, ele é pré-configurado para formato de linha, índices e armazenamento em cache de dados, fornecendo escalabilidade, disponibilidade, segurança transparente e análise operacional em tempo real. Desenvolvedores de aplicativos e DBAs podem desenvolver e implantar aplicativos de forma rápida e econômica sem sacrificar a funcionalidade ou as propriedades de atomicidade, consistência, isolamento e durabilidade (ACID).

Arquitetura Funcional

Essa arquitetura de referência pressupõe que você tenha uma carga de trabalho com um aplicativo e um banco de dados MongoDB, on-premises ou na nuvem, e migrará para a OCI. Ele descreve a arquitetura de estado futura, seus benefícios, como você pode implantá-la e quais recursos adicionais você pode usar para aumentar a carga de trabalho existente.

Essa arquitetura de referência se concentra na implantação da carga de trabalho migrada e não no próprio processo de migração. Para obter mais detalhes sobre o processo de migração, consulte a seção Explorar Mais.

Um dos principais produtos usados nessa arquitetura é a API do Oracle Database para MongoDB, que permite que os aplicativos interajam com coleções de documentos JSON no Oracle Database usando drivers, ferramentas e SDKs MongoDB. Isso permite que o código do aplicativo existente funcione com dados armazenados no Autonomous Transaction Processing Serverless (ATP Serverless) sem a necessidade de refatorar o código.

O diagrama a seguir descreve um aplicativo típico composto por camadas de banco de dados, back-end e front-end.


Veja a seguir a descrição da instrução mongodb-atp-s-logical-arch-migration.png
Descrição da ilustração mongodb-atp-s-logical-arcomigration.png

mongodb-atp-s-logical-arch-migration-oracle.zip

A pilha MEAN é uma pilha popular usada para implementar este padrão:
  • MongoDB: Banco de dados de documentos
  • Express: Estrutura de back-end
  • Angular: Estrutura front-end
  • Node.js: Servidor de backend

Este exemplo usa uma pilha MEAN para migrar uma implantação existente para o OCI e o ATP Serverless.

A migração dessa carga de trabalho para a OCI e ATP Serverless é simples e consiste, em alto nível, nas seguintes etapas:

  1. Implante uma instância ATP Serverless, ativando no momento da criação a API de BD Mongo do Oracle Database.
  2. Migre metadados e dados do MongoDB para o ATP Serverless.
  3. Implante servidores de aplicativos para executar o Node.js e o Express usando VMs, contêineres ou Kubernetes, na mesma região e domínio de disponibilidade do ATP Serverless.
  4. Implante o código do aplicativo de back-end nos servidores de aplicativos.
  5. Conecte o aplicativo de back-end ao ATP Serverless usando as mesmas ferramentas e drivers MongoDB usados no aplicativo atual.
  6. Conecte usuários ao novo URI do aplicativo.

Após a migração da carga de trabalho para o ATP Serverless, vários recursos estão disponíveis para aumentar a funcionalidade existente, seja para 1) oferecer suporte a requisitos não funcionais adicionais, como melhorar facilmente a escalabilidade, a resiliência ou a alta disponibilidade ou 2) ter recursos funcionais adicionais, como relatórios operacionais, análises e machine learning, sem a necessidade de copiar dados do banco de dados.

Para melhorar a escalabilidade e a alta disponibilidade, use o recurso de dimensionamento automático do Autonomous Transaction Processing Serverless. Com um único clique ou chamada de API, ela permite que a carga de trabalho use até 3 vezes a capacidade da linha de base sem qualquer tempo de inatividade. Observe que o Autonomous Transaction Processing Serverless usa a tecnologia Oracle Real Application Clusters (Oracle RAC) para alta disponibilidade. Para a camada de backend, use pools de instâncias de computação com regras de dimensionamento automático para permitir alta disponibilidade e escalabilidade do aplicativo.

Como o Autonomous Transaction Processing Serverless é desenvolvido com base na tecnologia de banco de dados multimodelo e com várias cargas de trabalho, você pode adicionar recursos que dependem de tipos de dados relacionais, espaciais, gráficos ou vetoriais que funcionam ao lado do aplicativo existente.

Arquitetura Física

A arquitetura física inclui sub-redes públicas e privadas na OCI com uma região de backup secundária para oferecer suporte à alta disponibilidade.

A arquitetura suporta o seguinte:

  • Camada front-end
    • Os usuários do aplicativo podem se conectar pela internet ou pela rede corporativa.
    • A conexão do usuário é protegida por meio de um OCI Web Application Firewall.
    • A conexão do usuário com o aplicativo é balanceada para maior resiliência e escalabilidade.
    • O balanceador de carga é implantado com alta disponibilidade.
  • Camada de back-end
    • Os servidores de aplicativos são implantados de forma de alta disponibilidade usando um pool de instâncias.
    • O Pool de Instâncias é usado com dimensionamento automático para obter escalabilidade horizontal.
    • O Pool de Instâncias está configurado para implantar instâncias no mesmo Domínio de Disponibilidade que o ATP Serverless, para ter co-localização de aplicativo e banco de dados, otimizando assim a latência de conexão.
    • O Pool de Instâncias está configurado para distribuir instâncias entre domínios de falha no mesmo domínio de disponibilidade em que o ATP Serverless é colocado, a fim de aumentar a resiliência da carga de trabalho.
  • Camada de banco de dados
    • O ATP Serverless fornece alta disponibilidade como Oracle Real Application Clusters (Oracle RAC) e vários nós de banco de dados que sustentam a instância de serviço. Portanto, por padrão, a camada de banco de dados é altamente disponível e resiliente.
    • A API do Oracle Database para MongoDB ativada no ATP Serverless permite que você use o código de aplicativo existente sem alterações.
    • A API do Oracle Database para MongoDB é altamente resiliente e essa resiliência é garantida internamente pelo ATP Serverless.
    • O ATP Serverless pode usar dimensionamento automático, ajustando-se a aumentos e diminuições da carga do sistema.
    • A continuidade dos negócios do ATP Serverless é obtida com a recuperação de desastres entre regiões baseada no Oracle Autonomous Data Guard.
    • O RTO (Standby Recovery Time Objective) entre regiões do Oracle Autonomous Data Guard é quinze minutos e o RPO (Recovery Point Objective) é um minuto.
  • Recuperação de desastre
    • Duas regiões suportam a recuperação de desastres entre regiões para toda a implementação da nuvem.
    • A região stand-by suporta um stand-by quente em que as instâncias de nuvem são pré-implantadas para reduzir o RTO (Total Recovery Time Objective).
    • O ATP Serverless na região principal tem um par entre regiões do Oracle Autonomous Data Guard na região stand-by
    • O pool de instâncias da camada de backend é pré-configurado com uma quantidade mínima de instâncias no pool, e o plano de DR OCI Full Stack Disaster Recovery, que automatiza cada etapa do failover, pode alterar o número de instâncias de computação que devem ser executadas após o failover. A configuração de dimensionamento automático baseada em métrica é definida para determinar o número mínimo e máximo de instâncias no pool, bem como as métricas usadas para ampliação e inclusão.
    • A região stand-by é implantada com uma topologia semelhante para reduzir o objetivo geral de tempo de recuperação.
    • O OCI Full Stack Disaster Recovery automatiza o failover de toda a pilha para a região stand-by e os fallbacks para a região principal.
  • Redes
    • Os gateways de roteamento dinâmico implantados em ambas as regiões são pareados.
    • A conectividade local utiliza o Oracle Cloud Infrastructure FastConnect e a VPN site a site para obter redundância.
    • Todo o tráfego de entrada do local e da internet é primeiro roteado para a VCN hub e depois para a VCN de carga de trabalho.
    • Usa um design de rede hub e spoke para aumentar a postura de segurança e acomodar outras VCNs de carga de trabalho.
    • Serviços são implantados com pontos finais privados para aumentar a postura de segurança.
    • A VCN de carga de trabalho JSON é segregada em várias sub-redes privadas para aumentar a postura de segurança.
  • Segurança
    • Todos os dados estão seguros em trânsito e em repouso.
    • Os possíveis aprimoramentos de design não descritos nesta implantação por motivos de simplicidade incluem o uso de uma zona de destino compatível com o CIS e o aproveitamento de um firewall de rede implantado na VCN hub. Um firewall de rede melhorará a postura de segurança geral, inspecionando todo o tráfego e aplicando políticas.

Veja a seguir a descrição da instrução mongodb-atp-s-physical-arch.png
Descrição da ilustração mongodb-atp-s-physical-arch.png

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

A arquitetura tem os seguintes componentes principais:

  • Região

    Uma região do OCI é uma área geográfica localizada que contém um ou mais data centers, hospedando domínios de disponibilidade. Regiões são independentes de outras regiões, e grandes distâncias podem separá-las (entre países ou mesmo continentes).

  • VCN (rede virtual na nuvem) e sub-redes

    Uma VCN é uma rede personalizável e definida por software que você configura em uma região da OCI. Assim como as redes tradicionais do data center, as VCNs dão a você controle sobre seu ambiente de rede. Uma VCN pode ter vários blocos de CIDR (Classless Inter-domain Routing) não sobrepostos que você pode alterar após criar a VCN. Você pode segmentar uma VCN em sub-redes, com escopo definido para uma região ou para um domínio de disponibilidade. Cada sub-rede consiste em um intervalo contíguo de endereços que não se sobrepõem a outras sub-redes da VCN. Você pode alterar o tamanho de uma sub-rede após a criação. Uma sub-rede pode ser pública ou privada.

  • FastConnect

    O Oracle Cloud Infrastructure FastConnect cria uma conexão privada dedicada entre seu data center e a OCI. FastConnect fornece opções mais altas de largura de banda e uma experiência em rede mais confiável quando comparada com conexões baseadas na internet.

  • Gateway de roteamento dinâmico (DRG)

    O DRG é um roteador virtual que fornece um caminho para tráfego de rede privada entre VCNs na mesma região, entre uma VCN e uma rede fora da região, como uma VCN em outra região do OCI, uma rede on-premises ou uma rede em outro provedor de nuvem.

  • Gateway de tradução de endereço de rede (NAT)

    Um gateway NAT permite que recursos privados em uma VCN acessem hosts na internet, sem expor esses recursos a conexões de internet de entrada.

  • Gateway de serviço

    Um gateway de serviço fornece acesso de uma VCN a outros serviços, como o Oracle Cloud Infrastructure Object Storage. O tráfego da VCN para o serviço Oracle atravessa a malha de rede Oracle e não atravessa a internet.

  • Gateway de internet

    Um gateway de internet permite o tráfego entre as sub-redes públicas em uma VCN e a internet pública.

  • Balanceador de carga

    O Oracle Cloud Infrastructure Load Balancing fornece distribuição automatizada de tráfego de um único ponto de entrada para vários servidores.

  • Firewall do Aplicativo Web

    O Oracle Cloud Infrastructure Web Application Firewall (WAF) é uma aplicação de borda, baseada em regional e compatível com o setor de cartões de pagamento (PCI) anexada a um ponto de imposição, como um balanceador de carga ou um nome do domínio do aplicativo Web. O WAF protege aplicativos contra tráfego mal-intencionado e indesejado na internet. O WAF pode proteger qualquer ponto final voltado para internet, fornecendo uma aplicação consistente de regra entre seus aplicativos.

  • Oracle Autonomous Transaction Processing Serverless

    O Oracle Autonomous Transaction Processing Serverless é um serviço de banco de dados totalmente automatizado otimizado para executar cargas de trabalho transacionais, analíticas e em lote simultaneamente. Para acelerar o desempenho, ele é pré-configurado para formato de linha, índices e armazenamento em cache de dados, fornecendo escalabilidade, disponibilidade, segurança transparente e análise operacional em tempo real. Desenvolvedores de aplicativos e DBAs podem desenvolver e implantar aplicativos de forma rápida, fácil e econômica sem sacrificar a funcionalidade ou as propriedades de atomicidade, consistência, isolamento e durabilidade (ACID).

  • Full Stack Disaster Recovery

    O Oracle Cloud Infrastructure Full Stack Disaster Recovery é um serviço da orquestração e do gerenciamento que fornece recursos abrangentes da recuperação do desastre para todas as camadas de uma pilha do aplicativo, incluindo infraestrutura, middleware, bancos de dados e aplicativo.

  • Object Storage

    O OCI Object Storage oferece acesso a grandes quantidades de dados estruturados e não estruturados de qualquer tipo de conteúdo, incluindo backups de banco de dados, dados analíticos e conteúdo avançado como imagens e vídeos. Você pode armazenar dados com segurança e diretamente da internet ou de dentro da plataforma na nuvem. Você pode dimensionar o armazenamento sem sofrer qualquer degradação no desempenho ou na confiabilidade de serviço.

    Use armazenamento padrão para armazenamento "quente" que você precisa acessar com rapidez, rapidez e frequência. Use armazenamento de arquivo compactado para armazenamento "frio" que você retém por longos períodos de tempo e acesso raro.

  • Oracle Database API for MongoDB

    A API do Oracle Database para MongoDB permite que os aplicativos interajam com coleções de documentos JSON no Oracle Database usando drivers, ferramentas e SDKs MongoDB.

Variante de Arquitetura Física

A API MongoDB totalmente gerenciada fornecida pelo ATP Serverless é a melhor solução para a maioria das cargas de trabalho, pois é mais fácil de gerenciar. Essa variante de arquitetura física usa uma implantação do Oracle REST Data Services gerenciada pelo cliente em execução em cada servidor de aplicativos.

Se houver requisitos para controlar manualmente a configuração e o gerenciamento do Oracle REST Data Services, o uso do Oracle REST Data Services gerenciado pelo cliente será uma opção. Por exemplo, para permitir que o aplicativo use pools de conexões maiores.

Observação:

Use essa variante de arquitetura se houver um requisito de carga de trabalho específico para isso. Somente usuários avançados devem implantar esta variante de arquitetura.

Esta seção descreve apenas as diferenças em comparação com a arquitetura física descrita anteriormente, portanto, todos os princípios de design de arquitetura física são válidos, salvo indicação em contrário.

O diagrama de arquitetura abaixo mostra como a variante é implantada. Para simplificar, apenas os recursos de nuvem implantados na VCN de Carga de Trabalho JSON são representados, pois o restante da implantação é o mesmo descrito antes.


Veja a seguir a descrição da instrução mongodb-atp-s-arch-variant.png
Descrição da ilustração mongodb-atp-s-arch-variant.png

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

Veja a seguir a camada front-end da variante:
  • O código do aplicativo de back-end é implantado em servidores de aplicativos que fazem parte de um pool de instâncias.
  • As solicitações de usuário recebidas são distribuídas pelo balanceador de carga, de modo que a camada front-end é escalável horizontalmente e não tem um único ponto de falha.
  • O Oracle REST Data Services gerenciado pelo cliente é instalado em cada servidor de aplicativos e configurado para ativar a API MongoDB, para que o aplicativo possa se conectar ao banco de dados usando ferramentas e drivers MongoDB.
  • O Oracle REST Data Services gerenciado pelo cliente é configurado para se ajustar aos requisitos não funcionais da carga de trabalho, por exemplo, configurando pools de conexão maiores ou usando outro serviço de banco de dados.
  • Tanto o código de back-end quanto o Oracle REST Data Services gerenciado pelo cliente são pré-instalados e pré-configurados na configuração de instância usada pelo pool, de modo que, sempre que uma instância for adicionada ao pool, ela poderá executar o back-end e estabelecer conexão com o banco de dados, após o provisionamento da instância.

Recomendações

Use as recomendações a seguir como ponto de partida para melhorar e desenvolver ainda mais a carga de trabalho. Seus requisitos podem ser diferentes da arquitetura descrita aqui.

Considere o seguinte:

  • Implantação do Aplicativo

    Use uma implantação baseada em contêiner com o Oracle Cloud Infrastructure Kubernetes Engine (OKE) se o aplicativo puder ser executado em contêineres.

  • Segurança
    • Use o Oracle Data Safe para aumentar ainda mais a postura de segurança da carga de trabalho e ser capaz de executar auditoria de banco de dados.
  • Observabilidade
    • Use o OCI Audit para executar auditoria forense para todos os serviços da OCI além do Oracle Autonomous Database Serverless.
    • Use o OCI Monitoring, o OCI Logging e o OCI Logging Analytics para ter total visibilidade do status operacional do ambiente.
  • Eficiência Operacional
    • Use Pools Elásticos se a carga de trabalho JSON sem Servidor ATP fizer parte de uma frota de banco de dados mais ampla para maior eficiência de custos.
    • Ative o Oracle Cloud Infrastructure Database Management. Este serviço fornece um conjunto abrangente de recursos de gerenciamento e monitoramento de desempenho do banco de dados, para agilizar a instância ATP Serverless.
  • Evolução do Aplicativo
    • Implemente análises operacionais e relatórios em tempo real no ATP Serverless usando SQL e um frontend, como APEX ou Oracle Analytics Cloud, sem mover dados do banco de dados para análise de dados confiável e em tempo real.
    • Use o ATP Serverless e o Oracle Machine Learning para criar e treinar modelos com dados JSON sem mover dados e para implantar os modelos juntamente com a carga de trabalho existente para inferência eficiente.
    • Para casos de uso adicionais além do núcleo da aplicação, considere o uso de views do Oracle Autonomous Database Select AI e do banco de dados consultando JSON e mantendo metadados. Isso permite que os usuários consultem dados JSON usando linguagem natural.
    • Use o ATP Serverless para armazenar tipos de dados adicionais (relacional, vetorial, espacial ou gráfico) para maior funcionalidade e flexibilidade de carga de trabalho.

Explorar Mais

Saiba mais sobre os recursos desta arquitetura e sobre arquiteturas relacionadas.

Revise estes recursos adicionais:

Confirmações

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