Compartilhar via

Multilocação e o Cache do Azure para Redis

  • Artigo

O Cache do Azure para Redis é comumente usado para aumentar o desempenho de sua solução, reduzir a carga no banco de dados ou em outros componentes da camada de dados e reduzir a quantidade de estado que armazena nos nós de computação. Neste artigo, descrevemos alguns dos recursos do Cache do Azure para Redis que são úteis para soluções multilocatário e fornecemos links para as diretrizes que poderão ajudar quando você estiver planejando o uso do 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 do Azure para Redis tem suporte para 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:

Consideração Cache compartilhado, banco de dados compartilhado Cache e banco de dados compartilhados, lista de controle de acesso Cache compartilhado, banco de dados por locatário Cache por locatário
Isolamento de dados Baixo. Usar estruturas de dados ou prefixos de chave do Redis para identificar os dados de cada locatário Alto. Os dados são isolados com base em prefixos de chave Baixo. Os dados são separados, mas nenhum isolamento de segurança é fornecido Alto
Isolamento de desempenho Baixo. Todos os locatários compartilham os mesmos recursos de computação Baixo. Todos os locatários compartilham os mesmos recursos de computação Baixo. Todos os locatários compartilham os mesmos recursos de computação Alto
Complexidade da implantação Baixo Médio-baixo Médio Médio-alto
Complexidade operacional Baixo Médio-baixo Baixo Médio-alto
Custo de recurso Baixo Baixo Baixo Alta
Cenário de exemplo Grande solução multilocatário com uma camada de aplicativo compartilhada Grande solução multilocatário com identidades de aplicativos distintas que acessam o cache Migrando um aplicativo de locatário único para ter reconhecimento multilocatário Instâncias de aplicativos individuais por locatário

Instância de cache compartilhada e banco de dados compartilhado

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

Quando você adota 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 diferentes locatários, mas seu aplicativo precisa ser cuidadoso para acessar apenas os dados do locatário com o qual está trabalhando. Como alternativa, você pode considerar usar estruturas de dados Redis, como conjuntos ou hashes, para os dados de cada locatário. Cada uma dessas abordagens suporta um grande número de chaves, de modo que podem ser escaladas para muitos locatários. No entanto, você precisa gerenciar a autorização no aplicativo, e não no cache.

Ao compartilhar uma instância de cache e um banco de dados entre locatários, considere que todos os seus locatários compartilham os mesmos recursos de computação subjacentes para o cache. Então, essa abordagem pode ser vulnerável ao problema do vizinho barulhento. Certifique-se de seguir as práticas recomendadas do Cache do Azure para Redis, a fim de usar com mais eficiência os recursos do cache e atenuar quaisquer efeitos de vizinhos barulhentos. Melhores práticas incluem:

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 verticalmente uma SKU ou camada de cache com níveis mais altos de recursos.
  • Escale horizontalmente vários caches fragmentando seus dados armazenados em cache. Uma opção é fragmentar por locatário, em que alguns locatários usam o cache A e alguns usam o cache B. Ou você pode fragmentar por subsistema, em que uma parte da solução armazena em cache os dados para todos os locatários no cache A e outra parte da solução armazena no cache B.

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

Se a camada do aplicativo usar identidades distintas para acessar o cache de cada locatário, use as listas de controle de acesso do Redis. As listas de controle de acesso permitem restringir 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 ou prefixos de chaves. Essa abordagem pode ser uma boa opção quando você tem instâncias de aplicativos 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, o compartilhamento do cache e do banco de dados significa que você precisa tomar cuidado 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 dentro da 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 múltiplos locatários e o converta gradualmente para ter reconhecimento de multilocação, incluindo o contexto do locatário em todas as solicitações. Você pode obter algumas eficiências de custo 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 do Azure para Redis 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 que você espera alcançar.

Além disso, essa abordagem não oferece nenhum benefício para o isolamento de segurança dos 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.

Observação

O Cache do Azure para Redis tem suporte para vários bancos de dados em camadas específicas e não tem suporte para vários bancos de dados quando você usa instâncias clusterizadas.

Instância de cache por locatário

Você pode considerar implantar uma instância separada do Cache do Azure para Redis para cada locatário. Não há limite para o número de caches que você pode implantar em uma assinatura única 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, uma vez que cada instância do Cache do Azure para Redis geralmente tem suporte para grandes volumes de solicitações. Será melhor considerar essa abordagem de isolamento apenas se você tiver requisitos rígidos de isolamento de dados ou desempenho.

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

Listas de controle de acesso

O Cache do Azure para Redis fornece um avançado sistema de controle de acesso baseado em funções, que permite criar políticas abrangentes de acesso a dados para aplicar suas regras de autenticação e autorização. Essas regras podem ser definidas em vários níveis de granularidade, inclusive para permitir o acesso de um usuário a chaves de cache que seguem um padrão específico. Ao usar 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 do Azure para Redis aplica 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 a leitura e a configuração de todas as chaves de cache que comecem com Fabrikam:

+@read +set ~Fabrikam*

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

Replicação geográfica ativa

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

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

  • John Downs | Engenheiro de software principal
  • Will Velida | Engenheiro do Cliente 2, FastTrack for Azure

Outros colaboradores:

  • Carl Dacosta | Gerente de Engenharia de Software Principal, Cache do Azure para Redis
  • Kyle Teegarden | Gerente de Programa Sênior, Cache do Azure para Redis
  • Arsen Vladimirskiy | Engenheiro principal de atendimento ao cliente, FastTrack for Azure

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

Próximas etapas

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