Orientação para usar o Banco de Dados do Azure para PostgreSQL em uma solução multilocatária

Muitas soluções multiclientes no Azure utilizam o sistema de gestão de bases de dados relacionais de código aberto Azure Database para PostgreSQL. Este artigo descreve os recursos do Banco de Dados do Azure para PostgreSQL que são úteis quando você trabalha com sistemas multilocatário. O artigo também inclui links para orientações e exemplos de como usar o Banco de Dados do Azure para PostgreSQL em uma solução multilocatário.

Opções de implementação

As seguintes opções estão disponíveis para Base de Dados do Azure para PostgreSQL e são adequadas para utilização com aplicações multiinquilino:

• Base de Dados do Azure para PostgreSQL é uma boa escolha para a maioria das implementações multitenant que não exigem a elevada escalabilidade que o Azure Cosmos DB para PostgreSQL oferece.

• Base de Dados do Azure para PostgreSQL clusters elásticos fornece escalabilidade horizontal dentro de um serviço gerido. É adequado para aplicações multilocatárias que precisam ser dimensionadas de alguns inquilinos para um grande número de inquilinos.

• O Azure Cosmos DB para PostgreSQL é um serviço de banco de dados gerenciado pelo Azure projetado para soluções que exigem um alto nível de escala, como aplicativos multilocatário. Este serviço faz parte da família de produtos Azure Cosmos DB.

  Important

  O Azure Cosmos DB para PostgreSQL está numa fase de reforma e já não é recomendado para novos projetos.

Recursos do Banco de Dados do Azure para PostgreSQL que dão suporte à multilocação

Quando você usa o Banco de Dados do Azure para PostgreSQL para criar um aplicativo multilocatário, os recursos a seguir podem aprimorar sua solução.

Segurança a nível de linha

A segurança ao nível de linha é útil para garantir o isolamento ao nível do cliente quando se utilizam tabelas partilhadas. No PostgreSQL, você implementa segurança em nível de linha aplicando políticas de segurança de linha a tabelas para restringir o acesso a linhas por locatário.

A implementação da segurança em nível de linha em uma tabela pode afetar o desempenho. Talvez seja necessário criar outros índices em tabelas que tenham a segurança em nível de linha habilitada para garantir que o desempenho não seja afetado. Ao usar a segurança em nível de linha, é importante usar técnicas de teste de desempenho para validar se sua carga de trabalho atende aos requisitos de desempenho da linha de base.

Para mais informações sobre segurança ao nível das linhas, consulte Gestão de Acesso para Azure Database para PostgreSQL.

Contexto do inquilino para segurança ao nível da linha

As políticas de segurança ao nível da linha exigem acesso ao identificador de inquilino atual. Base de Dados do Azure para PostgreSQL fornece duas extensões que ajudam a gerir o contexto do tenant:

• session_variable: Fornece variáveis com âmbito de sessão que pode usar para armazenar e recuperar o identificador de inquilino dentro de uma sessão. Use estas variáveis nas suas políticas de segurança ao nível da linha.
• login_hook: Executa uma função no momento do login. Use esta extensão para definir automaticamente o contexto do locatário quando uma ligação é estabelecida.

Para mais informações, consulte Extensões e versões de extensão para Base de Dados do Azure para PostgreSQL.

Dimensionamento horizontal com fragmentação

O padrão de fragmentação permite dimensionar a sua carga de trabalho em vários bancos de dados ou servidores de banco de dados.

As soluções que precisam de um alto nível de escala podem usar o Azure Cosmos DB para PostgreSQL. Esse modo de implantação permite a fragmentação horizontal de locatários em vários servidores ou nós. Use tabelas distribuídas em bancos de dados multilocatários para garantir que todos os dados de um locatário sejam armazenados no mesmo nó. Essa abordagem melhora o desempenho da consulta.

Para obter mais informações, consulte os seguintes artigos:

• Projetar um banco de dados multilocatário usando o Azure Cosmos DB para PostgreSQL
• Tabelas distribuídas
• Escolher colunas de distribuição
• Usar o Citus para aplicativos multilocatários

Agrupamentos elásticos

Clusters elásticos são uma funcionalidade do Base de Dados do Azure para PostgreSQL. Eles fornecem recursos de dimensionamento horizontal em um único serviço gerenciado. Essa opção de implantação usa a funcionalidade de tabela distribuída para cargas de trabalho multilocatárias que exigem recursos de expansão.

Em soluções multilocatário, os clusters elásticos permitem a fragmentação de dados do locatário em vários nós. Clusters elásticos suportam dois modelos de fragmentação:

