Gerenciamento de banco de dados de várias nuvens: arquiteturas, casos de uso e práticas recomendadas.

Last reviewed 2024-03-06 UTC

Neste documento, descrevemos as arquiteturas de implantação, os casos de uso e as práticas recomendadas para o gerenciamento de bancos de dados com várias nuvens. Ele é destinado a arquitetos e engenheiros que projetam e implementam aplicativos com estado em várias nuvens.

As arquiteturas de aplicativos de várias nuvens que acessam bancos de dados dependem do caso de uso. Nenhuma arquitetura de aplicativo com estado é compatível com todos os casos de uso de várias nuvens. Por exemplo, a melhor solução de banco de dados para um caso de uso de bursting de nuvem é diferente da melhor solução de banco de dados para um aplicativo executado simultaneamente em vários ambientes de nuvem.

Para nuvens públicas como o Google Cloud, há várias tecnologias de banco de dados que se encaixam em casos de uso específicos de várias nuvens. Para implantar um aplicativo em várias regiões dentro de uma única nuvem pública, uma opção é usar um banco de dados público, gerenciado pelo provedor e multirregional, como o Spanner. Para implantar um aplicativo que pode ser portátil em nuvens públicas, um banco de dados independente da plataforma pode ser uma opção melhor, como o PostgreSQL.

Neste documento, apresentamos uma definição para um aplicativo de banco de dados com estado, seguida por uma análise de caso de uso de banco de dados de várias nuvens. Ele também apresenta uma categorização detalhada do sistema de banco de dados para arquiteturas de implantação em várias nuvens com base nos casos de uso.

O documento também apresenta uma árvore de decisão para selecionar bancos de dados, que descreve os principais pontos de decisão para selecionar uma tecnologia de banco de dados apropriada. Ele termina com uma discussão sobre as práticas recomendadas para o gerenciamento de bancos de dados com várias nuvens.

Principais termos e definições

Nesta seção, fornecemos uma terminologia e define o aplicativo genérico de banco de dados com estado usado neste documento.

Terminologia

• Nuvem pública. Uma nuvem pública fornece infraestrutura multilocatária (geralmente global) e serviços que os clientes podem usar para executar suas cargas de trabalho de produção. O Google Cloud é uma nuvem pública que fornece muitos serviços gerenciados, incluindo GKE, GKE Enterprise e bancos de dados gerenciados.
• Nuvem híbrida. Uma nuvem híbrida é uma combinação de uma nuvem pública com um ou mais data centers no local. Os clientes de nuvem híbrida podem combinar os serviços locais com serviços adicionais fornecidos por uma nuvem pública.
• Multicloud. Várias nuvens é uma combinação de nuvens públicas e data centers no local. Uma nuvem híbrida é um subconjunto de várias nuvens.
• Local de implantação. Um local de infraestrutura é um local físico que pode implantar e executar cargas de trabalho, incluindo aplicativos e bancos de dados. Por exemplo, no Google Cloud, os locais de implantação são zonas e regiões. Em um nível abstrato, uma região ou zona de nuvem pública e um data center local são locais de implantação.

Aplicativos de banco de dados com estado

Para definir casos de uso de várias nuvens, uma arquitetura de aplicativo genérica de banco de dados com estado é usada neste documento, conforme mostrado no diagrama a seguir.

O diagrama mostra os seguintes componentes:

• Banco de dados. Um banco de dados pode ser uma instância única, de várias instâncias ou distribuída, implantado em nós de computação ou disponível como um serviço gerenciado na nuvem.
• Serviços para aplicativos. Esses serviços são combinados como um aplicativo que implementa a lógica de negócios. Os serviços de aplicativo podem ser qualquer um destes:
  • Microsserviços no Kubernetes.
  • Processos granulares em execução em uma ou mais máquinas virtuais.
  • Um aplicativo monolítico em uma grande máquina virtual.
  • Código sem servidor no Cloud Functions ou no Cloud Run. Alguns serviços de aplicativo podem acessar o banco de dados. É possível implantar cada serviço de aplicativo várias vezes. Cada implantação de um serviço de aplicativo é uma instância desse serviço.
• Clientes do aplicativo. Os clientes do aplicativo acessam a funcionalidade fornecida pelos serviços do aplicativo. Os clientes de aplicativos podem ser um dos seguintes:
  • Clientes implantados, em que o código é executado em uma máquina, laptop ou smartphone.
  • Clientes não implantados, em que o código do cliente é executado em um navegador. As instâncias do cliente do aplicativo sempre acessam uma ou mais instâncias do serviço de aplicativo.

No contexto de uma discussão sobre banco de dados de várias nuvens, a abstração arquitetônica de um aplicativo com estado consiste em um banco de dados, serviços de aplicativos e clientes de aplicativos. Na implementação de um aplicativo, fatores como o uso de sistemas operacionais ou as linguagens de programação usadas podem variar. No entanto, esses detalhes não afetam o gerenciamento de bancos de várias nuvens.

Filas e arquivos como serviços de armazenamento de dados

Há muitos recursos de persistência disponíveis para que os serviços de aplicativos mantenham os dados. Esses recursos incluem bancos de dados, filas e arquivos. Cada recurso de persistência fornece modelos de dados de armazenamento e padrões de acesso especializados para esses modelos. Embora as filas, os sistemas de mensagens e os sistemas de arquivos sejam usados por aplicativos, na seção a seguir, o foco é especificamente nos bancos de dados.

Embora as mesmas considerações para fatores como local de implantação, compartilhamento de estado, replicação síncrona e assíncrona para bancos de dados com várias nuvens sejam aplicáveis a filas e arquivos, essa discussão está fora do escopo deste documento.

Rede

Na arquitetura de um aplicativo com estado genérico (mostrado novamente no diagrama a seguir), cada seta entre os componentes representa uma relação de comunicação em uma conexão de rede. Por exemplo, um cliente de aplicativo que acessa um serviço de aplicativo.

Uma conexão pode estar dentro de uma zona ou entre zonas, regiões ou nuvens. É possível ter conexões entre qualquer combinação de locais de implantação. Em ambientes de várias nuvens, a rede entre nuvens é uma consideração importante, e há várias opções que você pode usar. Para mais informações sobre redes em nuvens, consulte Como se conectar ao Google Cloud: explicação das opções de rede.

Nos casos de uso neste documento, presume-se que:

• Existe uma conexão de rede segura entre as nuvens.
• Os bancos de dados e os componentes deles podem se comunicar uns com os outros.

Do ponto de vista não funcional, o tamanho da rede, ou seja, a capacidade e a latência, pode afetar a latência e a capacidade do banco de dados. Do ponto de vista funcional, a rede geralmente não tem efeito.

Casos de uso do banco de dados de várias nuvens

Nesta seção, apresentamos uma seleção dos casos de uso mais comuns do gerenciamento de banco de dados de várias nuvens. Para esses casos de uso, presume-se que haja conectividade de rede segura entre as nuvens e os nós do banco de dados.

Migração de aplicativos

No contexto do gerenciamento de banco de dados de várias nuvens, a migração de aplicativos refere-se à migração de um aplicativo, de todos os serviços de aplicativos e do banco de dados da nuvem atual para uma nuvem de destino. Existem muitas razões para uma empresa decidirmigrar um aplicativo, por exemplo, para evitar uma situação competitiva com o provedor de nuvem, modernizar a tecnologia ou reduzir o custo total de propriedade (TCO, na sigla em inglês).

Na migração do aplicativo, a intenção é interromper a produção na nuvem atual e continuar a produção na nuvem de destino após a conclusão da migração. Os serviços de aplicativos precisam ser executados na nuvem de destino. Para implementar os serviços, é possível usar uma abordagem de migração lift-and-shift. Nessa abordagem, o mesmo código é implantado na nuvem de destino. Para reimplementar o serviço, as tecnologias modernas da nuvem que estão disponíveis na nuvem de destino podem ser usadas.

Do ponto de vista do banco de dados, considere as seguintes opções alternativas para migração de aplicativos:

• Migração lift-and-shift do banco de dados: se o mesmo mecanismo de banco de dados estiver disponível na nuvem de destino, será possível fazer a migração lift-and-shift do banco de dados para criar uma implantação idêntica na nuvem de destino.
• Aumento de banco de dados e migração para o equivalente gerenciado: um banco de dados autogerenciado pode ser migrado para uma versão gerenciada do mesmo mecanismo de banco de dados se a nuvem de destino o fornecer.
• Modernização do banco de dados: diferentes nuvens oferecem diferentes tecnologias de banco de dados. Os bancos de dados gerenciados por um provedor de nuvem podem ter vantagens como contratos de nível de serviço (SLAs, na sigla em inglês) mais rigorosos, escalonabilidade e recuperação automática de desastres.

Independentemente da estratégia de implantação, a migração do banco de dados é um processo que leva tempo devido à necessidade de mover dados da nuvem atual para a nuvem de destino. É possível seguir uma abordagem de exportação e importação que gera inatividade, mas é preferível usar migração de tempo de inatividade mínimo ou zero. Essa abordagem minimiza o tempo de inatividade do aplicativo e tem o menor impacto em uma empresa e nos clientes dela. No entanto, ela normalmente requer uma configuração de migração mais complexa, já que envolve carga inicial, replicação contínua, monitoramento, validação granular e sincronização na troca. Para oferecer suporte a cenários de fallback, é necessário implementar um mecanismo de replicação reversa para sincronizar as alterações de volta no banco de dados de origem depois de alternar para o de destino.

Recuperação de desastres

Recuperação de desastres refere-se à capacidade de um aplicativo de continuar fornecendo serviços a clientes de aplicativos durante uma interrupção de região. Para garantir a recuperação de desastres, um aplicativo precisa ser implantado em pelo menos duas regiões e estar pronto para ser executado a qualquer momento. Em produção, o aplicativo é executado na região principal. No entanto, se ocorrer uma interrupção, uma região secundária se tornará a região principal. Veja a seguir os diferentes modelos de prontidão para a recuperação de desastres:

• Espera ativa. O aplicativo é implantado em duas ou mais regiões, primária e secundária, e funciona plenamente em todas as regiões Se a região principal falhar, o aplicativo na região secundária poderá aceitar o tráfego do cliente do aplicativo imediatamente.
• Espera passiva. O aplicativo está em execução na região principal, mas está pronto para inicialização em uma região secundária (mas não em execução). Se a região principal falhar, o aplicativo será iniciado na região secundária. Ocorre uma interrupção até que o aplicativo possa ser executado e fornecer todos os serviços para os clientes do aplicativo.
• Sem espera. Nesse modelo, o código do aplicativo está pronto para implantação, mas ainda não foi implantado na região secundária e, portanto, não está usando os recursos implantados. Se uma região principal tiver uma interrupção, a primeira implantação do aplicativo precisará estar na região secundária. Essa implantação coloca o aplicativo no mesmo estado de um modo de espera fria, o que significa que ele precisa ser iniciado. Nessa abordagem, a interrupção do aplicativo é mais longa em comparação com o caso de espera fria, porque a implantação do aplicativo precisa ocorrer primeiro, o que inclui a criação de recursos em nuvem.

Da perspectiva do banco de dados, os modelos de prontidão discutidos na lista anterior correspondem às seguintes abordagens de banco de dados:

• Banco de dados sincronizado transacionalmente. Esse banco de dados corresponde ao modelo de espera ativa. Toda transação na região primária é confirmada na coordenação síncrona em uma região secundária. Quando a região secundária se torna a região principal durante uma interrupção, o banco de dados é consistente e está imediatamente disponível. Nesse modelo, o objetivo de ponto de recuperação (RPO, na sigla em inglês) e o objetivo de tempo de recuperação (RTO, na sigla em inglês) são zero.
• Banco de dados replicado de maneira assíncrona. Esse banco de dados também corresponde ao modelo de espera ativa. Como a replicação do banco de dados da região primária para a região secundária é assíncrona, há uma possibilidade de que, se a região principal falhar, algumas transações podem ser replicadas para a região secundária. Embora o banco de dados na região secundária esteja pronto para carga de produção, ele pode não ter os dados mais atuais. Por isso, o aplicativo pode gerar uma perda de transações que não podem ser recuperadas. Devido a esse risco, essa abordagem tem um RTO de zero, mas o RPO é maior que zero.
• Banco de dados de inatividade. Esse banco de dados corresponde ao modelo de espera fria. O banco de dados é criado sem nenhum dado. Quando a região primária falha, os dados precisam ser carregados no banco de dados de inatividade. Para ativar essa ação, um backup regular precisa ser realizado na região principal e transferido para a região secundária. O backup pode ser completo ou incremental, dependendo do que é compatível com o mecanismo de banco de dados. Em ambos os casos, o banco de dados é definido de volta para o último backup e, do ponto de vista do aplicativo, muitas transações podem ser perdidas em comparação com a região principal. Embora essa abordagem possa ser econômica, o valor é mitigado pelo risco de que todas as transações desde o último backup disponível possam ser perdidas devido à falta de atualização do estado do banco de dados.
• Nenhum banco de dados. Esse modelo é equivalente ao caso sem espera. A região secundária não tem nenhum banco de dados instalado e, se a região principal falhar, um banco de dados precisará ser criado. Depois que o banco de dados é criado, como no caso de banco de dados inativo, ele precisa ser carregado com dados antes de estar disponível para o aplicativo.

As abordagens de recuperação de desastres discutidas neste documento também se aplicam se uma nuvem primária e uma secundária forem usadas em vez de uma região primária e secundária. A principal diferença é que, devido à heterogeneidade da rede entre as nuvens, a latência entre as nuvens pode aumentar em comparação à distância da rede entre regiões dentro de uma nuvem. Outras discrepâncias podem vir de diferentes recursos e configurações padrão de bancos de dados gerenciados de diferentes provedores de nuvem.

A probabilidade de uma nuvem inteira falhar é menor do que a de uma região com falha. No entanto, ainda pode ser útil para as empresas ter um aplicativo implantado em duas nuvens. Essa abordagem pode ajudar a proteger uma empresa contra falhas ou a cumprir os regulamentos de negócios ou do setor.

Outra abordagem de recuperação de desastres é ter uma região primária e uma secundária, além de uma nuvem primária e uma secundária. Essa abordagem permite que as empresas escolham o melhor processo de recuperação de desastres para resolver uma situação de falha. Para permitir a execução de um aplicativo, uma região secundária ou uma nuvem secundária podem ser usadas, dependendo da gravidade da interrupção.

Bursting de nuvem

O bursting de nuvem se refere a uma configuração que permite o escalonamento vertical do tráfego de clientes do aplicativo em diferentes locais de implantação. Um aplicativo burst quando a demanda por capacidade aumenta e um local em espera fornece capacidade adicional. Um local principal aceita o tráfego regular, enquanto um local em espera pode fornecer capacidade adicional caso o tráfego de cliente do aplicativo esteja aumentando além do que o local principal pode suportar. Tanto o local principal quanto o local de espera têm instâncias de serviço de aplicativo implantadas.

O bursting de nuvem é implementado nas nuvens em que uma nuvem é a nuvem primária e outra é a nuvem em espera. Ele é usado em um contexto de nuvem híbrida para aumentar um número limitado de recursos de computação em data centers no local com recursos elásticos de computação em nuvem em uma nuvem pública.

Para suporte ao banco de dados, as seguintes opções estão disponíveis:

• Implantação do local principal. Nesta implantação, o banco de dados é implantado apenas no local principal e não no local em espera. Quando um aplicativo é burst, o aplicativo no local de espera acessa o banco de dados no local principal.
• Implantação de locais principal e de espera. Essa implantação é compatível com os locais principal e de espera. Uma instância de banco de dados é implantada em ambos os locais e é acessada pelas instâncias de serviço de aplicativo desse local, especialmente no caso de bursting. Como em Recuperação de desastres dentro e entre nuvens, os dois bancos de dados podem ser sincronizados de maneira transacional ou sincronizados de maneira assíncrona. Na sincronização assíncrona, pode haver um atraso. Se ocorrerem atualizações no local de espera, elas precisarão ser propagadas de volta para o local principal. Se for possível fazer atualizações simultâneas nos dois locais, será necessário implementar a resolução de conflitos.

O bursting de nuvem é um caso de uso comum em nuvens híbridas para aumentar a capacidade em data centers locais. Também é uma abordagem que pode ser usada em nuvens públicas quando os dados precisam permanecer em um país. Em situações em que uma nuvem pública tem apenas uma região em um país, é possível estourar em uma região de uma nuvem pública diferente no mesmo país. Essa abordagem garante que os dados permaneçam dentro do país e, ao mesmo tempo, resolva as restrições de recursos na região das regiões de nuvem pública.

Melhor uso de serviços na nuvem

Alguns aplicativos exigem serviços e produtos de nuvem especializados que não estão disponíveis em uma única nuvem. Por exemplo, um aplicativo pode executar o processamento lógico de negócios em uma nuvem e os dados de negócios em outra nuvem. Nesse caso de uso, as partes de processamento de lógica de negócios e as partes de análise do aplicativo são implantadas em diferentes nuvens.

Do ponto de vista do gerenciamento de dados, os casos de uso são os seguintes:

• Dados particionados. Cada parte do aplicativo tem seu próprio banco de dados (partição separada) e nenhum dos bancos de dados está conectado diretamente uns aos outros. O aplicativo que gerencia os dados grava todos os que precisam estar disponíveis em ambos os bancos de dados (partições) duas vezes.
• Banco de dados replicado de maneira assíncrona. Se os dados de uma nuvem precisarem estar disponíveis na outra, uma relação de replicação assíncrona poderá ser apropriada. Por exemplo, se um aplicativo de análise exigir o mesmo conjunto de dados ou um subconjunto do conjunto de dados para um aplicativo de negócios, o último poderá ser replicado entre as nuvens.
• Banco de dados sincronizado transacionalmente. Esses tipos de bancos de dados permitem disponibilizar informações para ambas as partes do aplicativo. Cada atualização de cada um dos aplicativos é transacionalmente consistente e está disponível para ambos os bancos de dados (partições) imediatamente. Os bancos de dados sincronizados transacionalmente atuam como um único banco de dados distribuído.

Serviços distribuídos

Um serviço distribuído é implantado e executado em dois ou mais locais de implantação. É possível implantar todas as instâncias do serviço em todos os locais da implantação. Como alternativa, é possível implantar alguns serviços em todos os locais e alguns apenas em um dos locais, com base em fatores como disponibilidade de hardware ou carga limitada esperada.

Os dados em um banco de dados sincronizado transacional são consistentes em todos os locais. Portanto, esse banco de dados é a melhor opção para implantar instâncias de serviço em todos os locais de implantação.

Quando você usa um banco de dados replicado assíncrono, há o risco de modificar o mesmo item de dados em dois locais de implantação simultaneamente. Para determinar qual das duas alterações conflitantes é o estado final consistente, uma estratégia de resolução de conflitos precisa ser implementada. Embora seja possível implementar uma estratégia de resolução de conflitos, isso nem sempre é simples e há casos em que é necessária intervenção manual para restaurar os dados a um estado consistente.

Realocação e failover de serviço distribuído

Se uma região inteira da nuvem falhar, a recuperação de desastres será iniciada. Se um único serviço em um aplicativo de banco de dados com estado falhar (não a região ou o aplicativo inteiro), o serviço precisará ser recuperado e reiniciado.

Uma abordagem inicial para recuperação de desastres é reiniciar o serviço com falha no local de implantação original (uma abordagem de reinicialização no local). Tecnologias como o Kubernetes reiniciam automaticamente um serviço com base na configuração dele.

No entanto, se essa abordagem de reinicialização no local não for bem-sucedida, uma alternativa será reiniciar o serviço em um local secundário. O serviço faz o failover do local principal para um local secundário. Se o aplicativo for implantado como um conjunto de serviços distribuídos, o failover de um único serviço pode ocorrer dinamicamente.

Do ponto de vista do banco de dados, a reinicialização do serviço no local de implantação original não requer uma implantação específica do banco de dados. Quando um serviço é movido para um local de implantação alternativo e acessa o banco de dados, aplicam-se os mesmos modelos de prontidão discutidos anteriormente em Serviços distribuídos neste documento.

Se um serviço estiver sendo realocado temporariamente e se latências maiores forem aceitáveis para uma empresa durante a realocação, o serviço poderá acessar o banco de dados em locais de implantação. Embora o serviço seja realocado, ele continua acessando o banco de dados da mesma forma que faria a partir do local de implantação original.

Implantação baseada no contexto

Em geral, uma única implantação de aplicativo para atender a todos os clientes de aplicativos inclui todos os serviços e bancos de dados do aplicativo. No entanto, existem casos de uso excepcionais. Uma única implantação de aplicativo pode atender a apenas um subconjunto de clientes (com base em critérios específicos), o que significa que mais de uma implantação de aplicativo é necessária. Cada implantação atende a um subconjunto diferente de clientes, e todas as implantações juntas atendem a todos os clientes.

Exemplos de casos de uso para uma implantação dependente do contexto são os seguintes:

• Ao implantar um aplicativo multilocatário em que um aplicativo é implantado para todos os locatários pequenos, outro aplicativo é implantado para cada dez locatários médios, e um aplicativo é implantado para cada locatário premium.
• Quando há a necessidade de separar clientes, por exemplo, clientes empresariais e governamentais.
• Quando há uma necessidade de separar ambientes de desenvolvimento, preparação e produção.

Do ponto de vista do banco de dados, é possível implantar um banco de dados para cada implantação de aplicativo em uma estratégia de implantação de um para um. Conforme mostrado no diagrama a seguir, essa estratégia é uma abordagem simples em que os dados particionados são criados porque cada implantação tem seu próprio conjunto de dados.

O diagrama anterior mostra o seguinte:

• Configuração com três implantações de um aplicativo.
• Cada conjunto de dados tem seu próprio banco de dados.
• Nenhum dado é compartilhado entre as implantações.

Em muitas situações, uma implantação individual é a estratégia mais apropriada. No entanto, existem alternativas.

No caso da multilocação, os locatários podem ser realocados. Um locatário pequeno pode se tornar um locatário médio e precisar ser realocado para um aplicativo diferente. Nesse caso, implantações de banco de dados separadas exigem migração de banco de dados. Se um banco de dados distribuído for implantado e usado por todas as implantações ao mesmo tempo, todos os dados de locatário ficarão em um único sistema de banco de dados. Por isso, mover um locatário entre bancos de dados não requer migração. O diagrama a seguir mostra um exemplo desse tipo de banco de dados:

O diagrama anterior mostra o seguinte:

• Três implantações de um aplicativo.
• Todas as implantações compartilham um único banco de dados distribuído.
• Os aplicativos podem acessar todos os dados em cada implantação.
• Não há particionamento de dados implementado.

Se uma empresa costuma realocar locatários como parte de operações de ciclo de vida, a replicação de banco de dados pode ser uma alternativa útil. Nessa abordagem, os dados de locatário são replicados entre os bancos de dados antes de uma migração de locatário. Nesse caso, bancos de dados independentes são usados para diferentes implantações de aplicativos e só são configurados para replicação imediatamente antes e durante a migração de locatários. O diagrama a seguir mostra uma replicação temporária entre duas implantações de aplicativos durante uma migração de locatário.

O diagrama anterior mostra três implantações de um aplicativo com três bancos de dados separados que contêm os dados associados a cada implantação. Para migrar dados de um banco de dados para outro, é possível configurar uma migração temporária.

Portabilidade de aplicativos

A portabilidade do aplicativo garante que um aplicativo possa ser implantado em diferentes locais de implantação, especialmente nuvens diferentes. Essa portabilidade garante que um aplicativo possa ser migrado a qualquer momento, sem a necessidade de reengenharia específica de migração ou desenvolvimento adicional de aplicativos para se preparar para uma migração de aplicativo.

Para garantir a portabilidade do aplicativo, você pode usar uma das seguintes abordagens, que são descritas mais adiante nesta seção:

• Portabilidade baseada em sistema
• Compatibilidade de API
• Portabilidade baseada em funcionalidade

A portabilidade baseada em sistema usa os mesmos componentes técnicos usados em todas as implantações possíveis. Para garantir a portabilidade baseada em sistema, cada tecnologia precisa estar disponível em todos os locais de implantação em potencial. Por exemplo, se um banco de dados como o PostgreSQL for candidato, sua disponibilidade em todos os possíveis locais de implantação precisará ser verificada pelo período esperado. O mesmo acontece com todas as outras tecnologias, como linguagens de programação e tecnologias de infraestrutura. Conforme mostrado no diagrama a seguir, essa abordagem estabelece um conjunto de funcionalidades comuns em todos os locais de implantação com base na tecnologia.

O diagrama anterior mostra uma implantação de aplicativo portátil em que o aplicativo espera exatamente o mesmo sistema de banco de dados em todos os locais em que foi implantado. Como o mesmo sistema de banco de dados é usado em cada local, o aplicativo é portátil. O aplicativo espera que o mesmo sistema de banco de dados seja usado em toda a implantação. Portanto, é possível adotar a mesma interface e o comportamento do sistema de banco de dados.

No contexto dos bancos de dados, no sistema de compatibilidade da API, o cliente usa uma biblioteca de acesso de banco de dados específica (por exemplo, uma biblioteca de cliente MySQL) para garantir que ele possa se conectar a qualquer implementação compatível que possa estar disponível. em um ambiente de nuvem. O diagrama a seguir ilustra a compatibilidade da API.

O diagrama anterior mostra a portabilidade do aplicativo com base na API do sistema de banco de dados, e não no sistema. Embora os sistemas de banco de dados possam ser diferentes em cada um dos locais, a API é a mesma e expõe a mesma funcionalidade. O aplicativo é portátil porque pode presumir a mesma API em cada local, mesmo que o sistema de banco de dados subjacente seja uma tecnologia de banco de dados diferente.

Na portabilidade baseada em funcionalidade, diferentes tecnologias em nuvens diferentes podem ser usadas para fornecer a mesma funcionalidade. Por exemplo, talvez seja possível restringir o uso de bancos de dados ao modelo relacional. Como qualquer sistema de banco de dados relacional pode oferecer suporte ao aplicativo, diferentes sistemas de banco de dados em diferentes versões podem ser usados em diferentes nuvens sem afetar a portabilidade do aplicativo. Uma desvantagem da portabilidade baseada em funcionalidade é que ela só pode usar as partes do modelo de banco de dados compatíveis com todos os sistemas de banco de dados relacional. Em vez de um sistema de banco de dados compatível com todas as nuvens, é preciso usar um modelo de banco de dados. O diagrama a seguir mostra um exemplo de arquitetura para portabilidade baseada em funcionalidade.

Como mostra o diagrama anterior, a API do sistema de banco de dados e o sistema de banco de dados podem ser diferentes em cada local. Para garantir a portabilidade, o aplicativo precisa usar apenas as partes de cada sistema de banco de dados e cada API disponível em cada local. Como apenas um subconjunto de cada sistema de banco de dados costuma estar disponível em cada local, o aplicativo precisa restringir seu uso a esse subconjunto.

Para garantir a portabilidade de todas as opções nesta seção, a arquitetura completa precisa ser implantada continuamente em todos os locais de destino. Todos os casos de teste de unidade e sistema precisam ser executados nessas implantações. Esses são os requisitos essenciais para que as mudanças nas infraestruturas e tecnologias sejam detectadas antecipadamente e abordadas.

Prevenção de dependência de fornecedores

A prevenção da dependência do fornecedor (bloqueio) ajuda a reduzir o risco de dependência de uma tecnologia e um fornecedor específicos. Ele é muito semelhante à portabilidade de aplicativos. A prevenção de dependência do fornecedor se aplica a todas as tecnologias usadas, não apenas aos serviços de nuvem. Por exemplo, se o MySQL for usado como um sistema de banco de dados e instalado em máquinas virtuais em nuvens, não haverá dependência da perspectiva da nuvem, mas há dependência do MySQL. Um aplicativo portátil entre nuvens ainda pode depender de tecnologias fornecidas por fornecedores diferentes da nuvem.

Para evitar a dependência do fornecedor, todas as tecnologias precisam ser substituíveis. Por esse motivo, a abstração completa e estruturada de toda a funcionalidade do aplicativo é necessária para que cada serviço de aplicativo possa ser reimplementado para uma base de tecnologia diferente sem afetar a implementação do aplicativo. Do ponto de vista do banco de dados, essa abstração pode ser feita separando o uso de um modelo de banco de dados de um sistema de gerenciamento de banco de dados específico.

Sistema de gerenciamento de banco de dados de produção existente

Muitos aplicativos com várias nuvens são desenvolvidos com sistemas de banco de dados como parte do design, mas muitas empresas desenvolvem aplicativos desse tipo como parte do esforço de modernização deles. Esses aplicativos são desenvolvidos com a suposição de que o aplicativo recém-projetado e implementado acessa os bancos de dados existentes.

Há muitos motivos para não incorporar bancos de dados atuais a um esforço de modernização. Pode haver recursos específicos em uso que não estejam disponíveis em outros sistemas de banco de dados. Uma empresa pode ter bancos de dados com processos de gerenciamento complexos e bem estabelecidos, o que faz com que a migração para um sistema diferente seja impraticável ou não econômica. Ou uma empresa pode optar por modernizar um aplicativo na primeira fase e modernizar o banco de dados na segunda fase.

Quando uma empresa usa um sistema de banco de dados atual, o designer do aplicativo de várias nuvens precisa decidir se será o único banco de dados usado ou se outro sistema de banco de dados precisa ser adicionado para uma implantação diferente. Por exemplo, se um banco de dados for usado no local e o aplicativo também precisar ser executado no Google Cloud, ele precisará considerar se os serviços de aplicativos implantados no Google Cloud acessam o banco de dados no local. Ou, se preferir, se um segundo banco de dados for implantado no Google Cloud e nos serviços de aplicativos em execução localmente.

Se um segundo banco de dados for implantado no Google Cloud, o caso de uso poderá ser o mesmo discutido no bursting de nuvem ou nos serviços distribuídos. Em ambos os casos, a mesma discussão sobre banco de dados se aplica como nestas seções. No entanto, ela é limitada à funcionalidade entre locais que o banco de dados local pode oferecer, por exemplo, sincronização e replicação.

Padrões de implantação

Os casos de uso discutidos neste documento levantam uma questão comum do ponto de vista do banco de dados: se os bancos de dados estão em mais de um local de implantação, qual é a relação deles?

Os principais tipos de relacionamentos (padrões de implantação), discutidos na próxima seção, são os seguintes:

• Particionada sem dependência entre bancos de dados
• Replicação unidirecional assíncrona
• Replicação bidirecional com resolução de conflitos
• Sistema distribuído totalmente ativo-ativo e sincronizado

É possível mapear cada caso de uso neste documento para um ou mais dos quatro padrões de implantação.

Na discussão a seguir, presume-se que os clientes acessem serviços de aplicativos diretamente. Dependendo do caso de uso, um balanceador de carga pode ser necessário para direcionar dinamicamente o acesso do cliente aos aplicativos, conforme mostrado no diagrama a seguir.

No diagrama anterior, um balanceador de carga na nuvem direciona chamadas de clientes para um dos locais disponíveis. O balanceador de carga garante que as políticas de balanceamento de carga sejam aplicadas e que os clientes sejam direcionados para o local correto do aplicativo e do banco de dados.

Particionada sem dependência entre bancos de dados

