Compartilhar via

Multilocatário e Azure Cosmos DB

  • Artigo

Este artigo descreve os recursos do Azure Cosmos DB que você pode usar para sistemas multilocatários. Ele fornece diretrizes e exemplos sobre como usar o Azure Cosmos DB em uma solução multilocatário.

Requisitos de multilocação

Ao planejar uma solução multilocatário, você tem dois requisitos principais:

  • Ajude a garantir um forte isolamento entre os inquilinos e atenda aos rigorosos requisitos de segurança para aqueles que precisam deles.
  • Mantenha um baixo custo por locatário. Como provedor, certifique-se de que o custo para executar o aplicativo permaneça sustentável à medida que ele é dimensionado.

Essas duas necessidades muitas vezes podem entrar em conflito e introduzir um trade-off em que você deve priorizar uma sobre a outra. As diretrizes neste artigo podem ajudá-lo a entender melhor as compensações que você deve fazer para atender a essas necessidades. Este artigo 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

Determine o nível de isolamento necessário entre seus locatários. 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:

  • Uma chave de partição por locatário geralmente é usada para soluções totalmente multilocatário, como soluções SaaS (software como serviço) business-to-consumer.
  • Uma conta de banco de dados por locatário geralmente é usada para soluções SaaS business-to-business (B2B).

Para escolher o modelo de isolamento mais apropriado, 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 uma empresa vende um produto ou serviço diretamente a um cliente individual. No entanto, os modelos B2B podem priorizar um forte isolamento de segurança e 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 para atender às diferentes necessidades do cliente. Por exemplo, suponha que você crie uma solução SaaS B2B que vende para clientes corporativos e forneça 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. E você pode compartilhar uma conta de banco de dados e usar chaves de partição para isolar clientes de avaliação.

O modelo de chave de partição por locatário e o modelo de conta de banco de dados por locatário são os modelos de isolamento mais comuns para soluções multilocatário. Esses modelos fornecem o melhor equilíbrio entre isolamento de locatários e eficiência de custos.

Modelo de chave de partição por locatário

Se você isolar seus locatários por chave de partição, a taxa de transferência será compartilhada entre locatários e gerenciada no mesmo contêiner.

Observação

Uma RU (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 (RU/s) para sua carga de trabalho, que é chamada de taxa de transferência.

Benefícios

  • Eficiência de custo: você coloca todos os locatários em um contêiner, que é particionado pela ID do locatário. Essa abordagem tem apenas um recurso faturável que provisiona e compartilha RUs entre vários locatários. Esse modelo geralmente é mais econômico e fácil de gerenciar do que ter contas separadas para cada locatário.

  • Gerenciamento simplificado: você tem menos contas do Azure Cosmos DB para gerenciar.

Compensações

  • Contenção de recursos: a taxa de transferência compartilhada (RU/s) entre locatários que estão no mesmo contêiner pode levar à contenção durante o pico de uso. Essa contenção pode criar problemas de vizinhos barulhentos e desafios de desempenho se seus locatários tiverem cargas de trabalho altas ou sobrepostas. Use esse modelo de isolamento para cargas de trabalho que precisam de RUs garantidas em um único locatário e podem compartilhar a taxa de transferência.

  • Isolamento limitado: esta abordagem fornece isolamento lógico, não isolamento físico. Ele pode não atender a requisitos de isolamento estritos do ponto de vista de desempenho ou segurança.

  • Menos flexibilidade: você não pode personalizar recursos no nível da conta, como replicação geográfica, restauração pontual e chaves gerenciadas pelo cliente, para cada locatário se você isolar por chave de partição ou por banco de dados ou contêiner.

Recursos do Azure Cosmos DB para multilocação

  • Controle sua taxa de transferência: explore recursos que podem ajudar a controlar o problema do vizinho barulhento ao usar uma chave de partição para isolar locatários. Use recursos 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: use o Azure Cosmos DB para que cada partição lógica possa aumentar de tamanho até 20 GB. Se você tiver um locatário que precise armazenar mais de 20 GB de dados, considere distribuir os dados em várias partições lógicas. Por exemplo, em vez de ter uma única chave de partição de , você pode distribuir as chaves de partição criando várias chaves de Contosopartição para um locatário, como Contoso1 e Contoso2.

    Ao consultar dados de um locatário, você pode usar a WHERE IN cláusula para corresponder a todas as chaves de partição. Você também pode usar chaves de partição hierárquicas para fornecer locatários grandes com armazenamento superior a 20 GB se tiver uma alta cardinalidade de locatários. Você não precisa usar chaves de partição sintéticas ou vários valores de chave de partição por locatário para esse método.

    Suponha que você tenha uma carga de trabalho que isola locatários por chave de partição. Um locatário, a Contoso, é maior e mais pesado em gravação do que outros, e continua a crescer em tamanho. Para evitar o risco de não conseguir ingerir mais dados para esse locatário, você pode usar 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 que a TenantID combinação e UserID produzirá partições lógicas que excedam o limite de 20 GB, poderá particionar mais para baixo em outro nível, como SessionID. Consultas que especificam um TenantID ou ambos 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 tiver 1.000 partições físicas, mas um valor específico TenantId estiver apenas em cinco partições físicas, a consulta será roteada para o menor número de partições físicas relevantes.

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

Modelo de conta de banco de dados por locatário

Se você isolar seus 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 e contêineres dedicados do Azure Cosmos DB que provisionaram RUs por locatário exclusivo.

  • SLAs (contratos de nível de serviço) personalizados: cada locatário tem sua própria conta, portanto, você pode fornecer recursos personalizados específicos, SLAs voltados para o cliente e garantias, pois você pode ajustar a conta de banco de dados de cada locatário independentemente para a taxa de transferência.

  • Segurança aprimorada: o isolamento físico de dados ajuda a garantir uma segurança robusta porque 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 pontual e chaves gerenciadas pelo cliente, conforme necessário.

Compensações

  • Maior gerenciamento: essa abordagem é mais complexa porque você gerencia várias contas do Azure Cosmos DB.

  • Custos mais altos: mais contas significam que você deve provisionar a taxa de transferência em cada recurso, como bancos de dados ou contêineres, dentro da conta para cada locatário. Sempre que um recurso provisiona RUs, os custos do Azure Cosmos DB aumentam.

  • Limitações de consulta: todos os locatários estão em contas diferentes, portanto, os aplicativos que consultam vários locatários exigem várias chamadas dentro da lógica do aplicativo.

Recursos do Azure Cosmos DB para multilocação

  • Recursos de segurança: esse modelo fornece maior isolamento de segurança de acesso a dados por meio do RBAC do Azure. Esse modelo também 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 de 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 locatário (recomendada) Contêineres por locatário (taxa de transferência compartilhada) Contêiner por locatário (taxa de transferência dedicada) Banco de dados por locatário Conta de banco de dados por locatário (recomendada)
Consultas entre locatários Fácil (o contêiner atua como limite para consultas) Reserva fixa Reserva fixa Reserva fixa Reserva fixa
Densidade do locatário Alta (menor custo por locatário) Médio Baixo Baixo Baixo
Exclusão de dados do locatário Fácil Fácil (remover contêiner quando o locatário sair) Fácil (remover contêiner quando o locatário sair) Fácil (remover banco de dados quando o locatário sair) Fácil (remover banco de dados quando o locatário sair)
Isolamento de segurança de acesso a dados Necessidade de implementar dentro do aplicativo Contêiner de RBAC Contêiner de RBAC RBAC do banco de dados RBAC
Replicação geográfica 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 Não Não Sim Sim Sim
Latência de criação de novo locatário Imediata Rápido Rápido Médio Lento
Vantagens da modelagem de dados Nenhum Colocation de entidade Colocation de entidade Vários contêineres para entidades de locatário de modelo Vários contêineres e bancos de dados para locatários de modelo
Chave de criptografia O mesmo para todos os locatários O mesmo para todos os locatários O mesmo para todos os locatários O mesmo para todos os locatários 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 (somente com dimensionamento automático, caso contrário >, 400 RUs por locatário) >400 RUs por locatário >400 RUs por locatário
Caso de uso de exemplo Aplicativos B2C Oferta Standard para aplicativos B2B Oferta Premium para aplicativos B2B Oferta Premium para aplicativos B2B Oferta Premium para aplicativos B2B

Modelo de contêiner por locatário

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

Ao usar um contêiner para cada locatário, considere 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 os limites para o número mínimo de RUs para seu banco de dados e o número máximo de contêineres no banco de dados. Considere também se seus locatários 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 tiver um ou mais inquilinos grandes. 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 a taxa de transferência dedicada para cada contêiner. Essa abordagem funciona bem para inquilinos maiores e para inquilinos que correm o risco de ter o problema do vizinho barulhento. Mas a taxa de transferência de linha de base para cada locatário é maior, portanto, considere os requisitos mínimos e as implicações de custo desse modelo.

Se o modelo de dados do locatário exigir mais de uma entidade e se todas as entidades puderem compartilhar a mesma chave de partição, você poderá colocá-las no mesmo contêiner. Mas se o modelo de dados de 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. Para obter mais informações, consulte Modelar e particionar dados no Azure Cosmos DB.

O gerenciamento do ciclo de vida geralmente é mais simples quando você dedica contêineres a locatários. Você pode mover facilmente locatários entre modelos de taxa de transferência compartilhados e dedicados. E quando você desprovisiona um locatário, pode excluir rapidamente o contêiner.

Modelo de banco de dados por locatário

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

Semelhante ao modelo de conta por locatário, essa abordagem fornece o nível mais alto de isolamento de desempenho, mas fornece a menor densidade de locatário. Use essa opção se cada locatário exigir um modelo de dados mais complicado do que o viável no modelo de contêiner por locatário. Ou siga essa abordagem se a criação de novos locatários precisar ser rápida ou livre de qualquer sobrecarga inicial. Para algumas estruturas de desenvolvimento de software, o modelo de banco de dados por locatário pode ser o único nível de isolamento de desempenho compatível com a estrutura. Essas estruturas normalmente não dão suporte ao isolamento no nível da entidade (contêiner) e à colocação de entidade.

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

Particionamento

Use partições com seus contêineres do Azure Cosmos DB para criar contêineres compartilhados por 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 em um locatário. Uma estratégia de particionamento bem planejada implementa efetivamente o Padrão de fragmentação. Quando você tem contêineres grandes, o Azure Cosmos DB distribui seus locatários em vários nós físicos para obter um alto grau de escala.

Considere chaves de partição hierárquicas para ajudar a melhorar o desempenho de sua solução multilocatário. Use chaves de partição hierárquicas para criar uma chave de partição que inclua vários valores. Por exemplo, você pode usar uma chave de partição hierárquica que inclui o identificador de locatário, como um GUID de alta cardinalidade, para permitir uma escala praticamente desassociada. Ou você pode especificar uma chave de partição hierárquica que inclua uma propriedade que as consultas usam com frequência. Essa abordagem ajuda a evitar consultas entre partições. Use chaves de partição hierárquicas para dimensionar além do limite de partição lógica de 20 GB por valor de chave de partição e limitar consultas de fan-out caras.

Para saber mais, consulte os recursos a seguir:

Gerenciar RUs

O modelo de preços do Azure Cosmos DB é baseado no número de RU/s que você provisiona ou consome. O Azure Cosmos DB fornece várias opções para provisionar a taxa de transferência. Em um ambiente multilocatário, sua seleção 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 que você isole os locatários por conta de banco de dados e aloque RUs para o locatário. Para locatários que têm requisitos menos rigorosos, recomendamos que você isole os locatários por chave de partição. Use esse modelo para compartilhar RUs entre seus locatários e otimizar o custo por locatário.

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

O Azure Cosmos DB também fornece uma camada sem servidor, que se adapta a cargas de trabalho com tráfego intermitente ou imprevisível. Como alternativa, você pode usar o dimensionamento automático para configurar políticas que especificam o dimensionamento da taxa de transferência provisionada. Você também pode aproveitar a capacidade de intermitência do Azure Cosmos DB para maximizar o uso da capacidade de taxa de transferência provisionada, que de outra forma é restrita por limites de taxa. Em uma solução multilocatário, você pode combinar todas essas abordagens para dar suporte a diferentes tipos de locatários.

Observação

Ao planejar a configuração do Azure Cosmos DB, considere as cotas e os limites de serviço.

Para monitorar e gerenciar os custos associados a cada locatário, lembre-se de que todas as operações que usam a API do Azure Cosmos DB incluem as RUs consumidas. Você pode usar essas informações para agregar e comparar as RUs reais que cada locatário consome. Em seguida, você pode identificar locatários com características de desempenho diferentes.

Para saber mais, consulte os recursos a seguir:

Chaves gerenciadas pelo cliente

Alguns locatários podem exigir o uso das próprias chaves de criptografia. O Azure Cosmos DB fornece um recurso de chave gerenciada pelo cliente. Você aplica esse recurso no nível de uma conta do Azure Cosmos DB. Portanto, se os locatários exigirem suas próprias chaves de criptografia, você deverá usar contas dedicadas do Azure Cosmos DB para implantar os locatários.

Para saber mais, confira Configurar chaves gerenciadas pelo cliente para sua conta do Azure Cosmos DB com o Azure Key Vault.

Colaboradores

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

Principais autores:

  • Tara Bhatia | Gerente de Programa, Azure Cosmos DB
  • Paul Burpo | Engenheiro de cliente principal, FastTrack para Azure
  • John Downs | Engenheiro de software principal

Outros colaboradores:

  • Mark Brown | Gerente Principal de PM, Azure Cosmos DB
  • Deborah Chen | Gerente Principal de Programas
  • Theo van Kraay | Gerente Sênior de Programa, Azure Cosmos DB
  • Arsen Vladimirskiy | Engenheiro principal de atendimento ao cliente, FastTrack for Azure
  • Thomas Weiss | Gerente Principal de Programas
  • Vic Perdana | Arquiteto de Soluções de Nuvem, ISV do Azure

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

Próximas etapas

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

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