Os dados são muitas vezes considerados a parte mais valiosa de uma solução, porque representam as suas - e as dos seus clientes - valiosas informações comerciais. Por isso, é importante gerir cuidadosamente os seus dados. Ao planejar o armazenamento ou os componentes de dados para um sistema multilocatário, você precisa decidir sobre uma abordagem para compartilhar ou isolar os dados dos locatários.
Neste artigo, fornecemos orientação sobre as principais considerações e requisitos que são essenciais para os arquitetos de soluções ao decidir sobre uma abordagem para armazenar dados em um sistema multilocatário. Em seguida, sugerimos alguns padrões comuns para aplicar a multilocação a serviços de armazenamento e dados, e alguns antipadrões a evitar. Por último, fornecemos orientações específicas para algumas situações específicas.
Principais considerações e requisitos
É importante considerar as abordagens que você usa para armazenamento e serviços de dados de várias perspetivas, incluindo os pilares do Azure Well-Architected Framework.
Escala
Ao trabalhar com serviços que armazenam seus dados, você deve considerar o número de locatários que você tem e o volume de dados que você armazena. Se você tiver um pequeno número de locatários (como cinco ou menos) e estiver armazenando pequenas quantidades de dados para cada locatário, é provável que seja um esforço desperdiçado planejar uma abordagem de armazenamento de dados altamente escalável ou criar uma abordagem totalmente automatizada para gerenciar seus recursos de dados. Mas, à medida que você cresce, você se beneficia cada vez mais de ter uma estratégia clara para dimensionar seus dados e recursos de armazenamento e aplicar automação ao gerenciamento deles. Quando você tem 50 locatários ou mais, ou se planeja atingir esse nível de escala, é especialmente importante projetar sua abordagem de dados e armazenamento, com a escala como uma consideração fundamental.
Considere até que ponto você planeja dimensionar e planeje claramente sua abordagem de arquitetura de armazenamento de dados para atender a esse nível de escala.
Previsibilidade do desempenho
Os dados multilocatários e os serviços de armazenamento são particularmente suscetíveis ao problema do vizinho barulhento. É importante considerar se os inquilinos podem afetar o desempenho uns dos outros. Por exemplo, os seus inquilinos têm picos sobrepostos nos seus padrões de utilização ao longo do tempo? Todos os seus clientes utilizam a sua solução à mesma hora todos os dias ou os pedidos são distribuídos uniformemente? Esses fatores afetarão o nível de isolamento para o qual você precisa projetar, a quantidade de recursos que precisa provisionar e o grau em que os recursos podem ser compartilhados entre os locatários.
É importante considerar as cotas de recursos e solicitações do Azure como parte dessa decisão. Por exemplo, suponha que você implante uma única conta de armazenamento para conter todos os dados de seus locatários. Se você exceder um número específico de operações de armazenamento por segundo, o Armazenamento do Azure rejeitará as solicitações do seu aplicativo e todos os seus locatários serão afetados. Isso é chamado de comportamento de limitação . É importante que você monitore as solicitações limitadas. Para obter mais informações, consulte Diretrizes de repetição para serviços do Azure.
Isolamento de dados
Ao projetar uma solução que contém serviços de dados multilocatário, geralmente há diferentes opções e níveis de isolamento de dados, cada um com seus próprios benefícios e compensações. Por exemplo:
- Ao usar o Azure Cosmos DB, você pode implantar contêineres separados para cada locatário e compartilhar bancos de dados e contas entre vários locatários. Como alternativa, você pode considerar a implantação de bancos de dados diferentes ou até mesmo contas para cada locatário, dependendo do nível de isolamento necessário.
- Ao usar o Armazenamento do Azure para dados de blob, você pode implantar contêineres de blob separados para cada locatário ou pode implantar contas de armazenamento separadas.
- Ao usar o SQL do Azure, você pode usar tabelas separadas em bancos de dados compartilhados ou implantar bancos de dados ou servidores separados para cada locatário.
- Em todos os serviços do Azure, você pode considerar a implantação de recursos em uma única assinatura compartilhada do Azure ou pode usar várias assinaturas do Azure - talvez até uma por locatário.
Não existe uma solução única que funcione para todas as situações. A opção escolhida depende de uma série de fatores e dos requisitos dos seus inquilinos. Por exemplo, se os seus inquilinos precisarem de cumprir normas regulamentares ou de conformidade específicas, poderá ter de aplicar um nível mais elevado de isolamento. Da mesma forma, você pode ter requisitos comerciais para isolar fisicamente os dados de seus clientes ou pode ser necessário impor o isolamento para evitar o problema do vizinho barulhento. Além disso, se os locatários precisarem usar suas próprias chaves de criptografia, tiverem políticas individuais de backup e restauração ou precisarem ter seus dados armazenados em locais geográficos diferentes, talvez seja necessário isolá-los de outros locatários ou agrupá-los com locatários que tenham políticas semelhantes.
Complexidade da execução
É importante considerar a complexidade da sua implementação. É uma boa prática manter sua arquitetura o mais simples possível, sem deixar de atender às suas necessidades. Evite comprometer-se com uma arquitetura que se tornará cada vez mais complexa à medida que você escala, ou uma arquitetura que você não tem os recursos ou a experiência para desenvolver e manter.
Da mesma forma, se sua solução não precisar ser dimensionada para um grande número de locatários ou se você não tiver preocupações com o desempenho ou o isolamento de dados, é melhor manter a solução simples e evitar adicionar complexidade desnecessária.
Uma preocupação particular para soluções de dados multilocatários é o nível de personalização suportado. Por exemplo, um locatário pode estender seu modelo de dados ou aplicar regras de dados personalizadas? Certifique-se de projetar para esse requisito antecipadamente. Evite bifurcar ou fornecer infraestrutura personalizada para locatários individuais. A infraestrutura personalizada inibe sua capacidade de escalar, testar sua solução e implantar atualizações. Em vez disso, considere o uso de sinalizadores de recursos e outras formas de configuração de locatário.
Complexidade da gestão e das operações
Considere como você planeja operar sua solução e como sua abordagem de multilocação afeta suas operações e processos. Por exemplo:
- Gerenciamento: considere operações de gerenciamento entre locatários, como atividades de manutenção regulares. Se você usar várias contas, servidores ou bancos de dados, como iniciará e monitorará as operações para cada locatário?
- Monitoramento e medição: se você monitorar ou medir seus locatários, considere como sua solução relata métricas e se elas podem ser facilmente vinculadas ao locatário que disparou a solicitação.
- Relatórios: a geração de relatórios de dados entre locatários isolados pode exigir que cada locatário publique dados em um data warehouse centralizado, em vez de executar consultas em cada banco de dados individualmente e, em seguida, agregar os resultados.
- Atualizações de esquema: se você usar um banco de dados que imponha um esquema, planeje como implantará as atualizações de esquema em todo o seu patrimônio. Considere como seu aplicativo sabe qual versão de esquema usar para consultas de banco de dados de um locatário específico.
- Requisitos: considere os requisitos de alta disponibilidade de seus locatários (por exemplo, contratos de nível de serviço de tempo de atividade ou SLAs) e os requisitos de recuperação de desastres (por exemplo, objetivos de tempo de recuperação, ou RTOs, e objetivos de ponto de recuperação, ou RPOs). Se os inquilinos tiverem expectativas diferentes, conseguirá satisfazer os requisitos de cada inquilino?
- Migração: Como você migrará locatários se eles precisarem mudar para um tipo diferente de serviço, uma implantação diferente ou outra região?
Custo
Geralmente, quanto maior a densidade de locatários para sua infraestrutura de implantação, menor o custo para provisionar essa infraestrutura. No entanto, a infraestrutura compartilhada aumenta a probabilidade de problemas como o problema do vizinho barulhento, portanto, considere as compensações cuidadosamente.
Abordagens e padrões a considerar
Vários padrões de design do Centro de Arquitetura do Azure são relevantes para o armazenamento multilocatário e os serviços de dados. Você pode optar por seguir um padrão de forma consistente. Ou, você pode considerar misturar e combinar padrões. Por exemplo, você pode usar um banco de dados multilocatário para a maioria dos locatários, mas implantar carimbos de locatário único para locatários que pagam mais ou que têm requisitos incomuns. Da mesma forma, geralmente é uma boa prática dimensionar usando carimbos de implantação, mesmo quando você usa um banco de dados multilocatário ou bancos de dados fragmentados dentro de um carimbo.
Padrão de selos de implantação
Para obter mais informações sobre como o padrão de Carimbos de Implantação pode ser usado para dar suporte a uma solução multilocatário, consulte Visão geral.
Bancos de dados multilocatários compartilhados e armazenamentos de arquivos
Você pode considerar implantar um banco de dados multilocatário compartilhado, uma conta de armazenamento ou um compartilhamento de arquivos e compartilhá-lo entre todos os seus locatários.
Essa abordagem fornece a maior densidade de inquilinos para a infraestrutura, por isso tende a ter o menor custo de qualquer abordagem. Muitas vezes, também reduz a sobrecarga de gerenciamento, porque há um único banco de dados ou recurso para gerenciar, fazer backup e proteger.
No entanto, quando você trabalha com infraestrutura compartilhada, há várias ressalvas a serem consideradas:
- Limites de escala: quando você depende de um único recurso, considere a escala e os limites suportados desse recurso. Por exemplo, o tamanho máximo de um banco de dados ou armazenamento de arquivos, ou os limites máximos de taxa de transferência, acabarão se tornando um bloqueador rígido, se sua arquitetura depender de um único banco de dados. Considere cuidadosamente a escala máxima que você precisa alcançar e compare-a com seus limites atuais e futuros, antes de selecionar esse padrão.
- Vizinhos barulhentos: O problema do vizinho barulhento pode se tornar um fator, especialmente se você tiver inquilinos que estão particularmente ocupados ou geram cargas de trabalho mais altas do que outros. Considere a aplicação do padrão de Limitação ou do padrão de Limitação de Taxa para mitigar esses efeitos.
- Monitoramento de cada locatário: você pode ter dificuldade em monitorar a atividade e medir o consumo de um único locatário. Alguns serviços, como o Azure Cosmos DB, fornecem relatórios sobre o uso de recursos para cada solicitação, para que essas informações possam ser rastreadas para medir o consumo de cada locatário. Outros serviços não fornecem o mesmo nível de detalhe. Por exemplo, as métricas de Arquivos do Azure para capacidade de arquivo estão disponíveis por dimensão de compartilhamento de arquivos e somente quando você usa compartilhamentos premium. No entanto, o nível padrão fornece as métricas apenas no nível da conta de armazenamento.
- Requisitos do locatário: os locatários podem ter requisitos diferentes de segurança, backup, disponibilidade ou local de armazenamento. Se eles não corresponderem à configuração do seu único recurso, talvez você não consiga acomodá-los.
- Personalização de esquema: Quando você trabalha com um banco de dados relacional ou outra situação em que o esquema dos dados é importante, a personalização do esquema no nível do locatário é difícil.
Padrão de fragmentação
O padrão de compartilhamento envolve a implantação de vários bancos de dados separados, chamados fragmentos, cada um contendo um ou mais dados de locatários. Ao contrário dos carimbos de implantação, os fragmentos não implicam que toda a infraestrutura seja duplicada. Você pode fragmentar bancos de dados sem também duplicar ou fragmentar outra infraestrutura em sua solução.
O compartilhamento está intimamente relacionado ao particionamento, e os termos são frequentemente usados de forma intercambiável. Considere a orientação de particionamento de dados horizontal, vertical e funcional.
O padrão de compartilhamento pode ser dimensionado para um número muito grande de locatários. Além disso, dependendo da sua carga de trabalho, você pode conseguir uma alta densidade de inquilinos para fragmentos, para que o custo possa ser atraente. O padrão de compartilhamento também pode ser usado para abordar a assinatura do Azure e cotas, limites e restrições.
Alguns armazenamentos de dados, como o Azure Cosmos DB, fornecem suporte nativo para fragmentação ou particionamento. Quando você trabalha com outras soluções, como o Azure SQL, pode ser mais complexo criar uma infraestrutura de fragmentação e rotear solicitações para o fragmento correto para um determinado locatário.
O compartilhamento também dificulta o suporte a diferenças de configuração no nível do locatário e permite que os clientes forneçam suas próprias chaves de criptografia.
Aplicativo multilocatário com bancos de dados dedicados para cada locatário
Outra abordagem comum é implantar um único aplicativo multilocatário, com bancos de dados dedicados para cada locatário.
Nesse modelo, os dados de cada locatário são isolados dos outros, e você pode oferecer suporte a algum grau de personalização para cada locatário.
Como você provisiona recursos de dados dedicados para cada locatário, o custo dessa abordagem pode ser maior do que os modelos de hospedagem compartilhada. No entanto, o Azure fornece várias opções que você pode considerar, a fim de compartilhar o custo de hospedar recursos de dados individuais entre vários locatários. Por exemplo, quando você trabalha com o Azure SQL, pode considerar pools elásticos. Para o Azure Cosmos DB, você pode provisionar a taxa de transferência para um banco de dados e a taxa de transferência é compartilhada entre os contêineres nesse banco de dados, embora essa abordagem não seja apropriada quando você precisa de desempenho garantido para cada contêiner.
Nessa abordagem, como apenas os componentes de dados são implantados individualmente para cada locatário, você provavelmente pode obter alta densidade para os outros componentes em sua solução e reduzir o custo desses componentes.
É importante usar abordagens de implantação automatizadas ao provisionar bancos de dados para cada locatário.
Padrão geodo
O padrão Geode foi projetado especificamente para soluções distribuídas geograficamente, incluindo soluções multilocatário. Suporta cargas elevadas e elevados níveis de resiliência. Se você implementar o padrão Geode, sua camada de dados deverá ser capaz de replicar os dados entre regiões geográficas e deverá oferecer suporte a gravações em várias geografias.
O Azure Cosmos DB fornece gravações de várias regiões para dar suporte a esse padrão, e o Cassandra dá suporte a clusters de várias regiões. Outros serviços de dados geralmente não são capazes de suportar esse padrão, sem personalização significativa.
Antipadrões a evitar
Ao criar serviços de dados multilocatário, é importante evitar situações que inibem sua capacidade de escala.
Para bancos de dados relacionais, eles incluem:
- Isolamento baseado em tabela. Ao trabalhar em um único banco de dados, evite criar tabelas individuais para cada locatário. Um único banco de dados não será capaz de suportar um número muito grande de locatários quando você usar essa abordagem, e torna-se cada vez mais difícil consultar, gerenciar e atualizar dados. Em vez disso, considere usar um único conjunto de tabelas multilocatárias com uma coluna de identificador de locatário. Como alternativa, você pode usar um dos padrões descritos acima para implantar bancos de dados separados para cada locatário.
- Personalização do locatário no nível da coluna. Evite atualizações de esquema que se aplicam apenas a um único locatário. Por exemplo, suponha que você tenha um único banco de dados multilocatário. Evite adicionar uma nova coluna para atender aos requisitos de um locatário específico. Pode ser aceitável para um pequeno número de personalizações, mas isso rapidamente se torna incontrolável quando você tem um grande número de personalizações a considerar. Em vez disso, considere revisar seu modelo de dados para controlar dados personalizados para cada locatário em uma tabela dedicada.
- Alterações manuais de esquema. Evite atualizar seu esquema de banco de dados manualmente, mesmo que você tenha apenas um único banco de dados compartilhado. É fácil perder o controle das atualizações aplicadas e, se precisar expandir para mais bancos de dados, é um desafio identificar o esquema correto a ser aplicado. Em vez disso, crie um pipeline automatizado para implantar suas alterações de esquema e use-o de forma consistente. Acompanhe a versão do esquema usada para cada locatário em um banco de dados dedicado ou tabela de pesquisa.
- Dependências de versão. Evite que seu aplicativo dependa de uma única versão do esquema de banco de dados. À medida que você dimensiona, talvez seja necessário aplicar atualizações de esquema em momentos diferentes para locatários diferentes. Em vez disso, verifique se a versão do aplicativo é compatível com versões anteriores com pelo menos uma versão do esquema e evite atualizações destrutivas do esquema.
Bases de Dados
Existem alguns recursos que podem ser úteis para a multilocação. No entanto, eles não estão disponíveis em todos os serviços de banco de dados. Considere se você precisa deles, quando decidir sobre o serviço a ser usado para seu cenário:
- A segurança em nível de linha pode fornecer isolamento de segurança para dados de locatários específicos em um banco de dados multilocatário compartilhado. Esse recurso está disponível no Azure SQL e no Postgres Flex, mas não está disponível em outros bancos de dados, como MySQL ou Azure Cosmos DB.
- A criptografia no nível do locatário pode ser necessária para dar suporte a locatários que fornecem suas próprias chaves de criptografia para seus dados. Esse recurso está disponível no SQL do Azure como parte do Always Encrypted. O Azure Cosmos DB fornece chaves gerenciadas pelo cliente no nível da conta e também dá suporte ao Always Encrypted.
- O pool de recursos oferece a capacidade de compartilhar recursos e custos entre vários bancos de dados ou contêineres. Esse recurso está disponível nos pools elásticos e instâncias gerenciadas do Azure SQL e na taxa de transferência do banco de dados do Azure Cosmos DB, embora cada opção tenha limitações das quais você deve estar ciente.
- O compartilhamento e o particionamento têm um suporte nativo mais forte em alguns serviços do que em outros. Esse recurso está disponível no Azure Cosmos DB, usando seu particionamento lógico e físico. Embora o SQL do Azure não ofereça suporte nativo à fragmentação, ele fornece ferramentas de fragmentação para dar suporte a esse tipo de arquitetura.
Além disso, ao trabalhar com bancos de dados relacionais ou outros bancos de dados baseados em esquema, considere onde o processo de atualização de esquema deve ser acionado, quando você mantém uma frota de bancos de dados. Em um pequeno conjunto de bancos de dados, você pode considerar o uso de um pipeline de implantação para implantar alterações de esquema. À medida que o número de bancos de dados aumenta, pode ser melhor para sua camada de aplicativo detetar a versão do esquema para um banco de dados específico e iniciar o processo de atualização.
Armazenamento de arquivos e blob
Considere a abordagem usada para isolar dados em uma conta de armazenamento. Por exemplo, você pode implantar contas de armazenamento separadas para cada locatário ou pode compartilhar contas de armazenamento e implantar contêineres individuais. Como alternativa, você pode criar contêineres de blob compartilhados e, em seguida, usar o caminho de blob para separar dados para cada locatário. Considere os limites e quotas de subscrição do Azure e planeie cuidadosamente o seu crescimento para garantir que os seus recursos do Azure sejam dimensionados para suportar as suas necessidades futuras.
Se você usa contêineres compartilhados, planeje sua estratégia de autenticação e autorização com cuidado, para garantir que os locatários não possam acessar os dados uns dos outros. Considere o padrão de chave de manobrista ao fornecer aos clientes acesso aos recursos do Armazenamento do Azure.
Alocação de custos
Considere como você medirá o consumo e alocará os custos aos locatários, para o uso de serviços de dados compartilhados. Sempre que possível, procure usar métricas incorporadas em vez de calcular as suas. No entanto, com a infraestrutura compartilhada, torna-se difícil dividir a telemetria para locatários individuais, e talvez seja necessário considerar a medição personalizada no nível do aplicativo.
Em geral, os serviços nativos da nuvem, como o Azure Cosmos DB e o Armazenamento de Blobs do Azure, fornecem métricas mais granulares para controlar e modelar o uso para um locatário específico. Por exemplo, o Azure Cosmos DB fornece a taxa de transferência consumida para cada solicitação e resposta.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Autor principal:
- John Downs - Brasil | Engenheiro de Software Principal
Outros contribuidores:
- Paul Burpo - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
- Daniel Scott-Raynsford - Brasil | Estrategista de Tecnologia de Parceiros
- Arsen Vladimirskiy - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.
Próximos passos
Para obter mais informações sobre multilocação e serviços específicos do Azure, consulte: