Padrões de locação de banco de dados SaaS multilocatário

Aplica-se a:Banco de Dados SQL do Azure

Este artigo descreve os vários modelos de locação disponíveis para um aplicativo SaaS multilocatário.

Ao projetar um aplicativo SaaS multilocatário, você deve escolher cuidadosamente o modelo de locação que melhor se adapta às necessidades do seu aplicativo. Um modelo de locação determina como os dados de cada locatário são mapeados para armazenamento. Sua escolha de modelo de locação afeta o design e o gerenciamento de aplicativos. Mudar para um modelo diferente mais tarde é, por vezes, dispendioso.

R. Conceitos e terminologia SaaS

No modelo Software as a Service (SaaS), a sua empresa não vende licenças para o seu software. Em vez disso, cada cliente faz pagamentos de aluguel para sua empresa, tornando cada cliente um inquilino de sua empresa.

Em troca do pagamento do aluguel, cada locatário recebe acesso aos componentes do seu aplicativo SaaS e tem seus dados armazenados no sistema SaaS.

O termo modelo de arrendamento refere-se à forma como os dados armazenados dos inquilinos são organizados:

• Locação única: cada banco de dados armazena dados de apenas um locatário.
• Multilocação: cada banco de dados armazena dados de vários locatários separados (com mecanismos para proteger a privacidade dos dados).
• Também estão disponíveis modelos de arrendamento híbridos.

B. Como escolher o modelo de arrendamento adequado

Em geral, o modelo de locação não afeta a função de um aplicativo, mas provavelmente afeta outros aspetos da solução geral. Para avaliar cada um dos modelos, são utilizados os seguintes critérios:

• Escalabilidade:

  • Número de inquilinos.
  • Armazenamento por locatário.
  • Armazenamento em conjunto.
  • Carga de trabalho.

• Isolamento do locatário: isolamento e desempenho de dados (se a carga de trabalho de um locatário afeta outros).

• Custo por locatário: custos do banco de dados.

• Complexidade do desenvolvimento:

  • Alterações no esquema.
  • Alterações nas consultas (exigidas pelo padrão).

• Complexidade operacional:

  • Monitorização e gestão do desempenho.
  • Gerenciamento de esquema.
  • Restaurando um locatário.
  • Recuperação após desastre

• Capacidade de personalização: facilidade de suportar personalizações de esquema que são específicas do locatário ou da classe do locatário.

A discussão sobre locação está focada na camada de dados . Mas considere por um momento a camada de aplicação . A camada de aplicação é tratada como uma entidade monolítica. Se você dividir o aplicativo em muitos componentes pequenos, sua escolha do modelo de locação pode mudar. Você pode tratar alguns componentes de forma diferente de outros em relação à locação e à tecnologia ou plataforma de armazenamento usada.

C. Aplicativo autônomo de locatário único com banco de dados de locatário único

Isolamento no nível do aplicativo

Neste modelo, toda a aplicação é instalada repetidamente, uma vez para cada inquilino. Cada instância do aplicativo é uma instância autônoma, portanto, nunca interage com nenhuma outra instância autônoma. Cada instância do aplicativo tem apenas um locatário e, portanto, precisa de apenas um banco de dados. O locatário tem o banco de dados todo para si.

Cada instância do aplicativo é instalada em um grupo de recursos do Azure separado. O grupo de recursos pode pertencer a uma assinatura de propriedade do fornecedor do software ou do locatário. Em ambos os casos, o fornecedor pode gerenciar o software para o locatário. Cada instância do aplicativo é configurada para se conectar ao banco de dados correspondente.

Cada banco de dados de locatário é implantado como um único banco de dados. Este modelo fornece o maior isolamento de banco de dados. Mas o isolamento exige que recursos suficientes sejam alocados a cada banco de dados para lidar com seus picos de carga. Aqui é importante que os pools elásticos não possam ser usados para bancos de dados implantados em grupos de recursos diferentes ou para assinaturas diferentes. Essa limitação torna esse modelo de aplicativo autônomo de locatário único a solução mais cara do ponto de vista do custo geral do banco de dados.

Gestão de fornecedores

O fornecedor pode acessar todos os bancos de dados em todas as instâncias de aplicativo autônomas, mesmo que as instâncias do aplicativo estejam instaladas em assinaturas de locatário diferentes. O acesso é conseguido através de ligações SQL. Esse acesso entre instâncias pode permitir que o fornecedor centralize o gerenciamento de esquema e a consulta entre bancos de dados para fins de relatório ou análise. Se esse tipo de gerenciamento centralizado for desejado, deverá ser implantado um catálogo que mapeie identificadores de locatário para URIs de banco de dados. O Banco de Dados SQL do Azure fornece uma biblioteca de fragmentação que é usada em conjunto para fornecer um catálogo. A biblioteca de fragmentação é formalmente chamada de Biblioteca de Cliente do Banco de Dados Elástico.

D. Aplicativo multilocatário com banco de dados por locatário

Esse próximo padrão usa um aplicativo multilocatário com muitos bancos de dados, todos sendo bancos de dados de locatário único. Um novo banco de dados é provisionado para cada novo locatário. A camada de aplicativo é dimensionada verticalmente adicionando mais recursos por nó. Ou o aplicativo é dimensionado horizontalmente adicionando mais nós. O dimensionamento é baseado na carga de trabalho e é independente do número ou da escala dos bancos de dados individuais.

Personalizar para um inquilino

Como o padrão de aplicativo autônomo, o uso de bancos de dados de locatário único proporciona um forte isolamento de locatário. Em qualquer aplicativo cujo modelo especifique apenas bancos de dados de locatário único, o esquema para qualquer banco de dados determinado pode ser personalizado e otimizado para seu locatário. Essa personalização não afeta outros locatários no aplicativo. Talvez um locatário precise de dados além dos campos de dados básicos de que todos os locatários precisam. Além disso, o campo de dados extra pode precisar de um índice.

Com o banco de dados por locatário, personalizar o esquema para um ou mais locatários individuais é fácil de alcançar. O fornecedor do aplicativo deve projetar procedimentos para gerenciar cuidadosamente as personalizações de esquema em escala.

Conjuntos elásticos

Quando os bancos de dados são implantados no mesmo grupo de recursos, eles podem ser agrupados em pools elásticos. Os pools fornecem uma maneira econômica de compartilhar recursos entre muitos bancos de dados. Essa opção de pool é mais barata do que exigir que cada banco de dados seja grande o suficiente para acomodar os picos de uso que ele experimenta. Embora os bancos de dados em pool compartilhem acesso a recursos, eles ainda podem alcançar um alto grau de isolamento de desempenho.

O Banco de Dados SQL do Azure fornece as ferramentas necessárias para configurar, monitorar e gerenciar o compartilhamento. As métricas de desempenho no nível do pool e no nível do banco de dados estão disponíveis no portal do Azure e por meio dos logs do Azure Monitor. As métricas podem fornecer ótimas informações sobre o desempenho agregado e específico do locatário. Os bancos de dados individuais podem ser movidos entre pools para fornecer recursos reservados a um locatário específico. Estas ferramentas permitem-lhe garantir um bom desempenho de uma forma rentável.

Escala de operações para banco de dados por locatário

O Banco de Dados SQL do Azure tem muitos recursos de gerenciamento projetados para gerenciar um grande número de bancos de dados em escala, como mais de 100.000 bancos de dados. Esses recursos tornam o padrão de banco de dados por locatário plausível.

Por exemplo, suponha que um sistema tenha um banco de dados de 1000 locatários como seu único banco de dados. O banco de dados pode ter 20 índices. Se o sistema converter para ter 1000 bancos de dados de locatário único, a quantidade de índices sobe para 20.000. No Banco de Dados SQL do Azure como parte do ajuste automático, os recursos de indexação automática são habilitados por padrão. A indexação automática gerencia para você todos os 20.000 índices e suas otimizações contínuas de criação e queda. Essas ações automatizadas ocorrem dentro de um banco de dados individual e não são coordenadas ou restritas por ações semelhantes em outros bancos de dados. A indexação automática trata os índices de forma diferente em um banco de dados ocupado do que em um banco de dados menos ocupado. Esse tipo de personalização de gerenciamento de índice seria impraticável na escala de banco de dados por locatário se essa enorme tarefa de gerenciamento tivesse que ser feita manualmente.

Outros recursos de gerenciamento que se dimensionam bem incluem o seguinte:

• Backups integrados.
• Elevada disponibilidade.
• Encriptação no disco.
• Telemetria de desempenho.

Automatização

As operações de gerenciamento podem ser roteirizadas e oferecidas por meio de um modelo devops . As operações podem até ser automatizadas e expostas no aplicativo.

Por exemplo, você pode automatizar a recuperação de um único locatário para um ponto anterior no tempo. A recuperação só precisa restaurar o banco de dados de um único locatário que armazena o locatário. Essa restauração não tem impacto sobre outros locatários, o que confirma que as operações de gerenciamento estão no nível granular de cada locatário individual.

E. Aplicativo multilocatário com bancos de dados multilocatários

