ASP.NET Core - Aplicações Multi-Tenant

ASP.NET Core - Aplicações Multi-Tenant - I

Hoje vou apresentar os principais conceitos e a seguir mostrar como criar uma aplicação Multi-Tenant usando a ASP .NET Core 5.

Para poder tratar de todas as possibilidades e recursos envolvidos em aplicações Multi-Tenant seria preciso escrever um livro dedicado ao assunto.

Por isso meu objetivo nesta série de dois ou três artigos é apresentar de forma resumida, objetiva e prática os principais conceitos envolvidos com essas aplicações.(Baseado no artigo original : Building Multi-Tenant Applications Using ASP.NET 5 de Joydip Kanjilal )

(Eu vou usar o termo aplicação multi-tenant ao invés de traduzir para aplicação multilocatária e para o termo tenant eu vou traduzir de forma intercambiável como cliente/usuário/locatário/inquilino a tradução direta seria inquilino, locatário, arrendatário.

Vamos iniciar definindo o termo 'software multi-tenancy' que se refere a uma arquitetura na qual uma única instância do software é executada em um servidor e atende a vários locatários(tenants). Essa arquitetura é usada pelas aplicações Multi-Tenant.

O que são aplicações Multi-Tenant e o que é um Tenant ?

Uma aplicação Multi-Tenant segue uma arquitetura de software na qual um único aplicativo é compartilhado entre vários clientes ou locatários. Cada cliente vê apenas seus próprios dados e não tem conhecimento da existência de outros clientes, sendo que essa arquitetura pode servir a muitos clientes diferentes usando uma única fonte de código.

Neste contexto precisamos definir melhor o que é um Tenant que seria um cliente ou locatário.

Um locatário é composto por um grupo de usuários que compartilham os mesmos dados, informações de configuração e informações de gerenciamento de usuários. Cada locatário tem uma identidade específica e o aplicativo deve ser adequado o suficiente para responder a cada locatário de maneira diferente.

Nesta arquitetura cada locatário é integrado fisicamente, mas logicamente separado um do outro. (Cada inquilino pode estar fisicamente isolado dos outros).

Assim um locatário compartilha o acesso ao hardware e tem a capacidade de personalizar certas partes do aplicativo - pode ser a aparência da interface do usuário ou até mesmo personalizar regras de negócios.

O que é uma arquitetura Single-Tenant ?

Uma arquitetura de Single-Tenant ou de locatário único é construída a partir de uma base de código comum e é aquela em que uma única instância do aplicativo pode servir a um único cliente ou locatário. Ao contrário de um aplicativo multilocatário, nesta abordagem cada locatário mantém sua própria cópia do banco de dados, bem como uma instância do aplicativo.

Um aplicativo de locatário único é considerado confiável e você pode restaurar rapidamente os dados em caso de perda devido a um desastre. Se houver uma violação de dados com um locatário, os outros locatários não serão afetados porque usam instâncias separadas do aplicativo. Um inquilino também pode escolher quando instalar as atualizações.

A personalização, configuração, manutenção e atualização de um aplicativo de um único locatário pode custar caro em termos de tempo e dinheiro. Embora esses os aplicativos possam ter acesso a recursos em abundância e possam ser personalizados facilmente, a manutenção e o gerenciamento regulares desses aplicativos são uma tarefa árdua. Assim nessa arquitetura embora os aplicativos forneçam mais recursos, com um único cliente apenas para o seu aplicativo, isso tem um custo elevado.

O que é uma arquitetura Multi-Tenant ?

A arquitetura Multi-Tenant ou multilocação é um estilo de arquitetura de software em que uma instância de aplicativo é compartilhada entre vários locatários do aplicativo, com cada locatário tendo sua própria parte da instância, que é isolada para fins de desempenho, segurança de dados, etc.

A multilocação é uma arquitetura ideal para aproveitar o ambiente de nuvem da melhor maneira possível. Em essência, ela fornece uma plataforma compartilhada que você pode usar para aproveitar ao máximo a infraestrutura em nuvem - ela evolui continuamente para acompanhar as demandas de todos os locatários que usam o aplicativo.

Um aplicativo multilocatário pode melhorar o ROI e reduzir os custos de desenvolvimento e implantação consideravelmente, compartilhando os mesmos recursos com vários locatários, ao mesmo tempo em que é modular e escalonável. Não é a toa que Google, Facebook, Amazon, etc. são completamente multilocatários.

Assim podemos enumerar alguns dos benefícios da arquitetura Multi-Tenant:

Fácil integração: É a escolha perfeita para aplicativos que precisam de experiências de inicialização ou integração mais fáceis e menos requisitos de hardware.
Manutenção: A facilidade de manutenção aprimorada é um benefício do aplicativo multilocatário.
Custo reduzido: Ao contrário da arquitetura single-tenant, esta arquitetura é relativamente barata devido à infraestrutura compartilhada e ajuda a construir aplicativos com custos de manutenção mais baixos e melhores capacidades de computação;
Uso de recursos: Garante melhor uso dos recursos disponíveis em comparação com a arquitetura de locatário único;
Atualização mais fácil: As atualizações são contínuas e relativamente simples;

A seguir temos algumas desvantagens que a arquitetura Multi-Tenant pode apresentar:

Isolamento: Você precisa isolar dados, configuração e requisitos não funcionais, como desempenho e registro entre os locatários. Esse isolamento apresenta desafios e apresenta complexidades adicionais no código-fonte do aplicativo, bem como no esquema do banco de dados.
Complexidade: Um aplicativo de vários locatários é mais complexo porque você tem vários locatários com dados isolados e armazenamento de configuração para cada um deles. Quando seu aplicativo multilocatário fica inativo devido à indisponibilidade do banco de dados, todos os locatários que usam o aplicativo são afetados.
Segurança: Embora outros locatários não possam ter acesso aos seus dados, os dados da sua organização são armazenados em um único banco de dados onde todos os usuários pertencentes à sua organização têm acesso.

Características da arquitetura Multi-Tenant

Dessa forma arquitetar um sistema Multi-Tenant é mais complicado do que arquitetar um sistema multiusuário. Existem dois modelos de arquitetura de um sistema multilocatário: replicação de instância e segregação de dados.

No modelo de replicação de instância, o sistema gera uma nova instância para cada locatário. É mais fácil de começar, mas difícil de escalar. Torna-se um pesadelo quando centenas de inquilinos se inscrevem.

No modelo de segregação de dados, o aplicativo é compartilhado entre os locatários, mas os dados de cada locatário são armazenados em armazenamentos de dados separados. Armazenamentos de dados separados podem ser bancos de dados separados ou esquema separado dentro do mesmo banco de dados.

a- Isolamento de dados de locatário

o isolamento de dados por locatário é um dos recursos mais importantes dos aplicativos multilocatários. O que isso significa é que cada locatário tem acesso a seus dados e apenas a seus dados.

Em outras palavras, os dados em um aplicativo multilocatário são logicamente e fisicamente isolados por locatário, com um locatário não tendo acesso aos dados pertencentes a outro locatário. Pode ser necessário configurar seu aplicativo de maneira diferente para cada locatário. Esses dados de configuração podem incluir normalmente chaves de autenticação, strings de conexão de banco de dados, etc.

b- Estratégia de resolução de inquilino

Uma estratégia de resolução de inquilino implica em qual contexto de inquilino uma solicitação específica deve ser executada. As estratégias de resolução de inquilino devem considerar o banco de dados a ser acessado pelo inquilino, a configuração a ser usada, etc. Em um aplicativo multilocatário, você deve ter sua estratégia de resolução de inquilino em vigor.

Banco de dados Multi-Tenant

Um banco de dados multilocatário é um banco de dados compartilhado com esquema compartilhado no qual os dados pertencentes a vários locatários são armazenados. Para isolar dados pertencentes a diferentes inquilinos, geralmente é usada uma coluna de identificador de inquilino.

Você pode obter multilocação usando o isolamento lógico ou o isolamento físico.

Os inquilinos devem estar logicamente isolados, mas o grau de isolamento físico pode variar. Ao ao implementar a segregação lógica de inquilinos você deve estar ciente de dois problemas:

O primeiro diz respeito à necessidade de segregar os dados de um determinado inquilino;
O segundo implica o acesso aos dados para os usuários que fazem parte de vários inquilinos;

Dependendo do acesso aos dados, existem três tipos de abordagens que você pode seguir para projetar seus bancos de dados multilocatário:

Vários bancos de dados: com um único banco de dados por locatário;
Um único banco de dados com esquemas separados por locatário;
Um único banco de dados com esquema compartilhado;

Vejamos cada um deles.

1- Vários bancos de dados com um único banco de dados por locatário;

Essa abordagem fornece o nível máximo de segurança de dados. Os bancos de dados são separados fisicamente e um locatário não pode acessar os dados pertencentes a outro locatário, portanto, você também tem um melhor isolamento de dados.

Essa abordagem é flexível e você pode restaurar facilmente os dados de um locatário, se necessário, mas terá que pagar por servidores adicionais. Em outras palavras, você tem um melhor isolamento de dados, mas isso acarreta um custo de complexidade adicional - complexidade de gerenciamento, manutenção e escalabilidade, porque você precisa implantar vários bancos de dados.

2 - Um único banco de dados com esquemas separados por locatário

Neste modelo, um único banco de dados é usado, mas existem vários esquemas: um por locatário.

Cada locatário tem seu próprio esquema dentro do banco de dados, que normalmente é composto por um conjunto de tabelas. Você pode optar por esse design se desejar reduzir os custos operacionais da camada de banco de dados, bem como a complexidade da infraestrutura do servidor.

No entanto, a desvantagem dessa abordagem é que você precisará de esforço adicional para backup e restauração de dados, especialmente se os dados pertencentes a um locatário foram corrompidos.

3- Um único banco de dados com esquema compartilhado

Este é um design simples e fácil de implementar; você tem um esquema compartilhado que é usado por todos os locatários. Em essência, o esquema para todos os locatários é idêntico, ou seja, todos os locatários usam as mesmas tabelas de banco de dados.

Você não precisa criar um esquema por locatário ou executar servidores adicionais para os bancos de dados e normalmente deseja usar uma ID de locatário para recuperar dados pertencentes a um determinado locatário.

No entanto, a desvantagem é que, com o tempo, à medida que mais e mais locatários usam o aplicativo, fica cada vez mais difícil consultar ou atualizar os dados.

Multi-Tenant : Identificação do Tenant

Os aplicativos desenvolvidos com a arquitetura multilocatário são adeptos a responder de maneira diferente aos vários clientes ou locatários. Um aplicativo multilocatário pode identificar de qual locatário uma determinada solicitação se originou. Em outras palavras, a identificação do inquilino determina qual inquilino está envolvido com base nas informações disponíveis, como um nome de host, IP de origem ou um cabeçalho HTTP personalizado.

Cada inquilino possui uma identidade única específica e o aplicativo se comporta de maneira diferente de um inquilino para outro. Essas mudanças podem incluir mudanças na interface do usuário, mudanças nos dados, incluindo parâmetros de configuração e mudanças no comportamento.

A identidade de um inquilino é diferente de outro inquilino e dois inquilinos podem diferir nos seguintes fatores:

Dados: Cada inquilino tem acesso apenas aos seus próprios dados. Cada locatário tem seus próprios dados de configuração, ou seja, strings de conexão, fluxos de trabalho, nome de domínio, etc.
Comportamento: Um locatário pode se comportar de maneira diferente de outro locatário com base nos recursos aos quais ele tem acesso;
Interface do usuário: A aparência pode incluir folhas de estilo, imagens, etc.;

Temos assim uma visão geral bem simplificada e resumida das aplicações Multi-Tenants, lembrando que devido a complexidade do ambiente teremos que enfrentar diversos desafios relacionados a segurança, desempenho, acoplamento e complexidade. E em cada um deles temos diversas abordagens e possibilidades a considerar o que foge ao escopo deste artigo.

Assim na próxima parte do artigo vou apresentar a criação de uma aplicação multi-tenant bem simples para ilustrar alguns dos conceitos aqui apresentados.

"Como também nos elegeu nele antes da fundação do mundo, para que fôssemos santos e irrepreensíveis diante dele em amor;"
Efésios 1:4

Referências:

José Carlos Macoratti