Implemente uma Carga de Trabalho MongoDB Migrada para o Oracle Autonomous Transaction Processing Serverless@Azure
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 (ATP) 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 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 na nuvem, e será migrada para o Azure e o Oracle Database@Azure. Ele descreve a arquitetura de estado futura, seus benefícios, como ela pode ser implantada e quais recursos adicionais você pode usar para aumentar a carga de trabalho existente.
Um dos principais recursos usados nessa arquitetura é a Oracle Database API for 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 aplicativo existente pode trabalhar com dados armazenados no Oracle Autonomous Transaction Processing sem servidor, sem a necessidade de refatorar o código.
O diagrama a seguir mostra um aplicativo típico composto por camadas de banco de dados, back-end e front-end.
mongodb-atp-s-azure-logical-arch-migration.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 documento usa uma pilha MEAN como exemplo de uma implantação existente que será migrada para o Azure e para o ATP Serverless.
A migração dessa carga de trabalho para o Azure e o ATP Serverless é simples e consiste, em alto nível, nas seguintes etapas:
- Implantar uma instância sem Servidor ATP, ativando no momento da criação a API MongoDB do Oracle Database.
- Migre metadados e dados de MongoDB para o ATP Serverless.
- Implante servidores de aplicativos para executar o
Node.jse o Express usando o Azure App Service, VMs, contêineres ou o Kubernetes, na mesma região e domínio de disponibilidade do ATP Serverless. - Implante o código do aplicativo de back-end nos servidores de aplicativos.
- Conecte o aplicativo de back-end ao ATP Serverless usando as mesmas ferramentas e drivers MongoDB usados no aplicativo atual.
- Conecte usuários 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 ATP Serverless, vários recursos estarã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 sem servidor do Autonomous Transaction Processing. 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 os Conjuntos de Escalonamento de VM do Azure com configuração de Dimensionamento Automático ou um serviço PaaS, como o Serviço de Aplicativo com configuração de Dimensionamento Automático, para permitir alta disponibilidade e escalabilidade do aplicativo.
Como o ATP 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 o Autonomous Transaction Processing Serverless implantado usando sub-redes delegadas em duas regiões do 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 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 Serviço de Aplicativo do Azure.
- O Serviço de Aplicativo AutoScale do Azure é usado para obter escalabilidade horizontal.
- Camada de banco de dados
- O ATP Serverless fornece alta disponibilidade, como o 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.
- O Oracle Database API for MongoDB ativado no ATP Serverless permite que você use o código de aplicativo existente sem alterações.
- A API do Oracle Database API for 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 por meio do Autonomous Data Guard entre regiões.
- Disaster Recovery
- 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 ATP Serverless.
- 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 ATP Serverless é implantado com um ponto final privado para aumentar a postura de segurança.
- O Aplicativo Web do Azure App Service é implantado usando uma sub-rede de integração e VNet para acessar a instância ATP Serverless.
- O Aplicativo VNet é pareado com o Banco de Dados VNet, e o tráfego pode fluir entre o Aplicativo Web e o ATP Serverless.
- Segurança
- Todos os dados estão seguros em trânsito e em repouso.
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.
mongodb-atp-s-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 em nuvem que atua como um ponto de entrada global para aplicativos 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 Microsoft Azure
O Microsoft Azure App Service permite que você crie, hospede e dimensione aplicativos web, APIs e back-ends 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).
- Oracle Autonomous Database
O Oracle Autonomous Database é um ambiente de banco de dados pré-configurado e totalmente gerenciado que você pode usar para cargas de trabalho de processamento de transações e data warehousing. Você não precisa configurar nem gerenciar nenhum hardware, nem instalar nenhum software. A OCI lida com a criação, o backup, a aplicação de patches, o upgrade e o ajuste do banco de dados.
- Oracle Autonomous Data Guard
O Oracle Autonomous Data Guard permite que um banco de dados stand-by (par) forneça proteção de dados e recuperação de desastres para sua instância do Autonomous Database. Ele fornece um conjunto abrangente de serviços que criam, mantêm, gerenciam e monitoram um ou mais banco de dados stand-by para que os bancos de dados Oracle de produção permaneçam disponíveis sem interrupção. O Oracle Data Guard mantém esses banco de dados stand-by como cópias do banco de dados da produção. Em seguida, se o banco de dados de produção ficar indisponível por causa de uma interrupção planejada ou não planejada, você poderá alternar qualquer banco de dados stand-by para a atribuição de produção, minimizando o tempo de inatividade associado à interrupção.
- 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
Esta variante da arquitetura física proposta usa uma implantação do Oracle REST Data Services gerenciada pelo cliente em execução em cada servidor de aplicativos. No entanto, 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.
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 restante da implantação é igual à arquitetura física descrita anteriormente.
mongodb-atp-s-azure-arch-variant.zip
- As solicitações de usuário recebidas são distribuídas pelo balanceador de carga do Serviço de Aplicativo, de forma que a camada front-end seja escalável horizontalmente e não tenha 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 Monitor do Azure para monitorar métricas ATP Serverless 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 ATP Serverless fizer parte de uma frota de banco de dados mais ampla, considere o uso de Pools Elásticos para aumentar a 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 de banco de dados, para agilizar o gerenciamento da instância ATP Serverless.
- Evolução do Aplicativo
- Considere implementar análises operacionais e relatórios em tempo real no ATP Serverless 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 usar o ATP Serverless para machine learning usando o Oracle Machine Learning (OML), para criar e treinar modelos com dados JSON sem qualquer necessidade de movimentação de dados e para implantar os modelos juntamente com a carga de trabalho existente para uma inferência eficiente.
- Para casos de uso adicionais além do núcleo da aplicação, considere o uso de views ATP Serverless Select AI e de banco de dados consultando JSON e mantendo metadados, para que os usuários possam consultar dados JSON usando linguagem natural.
- Considere usar o ATP Serverless para armazenar tipos de dados adicionais (relacional, vetorial, espacial ou gráfico) para aumentar a funcionalidade e a flexibilidade da carga de trabalho.
Explorar Mais
Saiba mais sobre os recursos desta arquitetura:
Revise estes recursos adicionais:
- Plataforma de Dados da Oracle
- Documentação do Oracle Autonomous Transaction Processing Serverless
- Serviços do Autonomous Database para Azure
- Oracle Database API for MongoDB
- Usando o Oracle Autonomous Database sem Servidor
Revise estes recursos adicionais: