Multilocação e Cache do Azure para Redis

O Cache Redis do Azure é comumente usado para aumentar o desempenho de sua solução, reduzir a carga em seu banco de dados ou outros componentes da camada de dados e reduzir a quantidade de estado que você armazena em nós de computação. Neste artigo, descrevemos alguns dos recursos do Cache Redis do Azure que são úteis para soluções multilocatárias e, em seguida, fornecemos links para as orientações que podem ajudá-lo quando você estiver planejando como usará o Cache do Azure para Redis.

Modelos de isolamento

Ao trabalhar com um sistema multilocatário que usa o Cache do Azure para Redis, você precisa tomar uma decisão sobre o nível de isolamento que deseja usar. O Cache Redis do Azure dá suporte a vários modelos de isolamento.

A tabela a seguir resume as diferenças entre os principais modelos de isolamento de locação para o Cache do Azure para Redis:

Instância de cache compartilhada e banco de dados compartilhado

Você pode considerar implantar um único cache, com um único banco de dados Redis, e usá-lo para armazenar dados armazenados em cache para todos os seus locatários. Essa abordagem é comumente usada quando você tem uma única instância de aplicativo compartilhada por todos os locatários.

Quando você segue essa abordagem, seu aplicativo é o único responsável por manter os dados do locatário separados. Você pode usar prefixos de chave para distinguir dados de locatários diferentes, mas seu aplicativo precisa ser diligente em acessar apenas dados para o locatário com quem está trabalhando. Como alternativa, você pode considerar o uso de estruturas de dados Redis, como conjuntos ou hashes, para os dados de cada locatário. Cada uma dessas abordagens oferece suporte a um grande número de chaves, para que possam ser dimensionadas para muitos locatários. No entanto, você precisa gerenciar a autorização dentro do seu aplicativo em vez de dentro do cache.

Ao compartilhar uma instância de cache e um banco de dados entre locatários, considere que todos os locatários compartilham os mesmos recursos de computação subjacentes para o cache. Assim, esta abordagem pode ser vulnerável ao problema do vizinho barulhento. Certifique-se de seguir as práticas recomendadas para o Cache Redis do Azure para fazer o uso mais eficiente dos recursos do cache e mitigar quaisquer efeitos de vizinhos barulhentos. As melhores práticas incluem:

• Dimensionamento
• Gestão da memória
• Carga do servidor

Além disso, considere monitorar os recursos do cache, como CPU e memória. Se você observar a pressão de recursos, considere as seguintes atenuações:

• Escale para uma SKU de cache ou camada com níveis mais altos de recursos.
• Expanda para vários caches fragmentando os dados armazenados em cache. Uma opção é fragmentar por locatário, onde alguns locatários usam o cache A e outros o cache B. Ou você pode fragmentar por subsistema, onde uma parte da solução armazena em cache dados para todos os locatários armazenarem em cache A e outra parte da solução armazena em cache no cache B.

Cache e banco de dados compartilhados com listas de controle de acesso

Se sua camada de aplicativo usa identidades distintas para acessar o cache de cada locatário, use listas de controle de acesso Redis. As listas de controle de acesso permitem que você restrinja o acesso às informações dos locatários a identidades específicas. Você identifica os dados que a identidade tem permissão para acessar com base em nomes de chave ou prefixos. Essa abordagem pode ser uma boa opção quando você tem instâncias de aplicativo distintas para cada locatário ou se você tem um aplicativo compartilhado que usa várias identidades para acessar serviços downstream com base no contexto do locatário.

Da mesma forma que o modelo de isolamento anterior, compartilhar o cache e o banco de dados significa que você precisa tomar precauções para evitar o problema do vizinho barulhento.

Instância de cache compartilhada com um banco de dados por locatário

Outra abordagem que você pode considerar é implantar uma única instância de cache e implantar bancos de dados Redis específicos do locatário na instância. Essa abordagem fornece algum grau de isolamento lógico dos dados de cada locatário, mas não fornece nenhum isolamento de desempenho ou proteção contra vizinhos barulhentos.

Essa abordagem pode ser útil para cenários de migração. Por exemplo, suponha que você modernize um aplicativo de locatário único que não foi projetado para funcionar com vários locatários e o converta gradualmente para reconhecimento de multilocação, incluindo o contexto do locatário em todas as solicitações. Você pode obter algumas eficiências de custos usando um único cache compartilhado e não precisa atualizar a lógica do aplicativo para usar prefixos de chave de locatário ou estruturas de dados específicas do locatário.

O Cache Redis do Azure impõe limites ao número de bancos de dados que podem ser criados em um único cache. Antes de implementar essa abordagem, considere o número de locatários para os quais você espera crescer.

Além disso, essa abordagem não oferece nenhum benefício para o isolamento de segurança de dados. No Cache do Azure para Redis, a autenticação e a autorização são executadas no nível da instância de cache.

Instância de cache por locatário

Você pode considerar a implantação de uma instância separada do Cache Redis do Azure para cada locatário. Não há limite para o número de caches que você pode implantar em uma única assinatura do Azure. Essa abordagem fornece o nível mais forte de isolamento de dados e desempenho.

No entanto, cada cache é cobrado como um recurso separado do Azure, portanto, à medida que você cresce para um grande número de locatários, pode incorrer em mais custos. Além disso, essa abordagem geralmente não faz uso eficiente dos recursos de cada cache, já que cada instância do Cache do Azure para Redis geralmente dá suporte a grandes volumes de solicitações. É melhor considerar essa abordagem de isolamento apenas se você tiver requisitos rígidos de isolamento de dados ou desempenho.

Recursos do Cache do Azure para Redis que oferecem suporte à multilocação

Listas de controlo de acesso

O Cache Redis do Azure fornece um poderoso sistema de controle de acesso baseado em função, que permite criar políticas abrangentes de acesso a dados para impor suas regras de autenticação e autorização. Essas regras podem ser especificadas em diferentes níveis de granularidade, inclusive para permitir que um usuário acesse chaves de cache que seguem um padrão específico. Usando padrões de chave, você pode compartilhar uma única instância de cache e banco de dados entre vários locatários, cada um com suas próprias contas de usuário. O Cache Redis do Azure impõe o isolamento do locatário para garantir que um usuário só possa acessar seu próprio conjunto de chaves que seguem o padrão.

Por exemplo, suponha que você tenha um locatário chamado Fabrikam. Sua camada de aplicativo só deve ser capaz de acessar dados de cache relacionados à Fabrikam, e não de outros locatários. Você pode definir uma política de acesso personalizada que permita ler e definir todas as chaves de cache que começam com Fabrikam:

+@read +set ~Fabrikam*

Em seguida, você pode atribuir a política à identidade do Microsoft Entra usada pela instância do aplicativo Fabrikam. Depois de configurar o cache, o usuário da Fabrikam pode acessar as chaves nomeadas FabrikamData1 e FabrikamUserDetails, mas não ContosoData1.

Georreplicação ativa

Muitas soluções multilocatárias precisam ser distribuídas geograficamente. Você pode compartilhar uma camada de aplicativo distribuída globalmente, com suas instâncias de aplicativo lendo e gravando em um cache próximo para manter um desempenho aceitável. A camada Enterprise do Cache Redis do Azure dá suporte à vinculação de vários caches entre regiões, em uma configuração ativa-ativa.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

• John Downs - Brasil | Engenheiro de Software Principal
• Will Velida - Brasil | Engenheiro de Clientes 2, FastTrack para Azure

Outros contribuidores:

• Carl Dacosta - Brasil | Gerente Principal de Engenharia de Software, Cache do Azure para Redis
• Kyle Teegarden - Brasil | Gerente de Programa Sênior, Cache do Azure para Redis
• Arsen Vladimirskiy - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos

Analise as abordagens de armazenamento e dados para multilocação.