Ir para o conteúdo principal

ARQUITETURA MULTI-TENANCY

Data: 29/11/22

Autores:
1.João Batista da Silva Junior (Assessor)
2.Michel Farias Ferreira (Assessor)

__________________________________________________________________________________________________________________________________________

 

1. OBJETIVO

Esse documento tem o intuito de explicar a arquitetura multi-tenancy, e qual sua necessidade no ambiente da SETIC.


2. INTRODUÇÃO

Fez-se necessário realizar o estudo por entender que seria de grande valia para embasar a necessidade de abrigar uma arquitetura multi-tenancy na SETIC pois os sistemas e ferramentas que hoje são utilizados pela SETIC serão disponibilizados para outras Secretarias.

 

3. DESENVOLVIMENTO

De uma forma bem simples, multi-tenancy é um estilo de arquitetura onde você tem uma aplicação centralizada que atende a vários clientes. Neste caso, partindo do Inglês tenant, “clientes” significam locatários.


Ou seja, multi-tenancy (ou multi-tenant) é um termo utilizado em plataformas SAAS, plataformas que oferecem Software Como Serviço, onde, na maioria das vezes, os tenants são clientes corporativos. Ou seja, uma empresa utiliza serviços de outra empresa, numa relação B2B (business to business).


Mas isso não é regra, podem haver muito bem outros cenários com outros tipos de relações, incluindo clientes não corporativos.

O grande desafio na SETIC é tornar os sistemas on-premise multi-tenancy e também disponibilizar o ambiente de desenvolvimento utilizando a esteira de automação desenvolvida pela SETIC para outras secretarias.

Outro desafio é disponibilizar os orquestradores de containers e storages.

A solução provável será configurar filtros nas configurações do LDAP das aplicações para que os usuários de outras secretarias consigam acessar as ferramentas e sistemas através do login de AD.


Na prática, um exemplo de um contexto onde pode haver uma aplicação multi-tenant, seria uma secretária gerenciar seus documentos no bookstack da SETIC, que por sua vez, deve utilizar alguma estratégia de controle que diferencie em sua aplicação e em seu banco de dados uma secretária de outra outra, de forma que os contextos e, claro, os dados não se misturem.

 

3.1 Modelo single-tenant

 

É aí que entram as técnicas e conceitos que definem aplicações multi-tenant. Comparando multi-tenant ao estilo de arquitetura tradicional, a Loja de Departamento citada acima no estilo single-tenant teria um servidor próprio local, isolados dos demais clientes, contendo a aplicação da empresa gerenciadora de documentos e o banco de dados. No modelo multi-tenant os servidores são remotos e fazem parte da infra-estrutura da empresa que fornece o serviço SAAS. Tanto a aplicação quanto o banco de dados são, no conceito primário, compartilhados entre as várias secretarias (ou tenants). Tudo bem, na prática existem vários estilos de arquitetura multi-tenant onde há diferenças nas estratégias de compartilhamento de base de dados e recursos.

A priori pode parecer estranho, menos performático e menos seguro manter dados de secretarias (clientes) distintas na “mesma base de dados” … Mas para aplicações SAAS este é o cenário mais adequado por uma série de razões. Vamos à algumas vantagens e desvantagens do modelo single-tenant e multi-tenant.

Ter um servidor isolado no modelo single-tenant requer muito mais custo e exige muito mais trabalho de atualização de aplicação ou de manutenção. Geralmente este custo é repassado para o cliente. Imagine a trabalheira que dá para essa secretaria gestora de documentos garantir a atualização de todos os servidores de seus clientes.

 

3.2 Modelo multi-tenant

Voltando, no modelo multi-tenant atualizar uma aplicação ou fazer uma manutenção é muito mais rápido e prático. Por outro lado, pode haver necessidade de customização de código e exige mais cuidado e complexidade para segregar os dados.

Dependendo da necessidade, na sua aplicação multi-tenant você poderá ter múltiplos servidores de aplicação, sendo gerenciados por um balanceador de cargas e acessando um servidor de dados. Esse servidor de dados pode ser na verdade um cluster.

A nível de aplicação a identificação dos tenants pode ser feita por meio de login, domínio, subdomínio e até mesmo por rotas. A aplicação irá fazer uma checagem para identificar o tenant e após identificação irá direcioná-lo ao seu contexto de aplicação e à sua partição de dados.

 

3.3 Segregação de dados

Para garantir a segregação dos dados existem algumas técnicas e modelos de arquiteturas voltados para aplicações multi-tenant. No modelo single-database, onde se utiliza um único banco de dados ou até mesmo uma única tabela, essa separação pode ser feita por meio de um tenant_ID. Também podem ser utilizados esquemas distintos para cada cliente (ou tenant).

Uma vantagem de utilizar o mesmo banco de dados é que isso facilita a geração de relatórios. Por outro lado, você pode ter clientes que possuem um pequeno volume de dados e clientes que possuem um grande volume de dados, o que pode causar sobrecarga.

Para finalizar, outra opção de separação de dados é o modelo multi-database, neste modelo cada cliente possui o seu próprio banco de dados ou base de dados. Este cenário permite mais segurança na separação dos dados e possibilita realizar com mais facilidade testes específicos para cada cliente. Exportar os dados de um determinado tenent também se torna uma tarefa bem mais simples.

Se a gente ir adiante mais um pouquinho, iremos topar num termo chamado persistência poliglota, que é o conceito da utilização de diferentes bases de dados para atender diferentes necessidades de armazenamento, de acordo com cada lógica de aplicação.

 

4. CONCLUSÃO

De acordo com a necessidade que outras secretarias têm na utilização de ferramentas já disponibilizadas no ambiente da SETIC em uma infraestrutura estável e consolidada. Torna o trabalho de disponibilização do acesso para outras secretarias em multi-tenancy menos dispendioso que preparar uma nova infraestrutura disponibilizando as mesmas ferramentas nesse outro ambiente.