Outro padrão disponível é armazenar muitos locatários em um banco de dados multilocatário. A instância do aplicativo pode ter qualquer número de bancos de dados multilocatário. O esquema de um banco de dados multilocatário deve ter uma ou mais colunas de identificador de locatário para que os dados de qualquer locatário possam ser recuperados seletivamente. Além disso, o esquema pode exigir algumas tabelas ou colunas que são usadas apenas por um subconjunto de locatários. No entanto, o código estático e os dados de referência são armazenados apenas uma vez e são compartilhados por todos os locatários.

O isolamento do inquilino é sacrificado

Dados: um banco de dados multilocatário necessariamente sacrifica o isolamento do locatário. Os dados de vários locatários são armazenados juntos em um banco de dados. Durante o desenvolvimento, certifique-se de que as consultas nunca exponham dados de mais de um locatário. O Banco de dados SQL oferece suporte à segurança em nível de linha, que pode impor que os dados retornados de uma consulta tenham escopo para um único locatário.

Processamento: um banco de dados multilocatário compartilha recursos de computação e armazenamento entre todos os seus locatários. A base de dados no seu conjunto pode ser monitorizada para garantir um desempenho aceitável. No entanto, o sistema Azure não tem nenhuma maneira interna de monitorar ou gerenciar o uso desses recursos por um locatário individual. Portanto, o banco de dados multilocatário tem um risco maior de encontrar vizinhos barulhentos, onde a carga de trabalho de um locatário hiperativo afeta a experiência de desempenho de outros locatários no mesmo banco de dados. O monitoramento adicional no nível do aplicativo pode monitorar o desempenho no nível do locatário.

Custo mais reduzido

Em geral, os bancos de dados multilocatários têm o menor custo por locatário. Os custos de recursos para um único banco de dados são menores do que para um pool elástico de tamanho equivalente. Além disso, para cenários em que os locatários precisam apenas de armazenamento limitado, potencialmente milhões de locatários podem ser armazenados em um único banco de dados. Nenhum pool elástico pode conter milhões de bancos de dados. No entanto, uma solução contendo 1000 bancos de dados por pool, com 1000 pools, poderia atingir a escala de milhões, correndo o risco de se tornar difícil de gerenciar.

Duas variações de um modelo de banco de dados multilocatário são discutidas a seguir, com o modelo multilocatário fragmentado sendo o mais flexível e escalável.

F. Aplicativo multilocatário com um único banco de dados multilocatário

O padrão de banco de dados multilocatário mais simples usa um único banco de dados para hospedar dados para todos os locatários. À medida que mais locatários são adicionados, o banco de dados é ampliado com mais recursos de armazenamento e computação. Este aumento de escala pode ser tudo o que é necessário, embora haja sempre um limite de escala final. No entanto, muito antes de esse limite ser atingido, o banco de dados torna-se difícil de gerenciar.

As operações de gerenciamento focadas em locatários individuais são mais complexas de implementar em um banco de dados multilocatário. E, em escala, estas operações podem tornar-se inaceitavelmente lentas. Um exemplo é uma restauração point-in-time dos dados para apenas um locatário.

G. Aplicativo multilocatário com bancos de dados multilocatários fragmentados

A maioria dos aplicativos SaaS acessa os dados de apenas um locatário de cada vez. Esse padrão de acesso permite que os dados do locatário sejam distribuídos em vários bancos de dados ou fragmentos, onde todos os dados de qualquer locatário estão contidos em um fragmento. Combinado com um padrão de banco de dados multilocatário, um modelo fragmentado permite uma escala quase ilimitada.

Gerenciar fragmentos

O compartilhamento adiciona complexidade ao projeto e ao gerenciamento operacional. É necessário um catálogo para manter o mapeamento entre locatários e bancos de dados. Além disso, são necessários procedimentos de gestão para gerir os fragmentos e a população de inquilinos. Por exemplo, os procedimentos devem ser projetados para adicionar e remover fragmentos e para mover dados do locatário entre fragmentos. Uma maneira de dimensionar é adicionando um novo fragmento e preenchendo-o com novos inquilinos. Outras vezes, você pode dividir um fragmento densamente povoado em dois fragmentos menos densamente povoados. Depois que vários locatários forem movidos ou descontinuados, você poderá mesclar fragmentos escassamente povoados. A fusão resultaria numa utilização de recursos mais eficiente em termos de custos. Os locatários também podem ser movidos entre fragmentos para equilibrar as cargas de trabalho.

O Banco de dados SQL fornece uma ferramenta de divisão/mesclagem que funciona em conjunto com a biblioteca de fragmentação e o banco de dados de catálogo. O aplicativo fornecido pode dividir e mesclar fragmentos e pode mover dados de locatário entre fragmentos. O aplicativo também mantém o catálogo durante essas operações, marcando os locatários afetados como offline antes de movê-los. Após a mudança, o aplicativo atualiza o catálogo novamente com o novo mapeamento e marcando o locatário como online novamente.

Bancos de dados menores gerenciados mais facilmente

Ao distribuir locatários em vários bancos de dados, a solução multilocatária fragmentada resulta em bancos de dados menores que são gerenciados mais facilmente. Por exemplo, restaurar um locatário específico para um point-in-time anterior agora envolve a restauração de um único banco de dados menor a partir de um backup, em vez de um banco de dados maior que contém todos os locatários. O tamanho do banco de dados e o número de locatários por banco de dados podem ser escolhidos para equilibrar a carga de trabalho e os esforços de gerenciamento.

Identificador de locatário no esquema

Dependendo da abordagem de fragmentação usada, restrições adicionais podem ser impostas ao esquema do banco de dados. O aplicativo de divisão/mesclagem do Banco de dados SQL requer que o esquema inclua a chave de fragmentação, que normalmente é o identificador do locatário. O identificador de locatário é o elemento principal na chave primária de todas as tabelas fragmentadas. O identificador de locatário permite que o aplicativo de divisão/mesclagem localize e mova rapidamente os dados associados a um locatário específico.

Piscina elástica para estilhaços

Os bancos de dados multilocatários fragmentados podem ser colocados em pools elásticos. Em geral, ter muitos bancos de dados de locatário único em um pool é tão econômico quanto ter muitos locatários em alguns bancos de dados multilocatário. Os bancos de dados multilocatários são vantajosos quando há um grande número de locatários relativamente inativos.

H. Modelo de banco de dados multilocatário fragmentado híbrido

No modelo híbrido, todos os bancos de dados têm o identificador de locatário em seu esquema. Todos os bancos de dados são capazes de armazenar mais de um locatário e os bancos de dados podem ser fragmentados. Portanto, no sentido de esquema, todos eles são bancos de dados multilocatário. No entanto, na prática, algumas dessas bases de dados contêm apenas um inquilino. Independentemente disso, a quantidade de locatários armazenados em um determinado banco de dados não tem efeito sobre o esquema do banco de dados.

Mova os inquilinos

A qualquer momento, você pode mover um determinado locatário para seu próprio banco de dados multilocatário. E, a qualquer momento, você pode mudar de ideia e mover o locatário de volta para um banco de dados que contenha vários locatários. Você também pode atribuir um locatário ao novo banco de dados de locatário único ao provisionar o novo banco de dados.

O modelo híbrido brilha quando há grandes diferenças entre as necessidades de recursos de grupos identificáveis de inquilinos. Por exemplo, suponha que os locatários que participam de uma avaliação gratuita não têm garantido o mesmo alto nível de desempenho que os locatários assinantes. A política pode ser que os locatários na fase de avaliação gratuita sejam armazenados em um banco de dados multilocatário compartilhado entre todos os locatários de avaliação gratuita. Quando um locatário de avaliação gratuita se inscreve na camada de serviço básica, o locatário pode ser movido para outro banco de dados multilocatário que pode ter menos locatários. Um assinante que pague pela camada de serviço Premium pode ser movido para seu próprio novo banco de dados de locatário único.

Conjuntos

Nesse modelo híbrido, os bancos de dados de locatário único para locatários assinantes podem ser colocados em pools de recursos para reduzir os custos de banco de dados por locatário. Isso também é feito no modelo de banco de dados por locatário.

I. Comparação dos modelos de arrendamento

A tabela seguinte resume as diferenças entre os principais modelos de arrendamento.

Medida	Aplicação autónoma	Banco de dados por locatário	Multilocatário fragmentado
Escala	Meio 1-100 anos	Muito alta 1-100.000 anos	Ilimitado 1-1.000.000 anos
Isolamento do inquilino	Muito alta	Máximo	Baixa; exceto para qualquer inquilino único (que está sozinho em um banco de dados MT).
Custo do banco de dados por locatário	Alta; é dimensionado para picos.	Baixa; piscinas utilizadas.	Mais baixo, para pequenos inquilinos em MT DBs.
Monitorização e gestão do desempenho	Apenas por inquilino	Agregado + por inquilino	Agregado; embora seja por inquilino apenas para solteiros.
Complexidade do desenvolvimento	Mínimo	Mínimo	Média; devido à fragmentação.
Complexidade operacional	Baixa-Alta. Individualmente simples, complexo em escala.	Baixo-Médio. Os padrões abordam a complexidade em escala.	Baixa-Alta. A gestão individual de inquilinos é complexa.

Próximos passos

• Implantar e explorar um aplicativo Wingtip multilocatário que usa o modelo SaaS de banco de dados por locatário - Banco de Dados SQL do Azure

• Bem-vindo ao exemplo de Wingtip Tickets SaaS Aplicativo de locação do Banco de dados SQL do Azure