Compartilhar via

Multilocatário e Azure Cosmos DB

  • Artigo

Nesta página, descrevemos alguns dos recursos do Azure Cosmos DB que são úteis quando você está trabalhando com sistemas multilocatários. Também fornecemos links para diretrizes e exemplos de como usar o Azure Cosmos DB em uma solução multilocatário.

Requisitos de multilocação

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

  • Garantir um forte isolamento entre locatários e atender aos requisitos estritos de segurança para aqueles que precisam deles.
  • Manter baixo custo por locatário. Como provedor, você deseja garantir que o custo de execução do aplicativo permaneça sustentável à medida que ele é ampliado.

Muitas vezes, essas duas necessidades podem entrar em conflito, exigindo compensações e dando prioridade a uma em relação à outra. Existem certas diretrizes que você pode seguir para entender melhor as vantagens e desvantagens envolvidas em atender ambas as necessidades descritas acima. Este documento ajuda você a navegar por essas considerações, de forma que 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 locatários. O Azure Cosmos DB dá suporte a uma variedade de modelos de isolamento, mas para a maioria das soluções, recomendamos usar uma das seguintes estratégias:

  • Chave de partição por locatário, que geralmente é usada para soluções totalmente multilocatários, como aquelas usadas em software como serviço business-to-consumer (B2C SaaS).
  • Conta de banco de dados por locatário, o que é usado em SaaS business-to-business (B2B).

Para selecionar o modelo de isolamento mais apropriado, considere seu modelo de negócios e as exigências dos locatários. Por exemplo, para certos modelos de B2C, em que as empresas vendem diretamente a um cliente individual usando o produto ou serviço, o forte isolamento do desempenho pode não ser uma prioridade. No entanto, os modelos B2B podem priorizar o forte isolamento de segurança e de desempenho, podendo 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ê esteja criando uma solução SaaS B2B que vende para clientes corporativos, e também proporcionando 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, ao mesmo tempo que compartilha uma conta de banco de dados e usa chaves de partição para isolar clientes de avaliação.

Chave de partição por locatário

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

Benefícios:

  • Eficiência de custo: todos os locatários são colocados em um contêiner, que é particionado por ID de locatário. Como há apenas um único recurso faturável, em que as RU/s são provisionadas e compartilhadas entre vários locatários, essa abordagem geralmente é mais econômica e fácil de gerenciar do que ter contas separadas por locatário.
  • Gerenciamento simplificado: menor número de contas do Azure Cosmos DB para gerenciar.

Vantagens e desvantagens

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

Recursos relevantes do Azure Cosmos DB:

  • Controlar sua taxa de transferência: recursos que podem ajudar a controlar o problema do vizinho barulhento ao modelar o 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 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 chave de partição única de Contoso, você pode incluir sal nas chaves de partição criando várias chaves de partição para um locatário, como Contoso1, Contoso2 e assim por diante.

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

    Suponha que você tenha uma carga de trabalho que isola locatários por chave de partição. Um locatário, a Contoso, é muito 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 ainda mais baixo para outro nível, como SessionID. As consultas que especificam TenantID ou TenantID e UserID são roteadas efetivamente apenas para o subconjunto de partições físicas que contêm os dados relevantes, o que evita uma consulta do tipo fan-out completa. Se o contêiner tivesse 1.000 partições físicas, mas um valor específico de 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 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 a possibilidade de usar uma chave de partição sintética em vez de uma chave de partição hierárquica.

Conta do banco de dados por locatário

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

Benefícios:

  • Alto isolamento: esta abordagem evita contenção ou interferência devido a contas e contêineres dedicados do Azure Cosmos DB com RU/s provisionadas por locatário exclusivo.
  • SLAs personalizados: como cada locatário tem sua própria conta, você pode fornecer recursos personalizados específicos, SLAs voltados para o cliente e garantias, porque a conta de banco de dados de cada locatário pode ser ajustada de forma independente para a taxa de transferência.
  • Segurança aprimorada: o isolamento físico de dados garante segurança robusta, já que os clientes podem habilitar chaves gerenciadas pelo cliente em 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 de nível de conta, como replicação geográfica, restauração pontual (PITR) e chaves gerenciadas pelo cliente (CMK), conforme necessário.

Vantagens e desvantagens

  • Maior gerenciamento: essa abordagem traz maior complexidade devido ao gerenciamento de várias contas do Azure Cosmos DB.
  • Custos mais altos: mais contas significa 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, os custos do Azure Cosmos DB aumentam.
  • Limitações de consultas: como todos os locatários estão em contas diferentes, ao consultar para vários locatários, são necessárias várias chamadas dentro da lógica do aplicativo para cada locatário.

Recursos relevantes do Azure Cosmos DB:

  • Recursos de segurança: este modelo fornece maior isolamento de segurança de acesso a dados usando o RBAC do Azure. 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 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 Precisa ser implementada no 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 Nenhum Nenhum 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 colocação de entidades colocação de entidades 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
Exemplos de casos de uso Aplicativos B2C Oferta Standard para aplicativos B2B Oferta Premium para aplicativos B2B Oferta Premium para aplicativos B2B Oferta Premium para aplicativos B2B

Contêiner por locatário

Você pode provisionar contêineres dedicados para cada locatário. Os contêineres dedicados funcionam bem quando os dados que você armazena do locatário podem ser combinados em um contêiner único. 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 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 em relação ao número mínimo de unidades de solicitação para o banco de dados e ao número máximo de contêineres no banco de dados. Além disso, considere se os seus locatários exigem um nível garantido de desempenho e se eles estã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ê poderá ter um problema de vizinho barulhento, se houver um ou mais locatários 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 em locatários maiores e em locatários que têm risco de ter o problema do vizinho barulhento. No entanto, 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 requerer mais de uma entidade, desde que todas as entidades possam compartilhar a mesma chave de partição, elas poderão ser colocadas no mesmo contêiner. No entanto, se o modelo de dados do locatário for mais complexo e exigir entidades que não possam 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. Confira nosso artigo sobre como modelar e particionar dados no Azure Cosmos DB usando um exemplo do mundo real para obter mais orientação.

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

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 no modelo contêiner por locatário acima, esse modelo proporciona maior isolamento de desempenho do que o modelo chave de partição por locatário e também proporciona maior isolamento de segurança de acesso a dados por meio do RBAC do Azure.

Do modo similar que para o 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ário. 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 então, você deverá seguir essa abordagem quando for um requisito para que a criação de novos locatários seja rápida 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 modelo de banco de dados por locatário seja o único nível de isolamento de desempenho reconhecido nessa estrutura. Geralmente, o isolamento no nível de entidade (contêiner) e a colocação de entidade não têm suporte nativamente em tais estruturas.

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

Particionamento

Usando partições com seus contêineres do Azure Cosmos DB, você pode criar contêineres 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 em um locatário. Uma estratégia de particionamento bem planejada implementa efetivamente o Padrão de fragmentação. Em contêineres grandes, o Azure Cosmos DB espalha os locatários entre vários nós físicos para atingir 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 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 então você pode especificar uma chave de partição hierárquica que inclua uma propriedade usada com frequência em consultas. Esta abordagem ajuda a evitar consultas cruzadas 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 do tipo fan-out caras.

Para obter mais informações:

Como gerenciar unidades de solicitação

O modelo de preços do Azure Cosmos DB baseia-se 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 é conhecida como taxa de transferência. O Azure Cosmos DB fornece várias opções para provisionar a taxa de transferência. Em um ambiente multilocatário, a seleção que você faz afeta o desempenho e o preço dos recursos do Azure Cosmos DB.

Em caso de locatários que exijam desempenho garantido e isolamento de segurança, recomendamos isolar locatários por conta de banco de dados e alocar unidades de solicitação para o locatário. Em caso de locatários com exigências menos rigorosas, recomendamos isolar locatários por chave de partição, o que habilita o compartilhamento de unidades de solicitação entre os seus locatários e ajuda você a otimizar para um baixo 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. 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 suas cargas de trabalho de locatário normalmente não se sobrepõem, essa abordagem pode ajudar a reduzir seus custos operacionais. No entanto, essa abordagem é suscetível ao problema do "vizinho barulhento" porque um contêiner de locatário único pode consumir uma quantidade desproporcional das unidades de solicitação 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 é adequada para cargas de trabalho com tráfego intermitente ou imprevisível. Como alternativa, o dimensionamento automático permite que você configure políticas para especificar a escala 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 da 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 dar suporte a diferentes tipos de locatário.

Observação

Ao planejar sua 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, cada operação que usa 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 em cada locatário e identificar locatários com características de desempenho diferentes.

Para obter mais informações:

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. Esse recurso é aplicado no nível de uma conta do Azure Cosmos DB, portanto, os locatários que exigem as próprias chaves de criptografia precisam ser implantados usando contas dedicadas do Azure Cosmos DB.

Para obter mais informações:

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

Examine as abordagens de armazenamento e de 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: