Arquiteturas de dados em tempo real com o MongoDB Cloud Manager e o Verizon 5G Edge
.png&w=3840&q=75)
Ado Kukic, Robert Belson8 min read • Published Aug 12, 2021 • Updated Aug 28, 2024
Avalie esse Tutorial
A borda da rede tem sido uma das oportunidades de cloud computing mais explosivas dos últimos anos. À medida que as experiências móveis sem contacto se tornam a norma e as empresas migram cada vez mais rapidamente para plataformas e serviços digitais, a edge computing posiciona-se como uma alternativa mais rápida, mais barata e mais fiável para processamento de dados e computação em escala.
Embora os dispositivos móveis continuem a aumentar seus recursos de hardware com GPUs integradas, chipsets personalizados e mais armazenamento, até mesmo os dispositivos mais avançados sofrerão o mesmo problema fundamental: cada dispositivo serve como um único ponto de falha e, portanto, não pode servir efetivamente como uma camada de armazenamento de dados persistente. Dito de outra forma, não seria bom ter a alta disponibilidade da nuvem, mas com a distância topológica até os usuários finais do smartphone?
A computação móvel de ponta promete resolver esse problema com precisão, trazendo a computação de baixa latência para a borda das redes com a alta disponibilidade e a escala da cloud. Por meio do 5G Edge da Verizon com o AWS Wavelength, vimos a oportunidade de explorar como aproveitar os fluxos de trabalho atuais de computação intensiva e sobrepor uma camada de persistência de dados ao MongoDB, utilizando a plataforma de gerenciamento MongoDB Atlas, para permitir experiências ultra-imersivas com experiência personalizada, dependendo das estruturas de banco de dados existentes na região principal e com a facilidade de se estender até a borda da rede.
Neste artigo, saiba como a Verizon e o MongoDB se uniram para realizar essa visão, um rápido guia de introdução para criar seu primeiro aplicativo MongoDB na borda e arquiteturas avançadas para quem tem conhecimento do MongoDB.
Vamos começar!
Por meio do Verizon 5G Edge, os desenvolvedores da AWS agora podem implantar partes de seu aplicativo que exigem baixa latência na borda das redes 4G e 5G usando as mesmas APIs, ferramentas e funcionalidades da AWS que usam atualmente, enquanto conectando-se perfeitamente ao restante de seus aplicativos e à gama completa de serviços de nuvem em execução em uma região da AWS . Ao incorporar os serviços de computação e armazenamento da AWS na borda da rede, casos de uso como inferência de ML, streaming de vídeo em tempo real, produção remota de vídeo e streaming de jogos podem ser rapidamente acelerados.
No entanto, para muitos desses casos de uso, é necessária uma camada de armazenamento persistente que se estenda além dos recursos de armazenamento nativos do AWS Wavelength, ou seja, volumes de armazenamento em blocos elásticos (EBS). No entanto, com o MongoDB Enterprise, os desenvolvedores podem aproveitar a computação subjacente (ou seja, . EC2 (instâncias) na borda para implantar clusters MongoDB a) como clusters autônomos ou b) conjuntos de réplicas altamente disponíveis que podem sincronizar dados perfeitamente.
O MongoDB é um banco de dados distribuído, baseado em documentos e de uso geral, criado para desenvolvedores de aplicativos modernos. Com o MongoDB Atlas, os desenvolvedores podem começar a trabalhar ainda mais rápido com bancos de dados MongoDB totalmente gerenciados implantados em todos os principais provedores de nuvem.
Embora MongoDB Atlas hoje não ofereça suporte a implantações em zonas do Wavelength, oMongoDB Cloud Manager pode automatizar, monitorar e fazer backup de sua infraestrutura do MongoDB. O Cloud Manager Automation permite configurar e manter nós e clusters do MongoDB, por meio dos quais os agentes do MongoDB em execução em cada host do MongoDB podem manter suas implantações do MongoDB. Neste exemplo, começaremos com uma arquitetura bastante simples destacando a relação entre as zonas do Wavelength (a borda) e a região pai (nuvem principal):
Assim como em qualquer outra arquitetura, começaremos com uma VPC que consiste em duas sub-redes. Em vez de uma sub-rede pública e uma sub-rede privada, teremos uma sub-rede pública e uma sub-rede de operadora — uma nova maneira de descrever sub-redes expostas dentro de zonas do Wavelength apenas para a rede móvel.
- Sub- rede pública: na região us-west-2 Oregon, lançamos uma sub-rede em us-west-2uma zona de disponibilidade que consiste em uma única instância do EC2 com um endereço IP público. Do ponto de vista do roteamento, anexamos um gateway de internet à VPC para fornecer conectividade de saída e anexamos o gateway de internet como a rota padrão (0.0.0.0/0) à sub-rede tabela de roteamento associada.
- Sub-rede da operadora: Também na região us-west-2 região do Oregon, nossa segunda sub-rede está na San Francisco Wavelength Zone (us-west-2-wl1-sfo-wlz-1), um data center de borda dentro da rede da operadora Verizon, mas que faz parte da região us-west-2. Nessa sub-rede, também implementamos uma única instância de EC2, desta vez com um endereço IP de operadora - um endereço IP voltado para a rede da operadora exposto aos dispositivos móveis da Verizon. Do ponto de vista do roteamento, anexamos um Carrier Gateway à VPC para fornecer conectividade de saída e anexamos o Carrier Gateway como rota padrão (0.0.0.0/0) à tabela de rotas associada da sub-rede.
Em seguida, vamos configurar a instância do EC2 na região pai. Depois de obter o IP (54.68.26.68) da instância do EC2 lançada, SSH na própria instância e começar a baixar o MongoDB Agent.
Quando estiver dentro, baixe e instale os pacotes necessários para o MongoDB MMS Automation Agent. Execute o seguinte comando:
Uma vez na instância, baixe o MongoDB MMS Automation Agent e instale o agente usando o gerenciador de pacotes RPM.
Em seguida, navegue até /etc/mongodb-mms/ e edite o arquivoautomation-agent.config para incluir sua chave de API do MongoDB Cloud Manager. Para criar uma chave, acesse o MongoDB Atlas em https://mongodb.com/atlas e faça login em uma conta existente ou inscreva-se em uma nova conta gratuita.
Após fazer login, crie uma nova organização e, para o serviço de nuvem, certifique-se de selecionar Cloud Manager.
Com sua organização criada, em seguida criaremos um novo projeto. Ao criar um novo projeto, pode ser solicitado que você selecione um serviço de nuvem, e você escolherá o Cloud Manager novamente.
Em seguida, você nomeará seu projeto. Você pode selecionar qualquer nome que quiser, nós Go a Verizon para o nome do nosso projeto. Depois de dar um nome ao seu projeto, você receberá uma solicitação para convidar outras pessoas para o projeto. Você pode pular esta etapa por enquanto, pois sempre poderá adicionar outros usuários no futuro.
Finalmente, você está pronto para distribuir o MongoDB em seu ambiente usando o Cloud Manager. Com o Cloud Manager, você pode implantar instâncias standalone, bem como conjuntos de réplicas do MongoDB. Como queremos alta disponibilidade, implantaremos um conjunto de réplicas.
Clicar no botãoNovo conjunto de réplicas nos levará à interface do usuário para configurar nosso conjunto de réplicas. Neste ponto, provavelmente receberemos uma mensagem dizendo que nenhum servidor foi detectado, e tudo bem, já que ainda não iniciamos nossos Agentes MongoDB.
Clique no link “see instructions” para obter mais detalhes sobre como instalar o MongoDB Agent. No modal que aparece, ele terá instruções conhecidas que já estamos seguindo, mas também terá duas informações de que precisaremos. O mmsApiKey e mmsGroupId serão exibidos aqui e você provavelmente terá que clicar no botão Gerar Chave para gerar um novo mmsAPIKey que será preenchido automaticamente. Anote esses valoresmmsGroupId e mmsApiKey, pois precisaremos ao configurar nossos MongoDB Agents a seguir.
Volte ao seu terminal para a instância do EC2 , navegue até /etc/mongodb-mms/ e edite o arquivoautomation-agent.config para incluir sua chave de API do MongoDB Cloud Manager.
Neste exemplo, editamos as variáveismmsApiKey e mmsGroupId. A partir daí, criaremos o diretório de dados e iniciaremos nosso agente MongoDB!
Depois de concluir essas etapas de configuração, prossiga e faça o mesmo para sua instância do Wavelength Zone. Observe que você não poderá fazer o SSH diretamente para o IP da operadora da instância (155.146.16.178/). Em vez disso, você deve usar a instância da região principal como bastion host para “jump” na própria instância de borda. Para fazer isso, localize o endereço IP privado da instância de borda (10.0.0.54) e, a partir da instância da região pai, faça SSH na segunda instância usando o mesmo par de chaves que você usou.
Depois de concluir a configuração da segunda instância, que segue as mesmas instruções anteriores, é hora da parte mais gratuita: iniciar o ReplicaSet no Console do Cloud Manager! A única coisa a observar sobre o conjunto de réplicas é que, como teremos três nós, na instância de borda criaremos um diretório /data e /data2 para permitir que dois diretórios separados hospedem os dados de nós individuais. Volte para https://mongodb.com/atlas e para o Cloud Manager para concluir a configuração.
Atualize a página Criar novo conjunto de réplicas e, agora que os MongoDB Agents estão em execução, você verá muitas informações pré-preenchidas para você. Certifique-se de que corresponda ao que você esperava e, quando estiver satisfeito, clique no botão Criar conjunto de réplicas.
Clique no botão "Create Replica Set " para finalizar o processo.
Em poucos minutos, o cluster de conjunto de réplicas será implantado nos servidores e seu cluster do MongoDB estará em funcionamento.
Com o conjunto de réplicas implantado, agora você deve ser capaz de se conectar ao cluster do MongoDB hospedado na zona padrão Us-West ou Wavelength. Para fazer isso, você precisará do endereço público do cluster e da porta, bem como da autenticação ativada no Cloud Manager. Para habilitar a autenticação, basta clicar no botão Habilitado/Desabilitado abaixo da seção Autenticação do seu conjunto de réplicas e você terá várias opções para se conectar ao cliente. Selecionaremos Nome de usuário/senha.
Clique em Avançar e o modal subsequente terá seu nome de usuário e senha para se conectar ao cluster.
Está tudo pronto. Em seguida, vamos ver o desempenho do MongoDB na borda. Testaremos isso lendo dados de nosso nó padrão EUA-Oeste, bem como da zona de comprimento de onda, e compararemos nossos resultados.
Depois de definir a arquitetura, queríamos ver o poder do G Edge 5em ação. Para esse fim, projetamos um “race. muito simples . Em 1,000 testes em que lemos dados de nosso MongoDB database e carimbo de data/hora de cada operação do cliente para a borda e para a região pai.
Depois de realizar esse experimento, concluímos que nosso nó do MongoDB na borda teve um desempenho 40% mais rápido do que a região pai! Mas por que esse foi o caso?
Como os nós da Wavelength Zone foram implantados na rede móvel, os pacotes nunca precisaram sair da rede da Verizon e incorrer na penalidade de latência de atravessar a Internet pública - propensos a jitter, perda e latência incrementais. Em nosso exemplo, nosso dispositivo 5G Ultra Wideband conectado em São Francisco tinha duas opções: conectar-se a um endpoint local dentro da rede móvel de São Francisco ou viajar mais de 500milhas até um data center no Oregon. Assim, validamos a significativa economia de desempenho do MongoDB na Verizon 5G Edge em relação à próxima melhor alternativa: implantar a mesma arquitetura na nuvem principal.
Embora a Verizon 5o G Edge sozinho permita que os desenvolvedores criem aplicativos ultraimersivos, como os aplicativos imersivos podem se tornar personalizados e localizados?
Entre no MongoDB.
Do processamento de transações em tempo real à captura de telemetria para seu aplicativo IoT ou personalização usando dados de perfil para experiências em locais localizados, levar o MongoDB ReplicaSets para a borda permite manter as características de baixa latência do seu aplicativo sem sacrificar o acesso aos dados de perfil do usuário, produto catálogos, telemetria IoT e muito mais.
Não há melhor momento para iniciar sua viagem de habilitação de borda com Verizon 5G Edge e MongoDB. Para saber mais sobre o Verizon 5G Edge, visite nossa página de recursos para desenvolvedores. Se você tiver alguma dúvida sobre esta postagem do blog, encontre-nos na MongoDB Community.
Em nosso próximo post, demonstraremos como criar seu primeiro classificador de imagens no 5G Edge usando o MongoDB para identificar VIPs em seu próximo evento esportivo, conferência de desenvolvedores ou evento de grande escala.