Como arquitetar a migração e a replicação de bancos de dados usando o Striim

Este documento descreve o uso do Striim (em inglês) para arquitetar a migração e a replicação do banco de dados. Neste documento, focamos nos conceitos de arquitetura relacionados à migração do banco de dados e à replicação contínua. Ele é destinado a arquitetos e engenheiros de bancos de dados, bem como aos proprietários de dados que planejam migrar ou replicar fontes de dados para o Google Cloud.

Introdução à migração e à replicação de banco de dados

Muitas empresas buscam uma estratégia de aplicativos que prioriza a nuvem. Para isso, criam aplicativos de negócios usando serviços e tecnologias baseados em nuvem. Para competir, as empresas diminuem o tempo de lançamento dos serviços e respondem rapidamente às mudanças nas demandas dos clientes e nas condições do mercado. Aplicativos de negócios que aproveitam ao máximo a computação baseada em nuvem de ponta a ponta são essenciais para o crescimento duradouro dos negócios.

Os aplicativos legados essenciais apresentam vários desafios para uma migração em nuvem: migrar o nível do aplicativo, migrar o banco de dados subjacente e manter o acesso de usuário ininterrupto aos aplicativos durante uma migração.

Vários produtos e serviços de migração podem ajudar na migração do nível de aplicativos comerciais. No entanto, a migração dos bancos de dados subjacentes que atendem ao aplicativo de negócios geralmente é o desafio mais difícil.

Na prática, a migração de um banco de dados para a nuvem pode assumir algumas formas diferentes. O diagrama a seguir mostra o caso de uso mais básico: um banco de dados local é migrado para um banco de dados baseado em nuvem, neste caso, o Cloud Spanner.

Arquitetura de migração básica da origem para
o Cloud Spanner.

O diagrama a seguir ilustra um caso de uso mais complexo: mover vários bancos de dados com uma modernização de aplicativo.

Arquitetura de uma migração complexa que envolve vários bancos de dados de origem
e destino que usam um sistema de migração de banco de dados.

Nesta configuração, dois bancos de dados de origem são migrados para dois bancos de dados de destino. Um dos bancos de dados de origem é acessado por um aplicativo que acessa o banco de dados de destino correspondente em um formato modernizado (implementado no Google Kubernetes Engine). O segundo banco de dados de origem também tem clientes (não mostrado no diagrama).

Embora o sistema de migração de banco de dados esteja instalado no Google Cloud, o sistema de migração pode ser instalado em outro lugar. Por exemplo, pode ser necessário executar o sistema de migração no mesmo local do banco de dados de origem por motivos de segurança.

Migrações de banco de dados on-line e lift-and-shift

Em geral, as duas abordagens para a migração de banco de dados são migração on-line e lift-and-shift.

Em uma migração lift-and-shift, você normalmente exporta ou faz backup de um banco de dados de origem, move o arquivo exportado ou de backup para a nuvem e, em seguida, importa e restaura o arquivo para uma instância de banco de dados dd destino em execução na nuvem. Quando o novo banco de dados de destino estiver pronto, os aplicativos empresariais serão executados na nuvem e acessarão dados.

Uma desvantagem da abordagem de migração lift-and-shift é que ela requer inatividade para o aplicativo de negócios e o banco de dados. Essa abordagem requer um planejamento cuidadoso da migração durante períodos de baixa atividade. Essa abordagem também pressupõe que você pode interromper o aplicativo comercial durante a migração e reiniciá-lo depois que o banco de dados for restaurado na nuvem. Qualquer teste do aplicativo depois que o banco de dados é restaurado aumenta a inatividade. Além disso, a abordagem de migração lift-and-shift cria uma cópia intermediária do banco de dados que precisa ser protegida, movida, armazenada e, por fim, excluída. Esse aspecto adiciona custo e complexidade de gerenciamento. A abordagem de migração lift-and-shift pode funcionar para alguns aplicativos, mas os requisitos da maioria dos aplicativos essenciais para os negócios não toleram esses custos. Por esses motivos, uma migração de banco de dados on-line é uma abordagem muito melhor.

A abordagem de migração on-line tem como objetivo minimizar o impacto no desempenho do banco de dados e nos usuários dos aplicativos de negócios. A abordagem on-line permite migrar continuamente seus bancos de dados para a nuvem, mantendo os bancos de dados de origem e destino totalmente sincronizados por meses ou até anos, enquanto você otimiza e testa o aplicativo de negócios para o novo banco de dados baseado em nuvem.

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

Em uma migração de banco de dados para a nuvem, o banco de dados de origem é desativado quando a migração é concluída porque o banco de dados da nuvem agora é a instância de produção.

Em alguns casos de uso, a instância original do banco de dados pode continuar a ser executada enquanto o processamento downstream ocorre no Google Cloud. Nesse caso, o banco de dados de origem é replicado no Google Cloud. Por exemplo, é possível ter um aplicativo que acessa um banco de dados que depende da tecnologia e que não pode ser movido para o Google Cloud. Ao mesmo tempo, a tecnologia do Google Cloud é usada para funcionalidades como análise, por exemplo, para replicação para o BigQuery. Outro exemplo é quando um banco de dados que contém informações de identificação pessoal (PII) precisa residir em um ambiente local enquanto o processamento downstream que usa informações de PII ofuscadas ocorre no Google Cloud.

Nesses casos de uso, o banco de dados original precisa ser replicado continuamente para o destino operacional ou analítico, como o Spanner ou o BigQuery. O banco de dados de origem não é encerrado como acontece com uma migração de banco de dados.

A migração de banco de dados on-line e as replicações para bancos de dados diferentes são complexas, envolvendo meses ou até mesmo anos de codificação manual e integração de vários serviços. Uma abordagem mais moderna e eficiente para migrações de banco de dados on-line é o uso de uma migração de banco de dados e sistemas de integração, como o Striim.

O diagrama a seguir mostra uma arquitetura básica de implantação da plataforma de integração e inteligência de dados Striim com uma fonte e um banco de dados de destino.

Arquitetura de migração básica usando o
Striim.

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

O Striim, um parceiro em tecnologia do Google que fornece tecnologia de migração de banco de dados, simplifica as migrações on-line usando uma interface do tipo arrastar e soltar para configurar o migrações de dados contínuas entre bancos de dados diferentes. Em migrações para o Google Cloud, o Striim oferece uma plataforma de streaming não intrusiva do tipo extração, transformação e carregamento (ETL) que é mais rápida de implantar e mais fácil de iterar do que outras soluções.

A captura de dados de alteração (CDC, na sigla em inglês) não intrusiva permite que o Striim extraia dados em tempo real sem atrasar os bancos de dados transacionais de origem, possibilitando migrações de banco de dados na nuvem sem tempo de inatividade e com risco mínimo. Enquanto os dados estão em trânsito, o Striim pode filtrar, transformar, agregar e enriquecer dados por meio de consultas SQL ao usar um mecanismo abrangente de análise de streaming.

Ao replicar continuamente dados entre bancos de dados locais e do Google Cloud, o Striim oferece suporte à replicação on-line em que aplicativos essenciais continuam em execução sem causar inatividade. Ao proporcionar validação de entrega contínua integrada, alta disponibilidade e failover, o Striim também minimiza o risco de perda de dados.

Casos de uso para migração e replicação de banco de dados

As migrações de banco de dados on-line e a replicação contínua podem ser aplicadas a uma variedade de problemas tecnológicos e específicos do setor (industrial-neutro). Por exemplo, um uso específico do setor pode ser um serviço financeiro que utiliza serviços de dados em nuvem e dados em tempo real. Um caso de uso mais focado em tecnologia pode ser migrações de bancos de dados de relatórios ou migrações por etapas de bancos de dados operacionais. Para permitir esses casos de uso, o Striim oferece pipelines de dados contínuos que fornecem dados no formato certo, no momento certo.

Esta seção discute o uso do Striim para migrar bancos de dados para um caso de uso específico do setor e dois casos de uso tecnológico.

Tecnologia financeira

Empresas de tecnologia financeira (fintech) exigem dados rápidos e precisos. Por exemplo, os clientes bancários querem ver as transações e os novos saldos publicados nas contas deles imediatamente. Tomadores de empréstimo e credores querem economizar tempo com as origens do empréstimo. Empresas de Fintech podem usar a Striim para atender a diversos requisitos de negócios, como esses.

Considere um funcionário automatizado e um serviço de verificação de renda que acelere as origens do empréstimo. Nesse caso de uso, o Striim integra dados em tempo real de várias fontes locais ao Google Cloud. Essa automação reduz os atrasos no processo de verificação de emprego. O diagrama a seguir ilustra a arquitetura desse caso de uso.

Caso de uso de fintech que faz stream de dados para o Google Cloud usando
o Striim.

Esta arquitetura aproveita a integração de dados de streaming em tempo real do Striim. O Striim coleta continuamente dados de várias fontes externas e internas, por exemplo, folha de pagamento de processadores, como ADP, e dados demográficos e de funcionários de outros provedores. Em seguida, o Striim envia os dados para vários serviços do Google Cloud. O Striim ingere continuamente dados de bancos de dados relacionais usando o CDC baseado em registros, acessando arquivos de trilha do Oracle® GoldenGate, quando aplicável, e até mesmo de arquivos simples. O Striim envia os dados agregados e transformados continuamente ao Cloud Storage para potencializar aplicativos e serviços empresariais criados para a nuvem.

Descarregando os relatórios

Para alguns casos de uso tecnológico, é feita uma distinção entre cargas de trabalho transacionais e analíticas. Devido ao maior impacto no desempenho do banco de dados transacional de origem e à maior latência no retorno de consultas analíticas, não faz sentido executar consultas analíticas em bancos de dados transacionais.

Para lidar com essa distinção, forneça continuamente um subconjunto dos seus dados transacionais ao Google Cloud para executar análises e relatórios adicionais no BigQuery. O diagrama a seguir mostra um exemplo de arquitetura.

Arquitetura que divide cargas de trabalho entre bancos de dados transacionais e analíticos.

O Striim é capaz de transformar e normalizar dados em pipelines de dados de streaming, podendo integrar um subconjunto selecionado dos dados transacionais de origem às plataformas de análise enquanto os dados restantes são migrados continuamente para um ou mais destinos de dados do Google Cloud.

Migração por etapas

Grandes empresas têm bancos de dados locais extensos que armazenam anos de dados valiosos. A migração desses bancos de dados para a nuvem é uma tarefa laboriosa que pode levar anos. Manter os bancos de dados legados também tem um custo, por exemplo, a oportunidade perdida de implementar novas tecnologias de banco de dados de nuvem, como BigQuery, Cloud Spanner e Pub/Sub.

Para encontrar um equilíbrio entre manter sistemas legados e aproveitar as tecnologias de banco de dados em nuvem mais recentes, é possível migrar subconjuntos de dados para bancos de dados do Google Cloud usando o Striim em uma abordagem em etapas e manter os bancos de dados de produção de origem em execução. Começar com um pequeno subconjunto também permite que os desenvolvedores testem o nível do aplicativo no novo banco de dados da nuvem sem afetar o banco de dados de produção local.

Depois de confirmar que o nível do aplicativo é compatível, é possível aumentar lentamente os subconjuntos migrados até que todo o banco de dados seja migrado. Essa migração permite que você gerencie riscos e migre seus sistemas de produção com o mínimo de inatividade.

Arquitetura de implantação

As arquiteturas de implantação nesta seção mostram os vários bancos de dados, aplicativos e serviços de nuvem envolvidos em diversos casos de uso para migração e replicação de banco de dados.

Arquitetura básica de implantação

O diagrama a seguir mostra uma arquitetura de implantação simples: o sistema de banco de dados de origem é migrado para o sistema de banco de dados baseado em nuvem, o Cloud Spanner. Essa arquitetura é usada ao longo deste documento e funciona para replicação contínua e migrações completas ou em etapas.

Arquitetura de migração básica usando o
Striim.

Nesta arquitetura, o sistema de banco de dados de origem é migrado para o sistema de banco de dados baseado em nuvem, que nesse caso é o Cloud Spanner. O sistema de migração de banco de dados, o Striim, está conectado aos dois sistemas e migra os dados da origem para o sistema de banco de dados de destino.

Arquitetura de implantação de complexidade média

O diagrama a seguir mostra uma arquitetura que envolve dois sistemas de banco de dados de origem. Essa arquitetura é mais complexa que a arquitetura anterior e funciona para a migração e replicação de bancos de dados.

Migração de bancos de dados no local e de origem na nuvem para bancos de dados de
destino transacionais e analíticos.

No diagrama, mostramos a arquitetura inicial com dois sistemas de banco de dados de origem. Uma origem é um sistema de banco de dados (S1) em execução em uma nuvem pública que precisa ser migrada. A segunda fonte é um sistema de banco de dados (S2) em execução em um data center no local que permanece no local, enquanto os dados e as alterações subsequentes são replicados para o BigQuery para análise. Foram implantados dois sistemas de banco de dados de destino: o Cloud Spanner para receber os dados de S1 (migração) e o BigQuery para receber fluxos contínuos de dados do S2.

O diagrama a seguir representa a arquitetura de implantação depois que a migração do banco de dados é concluída. O S1 é encerrado. e o destino do Cloud Spanner correspondente não está mais conectado ao Strim.

Arquitetura depois que a migração é concluída, em que o banco de dados transacional é
desconectado do
Striim.

Esse cenário demonstra que a arquitetura de implantação não é necessariamente estática. Alguns casos de uso, como uma migração de banco de dados única, exigem que o sistema de migração esteja conectado aos sistemas ou serviços até que a migração seja concluída. Outros casos de uso são mais estáticos, como no caso de replicação do banco de dados. Essa arquitetura mostra como uma arquitetura pode atender a vários casos de uso.

Arquitetura de implantação complexa

Esta seção descreve uma migração projetada como fallback. Um fallback pode ser necessário quando os erros que ocorrem depois da migração exigem que você retorne ao processamento na origem. A configuração de subtituto garante que, quando uma migração for revertida, as alterações no destino serão comunicadas para a origem.

Essa arquitetura de implantação envolve replicação e migração e é a mais complexa das três arquiteturas discutidas neste documento.

Essa arquitetura também demonstra como o Striim pode operar em um ambiente em cluster para acomodar uma maior capacidade. O cluster na arquitetura a seguir consiste em três instâncias do Compute Engine para fornecer capacidade suficiente. Cada instância do Compute Engine é colocada em uma zona diferente, que fornece alta disponibilidade para proteção contra falhas de zona e de instância.

Nesse caso, dois bancos de dados de origem localizados em um data center no local são replicados para a nuvem. Um banco de dados é replicado para o Cloud Spanner e o outro para o BigQuery. Além disso, a migração move os dados de um banco de dados em uma nuvem pública para uma instância do Cloud SQL.

O diagrama a seguir mostra a arquitetura de implantação antes da migração ser concluída.

Arquitetura de vários bancos de dados de origem e de destino usando o sistema de migração Striim.

Três bancos de dados de origem estão conectados ao Striim, que migra e replica dados para três bancos de dados de destino. Os dois bancos de dados de origem no data center no local são replicados para o BigQuery e o Cloud Spanner, e o banco de dados de origem na nuvem é migrado para o Cloud SQL.

