A escolha de um paradigma de implantação requer a consideração das necessidades do aplicação em termos de disponibilidade (tanto em geral quanto no caso de uma interrupção), latência, conformidade e custo. Não existe um paradigma "correto" para a implantação. Esta seção explora as arquiteturas disponíveis para ajudá-lo a atender às suas necessidades de implementação.
Ao implantar seu banco de dados, você deve primeiro escolher entre implantar em uma única região ou em várias regiões. O diagrama a seguir mostra essas opções, que são explicadas mais abaixo:
Sistemas de região única
Um sistema de regiãoúnica é a opção de sistema mais simples. Em um sistema de região única, seus dados são armazenados em uma das regiões de um provedor (como us-west-2 da AWS ou do asia-northeast3 Google). Para as regiões que têm várias zonas, o Atlas sempre fornece disponibilidade em nível de zona; seus nós de cluster estão espalhados pelas zonas de disponibilidade em uma única região. Portanto, se uma única zona falhar, seus dados ainda estarão disponíveis nas outras zonas.
Observação
As regiões recomendadas têm três zonas de disponibilidade e são marcadas com um ícone de estrela na UI do Atlas .
A simplicidade e o custo menor de um sistema de região única acarreta o risco de menor disponibilidade e potencialmente maior latência, dependendo da distribuição dos usuários do seu aplicativo.
Sistemas multirregionais
Um sistema de multirregional é um paradigma de sistema mais complexo que fornece maior disponibilidade e baixa latência em um intervalo geográfico maior do que um sistema de região única. Existem vários tipos de sistemas multirregional :
Várias regiões em uma região geográfica: implementado em várias regiões hospedadas por um único provedor de nuvem em uma única região geográfica, definida como uma área grande como um país ou continente. Isso garante a disponibilidade se alguma região falhar.
Por exemplo, você implementa clusters nas regiõesda AWS
us-west-1us-east-1e, ambas nos Estados Unidos. Seus-east-1ficar indisponível,us-west-1continuará aceitando leituras e escritas com desempenho próximo ao normal.Multirregiões em várias regiões: Distribui em uma ou mais regiões em duas ou mais regiões. Isso garante a disponibilidade se qualquer região falhar ou se uma área geográfica inteira não estiver disponível.
Por exemplo, você implementa clusters nas regiões
us-east-1e da AWS,us-east-2ambas nos Estados Unidos, e um terceiro clustereu-west-2em, que está na Europa.Multinuvem: implementa em uma ou mais regiões hospedadas por vários fornecedores de nuvem. Isso fornece o mais alto nível de disponibilidade, garantindo que seus dados estejam disponíveis se alguma região falhar ou se um provedor de nuvem inteiro falhar.
Por exemplo, você implementa clusters na região do AWS
us-west-1e na região do Googleus-east4Cloud.
Considerações sobre disponibilidade
A disponibilidade é frequentemente considerada em termos de quão resilientes seus clusters são a interrupções, enquanto a recuperação de desastres é a rapidez com que seu sistema pode se recuperar de uma interrupção (RTO) e a quantidade de dados que pode ser perdida em uma interrupção (RPO). Como todas as instâncias do Atlas sempre têm dados atuais, os failovers não exigem a restauração de backups.
O Atlas tem replicação integrada em seus sistemas, o que significa:
As instâncias do banco de dados são mantidas perfeitamente sincronizadas umas com as outras, normalmente na faixa de milissegundos.
No evento de uma interrupção, o failover entre instâncias do banco de dados é totalmente automático. Não requer intervenção humana e leva apenas alguns segundos.
Ao usar o writeConcern padrão
majorityde, não ocorrerá perda de dados durante o failover porque todos os dados foram gravados em vários locais, evitando a perda de dados. Além disso, o driver de banco de dados tentará novamente automaticamente qualquer operação a bordo para garantir que ela seja bem-sucedida.
Isso significa que o RTO, o RPO e a frequência de replicação de dados são efetivamente iguais e seus clusters do Atlas estão totalmente operacionais, desde que a maioria dos nós esteja saudável.
Observação
O RTO e o RPO máximos devem ser considerados implicitamente em todo o cluster e como você implementa seu aplicação. Considere todo o volume de trabalho do seu cluster para garantir que ele atenda aos seus requisitos.
Comparação de paradigmas de implantação
Para descobrir qual padrão de implementação é adequado para você, divida seus aplicativos por quão críticos eles são para seus negócios principais. Quanto mais importante for o aplicação (em outras palavras, quanto mais impacto uma interrupção tiver em seus negócios), mais você deverá considerar uma arquitetura que gerencie automaticamente qualquer evento de interrupção .
A tabela a seguir fornece uma comparação de paradigmas de implantação para ajudá-lo a determinar a melhor opção para suas necessidades:
Nível de prioridade | Descrição | RTO | Modelo de sistema | Custo relativo |
|---|---|---|---|---|
Nível 0 | Aplicativos de maior criticidade. Requer failover totalmente automatizado mesmo no evento de interrupções regionais. | 0 | $$$ | |
Nível 1 | Aplicativos de criticidade mais baixa. Pode apresentar algum tempo de inatividade ou janelas de manutenção sem impacto significativo na receita . | > 1 hora e < 8 horas | $$ | |
Nível 2 | Aplicativos de menor criticidade. Pode ficar inativo por 24 horas sem impacto significativo na receita. | > 8 horas | $+ | |
Não produção | Aplicativos não críticos. Ambientes que não são diretamente responsáveis pela receita e não são voltados para o cliente. Normalmente, ambientes de desenvolvimento e teste. | N/A | A partir de US$0 |
Observação
O custo de cada tipo de sistema depende de vários fatores, incluindo o(s) fornecedor(es) selecionado(s), o número de regiões necessárias, a quantidade de armazenamento e o poder de processamento dos servidores. Para obter as informações mais recentes sobre preços, consulte Preços do MongoDB .
Casos de uso
Ao escolher seu paradigma de implantação, comece identificando o menor número de regiões que você pode implantar para atender à mais ampla distribuição geográfica de seus usuários. Em seguida, considere adicionar regiões ou provedores de nuvem adicionais de acordo com seus requisitos de disponibilidade, desempenho e soberania de dados.
Considere os seguintes casos de uso para ajudar a decidir qual paradigma de implantação funciona para a distribuição geográfica dos usuários do seu aplicativo:
Usuários principalmente em uma localidade
Se a maioria dos usuários do seu aplicativo estiver localizada em uma localidade geográfica, recomendamos que você implante em uma ou mais regiões dentro da mesma região geográfica. Enquanto uma implantação de região única pode proteger contra uma interrupção em uma zona de disponibilidade única, uma implantação de multirregional cobre uma área geográfica maior e garante a disponibilidade durante interrupções zonais e regionais. Para uma disponibilidade ainda maior, você pode implantar em várias regiões. Todas essas opções oferecem suporte a baixa latência e simplificam a conformidade com os requisitos de soberania de dados porque todos os dados do usuário são acessados e armazenados dentro da mesma localização geográfica.
Para saber mais sobre esses paradigmas de implantação, consulte as seguintes páginas de paradigma:
Usuários distribuídos em várias regiões
Se os usuários do seu aplicativo estiverem distribuídos em várias regiões, como entre os EUA e a Europa, recomendamos que você implante em uma ou mais regiões em cada região. A implementação em uma região em cada região geográfica onde você atende clientes oferece baixa latência e disponibilidade no caso de uma interrupção geográfica. Você também pode atender aos requisitos de soberania de dados particionamento seus dados de forma que os dados do usuário de cada localidade sejam hospedados dentro dessa localidade.
Para garantir alta disponibilidade em caso de interrupções regionais sem aumentar a latência ou violar os requisitos de soberania de dados, você também pode implantar em várias regiões em cada localidade. Você pode obter a mais alta disponibilidade para uma implantação de multirregional implantando clusters em várias regiões, em várias regiões.
Para saber mais sobre esses paradigmas de implantação, consulte as seguintes páginas de paradigma:
Usuários distribuídos em todo o mundo
Se você estiver implantando um aplicação em um público mundial, recomendamos que você implante uma implantação de multirregional em várias regiões antes de considerar uma implantação global. Em quase todos os casos, uma implantação de multirregional em várias regiões pode atender aos seus requisitos de alta disponibilidade, baixa latência e soberania de dados. Em casos raros, você pode precisar de sistemas globais do Atlas , que são os paradigmas de sistema multirregional mais complexos e exigem um planejamento muito cuidadoso.
Para saber mais sobre esses paradigmas de implantação, consulte as seguintes páginas: