Multilocatário e Azure Cosmos DB

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.

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 inclua o identificador de locatário e o tipo de dados que você está armazenando. Essa abordagem permite que você dimensione além do limite de partição lógica de 20 GB por valor de chave de partição.

Para obter mais informações:

• Particionamento e escala horizontal no Azure Cosmos DB
• Chaves de partição hierárquicas

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.

Um modelo de locação 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.

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:

• Taxa de transferência provisionada
• Autoescala
• Sem servidor
• Medindo o preço da RU de uma solicitação
• Cotas de serviço do Azure Cosmos DB
• Capacidade de intermitência

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:

• Configurar chaves gerenciadas pelo cliente para sua conta do Azure Cosmos DB com o Azure Key Vault

Modelos de isolamento

Ao trabalhar com um sistema multilocatário que usa o Azure Cosmos DB, você precisa tomar uma decisão sobre o nível de isolamento que deseja usar. B2B (entre empresas) refere-se à venda para uma empresa. BB2C (entre empresa e consumidor) refere-se à venda direta para um cliente individual que usa o produto ou serviço. O Azure Cosmos DB dá suporte a vários modelos de isolamento:

Chave de partição por locatário

Ao usar um contêiner único para múltiplos locatários, você poderá usar o suporte de particionamento do Azure Cosmos DB. Usando chaves de partição separadas para cada locatário, você pode consultar facilmente os dados para um locatário. Você também pode consultar vários locatários, mesmo que eles estejam em partições separadas. No entanto, as consultas entre partições têm um custo de RU (unidade de solicitação) maior do que as consultas de partição única.

Essa abordagem tende a funcionar bem quando a quantidade de dados armazenados em cada locatário é pequena. Pode ser uma boa opção para criar um modelo de preços que inclua uma camada gratuita e soluções B2C (empresa para consumidor). Em geral, usando contêineres compartilhados, você obtém uma densidade maior de locatários e, portanto, o menor preço por locatário.

É importante considerar a taxa de transferência do contêiner. Todos os locatários vão compartilhar a taxa de transferência do contêiner, portanto, o problema do "vizinho barulhento" poderá causar dificuldades de desempenho se os seus locatários tiverem cargas de trabalho altas ou sobrepostas. Às vezes, esse problema pode ser resolvido agrupando subconjuntos de locatários em contêineres diferentes e garantindo que cada grupo de locatários tenha padrões de uso compatíveis. Como alternativa, você pode considerar um modelo híbrido de locatário único e multilocatário. Agrupe locatários menores em contêineres particionados compartilhados e forneça contêineres dedicados a grandes clientes. Além disso, há 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.

Também é importante considerar a quantidade de dados que você armazena em cada partição lógica. 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, 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.

Considere os aspectos operacionais da sua solução e as diferentes fases do ciclo de vida do locatário. Por exemplo, quando um locatário for movido para um tipo de preço dedicado, você provavelmente precisará migrar os dados para um contêiner diferente. Quando um locatário for desprovisionado, você precisará executar uma consulta de exclusão no contêiner para remover os dados e, para locatários grandes, essa consulta pode consumir uma quantidade significativa de taxa de transferência enquanto ela é executada.

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.

Assim como o modelo de conta por locatário abaixo, 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.

Conta do banco de dados por locatário

O Azure Cosmos DB permite provisionar contas de banco de dados separadas para cada locatário, o que fornece o nível mais alto de isolamento, mas a densidade mais baixa. Assim como os modelos de contêiner por locatário e banco de dados por locatário acima, 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. 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.

Uma conta de banco de dados individual é dedicada a um locatário, o que significa que eles não estão sujeitos ao problema de vizinho barulhento. 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.

Se você usar esse modelo, deverá considerar a velocidade com que seu aplicativo precisa gerar novos locatários. A criação de conta no Azure Cosmos DB pode levar alguns minutos, portanto, talvez seja necessário criar contas antecipadamente. Se essa abordagem não for viável, considere o modelo de banco de dados por locatário.

Se você permitir que os locatários migrem de uma conta compartilhada para uma conta dedicada do Azure Cosmos DB, considere a abordagem de migração que você usará para mover os dados de um locatário entre as contas antigas e novas.

Abordagens híbridas

Você pode considerar uma combinação das abordagens acima para atender aos requisitos de diferentes locatários e ao seu modelo de preços. Por exemplo:

• Provisione todos os clientes de avaliação gratuita em um contêiner compartilhado e use a ID do locatário ou uma chave de partição de chave sintética.
• Ofereça uma camada Bronze paga que implanta um contêiner dedicado por locatário, mas com taxa de transferência compartilhada em um banco de dados.
• Ofereça uma camada Silver superior que provisione a taxa de transferência dedicada para o contêiner do locatário.
• Ofereça a camada Gold mais alta e forneça uma conta de banco de dados dedicada para o locatário, o que também permite que os locatários selecionem a geografia da implantação.

Colaboradores

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

Principais autores:

• 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:

• Azure Cosmos DB e sistemas multilocatários: uma postagem no blog que discute como criar um sistema multilocatário que usa o Azure Cosmos DB.
• Aplicativos multilocatários com o Azure Cosmos DB (vídeo)
• Como criar um SaaS multilocatário com o Azure Cosmos DB e o Azure (vídeo): um estudo de caso do mundo real sobre como o Whally, um startup de SaaS multilocatário, criou uma plataforma moderna do zero no Azure Cosmos DB e no Azure. O Whally mostra as decisões de design e implementação tomadas relacionadas ao particionamento, modelagem de dados, multilocação segura, desempenho, streaming em tempo real do feed de alterações para o SignalR e muito mais. Todas essas soluções usam ASP.NET Core nos Serviços de Aplicativos do Azure.

Recursos relacionados

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

• Aplicativos sem servidor usando o Azure Cosmos DB
• Azure Cosmos DB em cargas de trabalho de IoT
• Padrão de caixa de saída transacional com o Azure Cosmos DB
• Pesquisa visual no varejo com o Azure Cosmos DB
• Jogos com o Azure Cosmos DB