Depois que a migração é concluída, o fluxo é revertido do Cloud SQL para o banco de dados na nuvem e a fim de se preparar para um possível fallback. Para garantir que todas as alterações no destino também estejam disponíveis na origem, é necessário configurar uma migração reserva após a migração original.

O diagrama a seguir mostra a alteração de configuração para um possível fallback.

Arquitetura de fallback para banco de dados de origem usando o sistema de migração
Striim.

A direção do fluxo de dados é invertida entre o banco de dados de origem da nuvem e o Cloud SQL. Depois que a migração for concluída e for descartada a necessidade de um fallback, os sistemas relacionados na migração serão desconectados, incluindo o Cloud SQL e o banco de dados de origem no data center no local.

O diagrama a seguir mostra como essa arquitetura de implantação é compatível com o caso de uso de replicação contínua.

Arquitetura de replicação contínua de dois bancos de dados de origem no local para
vários destinos usando o
Striim.

Os dois bancos de dados de origem no data center bi local são replicados continuamente para o BigQuery e o Cloud Spanner.

Conforme esta discussão mostra, essa arquitetura de implantação é compatível com vários casos de uso, independentemente da complexidade. A configuração também pode ser alterada dinamicamente, por exemplo, quando a direção do movimento de dados é invertida.

Essa arquitetura também pode ser escalonada para ajudar a acomodar uma carga ou picos maiores.

Complexidade da arquitetura de implantação versus especificação de migração

Nas arquiteturas anteriores, as duas dimensões de complexidade incluem o seguinte:

  • Número de sistemas de banco de dados conectados ao Striim
  • Alteração da arquitetura de implantação ao longo do tempo à medida que os casos de uso são concluídos

A complexidade também pode ser considerada no contexto das especificações de migração, independentemente da arquitetura de implantação.

Por exemplo, se um banco de dados MySQL no local for migrado para um banco de dados MySQL na nuvem e se o esquema e os dados forem idênticos, a especificação da migração será simples, porque a especificação é uma cópia. No entanto, se a migração for de um banco de dados da Oracle para um banco de dados do Cloud Spanner, a complexidade da migração aumenta significativamente, porque os esquemas de origem e de destino são diferentes, e os dados precisam ser transformados durante a migração.

A tabela a seguir fornece uma abordagem de alto nível para determinar a complexidade de uma especificação de migração. Os recursos são listados junto com uma indicação de complexidade de migração ou replicação. Use a coluna Seu caso de uso para avaliar seus requisitos.

Recurso Similar Diferente Seu caso de uso
Sistema de banco de dados de origem e destino Baixa complexidade Alta complexidade
Esquema do banco de dados de origem e destino Baixa complexidade Alta complexidade
Dados de banco de dados de origem e destino Baixa complexidade Alta complexidade
Particionamento de dados (se houver) Baixa complexidade Alta complexidade
Separação ou consolidação de dados Alta complexidade Alta complexidade

A complexidade da migração é um espectro com base no caso de uso implementado. No seu caso de uso, é possível determinar a complexidade geral com base na proporção de baixa complexidade para alta complexidade para os recursos do seu caso de uso.

Outras considerações podem ser importantes para determinar a complexidade, especialmente em casos de uso avançados. Exemplo:

  • Vários bancos de dados de origem serão consolidados em um único banco de dados de destino?
  • Os dados de vários bancos de dados de origem serão redistribuídos em um conjunto de bancos de dados de destino, por exemplo, refragmentação ou reparticionamento?
  • Os dados serão enriquecidos ou reduzidos durante a migração para fornecer um conjunto de dados bem selecionado no sistema de destino?

Cada recurso adicionado ao caso de uso aumenta a complexidade dele, e o Striim é um sistema capaz de acomodâ-lo.

A seguir