• Fragmentação baseada em linhas: Pode distribuir tabelas por ID de cliente para garantir que os dados dos clientes se localizam em nós específicos. Esta abordagem pode melhorar o desempenho das consultas para consultas específicas de um cliente, mas exige que as consultas incluam a coluna de distribuição.
• Sharding baseado em esquemas: Pode isolar os inquilinos usando um esquema separado por inquilino. Esta abordagem é ideal para ISVs que implementam aplicações que não podem ser sujeitas a modificações de consulta para suportar sharding baseado em linhas. O sharding baseado em esquema é bem adequado para cargas de trabalho que têm entre 1 e 10.000 locatários.

Para obter mais informações, consulte os seguintes artigos:

• Clusters elásticos em Base de Dados do Azure para PostgreSQL
• Modelos de fragmentação para clusters elásticos

Pool de ligações

O Postgres usa um modelo baseado em processos para conexões. Este modelo torna ineficiente manter um grande número de conexões ociosas. Algumas arquiteturas multilocatárias exigem muitas conexões ativas, o que afeta negativamente o desempenho do servidor Postgres.

O agrupamento de ligações via PgBouncer está instalado por padrão no Base de Dados do Azure para PostgreSQL.

Para obter mais informações, consulte os seguintes artigos:

• PgBouncer na Base de Dados do Azure para PostgreSQL
• Agrupamento de conexões em Azure Cosmos DB para PostgreSQL
• Passos para instalar e configurar o proxy do conjunto de ligações do PgBouncer com a Base de Dados do Azure para PostgreSQL

Autenticação do Microsoft Entra

O Base de Dados do Azure para PostgreSQL suporta autenticação de ligação utilizando o Microsoft Entra ID. Esse recurso permite que cargas de trabalho de aplicativos em um ambiente multilocatário se autentiquem no banco de dados usando uma entidade de serviço específica do locatário ou uma identidade gerenciada. O acesso ao banco de dados pode ser delimitado a um inquilino específico. Ao combinar a autenticação do Microsoft Entra ID com políticas de segurança de linha específicas do locatário, você pode reduzir o risco de um aplicativo acessar os dados de outro locatário de dentro de um banco de dados multilocatário.

Para obter mais informações, consulte os seguintes artigos:

• Autenticação do Microsoft Entra na Base de Dados do Azure para PostgreSQL
• Conecte-se com identidade gerida ao Base de Dados do Azure para PostgreSQL

Computação confidencial do Azure

O Base de Dados do Azure para PostgreSQL suporta computação confidencial Azure através de ambientes de execução confiáveis (TEEs), que fornecem proteção baseada em hardware para dados em uso. Esse recurso protege os dados do locatário contra acesso não autorizado pelo sistema operacional, hipervisor ou outros aplicativos.

Para soluções multilocatárias que lidam com dados confidenciais, a computação confidencial fornece proteção de dados em nível de hardware durante o processamento. Use computação confidencial quando os locatários tiverem requisitos estritos de proteção de dados ou necessidades de conformidade regulatória ou quando você precisar garantir que o provedor de aplicativos não possa acessar os dados do locatário.

Para mais informações, consulte Computação Confidencial do Azure para o Base de Dados do Azure para PostgreSQL.

Encriptação

Os dados armazenados no Base de Dados do Azure para PostgreSQL são cifrados em repouso por defeito, utilizando chaves geridas pela Microsoft, mas também pode usar chaves geridas pelo cliente (CMKs) para que os locatários especifiquem as suas próprias chaves de cifra.

Ao usar CMKs, você pode fornecer suas próprias chaves de criptografia armazenadas no Cofre de Chaves do Azure. Em ambientes multilocatário, essa abordagem permite que você use chaves de criptografia diferentes para locatários diferentes, mesmo quando seus dados são armazenados no mesmo servidor de banco de dados. Esse recurso também dá aos locatários controle sobre suas próprias chaves de criptografia. Se um locatário optar por desativar sua conta, excluir a chave associada garantirá que seus dados não estejam mais acessíveis.

Base de Dados do Azure para PostgreSQL suporta atualizações automáticas de versão de chaves para CMKs. Esse recurso é atualizado automaticamente para novas versões de chaves após a rotação no Cofre de Chaves e não requer gerenciamento manual de versões de chaves. Em ambientes multilocatários onde a conformidade regulatória exige rotação regular de chaves, essa automação reduz as tarefas operacionais manuais e mantém a proteção de dados sem interrupção do serviço.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Autor principal:

• Daniel Scott-Raynsford | Arquiteto de Soluções de Parceiros, Dados e IA

Outros contribuidores:

• John Downs | Engenheiro de Software Principal, Azure Patterns & Practices
• Arsen Vladimirskiy | Engenheiro Principal de Clientes, FastTrack para Azure
• Paul Burpo | Engenheiro Principal de Clientes, FastTrack para ISVs do Azure
• Assaf Fraenkel | Engenheiro Sénior/Arquiteto de Dados, Azure FastTrack para ISVs e Startups

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Recurso relacionado

• Abordagens arquitetônicas para armazenamento e dados em soluções multilocatárias