Partilhar via

Multilocação e Azure Cosmos DB

  • Artigo

Nesta página, descrevemos alguns dos recursos do Azure Cosmos DB que são úteis quando você trabalha com sistemas multilocatário. Também vinculamos orientações e exemplos de como usar o Azure Cosmos DB em uma solução multilocatário.

Requisitos de multilocação

Quando você planeja uma solução multilocatário, há duas necessidades principais para as quais você pode precisar projetar:

  • Garantir um forte isolamento entre inquilinos e cumprir requisitos de segurança rigorosos para aqueles que deles necessitam.
  • Manter um baixo custo por inquilino. Como provedor, você deseja garantir que o custo de execução do aplicativo permaneça sustentável à medida que ele é dimensionado.

Essas duas necessidades muitas vezes podem entrar em conflito, exigindo compensações e priorizando uma sobre a outra. Existem algumas diretrizes que você pode seguir para entender melhor as compensações envolvidas na abordagem de ambas as necessidades descritas acima. Este documento ajuda você a navegar por essas considerações para que você possa tomar decisões informadas ao projetar sua solução multilocatário.

Modelos de isolamento

Você precisa decidir o nível de isolamento entre seus inquilinos. O Azure Cosmos DB dá suporte a uma variedade de modelos de isolamento, mas para a maioria das soluções, recomendamos que você use uma das seguintes estratégias:

  • Chave de partição por locatário, que é frequentemente usada para soluções totalmente multilocatárias, como as usadas em software como serviço de empresa para consumidor (SaaS B2C).
  • Conta de banco de dados por locatário, o que é freqüente. usado em SaaS business-to-business (B2B).

Para selecionar o modelo de isolamento mais adequado, considere seu modelo de negócios e os requisitos dos locatários. Por exemplo, um forte isolamento de desempenho pode não ser uma prioridade para alguns modelos B2C em que as empresas vendem diretamente a um cliente individual usando o produto ou serviço. No entanto, os modelos B2B podem priorizar segurança forte e isolamento de desempenho e podem exigir que os locatários tenham sua própria conta de banco de dados provisionada.

Você também pode combinar vários modelos juntos para atender às diferentes necessidades do cliente. Por exemplo, suponha que você esteja criando uma solução SaaS B2B que vende para clientes corporativos, além de fornecer uma avaliação gratuita para novos clientes em potencial. Você pode implantar uma conta de banco de dados separada para locatários corporativos pagos, que precisam de fortes garantias de segurança e isolamento, enquanto compartilha uma conta de banco de dados e usa chaves de partição para isolar clientes de avaliação.

Chave de partição por inquilino

Ao isolar nossos locatários por chave de partição, a taxa de transferência será compartilhada entre locatários e agrupá-los dentro do mesmo contêiner.

Benefícios:

  • Eficiência de custos: Todos os locatários são colocados dentro de um contêiner, que é particionado pelo ID do locatário. Como há apenas um recurso faturável em que os RU/s são provisionados e compartilhados entre vários locatários, essa abordagem geralmente é mais econômica e mais fácil de gerenciar do que ter contas separadas por locatário.
  • Gerenciamento simplificado: menos contas do Azure Cosmos DB para gerenciar.

Compensações:

  • Contenção de recursos: o compartilhamento de taxa de transferência (RU/s) entre locatários no mesmo contêiner pode levar à contenção durante o pico de uso, resultando no problema do vizinho barulhento que pode causar desafios de desempenho se seus locatários tiverem cargas de trabalho altas ou sobrepostas. Esse modelo de isolamento é apropriado para cargas de trabalho que precisam de RU/s garantido em um único locatário e podem ser compartilhadas.
  • Isolamento limitado: esta abordagem fornece isolamento lógico, não físico. Ele pode não atender a requisitos rígidos de isolamento, seja do ponto de vista de desempenho e segurança.
  • Menos flexibilidade: a personalização de recursos no nível da conta, como replicação geográfica, restauração point-in-time (PITR) e chaves gerenciadas pelo cliente (CMK) por locatário, não estará disponível se isolado por chave de partição (ou por banco de dados/contêiner).

Recursos relevantes do Azure Cosmos DB:

  • Controle sua taxa de transferência: explore recursos que podem ajudar a controlar o problema do vizinho barulhento ao modelar locatário por partição, como realocação de taxa de transferência, capacidade de intermitência e controle de taxa de transferência no Java SDK.

  • Chaves de partição hierárquicas: o Azure Cosmos DB permite que cada partição lógica cresça até 20 GB. Se você tiver um único locatário que precise armazenar mais de 20 GB de dados, considere distribuir os dados por várias partições lógicas. Por exemplo, em vez de ter uma única chave de partição de , você pode salgar as chaves de partição criando várias chaves de Contosopartição para um locatário, como Contoso1, Contoso2e assim por diante.

    Ao consultar os dados de um locatário, você pode usar a WHERE IN cláusula para corresponder a todas as chaves de partição. As chaves de partição hierárquicas também podem ser usadas para suportar locatários grandes (desde que você tenha alta cardinalidade de locatários), com armazenamento superior a 20 GB, sem ter que usar chaves de partição sintéticas ou vários valores de chave de partição por locatário.

    Suponha que você tenha uma carga de trabalho que isola os locatários por chave de partição. Um inquilino, a Contoso, é muito maior e mais pesado em termos de escrita do que outros, e continua a crescer em tamanho. Para evitar o risco de não conseguir ingerir mais dados para este inquilino, pode utilizar chaves de partição hierárquicas. Especifique TenantID como a chave de primeiro nível e, em seguida, adicione um segundo nível como UserId. Se você antecipar a TenantID combinação e UserID para produzir partições lógicas que excedam o limite de 20 GB, você pode particionar mais abaixo para outro nível, como SessionID. As consultas que especificam TenantID, ou ambas TenantID e UserID, são efetivamente roteadas apenas para o subconjunto de partições físicas que contêm os dados relevantes, o que evita uma consulta de distribuição completa. Se o contêiner tivesse 1.000 partições físicas, mas um valor específico TenantId estivesse apenas em 5 partições físicas, a consulta seria roteada para o menor número de partições físicas relevantes.

    Se o seu primeiro nível não tiver cardinalidade suficientemente alta e você atingir o limite de partição lógica de 20 GB na sua chave de partição, considere usar uma chave de partição sintética em vez de uma chave de partição hierárquica.

Conta de banco de dados por locatário

Ao isolar nossos locatários por conta de banco de dados, cada locatário terá sua própria taxa de transferência provisionada no nível do banco de dados ou no nível do contêiner.

Benefícios:

  • Alto isolamento: essa abordagem evita contenção ou interferência devido a contas dedicadas do Azure Cosmos DB e contêineres com RU/s provisionados por locatário exclusivo.
  • SLAs personalizados: devido a cada locatário ter sua própria conta, você pode fornecer recursos personalizados específicos, SLAs voltados para o cliente e garantias, pois a conta de banco de dados de cada locatário pode ser ajustada independentemente para taxa de transferência.
  • Segurança aprimorada: o isolamento físico de dados garante uma segurança robusta, uma vez que os clientes podem habilitar chaves gerenciadas pelo cliente em um nível de conta por locatário. Os dados de cada locatário são isolados por conta, em vez de estarem no mesmo contêiner.
  • Flexibilidade: os locatários podem habilitar recursos no nível da conta, como replicação geográfica, restauração point-in-time (PITR) e chaves gerenciadas pelo cliente (CMK), conforme necessário.

Compensações:

  • Gerenciamento aprimorado: essa abordagem traz maior complexidade porque você gerencia várias contas do Azure Cosmos DB.
  • Custos mais altos: Mais contas significam taxa de transferência de provisionamento (RU/s) em cada recurso (bancos de dados e/ou contêineres) dentro da conta, para cada locatário. Sempre que um recurso provisiona RU/s, seus custos do Azure Cosmos DB aumentam.
  • Limitações de consulta: Como todos os locatários estão dentro de contas diferentes, várias chamadas dentro da lógica do aplicativo para cada locatário são necessárias ao consultar vários locatários.

Recursos relevantes do Azure Cosmos DB:

  • Recursos de segurança: este modelo fornece maior isolamento de segurança de acesso a dados usando o Azure RBAC. Além disso, esse modelo fornece isolamento de segurança de criptografia de banco de dados no nível do locatário por meio de chaves gerenciadas pelo cliente.
  • Configuração personalizada: Você pode configurar o local da conta do banco de dados de acordo com os requisitos do locatário. Você também pode ajustar a configuração dos recursos do Azure Cosmos DB, como replicação geográfica e chaves de criptografia gerenciadas pelo cliente, para atender aos requisitos de cada locatário.

Ao usar uma conta dedicada do Azure Cosmos DB por locatário, considere o número máximo de contas do Azure Cosmos DB por assinatura do Azure.

Lista completa de modelos de isolamento

Necessidade de carga de trabalho Chave de partição por inquilino (recomendado) Contêiner por locatário (taxa de transferência compartilhada) Contêiner por locatário (taxa de transferência dedicada) Base de dados por inquilino Conta de banco de dados por locatário (recomendado)
Consultas entre inquilinos Fácil (o contêiner funciona como limite para consultas) Fixa Fixa Fixa Fixa
Densidade de inquilinos Alto (menor custo por inquilino) Médio Baixo Baixo Baixo
Exclusão de dados do locatário Fácil Fácil (deixar cair o recipiente quando o inquilino sair) Fácil (deixar cair o recipiente quando o inquilino sair) Fácil (soltar banco de dados quando o inquilino sai) Fácil (soltar banco de dados quando o inquilino sai)
Isolamento de segurança de acesso a dados Precisa ser implementado dentro do aplicativo Contentor RBAC Contentor RBAC Banco de dados RBAC RBAC
Georreplicação A replicação geográfica por locatário não é possível Agrupar locatários em contas de banco de dados com base nos requisitos Agrupar locatários em contas de banco de dados com base nos requisitos Agrupar locatários em contas de banco de dados com base nos requisitos Agrupar locatários em contas de banco de dados com base nos requisitos
Prevenção de vizinhos barulhentos Nenhuma Nenhuma Sim Sim Sim
Latência de criação de novos locatários Imediata Rápido Rápido Médio Lento
Vantagens da modelagem de dados Nenhuma Colocation de entidades Colocation de entidades Vários contêineres para modelar entidades locatárias Vários contêineres e bancos de dados para modelar locatários
Chave de encriptação O mesmo para todos os inquilinos O mesmo para todos os inquilinos O mesmo para todos os inquilinos O mesmo para todos os inquilinos Chave gerenciada pelo cliente por locatário
Requisitos de taxa de transferência >0 RUs por locatário >100 RUs por locatário >100 RUs por locatário (apenas com dimensionamento automático, caso contrário >, 400 RUs por locatário) >400 RUs por locatário >400 RUs por locatário
Exemplo(s) de caso(s) de uso Aplicações B2C Oferta padrão para aplicações B2B Oferta premium para aplicações B2B Oferta premium para aplicações B2B Oferta premium para aplicações B2B

Contentor por inquilino

Você pode provisionar contêineres dedicados para cada locatário. Os contêineres dedicados funcionam bem quando os dados que você armazena para seu locatário podem ser combinados em um único contêiner. Esse modelo fornece maior isolamento de desempenho do que o modelo de chave de partição por locatário acima e também fornece maior isolamento de segurança de acesso a dados por meio do Azure RBAC.

Ao usar um contêiner para cada locatário, você pode considerar compartilhar a taxa de transferência com outros locatários provisionando a taxa de transferência no nível do banco de dados. Considere as restrições e limites em torno do número mínimo de unidades de solicitação para seu banco de dados e o número máximo de contêineres no banco de dados. Além disso, considere se seus inquilinos exigem um nível garantido de desempenho e se eles são suscetíveis ao problema do vizinho barulhento. Quando você compartilha a taxa de transferência no nível do banco de dados, a carga de trabalho ou o armazenamento em todos os contêineres deve ser relativamente uniforme. Caso contrário, você pode ter um problema de vizinho barulhento, se houver um ou mais grandes inquilinos. Se necessário, planeje agrupar esses locatários em diferentes bancos de dados baseados em padrões de carga de trabalho.

Como alternativa, você pode provisionar taxa de transferência dedicada para cada contêiner. Esta abordagem funciona bem para inquilinos maiores e para inquilinos que estão em risco do problema do vizinho barulhento. No entanto, a taxa de transferência da linha de base para cada locatário é maior, portanto, considere os requisitos mínimos e as implicações de custo desse modelo.

Se o seu modelo de dados de locatário exigir mais de uma entidade, desde que todas as entidades possam compartilhar a mesma chave de partição, elas poderão ser colocalizadas no mesmo contêiner. No entanto, se o modelo de dados do locatário for mais complexo e exigir entidades que não podem compartilhar a mesma chave de partição, considere os modelos de banco de dados por locatário ou conta de banco de dados por locatário abaixo. Consulte o nosso artigo sobre como modelar e particionar dados no Azure Cosmos DB utilizando um exemplo do mundo real para obter mais orientações.

O gerenciamento do ciclo de vida geralmente é mais simples quando os contêineres são dedicados aos locatários. Você pode facilmente mover locatários entre modelos de taxa de transferência compartilhados e dedicados e, ao desprovisionar um locatário, pode excluir rapidamente o contêiner.

Base de dados por inquilino

Você pode provisionar bancos de dados para cada locatário, na mesma conta de banco de dados. Como o modelo de contêiner por locatário acima, esse modelo fornece maior isolamento de desempenho do que o modelo de chave de partição por locatário e também fornece maior isolamento de segurança de acesso a dados por meio do Azure RBAC.

Semelhante ao modelo de conta por locatário, essa abordagem oferece o mais alto nível de isolamento de desempenho, mas fornece a menor densidade de locatários. No entanto, essa opção é melhor quando cada locatário requer um modelo de dados mais complicado do que é viável no modelo de contêiner por locatário. Ou, você deve seguir essa abordagem quando for um requisito para a criação de novos locatários ser rápido e/ou livre de qualquer sobrecarga para criar contas de locatário antecipadamente. Também pode ser o caso, para a estrutura de desenvolvimento de software específica que está sendo usada, que o banco de dados por locatário seja o único nível de isolamento de desempenho reconhecido nessa estrutura. O isolamento em nível de entidade (contêiner) e a colocalização de entidade normalmente não são suportados nativamente nessas estruturas.

Recursos do Azure Cosmos DB que oferecem suporte à multilocação

Criação de partições

Usando partições com seus contêineres do Azure Cosmos DB, você pode criar contêineres que são compartilhados entre vários locatários. Normalmente, você usa o identificador de locatário como uma chave de partição, mas também pode considerar o uso de várias chaves de partição para um único locatário. Uma estratégia de particionamento bem planejada implementa efetivamente o padrão Sharding. Com contêineres grandes, o Azure Cosmos DB distribui seus locatários por vários nós físicos para alcançar um alto grau de escala.

Recomendamos que você explore o uso de chaves de partição hierárquicas para melhorar o desempenho de sua solução multilocatário. As chaves de partição hierárquicas permitem criar uma chave de partição que inclui vários valores. Por exemplo, você pode usar uma chave de partição hierárquica que inclua o identificador de locatário, como um GUID de alta cardinalidade, para permitir uma escala quase ilimitada. Ou, você pode especificar uma chave de partição hierárquica que inclui uma propriedade freqüentemente usada em consultas. Essa abordagem ajuda você a evitar consultas entre partições. Usando chaves de partição hierárquicas, você pode dimensionar além do limite de partição lógica de 20 GB por valor de chave de partição e limitar consultas de distribuição caras.

Mais informações:

Gerenciando unidades de solicitação

O modelo de preços do Azure Cosmos DB é baseado no número de unidades de solicitação por segundo que você provisiona ou consome. Uma unidade de solicitação é uma abstração lógica do custo de uma operação ou consulta de banco de dados. Normalmente, você provisiona um número definido de unidades de solicitação por segundo para sua carga de trabalho, que é chamada de taxa de transferência. O Azure Cosmos DB fornece várias opções para como provisionar a taxa de transferência. Em um ambiente multilocatário, a seleção feita afeta o desempenho e o preço dos recursos do Azure Cosmos DB.

Para locatários que exigem desempenho garantido e isolamento de segurança, recomendamos isolar os locatários por conta de banco de dados e alocar unidades de solicitação ao locatário. Para locatários com requisitos menos rigorosos, recomendamos isolar os locatários por chave de partição, o que permite compartilhar unidades de solicitação entre seus locatários e ajuda a otimizar para um baixo custo por locatário.

Um modelo de locação alternativo para o Azure Cosmos DB envolve a implantação de contêineres separados para cada locatário em um banco de dados compartilhado. O Azure Cosmos DB permite provisionar unidades de solicitação para um banco de dados e todos os contêineres compartilham as unidades de solicitação. Se as cargas de trabalho do locatário normalmente não se sobrepõem, essa abordagem pode ajudar a reduzir os custos operacionais. No entanto, essa abordagem é suscetível ao problema do vizinho barulhento porque o contêiner de um único locatário pode consumir uma quantidade desproporcional das unidades de solicitação provisionadas compartilhadas. Para mitigar esse problema, primeiro identifique os locatários barulhentos. Em seguida, você pode, opcionalmente, definir a taxa de transferência provisionada em um contêiner específico. Os outros contêineres no banco de dados continuam a compartilhar sua taxa de transferência, mas o locatário barulhento consome sua própria taxa de transferência dedicada.

O Azure Cosmos DB também fornece uma camada sem servidor, que é adequada para cargas de trabalho com tráfego intermitente ou imprevisível. Como alternativa, o dimensionamento automático permite configurar políticas para especificar o dimensionamento da taxa de transferência provisionada. Além disso, você pode aproveitar a capacidade de intermitência do Azure Cosmos DB, maximizando a utilização de sua capacidade de taxa de transferência provisionada, que teria sido limitada de outra forma. Em uma solução multilocatário, você pode combinar todas essas abordagens para oferecer suporte a diferentes tipos de locatário.

Nota

Ao planejar sua configuração do Azure Cosmos DB, certifique-se de considerar as cotas e limites de serviço.

Para monitorar e gerenciar os custos associados a cada locatário, cada operação usando a API do Azure Cosmos DB inclui as unidades de solicitação consumidas. Você pode usar essas informações para agregar e comparar as unidades de solicitação reais consumidas por cada locatário e, em seguida, identificar locatários com características de desempenho diferentes.

Mais informações:

Chaves geridas pelo cliente

Alguns locatários podem exigir o uso de suas próprias chaves de criptografia. O Azure Cosmos DB fornece um recurso de chave gerenciado pelo cliente. Esse recurso é aplicado no nível de uma conta do Azure Cosmos DB, portanto, os locatários que precisam de suas próprias chaves de criptografia precisam ser implantados usando contas dedicadas do Azure Cosmos DB.

Mais informações:

Contribuidores

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

Principais autores:

  • Tara Bhatia - Brasil | Gerente de Programas, Azure Cosmos DB
  • Paul Burpo - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
  • John Downs - Brasil | Engenheiro de Software Principal

Outros contribuidores:

  • Mark Brown - Brasil | Gerente de PM Principal, Azure Cosmos DB
  • Deborah Chen - Brasil | Gerente de Programa Principal
  • Theo van Kraay - Brasil | Gerente de Programa Sênior, Azure Cosmos DB
  • Arsen Vladimirskiy - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
  • Thomas Weiss - Brasil | Gerente de Programa Principal
  • Vic Perdana - Brasil | Arquiteto de Soluções na Nuvem, Azure ISV

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.

Saiba mais sobre multilocação e o Azure Cosmos DB:

Consulte alguns de nossos outros cenários de arquitetura do Cosmos DB: