Implantar uma Carga de Trabalho Migrada do MongoDB no Oracle Autonomous JSON Database@Azure
Migre uma carga de trabalho existente que use um banco de dados de documentos, neste caso MongoDB, para o Azure e o Oracle Autonomous JSON Database implementados no Azure, um serviço de banco de dados de documentos na nuvem que simplifica a modernização do 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 (Oracle 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
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 Oracle Autonomous JSON Database sem a necessidade de refatorá-lo.
O diagrama a seguir mostra um aplicativo típico composto por camadas de banco de dados, back-end e front-end.
mongodb-ajd-azure-logical-arch-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 Azure e o Autonomous JSON Database.
A migração dessa carga de trabalho para o Azure e o Autonomous JSON Database é simples e consiste, em alto nível, nas seguintes etapas:
- Implante uma instância do Autonomous JSON Database, ativando no momento da criação a API MongoDB do Oracle Database.
- Migre metadados e dados do MongoDB para o Autonomous JSON Database.
- Implante servidores de aplicativos para executar o
Node.jse o Express usando o Azure App Service, VMs, contêineres ou Kubernetes na mesma região e domínio de disponibilidade do Autonomous JSON Database. - Implante o código do aplicativo de back-end nos servidores de aplicativos.
- Conecte o aplicativo de back-end ao Autonomous JSON Database usando as mesmas ferramentas e drivers MongoDB usados no aplicativo atual.
- 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. Um único clique ou chamada de API 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 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 é desenvolvido com base em uma 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. É comum que os usuários queiram realizar análises em cima de dados JSON. O uso de 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. Se seus requisitos de volume de dados mudarem, você poderá facilmente converter para o Oracle Autonomous Database Serverless, que suporta os mesmos recursos. O armazenamento de Views e Views Materializadas não conta para o limite de dados não JSON do Autonomous JSON Database 20 Gb, para 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 o Autonomous JSON Database implantado usando sub-redes delegadas em duas regiões do Microsoft Azure para oferecer suporte à alta disponibilidade. Os serviços da OCI suportam backup automático para o Oracle Cloud Infrastructure Object Storage.
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 é roteada para a região ativa que está executando o aplicativo, usando o Microsoft Azure Front Door.
- A conexão do usuário é protegida usando o Firewall de Aplicativo Web do Azure.
- A conexão do usuário com o aplicativo é balanceada por meio do Serviço de Aplicativo.
- Camada de back-end
- O aplicativo é implantado de forma de alta disponibilidade usando o Azure App Service.
- O Serviço de Aplicativo do Azure AutoScale é usado para obter escalabilidade horizontal.
- 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.
- Use uma estratégia de DR quente para reduzir o RTO geral. Em uma estratégia de DR quente, os recursos de nuvem de camada de back-end já sã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.
- Redes
- Todo o tráfego de entrada de aplicativos do local e da internet é roteado pelo Azure Front Door.
- O Autonomous JSON Database é implantado com um ponto final privado para aumentar a postura de segurança.
- O Azure App Service é um Aplicativo Web implantado usando uma sub-rede de integração e VNet para acessar a instância do Autonomous JSON Database.
- O Aplicativo VNet é pareado com o Banco de Dados VNet, e o tráfego pode fluir entre o Aplicativo Web e o Autonomous JSON Database.
- Segurança
- Todos os dados estão seguros em trânsito e na rest.
- As seguintes melhorias de design em potencial não são descritas nesta implantação para simplificar:
- Automatize a Recuperação de Desastres de aplicativos usando os runbooks do Azure Automation para alternar os pontos finais da Front Door e validar a integridade do aplicativo pós-failover.
- Aproveite uma topologia de hub e spoke para impor a segurança de rede centralizada.
- Aproveite um firewall de rede, implantado no hub VNet, para melhorar a postura de segurança geral, inspecionando todo o tráfego e aplicando políticas.
O diagrama a seguir ilustra essa arquitetura de referência.
mongodb-ajd-azure-physical-arch.zip
A arquitetura tem os seguintes componentes da Microsoft:
- Gerenciador de Firewall do Azure
O Gerenciador de Firewall do Azure é um serviço de gerenciamento de segurança centralizado que simplifica a implantação e a configuração do Firewall do Azure em várias regiões e assinaturas. Ele permite o gerenciamento hierárquico de políticas, permitindo que políticas de firewall globais e locais sejam aplicadas de forma consistente. Quando integrado com o Azure Virtual WAN (vWAN) e um hub seguro, o Azure Firewall Manager aumenta a segurança automatizando o roteamento e a filtragem de tráfego sem a necessidade de rotas definidas pelo usuário. Essa integração garante que o tráfego entre redes virtuais, filiais e internet seja gerenciado e monitorado com segurança, fornecendo uma solução de segurança de rede robusta e simplificada.
- Porta da frente do Azure
O Azure Front Door é um serviço baseado na nuvem que atua como um ponto de entrada global para aplicações web, fornecendo entrega de conteúdo de alto desempenho, balanceamento de carga inteligente da Camada 7 e recursos de segurança integrados, como o Firewall de Aplicativo Web (WAF) e a proteção DDoS, para garantir experiências de usuário rápidas, confiáveis e seguras.
- Região do Azure
Uma região do Azure é uma área geográfica na qual um ou mais data centers físicos do Azure, chamados de zonas de disponibilidade, residem. Regiões são independentes de outras regiões, e grandes distâncias podem separá-las (entre países ou mesmo continentes).
As regiões do Azure e da OCI são áreas geográficas localizadas. Para o Oracle Database@Azure, uma região do Azure é conectada a uma região da OCI, com zonas de disponibilidade (AZs) no Azure conectadas a domínios de disponibilidade (ADs) na OCI. Os pares de regiões do Azure e da OCI são selecionados para minimizar a distância e a latência.
- Zona de disponibilidade do Azure
As zonas de disponibilidade do Azure são locais fisicamente separados dentro de uma região do Azure, projetados para garantir alta disponibilidade e resiliência, fornecendo energia, refrigeração e rede independentes.
- Rede Virtual do Azure (VNet)
A Rede Virtual do Azure (VNet) é o bloco de construção fundamental da sua rede privada no Azure. O VNet permite que muitos tipos de recursos do Azure, como VMs (máquinas virtuais) do Azure, se comuniquem com segurança entre si, com a internet e com redes locais.
- Serviço de Aplicativo do Azure
O Azure App Service é uma plataforma como serviço totalmente gerenciada (PaaS) que permite criar, hospedar e dimensionar aplicativos web, APIs e backends móveis sem gerenciar a infraestrutura subjacente.
- Sub-rede de integração do Azure App Service
Uma sub-rede dedicada dentro de uma Rede Virtual do Azure que é especificamente delegada para uso pelos planos do Serviço de Aplicativo, permitindo que os aplicativos Web façam conexões de saída com recursos privados dentro da rede virtual ou de suas redes pareadas, mas não para receber tráfego de entrada do VNet.
- Sub-rede delegada do Azure
Uma sub-rede delegada permite que você insira um serviço gerenciado, especificamente um serviço de plataforma como serviço (PaaS), diretamente na sua rede virtual como recurso. Você tem o gerenciamento completo da integração de serviços externos PaaS em suas redes virtuais.
A arquitetura tem os seguintes componentes Oracle:
- Região da OCI
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).
- OCI 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 diretamente de aplicativos ou de dentro da plataforma de 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.
- Ponto Final Privado do OCI
O OCI Private Endpoint fornece acesso seguro, privado e sem custo a um dos muitos serviços da OCI de dentro de uma rede virtual na nuvem (VCN) ou rede on-premises.
Variante de Arquitetura
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 a seguir 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 rest da implantação é o mesmo da arquitetura física descrita anteriormente.
mongodb-ajd-azure-arco-variante-oracle.zip
- As solicitações de usuário recebidas são distribuídas pelo balanceador de carga do Serviço de Aplicativo; portanto, a camada front-end é escalável horizontalmente e não tem um único ponto de falha.
- O aplicativo de back-end é implantado nos colaboradores da Unidade de Escala de Serviço de Aplicativo.
- O aplicativo é implantado usando contêiner como método de publicação.
- Crie, instale e configure o contêiner com o aplicativo e o Oracle REST Data Services, que permite que ambos sejam executados no mesmo contêiner.
- Cada colaborador executa a imagem do contêiner que colocaliza o aplicativo e o Oracle REST Data Services no mesmo ambiente de runtime.
- Os colaboradores do Oracle REST Data Services gerenciados pelo cliente são configurados 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ões 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 imagem de contêiner usada nos workers. Quando o Serviço de Aplicativo é dimensionado horizontalmente, novos colaboradores podem executar o aplicativo de back-end e estabelecer conexão com o banco de dados após o provisionamento.
Recomendações
- Implantação do Aplicativo
- Considere o uso de uma implantação baseada em contêiner usando o Azure Kubernetes Service (AKS) se você precisar de recursos avançados de orquestração, rede e segurança que possam não estar disponíveis no App Service.
- Segurança
- Considere usar o Oracle Data Safe para aumentar ainda mais a postura de segurança da carga de trabalho e executar a auditoria do banco de dados.
- Observabilidade
- Considere usar o Azure Monitor para monitorar métricas do Autonomous JSON Database juntamente com todos os outros dados de monitoramento de serviços do Azure.
- Disaster Recovery
- Considere automatizar e orquestrar o desastre e a recuperação de todas as camadas da pilha usando o Azure Site Recovery ou scripts personalizados que detectam falhas e iniciam processos de failover.
- Eficiência Operacional
- Se a carga de trabalho do Autonomous JSON Database fizer parte de uma frota de bancos de dados mais ampla, considere o uso de Pools Elásticos para maior eficiência de custos.
- Considere ativar o Oracle Cloud Infrastructure Database Management, um serviço da OCI que fornece um conjunto abrangente de recursos de gerenciamento e monitoramento de desempenho do banco de dados, para simplificar o gerenciamento da instância do Autonomous JSON Database.
- 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 PowerBI, sem mover dados do banco de dados, para análise de dados confiável e em tempo real
- Considere o uso do 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 para implantar os modelos juntamente com a carga de trabalho existente para inferências eficientes.
- Para casos de uso adicionais além do núcleo do aplicativo, 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) de até 20 Gb para maior funcionalidade e flexibilidade de carga de trabalho.
Explorar Mais
Saiba mais sobre os recursos desta arquitetura:
- Plataforma de Dados da Oracle
- Documentação do Autonomous JSON Database
- Serviços do Autonomous Database para Azure
- Oracle Database API for MongoDB
- Usando o Oracle Autonomous Database sem Servidor
- Migre um Banco de Dados MongoDB em Execução no MongoDB Atlas ou no Local para o Oracle Autonomous JSON Database (tutorial)
Revise estes recursos adicionais: