Implantar uma Carga de Trabalho Migrada do MongoDB no Oracle Autonomous JSON Database

Migre uma carga de trabalho existente que use um banco de dados de documentos, neste caso MongoDB, para o Oracle Autonomous JSON Database na Oracle Cloud Infrastructure (OCI) para modernizar o desenvolvimento de seus aplicativos centrados em JSON.

Cargas de trabalho e aplicativos que usam documentos e bancos de dados de documentos para evoluir esquemas de dados e aplicativos são bastante populares devido à flexibilidade que oferecem aos desenvolvedores. A flexibilidade do esquema, o desenvolvimento rápido e a escalabilidade permitem a prototipagem rápida de recursos de aplicativos, a evolução mais fácil dos aplicativos e a garantia 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 pudessem se beneficiar de todas as vantagens dos bancos de dados de documentos tradicionais, mas, ao mesmo tempo, aproveitar os benefícios dos bancos de dados relacionais? Por exemplo, tenha garantias transacionais mais fortes e use funcionalidades adicionais, como análise e machine learning, sem a necessidade de replicar dados para outro banco de dados ou sistema.

O Autonomous JSON Database apresenta APIs de documentos no estilo NoSQL (Simple Oracle Document Access (SODA) e Oracle Database API for MongoDB), dimensionamento sem servidor, transações ACID de alto desempenho, segurança abrangente e baixo preço de pagamento por uso. O Autonomous JSON Database automatiza o provisionamento, a configuração, o ajuste, o dimensionamento, a aplicação de patches, a criptografia e o reparo de bancos de dados, eliminando o gerenciamento de banco de dados e fornecendo 99,95% de disponibilidade.

Arquitetura Funcional

Essa arquitetura pressupõe, como ponto de partida, que existe uma carga de trabalho com um aplicativo e um banco de dados MongoDB, seja uma implantação local ou em nuvem, e será migrada para a OCI. Ele descreve a arquitetura de estado futura, seus benefícios, como ela pode ser implantada e quais recursos adicionais podem ser usados para aumentar a carga de trabalho existente.

Um dos principais recursos 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. O código de aplicativos existente pode funcionar com dados armazenados no Autonomous JSON Database, sem a necessidade de refatorá-lo.

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



mongodb-json-logical-arch-migration-oracle.zip

Uma pilha popular, usada para implementar esse padrão, é a pilha MEAN, usando MongoDB como o banco de dados de documentos, Express como a estrutura de back-end, Angular como a estrutura de front-end e Node.js como o servidor de back-end. Este documento usa uma pilha MEAN como exemplo de uma implantação existente que será migrada para o OCI e o Autonomous JSON Database.

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

  1. Implantar uma instância do Autonomous JSON Database, ativando no momento da criação a API de BD Mongo do Oracle Database
  2. Migre metadados e dados do MongoDB para o Autonomous JSON Database.
  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 Autonomous JSON Database.
  4. Implante o código do aplicativo de back-end nos servidores de aplicativos.
  5. Conecte o aplicativo de back-end ao Autonomous JSON Database usando as mesmas ferramentas e drivers MongoDB usados no aplicativo atual.
  6. Faça com que os usuários se conectem ao novo URI do aplicativo.

Observe que 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.

Depois que a carga de trabalho for migrada para o Autonomous JSON Database, você poderá usar vários recursos para aumentar a funcionalidade existente, seja para 1) oferecer suporte a requisitos não funcionais adicionais, como facilmente melhorar 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 JSON Database, que com um único clique ou chamada de API, permite que a carga de trabalho use até 3 vezes a capacidade da linha de base, sem tempo de inatividade. Observe que o Autonomous JSON Database usa a tecnologia Oracle Real Application Clusters (Oracle RAC) para alta disponibilidade. Para a camada de back-end, use pools de instâncias de computação, com regras de dimensionamento automático, permitindo, assim, alta disponibilidade e escalabilidade do aplicativo.

Como o Autonomous JSON Database é construído com base em uma tecnologia de banco de dados multimodelo e com várias cargas de trabalho, recursos adicionais que dependem de tipos de dados relacionais, espaciais, gráficos ou vetoriais podem ser adicionados, trabalhando ao lado do aplicativo existente. É comum que os usuários queiram realizar análises com base em dados JSON e usar SQL no Autonomous JSON Database, simplifica a criação de relatórios operacionais e analíticos, usando o mesmo mecanismo e dados.

O Autonomous JSON Database tem um limite de 20 Gb de dados não JSON, mas pode ser facilmente convertido para o Autonomous Transaction Processing Serverless, oferecendo suporte aos mesmos recursos, se os requisitos de volume de dados mudarem. Observe que o armazenamento de Views e Views Materializadas não conta para o limite de dados não JSON do Autonomous JSON Database 20 Gb, de modo que eles possam ser facilmente criados e usados, por exemplo, para oferecer suporte à análise operacional usando SQL em cima de documentos JSON.

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 usando um Firewall de Aplicativo Web
    • 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 do Autonomous JSON Database, para ter co-localização de aplicativo e banco de dados, otimizando assim a latência da 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 Autonomous JSON Database é colocado, a fim de aumentar a resiliência da carga de trabalho
  • Camada de banco de dados
    • O Autonomous JSON Database fornece alta disponibilidade como Oracle Real Application Clusters (Oracle RAC) e vários nós de banco de dados 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 Autonomous JSON Database 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 Autonomous JSON Database.
    • O Autonomous JSON Database pode usar o dimensionamento automático, ajustando-se a aumentos e diminuições da carga do sistema.
    • A continuidade dos negócios do Autonomous JSON Database é obtida por meio da recuperação de desastres entre regiões baseada em backup. Como alternativa, você pode usar clones atualizáveis.
  • Disaster Recovery
    • Duas regiões suportam a recuperação de desastres entre regiões para toda a implementação da nuvem.
    • O Autonomous JSON Database na região principal tem um pareamento entre regiões baseado em backup na região secundária.
    • A segunda região é implantada com uma topologia semelhante para reduzir o objetivo geral de tempo de recuperação.
    • Para reduzir o RTO geral, você pode usar uma estratégia de DR quente, em que os recursos de nuvem de camada de back-end já estão provisionados, juntamente com o banco de dados stand-by Autonomous JSON Database.
    • Como alternativa, você pode provisionar os recursos de camada de back-end em caso de falha, diminuindo o custo de execução dos recursos de DR, mas aumentando o RTO geral.
    • As possíveis melhorias de design não descritas nesta implantação por motivos de simplicidade incluem o uso do OCI Full Stack Disaster Recovery para automatizar a recuperação de desastres para o balanceador de carga e a camada de back-end.
  • Redes
    • Os Gateways de Roteamento Dinâmico implantados em ambas as regiões são pareados.
    • A conectividade on-premises aproveita o OCI 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.

O diagrama a seguir ilustra essa arquitetura.



mongodb-json-physical-arch-oracle.zip

A arquitetura tem os seguintes componentes:

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

  • Servidor de aplicativos

    Os servidores de aplicativos usam um par secundário que, como o banco de dados, assumirá o processamento em caso de desastre. Os servidores de aplicativos usam configuração e metadados armazenados no banco de dados e no sistema de arquivos. A clusterização do servidor de aplicativos fornece proteção no escopo de uma única região, mas as modificações contínuas e novas implantações precisam ser replicadas para o local secundário em uma base contínua para uma recuperação de desastres consistente.

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

  • Autonomous JSON Database

    O Oracle Autonomous JSON Database é um serviço de banco de dados de documentos em nuvem que simplifica o crescimento de aplicativos centrados em JSON. Ele apresenta APIs de documentos simples, dimensionamento sem servidor, transações ACID de alto desempenho, segurança abrangente e baixo preço de pagamento por uso. O Autonomous JSON Database automatiza o provisionamento, a configuração, o ajuste, o dimensionamento, a aplicação de patches, a criptografia e o reparo do banco de dados.

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

Variante de Arquitetura

A API MongoDB totalmente gerenciada fornecida pelo Autonomous JSON Database é a melhor solução para a maioria das cargas de trabalho, pois é mais fácil de gerenciar.

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.



mongodb-json-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.
  • VCN

    Ao criar uma VCN, determine o número de blocos CIDR necessários e o tamanho de cada bloco com base no número de recursos que você planeja anexar às sub-redes na VCN. Use blocos CIDR que estejam dentro do espaço de endereço IP privado padrão.

    Selecione blocos CIDR que não se sobreponham a qualquer outra rede (no Oracle Cloud Infrastructure, seu data center on-premises ou outro provedor de nuvem) para a qual você pretende configurar conexões privadas.

    Depois de criar uma VCN, você poderá alterar, adicionar e remover seus blocos CIDR.

    Ao projetar as sub-redes, considere o fluxo de tráfego e os requisitos de segurança. Anexe todos os recursos dentro de uma camada ou atribuição específica à mesma sub-rede, que pode servir como um limite de segurança.

  • Implantação do Aplicativo

    Considere usar uma implantação baseada em contêiner usando o Oracle Kubernetes Engine (OKE) se o aplicativo puder ser executado em contêineres.

  • Segurança

    Considere usar o Data Safe para aumentar ainda mais a postura de segurança da carga de trabalho e ser capaz de executar a auditoria do banco de dados.

  • Observabilidade
    • Considere usar o OCI Audit para executar auditoria forense para todos os serviços do OCI além do Autonomous JSON Database.
    • Considere usar o Monitoring, Logging e o Logging Analytics para ter total visibilidade do status operacional do ambiente.
  • Disaster Recovery

    Considere usar o OCI Full Stack Disaster Recovery para automatizar e orquestrar o desastre e a recuperação de todas as camadas da pilha.

  • Eficiência Operacional
    • Considere o uso de Elastic Pools se a carga de trabalho Autonomous JSON fizer parte de uma frota de bancos de dados mais ampla, para maior eficiência de custos.
    • Considere ativar o Database Management, um serviço da OCI que fornece um conjunto abrangente de recursos de monitoramento e gerenciamento de desempenho de banco de dados, para simplificar o gerenciamento de instâncias do AJD.
  • Evolução do Aplicativo
    • Considere implementar análises operacionais e relatórios em tempo real no Autonomous JSON Database usando SQL e um front-end, como APEX ou Oracle Analytics Cloud, sem mover dados do banco de dados, para análise de dados confiável e em tempo real
    • Considere usar o Autonomous JSON Database para machine learning usando o Oracle Machine Learning (OML), para criar e treinar modelos com dados JSON sem necessidade de movimentação de dados e 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 do Autonomous JSON Database. Selecione views de IA e banco de dados consultando JSON e mantendo metadados, para que os usuários possam consultar dados JSON usando linguagem natural
    • Considere o uso do Autonomous JSON Database para armazenar tipos de dados adicionais (relacional, vetorial, espacial ou gráfico), até 20 Gb, para maior funcionalidade e flexibilidade de carga de trabalho.

Confirmações

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