Esse padrão de implantação é o mais simples de todos os padrões discutidos neste documento: cada local ou nuvem tem um banco de dados e os bancos de dados contêm conjuntos de dados particionados que não dependem uns dos outros. Um item de dados é armazenado em apenas um banco de dados. Cada partição de dados está localizada em um banco de dados próprio. Um exemplo para esse padrão é um aplicativo multilocatário, em que um conjunto de dados está em um banco de dados. O diagrama a seguir mostra dois aplicativos totalmente particionados.

Como mostra o diagrama anterior, um aplicativo é implantado em dois locais, cada um responsável por uma partição de todo o conjunto de dados. Cada item de dados reside em apenas um dos locais, garantindo um conjunto de dados particionado sem replicação entre os dois.

Um padrão alternativo de implantação para bancos de dados particionados é quando o conjunto de dados é completamente particionado, mas ainda é armazenado no mesmo banco de dados. Há apenas um banco de dados que contém todos os conjuntos de dados. Embora os conjuntos de dados estejam armazenados no mesmo banco de dados, os conjuntos de dados são completamente separados (particionados) e uma alteração em um não causa alterações em outro. O diagrama a seguir mostra dois aplicativos que compartilham um único banco de dados.

O diagrama anterior mostra o seguinte:

• Duas implantações de aplicativos que compartilham um banco de dados comum, que está no primeiro local.
• Cada aplicativo pode acessar todos os dados na implantação porque o conjunto de dados não é particionado.

Replicação unidirecional assíncrona

Esse padrão de implantação tem um banco de dados primário que é replicado para um ou mais bancos de dados secundários. O banco de dados secundário pode ser usado para acesso de leitura, mas o aplicativo precisa levar em conta o possível atraso da replicação. Um exemplo desse padrão é quando o melhor banco de dados para um caso de uso específico é usado como banco de dados primário e o secundário é usado para análise. O diagrama a seguir mostra dois aplicativos que acessam bancos de dados replicados unidirecionalmente.

Como mostra o diagrama anterior, um dos dois bancos de dados é uma réplica do outro. A seta no diagrama indica a direção da replicação: os dados do sistema de banco de dados no local 1 são replicados para o sistema de banco de dados no local 2.

Replicação bidirecional com resolução de conflitos

Esse padrão de implantação tem dois bancos de dados primários que são replicados de maneira assíncrona. Se os mesmos dados forem gravados ao mesmo tempo em cada banco de dados (por exemplo, a mesma chave primária), poderá causar um conflito de gravação/gravação. Devido a esse risco, deve haver uma resolução de conflito para determinar qual estado é o último durante a replicação. Esse padrão pode ser usado em situações em que a chance de um conflito de gravação e gravação é rara. O diagrama a seguir mostra dois aplicativos que acessam bancos de dados replicados bidirecionalmente.

Como mostra o diagrama anterior, cada banco de dados é replicado para o outro. As duas replicações são independentes umas das outras, conforme indicado no diagrama por duas setas azuis separadas. Como as duas replicações são independentes, pode ocorrer um conflito se, por acaso, o mesmo item de dados for alterado por cada um dos aplicativos e replicado simultaneamente. Nesse caso, a resolução de conflitos precisa ocorrer.

Sistema distribuído totalmente ativo-ativo e sincronizado

Esse padrão de implantação tem um único banco de dados que tem uma configuração ativo-ativo (também primário). Em uma configuração ativo-ativo, uma atualização de dados em qualquer banco de dados primário é consistente em termos de transação e é replicada de forma síncrona. Um exemplo de caso de uso para esse padrão é a computação distribuída. No diagrama a seguir, mostramos dois aplicativos que acessam um banco de dados primário-primário totalmente sincronizado.

Como mostra o diagrama anterior, essa disposição garante que cada aplicativo sempre acesse o último estado consistente, sem atraso ou risco de conflito. Uma alteração em um banco de dados fica imediatamente disponível no outro banco de dados. Qualquer alteração é refletida nos dois bancos de dados quando ocorre uma alteração de transação.

Categorização do sistema de banco de dados

Nem todos os sistemas de gerenciamento de banco de dados podem ser usados igualmente bem para os padrões de implantação discutidos neste documento. Dependendo do caso de uso, só é possível implementar um padrão de implantação ou uma combinação de padrões de implantação com apenas um subconjunto de sistemas de banco de dados.

Na seção a seguir, os diferentes sistemas de banco de dados são categorizados e mapeados para os quatro padrões de implantação.

É possível categorizar bancos de dados por diferentes dimensões, como modelo de dados, arquitetura interna, modelo de implantação e tipos de transação. Na seção a seguir, para fins de gerenciamento de banco de dados de várias nuvens, duas dimensões são usadas:

• Arquitetura de implantação. A arquitetura de como um sistema de gerenciamento de banco de dados é implantado em recursos de nuvens (por exemplo, mecanismos de computação ou gerenciados na nuvem).
• Modelo de distribuição. O modelo de distribuição que um sistema de banco de dados suporta (por exemplo, instância única ou totalmente distribuída).

Essas duas dimensões são as mais relevantes no contexto de casos de uso em várias nuvens e são compatíveis com os quatro padrões de implantação derivados dos casos de uso de banco de dados de várias nuvens. Uma categorização popular é baseada nos modelos de dados compatíveis com um sistema de gerenciamento de banco de dados. Alguns sistemas aceitam apenas um modelo (por exemplo, um modelo de gráfico). Outros sistemas suportam vários modelos de dados ao mesmo tempo (por exemplo, modelos relacionais e de documentos). No entanto, no contexto do gerenciamento de bancos de dados de várias nuvens, essa categorização não é relevante porque os aplicativos de várias nuvens podem usar qualquer modelo de dados para a implantação de várias nuvens.

Sistema de banco de dados por arquitetura de implantação

O gerenciamento de banco de dados de várias nuvens inclui as seguintes quatro classes principais de arquitetura de implantação para sistemas de gerenciamento de banco de dados:

• Bancos de dados na nuvem integrados. Os bancos de dados na nuvem integrados são projetados, criados e otimizados para funcionar com a tecnologia de nuvem. Por exemplo, alguns sistemas de banco de dados usam o Kubernetes como plataforma de implementação e usam a funcionalidade do Kubernetes. CockroachDB e YugaByte são exemplos desse tipo de banco de dados. Eles podem ser implantados em qualquer nuvem compatível com o Kubernetes.
• Bancos de dados gerenciados pelo provedor do Cloud. Os bancos de dados gerenciados pelo provedor de nuvem são baseados em tecnologias específicas do provedor de nuvem e são um serviço gerenciado por um provedor específico. Spanner, Bigtable e AlloyDB para PostgreSQL são exemplos desse tipo de banco de dados. Os bancos de dados gerenciados pelo provedor de nuvem estão disponíveis apenas na nuvem do provedor de nuvem e não podem ser instalados e executados em outro lugar. No entanto, o AlloyDB para PostgreSQL é totalmente compatível com o PostgreSQL.
• Bancos de dados pré-nuvem. Os bancos de dados pré-cloud existiam antes do desenvolvimento da tecnologia de nuvem (às vezes por um longo tempo) e geralmente são executados em hardware bare metal e máquinas virtuais (VMs). PostgreSQL, MySQL e SQL Server são exemplos desse tipo de banco de dados. Esses sistemas podem ser executados em qualquer nuvem com suporte às VMs ou hardware bare metal necessários.
• Bancos de dados gerenciados pelo parceiro do Cloud. Algumas nuvens públicas têm parceiros de banco de dados que instalam e gerenciam os bancos de dados dos clientes na nuvem pública. Por esse motivo, os clientes não precisam gerenciar esses bancos de dados por conta própria. O MongoDB Atlas e o MariaDB são exemplos desse tipo de banco de dados.

Há algumas variantes dessas categorias principais. Por exemplo, um fornecedor de banco de dados que implementa um banco de dados criado para a nuvem também pode fornecer uma instalação sobre tecnologia criada para a nuvem e uma oferta gerenciada para os clientes na nuvem fornecida pelo fornecedor. Essa abordagem é equivalente ao fornecedor de uma nuvem pública compatível apenas com seu banco de dados como um único serviço.

Os bancos de dados pré-cloud também podem estar em contêineres e ser implantáveis em um cluster do Kubernetes. No entanto, esses bancos de dados não usam funcionalidades específicas do Kubernetes, como escalonamento, serviços diversos ou implantação de vários pods.

Os fornecedores de banco de dados podem fazer parceria com mais de um provedor de nuvem pública ao mesmo tempo, oferecendo seu banco de dados como um banco de dados gerenciado por parceiro em nuvem em mais de uma nuvem pública.

Sistema de banco de dados por modelo de distribuição

Diferentes sistemas de gerenciamento de banco de dados são implementados de acordo com os modelos de distribuição na arquitetura de um banco de dados. Os modelos de bancos de dados são os seguintes:

• Instância única. Uma única instância de banco de dados é executada em uma VM ou em um contêiner e atua como um sistema centralizado. Esse sistema gerencia todo o acesso ao banco de dados. Como a única instância não pode ser conectada a outra instância, o sistema de banco de dados não é compatível com replicação.
• Ativo-passivo para várias instâncias. Nessa arquitetura comum, várias instâncias de banco de dados são vinculadas. A vinculação mais comum é um relacionamento ativo-passivo, em que uma instância é a instância de banco de dados ativa que suporta instâncias e gravações e leituras. Um ou mais sistemas passivos são somente leitura e recebem todas as alterações do banco de dados de forma primária de forma síncrona ou assíncrona. Os sistemas passivos podem fornecer acesso de leitura. Também chamada de ativo-passivo ou réplica de origem.
• Ativo de várias instâncias. Nesta arquitetura relativamente incomum, cada instância é uma instância ativa. Nesse caso, cada instância pode executar transações de leitura e gravação e fornecer consistência de dados. Por esse motivo, para evitar inconsistências de dados, todas as instâncias são sempre sincronizadas.
• Ativo de várias instâncias com resolução de conflito. Esse também é um sistema relativamente incomum. Cada instância está disponível para gravação e acesso de leitura. No entanto, os bancos de dados são sincronizados em um modo assíncrono. Atualizações simultâneas do mesmo item de dados são permitidas, o que leva a um estado inconsistente. Uma política de resolução de conflitos precisa decidir qual dos estados é o último estado consistente.
• Fragmentação de várias instâncias. A fragmentação é baseada no gerenciamento de partições (desanexadas) de dados. Uma instância de banco de dados separada gerencia cada partição. Essa distribuição é escalonável porque mais fragmentos podem ser adicionados dinamicamente ao longo do tempo. No entanto, as consultas entre fragmentos talvez não sejam possíveis porque essa funcionalidade não é compatível com todos os sistemas.

Todos os modelos de distribuição discutidos nesta seção podem ser compatíveis com fragmentação e podem ser um sistema fragmentado. No entanto, nem todos os sistemas são projetados para fornecer uma opção de fragmentação. A fragmentação é um conceito de escalonabilidade e geralmente não é relevante para a seleção de banco de dados arquitetônico em ambientes de várias nuvens.

Os modelos de distribuição são diferentes para bancos de dados gerenciados na nuvem e por parceiros. Como esses bancos de dados estão vinculados à arquitetura de um provedor de nuvem, esses sistemas implementam arquiteturas com base nos seguintes locais de implantação:

• Sistema zonal. Um sistema de banco de dados gerenciado por zona está vinculado a uma zona. Quando a zona estiver disponível, o sistema de banco de dados também estará. No entanto, se a zona ficar indisponível, não será possível acessar o banco de dados.
• Sistema regional. Um banco de dados regional gerenciado está vinculado a uma região e é acessível quando pelo menos uma zona pode ser acessada. Qualquer combinação de zonas pode ficar inacessível.
• Sistema entre regiões. Um sistema entre regiões está vinculado a duas ou mais regiões e funciona corretamente quando pelo menos uma região está disponível.

Um sistema entre regiões também pode oferecer suporte a um sistema entre nuvens se o banco de dados puder ser instalado em todas as nuvens que uma empresa pretende usar.

Há outras alternativas possíveis para as arquiteturas de banco de dados gerenciado discutidas nesta seção. Um sistema regional pode compartilhar um disco entre duas zonas. Se uma das duas zonas ficar inacessível, o sistema de banco de dados poderá continuar na zona restante. No entanto, se uma interrupção afetar as duas zonas, o sistema de banco de dados ficará indisponível, mesmo que outras zonas ainda possam estar totalmente on-line.

Como mapear sistemas de banco de dados para padrões de implantação

A tabela a seguir descreve como os padrões de implantação e as arquiteturas de implantação discutidas neste documento se relacionam. Os campos declaram as condições necessárias para que uma combinação seja possível, com base no padrão e na arquitetura de implantação.

Arquitetura de implantação	Padrão de implantação
	Particionada sem dependência entre bancos de dados	Replicação unidirecional assíncrona	Replicação bidirecional com resolução de conflitos	Sistema distribuído totalmente ativo-ativo e sincronizado
Bancos de dados na nuvem integrados	Possível para todas as nuvens que fornecem tecnologia de nuvem integrada usada por sistemas de banco de dados. Se o mesmo banco de dados não estiver disponível, diferentes sistemas de banco de dados poderão ser usados.	Banco de dados da nuvem que fornece replicação.	Banco de dados em nuvem que fornece replicação bidirecional.	Banco de dados da nuvem que fornece sincronização primária primária.
Bancos de dados gerenciados pelo provedor de nuvem	Os sistemas de banco de dados podem ser diferentes em nuvens diferentes.	A réplica não precisa ser o banco de dados gerenciado pelo provedor de nuvem. Consulte O papel da tecnologia de migração de banco de dados nos padrões de implantação.	Somente em uma nuvem, não entre nuvens, se o banco de dados fornecer replicação bidirecional.	Apenas em uma nuvem, e não entre nuvens, se o banco de dados oferecer sincronização primária principal.
Bancos de dados pré-nuvem	Os sistemas de banco de dados podem ser iguais ou diferentes em nuvens diferentes.	A replicação é possível em várias nuvens.	O sistema de banco de dados oferece replicação bidirecional e resolução de conflitos.	O sistema de banco de dados oferece sincronização primário-principal.
Bancos de dados gerenciados pelo parceiro do Cloud	Os sistemas de banco de dados podem ser diferentes em nuvens diferentes. Se o parceiro fornecer um sistema de banco de dados gerenciado em todas as nuvens necessárias, o mesmo banco de dados poderá ser usado.	A réplica não precisa ser o banco de dados gerenciado pelo provedor de nuvem. Se o parceiro fornecer um sistema de banco de dados gerenciado em todas as nuvens necessárias, o mesmo banco de dados poderá ser usado.	O sistema de banco de dados oferece replicação bidirecional e resolução de conflitos.	O sistema de banco de dados oferece sincronização primário-principal.

Se um sistema de banco de dados não fornece replicação incorporada, pode ser possível usar a tecnologia de replicação de banco de dados. Para mais informações, consulte O papel da tecnologia de migração de banco de dados em padrões de implantação.

A tabela a seguir relaciona os padrões de implantação aos modelos de distribuição. Os campos indicam as condições para as quais a combinação é possível dado um padrão de implantação e um modelo de distribuição.

Modelo de distribuição	Padrão de implantação
	Particionada sem dependência entre bancos de dados	Replicação unidirecional assíncrona	Replicação bidirecional com resolução de conflitos	Sistema distribuído totalmente ativo-ativo e sincronizado
Instância única	Possível com o mesmo sistema de banco de dados ou um diferente nas nuvens envolvidas.	Não relevante	Não relevante	Não relevante
Várias instâncias ativas-passivas	Possível com o mesmo sistema de banco de dados ou um diferente nas nuvens envolvidas.	A replicação é possível entre nuvens.	A replicação é possível entre nuvens.	Não relevante
Várias instâncias ativas-ativas	Possível com o mesmo sistema de banco de dados ou um diferente nas nuvens envolvidas.	Não relevante	Não relevante	A sincronização é possível entre as nuvens.
Várias instâncias ativas-ativas com resolução de conflitos	Possível com o mesmo sistema de banco de dados ou um diferente nas nuvens envolvidas.	Não relevante	Não relevante	Aplicável se a replicação bidirecional for possível entre nuvens.

Algumas implementações de modelos de distribuição que adicionam abstração adicional com base na tecnologia de banco de dados subjacente não têm esse modelo de distribuição integrado, por exemplo, Postgres-BDR. sistema ativo-ativo. Esses sistemas estão incluídos na tabela anterior na respectiva categoria. Do ponto de vista da várias nuvens, é irrelevante como um modelo de distribuição é implementado.

Migração e replicação de banco de dados

Dependendo do caso de uso, uma empresa pode precisar migrar um banco de dados de um local de implantação para outro. Como alternativa, para processamento downstream, pode ser necessário replicar os dados de um banco de dados para outro local. Na seção a seguir, a migração do banco de dados e a replicação do banco de dados são discutidas em mais detalhes.

Migração de banco de dados

A migração de banco de dados é usada quando um banco de dados está sendo movido de um local de implantação para outro. Por exemplo, um banco de dados em execução em um data center local é migrado para ser executado na nuvem. Após a conclusão da migração, o banco de dados é encerrado no data center local.

As principais abordagens para a migração de banco de dados são as seguintes:

• Migração lift-and-shift. A VM e os discos que executam as instâncias do banco de dados são copiados para o ambiente de destino como estão. Depois de copiados, eles são iniciados e a migração é concluída.
• Exportar e importar, fazer backup e restaurar. Essas abordagens usam a funcionalidade do sistema de banco de dados para externalizar um banco de dados e recriá-lo no local de destino. A exportação/importação geralmente é baseada em um formato ASCII, enquanto o backup e a restauração são baseados em um formato binário.
• Migração sem inatividade. Nessa abordagem, um banco de dados é migrado enquanto os sistemas de aplicativos acessam o sistema de origem. Após um carregamento inicial, as alterações são transmitidas da origem para o banco de dados de destino usando as tecnologias de captura de dados de alterações (CDC, na sigla em inglês). O aplicativo gera inatividade a partir do momento em que é interrompido no sistema de banco de dados de origem até que seja reiniciado no sistema de banco de dados de destino após a conclusão da migração.

A migração do banco de dados se torna relevante em casos de uso de várias nuvens quando um banco de dados é movido de uma nuvem para outra ou de um tipo de mecanismo de banco de dados para outro.

A migração de banco de dados é um processo multifacetado. Para mais informações, consulte Migração do banco de dados: conceitos e princípios (Parte 1) e Migração do banco de dados: conceitos e princípios (Parte 2).

As tecnologias de banco de dados integradas podem ser usadas para fazer a migração de banco de dados. Por exemplo, exportação/importação, backup/restauração ou protocolos de replicação integrados. Quando os sistemas de origem e de destino são sistemas de banco de dados diferentes, as tecnologias de migração são a melhor opção para a migração de banco de dados. O Database Migration Service, o Striim e o Debezium são exemplos de tecnologias de migração de banco de dados.

Réplica do banco de dados

A replicação do banco de dados é semelhante à migração do banco de dados. No entanto, durante a replicação do banco de dados, o sistema de banco de dados de origem permanece em vigor enquanto todas as alterações são transmitidas para o banco de dados de destino.

A replicação de banco de dados é um processo contínuo que envia alterações do banco de dados de origem para o de destino. Quando esse processo é assíncrono, as alterações chegam ao banco de dados de destino após um pequeno atraso. Se o processo for síncrono, as alterações no sistema de origem serão feitas no sistema de destino ao mesmo tempo e nas mesmas transações.

Além de replicar uma origem para um banco de dados de destino, uma prática comum é replicar dados de um banco de dados de origem para um sistema de análise de destino.

Assim como na migração do banco de dados, se houver protocolos disponíveis, a tecnologia de banco de dados integrada poderá ser usada para a replicação do banco de dados. Se não houver protocolos de replicação integrados, é possível usar tecnologia de replicação, como Striim ou Debezium.

O papel da tecnologia de migração de banco de dados nos padrões de implantação

A tecnologia de banco de dados integrada para ativar a replicação geralmente não está disponível quando diferentes sistemas de banco de dados são usados em padrões de implantação, por exemplo, replicação assíncrona (heterogênea). Em vez disso, é possível implantar a tecnologia de migração de banco de dados para permitir esse tipo de replicação. Alguns desses sistemas de migração também implementam a replicação bidirecional.

Se a tecnologia de migração ou replicação de banco de dados estiver disponível para os sistemas de banco de dados usados em combinações marcadas como "Não aplicável" na Tabela 1 ou na Tabela 2 em Como mapear sistemas de banco de dados para padrões de implantação Depois, será possível usá-lo para a replicação do banco de dados. O diagrama a seguir mostra uma abordagem para replicação de banco de dados usando uma tecnologia de migração.

No diagrama anterior, o banco de dados no local 1 é replicado para o banco de dados no local 2. Em vez de uma replicação direta do sistema de banco de dados, um servidor de migração é implantado para implementar a replicação. Essa abordagem é usada para sistemas de banco de dados que não têm a funcionalidade de replicação de banco de dados integrada à implementação e que precisam contar com um sistema separado do sistema de banco de dados para implementar a replicação.

Escolha do banco de dados de várias nuvens

Os casos de uso de banco de dados de várias nuvens combinados com a classificação do sistema de banco de dados ajudam a decidir quais bancos de dados são melhores para um determinado caso de uso. Por exemplo, para implementar o caso de uso em Portabilidade de aplicativos, há duas opções. A primeira opção é garantir que o mesmo mecanismo de banco de dados esteja disponível em todas as nuvens. Essa abordagem garante a portabilidade do sistema. A segunda opção é garantir que o mesmo modelo de dados e interface de consulta estejam disponíveis para todas as nuvens. Os sistemas de banco de dados podem ser diferentes, mas a portabilidade é fornecida em uma interface funcional.

As árvores de decisão nas seções a seguir mostram os critérios de tomada de decisão dos casos de uso do banco de dados de várias nuvens neste documento. As árvores de decisão sugerem o melhor banco de dados a ser considerado para cada caso de uso.

Práticas recomendadas para o sistema de banco de dados atual

Se um sistema de banco de dados estiver em produção, será preciso tomar uma decisão sobre manter ou substituir. No diagrama a seguir, mostramos as perguntas a serem feitas no processo de decisão:

As perguntas e respostas na árvore de decisão são as seguintes:

• Há um sistema de banco de dados em produção?
  • Se nenhum sistema de banco de dados estiver em produção, selecione um sistema de banco de dados (pule para Decisão sobre gerenciamento de banco de dados de várias nuvens).
  • Se um sistema de banco de dados estiver em produção, avalie se ele precisa ser retido.
• Se um sistema de banco de dados estiver em produção, avalie se ele deve ser retido.
  • Se o sistema de banco de dados precisar ser mantido, a decisão será tomada e o processo de decisão será concluído.
  • Se o sistema de banco de dados precisar ser alterado ou se a decisão ainda estiver sendo tomada, selecione um sistema de banco de dados (pule para a Decisão sobre o gerenciamento de banco de dados de várias nuvens).

Decisão sobre o gerenciamento de banco de dados de várias nuvens

A árvore de decisão a seguir é para um caso de uso com um requisito de banco de dados de vários locais (incluindo uma implantação de banco de dados de várias nuvens). Ele usa o padrão de implantação como base para os critérios de tomada de decisão.

As perguntas e respostas na árvore de decisão são as seguintes:

• Os dados são particionados em diferentes bancos de dados sem qualquer dependência entre bancos de dados?
  • Em caso afirmativo, sistemas de banco de dados iguais ou diferentes podem ser selecionados para cada local.
  • Se não, vá para a próxima pergunta.
• A replicação unidirecional assíncrona é necessária?
  • Em caso afirmativo, avalie se um sistema de replicação de banco de dados é aceitável.
    • Em caso afirmativo, selecione os mesmos sistemas de banco de dados ou diferentes que sejam compatíveis com o sistema de replicação.
    • Em caso negativo, selecione um sistema de banco de dados que possa implementar um modelo de distribuição ativo-passivo.
    • Se não, vá para a próxima pergunta.
• Selecione um sistema de banco de dados com instâncias sincronizadas.
  • A resolução de conflitos é aceitável?
    • Em caso afirmativo, selecione um sistema de banco de dados de replicação bidirecional ou um sistema de banco de dados ativo-ativo.
    • Caso contrário, selecione um sistema ativo-ativo.

Se mais de um caso de uso de várias nuvens for implementado, uma empresa precisará decidir se quer usar um sistema de banco de dados compatível com todos os casos de uso ou vários sistemas de banco de dados.

Se uma empresa quiser usar um sistema de banco de dados compatível com todos os casos de uso, o sistema com a melhor sincronização será a melhor escolha. Por exemplo, se a replicação unidirecional for necessária e as instâncias sincronizadas, a melhor opção serão as instâncias sincronizadas.

A hierarquia da qualidade da sincronização é (de nenhuma para a melhor): replicação particionada, unidirecional, bidirecional e totalmente sincronizada.

Práticas recomendadas de implantação

Nesta seção, destacamos as práticas recomendadas a serem seguidas ao escolher um banco de dados para migração ou desenvolvimento de aplicativos de várias nuvens.

Sistema de gerenciamento de banco de dados existente

Recomenda-se reter um banco de dados e não fazer alterações no sistema de banco de dados, a menos que seja exigido por um caso de uso específico. Para uma empresa com um sistema de gerenciamento de banco de dados estabelecido e que tenha processos eficazes de desenvolvimento, operacional e de manutenção, é melhor evitar alterações.

Um caso de uso de bursting de nuvem que não requer um sistema de banco de dados na nuvem pode não precisar de uma mudança de banco de dados. Outro caso de uso é a replicação assíncrona para um local de implantação diferente dentro da mesma nuvem ou para outra nuvem. Para esses casos de uso, uma boa abordagem é implementar um comparativo de mercado e verificar se a comunicação entre locais e se a comunicação e a latência entre locais satisfazem os requisitos do aplicativo ao acessar o banco de dados.

Sistema de banco de dados como um serviço do Kubernetes

Se uma empresa estiver pensando em executar um sistema de banco de dados no Kubernetes como um serviço baseado em StatefulSets, considere os seguintes fatores:

• Se o banco de dados fornecer o modelo exigido pelo aplicativo.
• Fatores não funcionais que determinam como a operacionalização é implementada em um sistema de banco de dados como um serviço do Kubernetes. Por exemplo, como o escalonamento é feito (escalonamento vertical) e como o backup e a restauração são gerenciados. como o monitoramento é disponibilizado pelo sistema. Para ajudá-los a entender os requisitos de um sistema de banco de dados baseado em Kubernetes, as empresas precisam usar suas experiências com bancos de dados como ponto de comparação.
• Alta disponibilidade e recuperação de desastres. Para fornecer alta disponibilidade, o sistema precisa continuar operando quando uma zona em uma região falha. O banco de dados precisa ser capaz de fazer o failover rapidamente de uma zona para outra. Na melhor das hipóteses, o banco de dados tem uma instância em execução em cada zona que está totalmente sincronizada para um RTO e RPO de zero.
• Recuperação de desastres para resolver a falha de uma região (ou nuvem). Em um cenário ideal, o banco de dados continua funcionando em uma segunda região com um RPO e RTO zero. Em um cenário menos ideal, o banco de dados na região secundária pode não ser totalmente recuperado em todas as transações do banco de dados primário.

Para determinar a melhor maneira de executar um banco de dados no Kubernetes, uma avaliação completa do banco de dados é uma boa abordagem, especialmente quando o sistema precisa ser comparável a um sistema em produção fora do Kubernetes.

Sistema de banco de dados independente do Kubernetes

Nem sempre é necessário que um aplicativo implementado como serviços no Kubernetes tenha o banco de dados em execução no Kubernetes ao mesmo tempo. Há muitos motivos para um sistema de banco de dados precisar ser executado fora do Kubernetes. Por exemplo, processos estabelecidos, conhecimento do produto em uma empresa ou indisponibilidade. Os provedores de nuvem e os bancos de dados gerenciados pelo parceiro de nuvem se encaixam nessa categoria.

É igualmente possível e viável executar um banco de dados em um mecanismo de computação. Ao selecionar um sistema de banco de dados, é recomendável fazer uma avaliação completa do banco de dados para garantir que todos os requisitos para um aplicativo sejam atendidos.

Do ponto de vista do design do aplicativo, o pool de conexões é uma consideração importante do design. Um serviço de aplicativo que acessa um banco de dados pode usar um pool de conexões internamente. Usar um pool de conexões é bom para eficiência e latência reduzida. As solicitações são retiradas do pool sem a necessidade de que sejam iniciadas, e não é necessário esperar a criação de conexões. Se o aplicativo for escalonado com a adição de instâncias de serviço de aplicativo, cada instância criará um pool de conexões. Se as práticas recomendadas forem seguidas, cada pool pré-criará um conjunto mínimo de conexões. Sempre que outra instância de serviço de aplicativo é criada para escalonamento de aplicativos, as conexões são adicionadas ao banco de dados. Do ponto de vista do design, como os bancos de dados não são compatíveis com conexões ilimitadas, a adição de conexões precisa ser gerenciada para evitar sobrecarga.

Melhor sistema de banco de dados versus portabilidade de sistema de banco de dados

Ao selecionar sistemas de banco de dados, é comum que as empresas selecionem o melhor sistema de banco de dados para atender aos requisitos de um aplicativo. Em um ambiente de várias nuvens, o melhor banco de dados em cada nuvem pode ser selecionado e pode ser conectado um ao outro com base no caso de uso. Se esses sistemas forem diferentes, qualquer replicação unidirecional ou bidirecional exigirá um esforço significativo. Essa abordagem pode ser justificada se o benefício de usar o melhor sistema superar o esforço necessário para implementá-lo.

No entanto, uma prática recomendada é considerar e avaliar simultaneamente uma abordagem para um sistema de banco de dados disponível em todas as nuvens necessárias. Embora esse banco de dados possa não ser o ideal como a melhor opção, pode ser muito mais fácil implementar, operar e manter esse sistema.

Uma avaliação simultânea do sistema de banco de dados demonstra as vantagens e desvantagens dos dois sistemas de banco de dados, fornecendo uma base sólida para a seleção.

Replicação interna ou externa do sistema de banco de dados

Para casos de uso que exigem um sistema de banco de dados em todos os locais de implantação (zonas, regiões ou nuvens), a replicação é um recurso importante. A replicação pode ser replicação assíncrona-síncrona, bidirecional ou totalmente ativa-ativa. Nem todos os sistemas de banco de dados são compatíveis com todas essas formas de replicação.

Para os sistemas que não são compatíveis com a replicação como parte da replicação de implementação do sistema, sistemas como Striim podem ser usados para complementar a arquitetura (como discutido em Migração do banco de dados.

Uma prática recomendada é avaliar sistemas de gerenciamento de banco de dados alternativos para determinar as vantagens e desvantagens de um sistema que tenha replicação integrada ou um sistema que exija tecnologia de replicação.

Uma terceira classe de tecnologia também desempenha um papel nesse caso. Essa classe oferece complementos para sistemas de banco de dados atuais para fornecer replicação. Um exemplo é o cluster do MariaDB Galera. Se o processo de avaliação permitir, avaliar esses sistemas é uma boa prática.

A seguir

• Saiba mais sobre os padrões e práticas híbridas e de várias nuvens.
• Leia sobre padrões de conexão de outros provedores de serviços em nuvem com o Google Cloud.
• Saiba mais sobre como monitorar e gerar registros de arquiteturas para implantações de nuvem híbrida e várias nuvens no Google Cloud.
• Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.

Colaboradores

Autor: Alex Cârciu | Arquiteto de soluções