Migrando databases do Redshift sem afetar aplicações clientes

Por Luiz Yanai

Neste blog post vamos mostrar como é possível migrar um ou mais bancos de dados do Amazon Redshift entre contas da AWS seja por questões de custo, segurança ou mudança de arquitetura, eliminando o impacto no ambiente ao realizar este processo.

O Amazon Redshift é um data warehouse em nuvem totalmente gerenciado e em escala de petabytes, usado por dezenas de milhares de clientes para processar exabytes de dados todos os dias para potencializar sua carga de trabalho analítica ou OLAP (Online Analytical Processing).

É comum nos depararmos com um cenário de migração onde é necessário migrar o cluster atual do Amazon Redshift para outra conta de forma a facilitar ainda mais a segregação de custos e isolamento de segurança. Quando estamos falando de um cenário com poucas aplicações/usuário clientes, esse processo é simples e demanda somente a alteração do endpoint do cluster para o novo ambiente. Contudo, em cenários produtivos em que existem diversos e numerosos clientes do cluster do Redshift é necessário um planejamento mais detalhado para evitar impactos de disponibilidade.

O Amazon Redshift oferece diferentes integrações entre seus cluster para facilitar o acesso aos dados onde quer que estejam eliminando a necessidade de movimentação usando rotinas de ETL (Extract, Transform e Load) por exemplo.

Consultas cross-database em um mesmo cluster do Amazon Redshift

Figura 1: Cluster único do Amazon Redshift com múltiplos databases

O Amazon Redshift suporta consultas cross-databases nos tipos de nós ra3.4xlarge, ra3.16xlarge e ra3.xlplus. Também suporta fazer joins de dados de tabelas ou views englobando um ou mais databases no mesmo cluster do Amazon Redshift (Provisionado ou Serverless).

Na figura 1 temos um cluster do Amazon Redshift contendo diferentes databases (1, 2,… n) que são acessados por usuários, dashboards ou aplicações de BI. Estando o usuário/aplicação conectado no database 1, basta utilizar a notação de 3 partes para facilmente fazer a consulta das tabelas/views de qualquer outro database no mesmo cluster.

--As user1 on db1
SELECT * from db2.public.table2 ORDER BY c1;
c1 | c2 | c3
---+-----+----
1 | 2 | 3
4 | 5 | 6
7 | 8 | 9
(3 rows)

Além da possibilidade do uso de notação de 3 partes pode-se também criar um schema externo em determinado database para referenciar tabelas/views de outro database.

--As user2 on db2
CREATE EXTERNAL SCHEMA db1_public_sch
FROM REDSHIFT DATABASE 'db1' SCHEMA 'public';

SELECT * FROM db1_public_sch.table1 ORDER BY c1;

c1 | c2 | c3
----+----+----
1 | 2 | 3
4 | 5 | 6
7 | 8 | 9
(3 rows)

Uma dúvida que surge é sobre o motivo de se trabalhar com múltiplos databases no mesmo cluster ou dividi-los em diferentes clusters. De forma geral, a segregação em diferentes schemas e também databases é com o intuito de segregação de acesso em ambientes multi-tenant ou mesmo para segregação de acesso mais controlado por diferentes aplicações e usuários. O seguinte blog post discute em detalhes padrões de arquitetura multi-tenant no Amazon Redshift, incluindo possíveis novas topologias com o uso do Redshift data sharing.

https://aws.amazon.com/blogs/big-data/implementing-multi-tenant-patterns-in-amazon-redshift-using-data-sharing/

Consultas cross-database e cross-cluster do Amazon Redshift

Figura 02: Múltiplos clusters do Amazon Redshift com seus respectivos databases

Quando se avalia este tipo de arquitetura que foi apresentada anteriormente onde temos dois databases em um mesmo cluster (possivelmente suportando aplicações diferentes), uma preocupação que pode ser levantada é em relação ao consumo de recursos compartilhados. Se por acaso uma das aplicações tiver um consumo maior de recursos, podendo impactar os demais bancos de dados coexistentes na mesma infraestrutura, esse fenômeno é chamado de noisy neighbor ou vizinho barulhento.

A alternativa mais comum para se evitar isso é quebrar a infraestrutura em diferentes clusters para diferentes aplicações. A nova arquitetura RA3 do Amazon Redshift facilita este cenário porque permite que clusters diferentes compartilhem objetos entre si (tabelas, views, UDFs) usando a feature do Redshift data sharing. Desta forma, evita-se a necessidade de movimentação de dados entre os clusters.

Os objetos compartilhados entre um cluster provedor e outro consumidor são visíveis dentro do cluster consumidor como um database separado. Desta forma, para efetuar uma consulta a view customer_view e join com a tabela orders, ambos pertencentes ao schema public no data share registrado como database tpc, a sintaxe da consulta SQL seria:

SELECT c_mktsegment, o_orderpriority, sum(o_totalprice)
FROM tpc.public.customer_view c
JOIN tpc.public.orders o on c_custkey = o_custkey
GROUP BY c_mktsegment, o_orderpriority;

Isso nos leva ao nosso cenário de estudo inicial: Como impactar o mínimo possível as aplicações, scripts e consultas de usuários ao migrar nossos databases entre ambientes?
Imaginem o seguinte cenário:

A empresa AnyCompany possui um cluster em uma conta de produção que contém diferentes bancos de dados suportando dezenas de aplicações, dashboards, geradores de relatórios e consumo ad hoc por analistas de negócios;
O time de plataforma de dados deseja segregar melhor os recursos de infraestrutura para cada workload que consome este cluster atual (cluster 1) além de fazer uma melhor contabilização de custo de por workload;
Desse modo, eles decidiram migrar grande parte dos databases para uma outra conta da AWS administrada pelo time de plataforma em um novo cluster do Amazon Redshift (cluster 2);
Como o consumo em cima do ambiente atual envolve aplicações desenvolvidas por diferentes áreas de negócios, o time de plataforma quer evitar qualquer impacto que envolva modificação de aplicações, queries, endpoints, se possível.

Estratégia de migração usando Redshift Data Sharing e External Tables

Figura 03: Múltiplos clusters de Amazon Redshift em diferentes contas AWS

Uma vez que os databases foram migrados para o novo cluster do time de plataforma (cluster 2), o passo a passo de configuração da solução para diminuir os impactos nos consumidores finais é o seguinte:

Criar um data share dos objetos que devem continuar sendo utilizados pelas aplicações clientes no cluster 2;
Compartilhar o data share com a conta AWS de produção configurando-a como um data consumer. Autorizar o acesso ao data share para a conta de produção;
Criar um novo database no cluster 1 (ds_cluster2) com base no data share criado e compartilhado com a conta AWS de produção. Obs.: Nesse momento, as aplicações já tem a possibilidade de acessar os dados migrados para o cluster 2 através de uma conexão com o cluster 1 via data share. Contudo, para efetuarem as consultas é necessário usar a notação de 3 partes (database, schema, tabela/view) o que demandaria alteração nos scripts existentes e também para as aplicações já construídas;
Para evitar a reescrita das consultas pode-se criar uma external table que funcionaria como uma alias/apelido para o database+schema do datashare tornando a consulta semelhante ao cenário inicial. A idéia é que este novo alias substitua o nome do database atual(db1) e, por isso, precisamos antes renomear o database para um nome diferente (de db1 para db1_old).

ALTER DATABASE db1 rename to db1_old;

CREATE EXTERNAL SCHEMA db1
FROM REDSHIFT DATABASE 'ds_cluster2' SCHEMA 'public';

Com estas alterações, as aplicações conseguem manter o mesmo endpoint de conexão (cluster 1) e também as mesmas queries sem nenhuma modificação mesmo após a migração dos dados. Obs.: Os recursos consumidos para executar as consultas continuam sendo do cluster 1, contudo, com esta nova topologia é possível ir migrando gradativamente cada aplicação para consumir o cluster 2 diretamente.

CONCLUSÃO

Este post traz um cenário real onde uma empresa deseja migrar databases entre clusters e/ou contas por diferentes motivos e deseja evitar grandes impactos nas aplicações clientes.
Foram apresentadas as motivações por trás de topologias complexas de múltiplos database e clusters e como a feature do Redshift data sharing facilita bastante diferentes topologias evitando a necessidade de movimentação de dados, rotinas de ETL. Foi descrita também uma configuração suportada pelo Amazon Redshift que permite visualizar os data shares como tabelas locais que diminui o impacto deste tipo de cenário.

Seguem abaixo algumas referências para:

Execução de consultas cross database em um mesmo cluster do Amazon Redshift
https://docs.aws.amazon.com/redshift/latest/dg/cross-database_example.html

Compartilhamento de data share entre clusters de diferentes contas AWS
https://aws.amazon.com/blogs/aws/cross-account-data-sharing-for-amazon-redshift/

Workshop com exemplos de passo a passo de configuração de data share para isolamento de workloads (ETL e BI)
https://catalog.us-east-1.prod.workshops.aws/workshops/4b2fb166-b467-461b-bd30-782dd2a2265c/en-US/data-sharing-labs/workload-isolation-use-case

Sobre o autor

Luiz Yanai é arquiteto especialista sênior em analytics na AWS atuando com clientes nativos na nuvem e empresas do ramo financeiro en suas jornadas para se tornarem data-driven. Possui quase 20 anos de experiência em arquitetura e desenvolvimento de soluções envolvendo sistemas empresariais e de missão crítica sendo que os últimos 5 anos estão focados na nuvem AWS.

Revisores

Eduardo Pereira é Arquiteto de Soluções. Atua ajudando clientes do setor Enterprise durante a sua jornada na nuvem da AWS. Tem grande interesse na área de infraestrutura, networking e serverless.

Felipe Brito é Arquiteto de Soluções na AWS e atua guiando clientes nas melhores práticas de arquitetura na nuvem. Possui experiência com projetos de desenvolvimento de software e Analytics.

O blog da AWS

Migrando databases do Redshift sem afetar aplicações clientes

CONCLUSÃO

Sobre o autor

Revisores