Existem várias formas de considerar como trabalhar com inquilinos na sua solução. A sua escolha de abordagem depende importante de se e de como partilha recursos entre os seus inquilinos. Intuitivamente, poderá querer evitar partilhar recursos , mas essa abordagem torna-se rapidamente dispendiosa à medida que a sua empresa é dimensionada e integra mais inquilinos.
Quando considera os vários modelos de multi-inquilinos, é útil primeiro ter em conta a forma como define os inquilinos para a sua organização, quais são os seus fatores empresariais e como planeia dimensionar a sua solução. Este artigo fornece orientações para ajudar os decisores técnicos a avaliar os modelos de inquilinos e as suas desvantagens.
Definir um inquilino
Primeiro, tem de definir um inquilino para a sua organização. Considere quem é o seu cliente. Por outras palavras, a quem está a fornecer os seus serviços? Existem dois modelos comuns:
- Empresa-empresa (B2B). Se os seus clientes forem outras organizações, é provável que mapeie os inquilinos a esses clientes. No entanto, considere se os seus clientes têm divisões (equipas ou departamentos) e se têm uma presença em vários países/regiões. Poderá ter de mapear um único cliente para vários inquilinos se existirem requisitos diferentes para estes subgrupos. Da mesma forma, um cliente poderá querer manter duas instâncias do seu serviço para que possa manter os ambientes de desenvolvimento e produção separados uns dos outros. Geralmente, um único inquilino tem vários utilizadores. Por exemplo, todos os colaboradores do cliente serão utilizadores num único inquilino.
- Empresa-consumidor (B2C). Se os seus clientes forem consumidores, muitas vezes é mais complicado relacionar clientes, inquilinos e utilizadores. Em alguns cenários, cada consumidor pode ser um inquilino separado. No entanto, considere se a sua solução pode ser utilizada por famílias, grupos de amigos, clubes, associações ou outros grupos que possam ter de aceder e gerir os respetivos dados em conjunto. Por exemplo, um serviço de transmissão em fluxo de música pode suportar utilizadores e famílias individuais e pode tratar cada um destes tipos de conta de forma diferente quando os separa em inquilinos.
A sua definição de inquilino afetará alguns dos aspetos que tem de considerar ou realçar quando arquiteta a sua solução. Por exemplo, considere estes tipos de inquilinos:
- Se os seus inquilinos forem pessoas ou famílias individuais, poderá ter de estar particularmente preocupado com a forma como processa os dados pessoais e com as leis de soberania de dados em cada jurisdição que servir.
- Se os seus inquilinos forem empresas, poderá ter de estar atento aos requisitos dos seus clientes em relação à conformidade regulamentar, ao isolamento dos respetivos dados e garantir que cumpre um objetivo de nível de serviço (SLO) especificado, como o tempo de atividade ou a disponibilidade do serviço.
Como pode decidir que modelo utilizar?
Selecionar um modelo de inquilinos não é apenas uma decisão técnica. É também uma decisão comercial. Tem de considerar perguntas como estas:
- Quais são os seus objetivos comerciais?
- Os seus clientes aceitarão todas as formas de multi-inquilino? Como é que cada modelo multi-inquilino afeta os seus requisitos de conformidade ou os requisitos de conformidade do cliente?
- Será que uma solução de inquilino único será dimensionada para as suas futuras aspirações de crescimento?
- Qual é a dimensão da sua equipa de operações e a quantidade de gestão de infraestrutura que pode automatizar?
- Os seus clientes esperam que cumpra contratos de nível de serviço (SLAs) ou que tenha SLOs que pretende?
Se espera que a sua empresa seja dimensionada para um grande número de clientes, é importante implementar uma infraestrutura partilhada. Caso contrário, terá de manter uma grande e crescente frota de instâncias. É provável que a implementação de recursos individuais do Azure para cada cliente seja insustentável, a menos que aprovisione e utilize uma subscrição dedicada para cada inquilino. Quando partilha a mesma subscrição do Azure em vários inquilinos, podem começar a aplicar-se quotas e limites de recursos do Azure e os custos operacionais para implementar e reconfigurar estes recursos aumentam com cada novo cliente.
Por outro lado, se espera que a sua empresa tenha apenas alguns clientes, poderá considerar a utilização de recursos de inquilino único dedicados a cada cliente. Além disso, se os requisitos de isolamento dos seus clientes forem elevados, poderá ser adequada uma infraestrutura de inquilino único.
Inquilinos e implementações
Em seguida, tem de determinar o que o inquilino significa para a sua solução específica e se deve distinguir entre inquilinos lógicos e implementações.
Por exemplo, considere um serviço de transmissão em fluxo de música. Inicialmente, pode criar uma solução que consiga processar facilmente milhares (ou mesmo dezenas de milhares) de utilizadores. No entanto, à medida que continua a crescer, poderá ter de duplicar a sua solução ou alguns dos respetivos componentes para dimensionar para a procura de novos clientes. Isto significa que tem de determinar como atribuir clientes específicos a instâncias específicas da sua solução. Pode atribuir clientes aleatoriamente, geograficamente ou preenchendo uma única instância e, em seguida, iniciando outra. No entanto, provavelmente tem de manter um registo dos seus clientes e em que infraestrutura estão disponíveis os respetivos dados e aplicações para que possa encaminhar o tráfego para a infraestrutura correta. Neste exemplo, pode representar cada cliente como um inquilino separado e, em seguida, mapear os utilizadores para a implementação que contém os respetivos dados. Tem um mapeamento um-para-muitos entre inquilinos e implementações e pode mover inquilinos entre implementações a seu critério.
Por outro lado, considere uma empresa que cria software de cloud para empresas de advogados. Os seus clientes podem insistir em ter a sua própria infraestrutura dedicada para manter os seus padrões de conformidade. Por conseguinte, tem de estar preparado para implementar e gerir várias instâncias diferentes da sua solução desde o início. Neste exemplo, uma implementação contém sempre um único inquilino e um inquilino é mapeado para a sua própria implementação dedicada.
Uma diferença fundamental entre inquilinos e implementações é a forma como o isolamento é imposto. Quando vários inquilinos partilham uma única implementação (um conjunto de infraestruturas), normalmente depende do código da aplicação e de um identificador de inquilino que se encontra numa base de dados para manter os dados de cada inquilino separados. Quando tem inquilinos com as suas próprias implementações dedicadas, estes têm a sua própria infraestrutura, pelo que pode ser menos importante que o seu código tenha em atenção que está a funcionar num ambiente multi-inquilino.
Por vezes, as implementações são referidas como super-inquilinos ou selos.
Quando recebe um pedido para um inquilino específico, tem de mapeá-lo para a implementação que contém os dados desse inquilino, conforme mostrado aqui:
Isolamento de inquilinos
Uma das maiores considerações na conceção de uma arquitetura multi-inquilino é o nível de isolamento de que cada inquilino precisa. O isolamento pode significar coisas diferentes:
- Ter uma única infraestrutura partilhada, com instâncias separadas da sua aplicação e bases de dados separadas para cada inquilino.
- Partilhar alguns recursos comuns, mas manter outros recursos separados para cada inquilino.
- Manter dados numa infraestrutura física separada. Na cloud, esta configuração pode exigir recursos do Azure separados para cada inquilino. Pode até significar a implementação de uma infraestrutura física separada com anfitriões dedicados.
Em vez de pensar no isolamento como uma propriedade discreta, deve pensar nela como estando num continuum. Pode implementar componentes da sua arquitetura que estejam mais ou menos isolados do que outros componentes na mesma arquitetura, consoante os seus requisitos. O diagrama seguinte demonstra um continuum de isolamento:
O nível de isolamento afeta muitos aspetos da sua arquitetura, incluindo o seguinte:
- Segurança. Se partilhar a infraestrutura entre vários inquilinos, tem de ter especial cuidado para não aceder aos dados de um inquilino quando devolve respostas a outro. Precisa de uma base forte para a sua estratégia de identidade e tem de considerar a identidade do inquilino e do utilizador no seu processo de autorização.
- Custo. A infraestrutura partilhada pode ser utilizada por vários inquilinos, pelo que é menos dispendiosa.
- Desempenho. Se partilhar a infraestrutura, o desempenho do seu sistema poderá sofrer à medida que mais clientes a utilizam, uma vez que os recursos podem ser consumidos mais rapidamente.
- Fiabilidade. Se utilizar um único conjunto de infraestruturas partilhadas, um problema com os componentes de um inquilino pode resultar numa indisponibilidade para todas as pessoas.
- Capacidade de resposta às necessidades individuais do inquilino. Quando implementa uma infraestrutura dedicada a um inquilino, poderá conseguir adaptar a configuração dos recursos aos requisitos desse inquilino específico. Pode até considerar esta capacidade no seu modelo de preços, permitindo que os clientes paguem mais pelas implementações isoladas.
A arquitetura da solução pode influenciar as opções disponíveis para isolamento. Por exemplo, considere uma arquitetura de solução de três camadas:
- O escalão de interface de utilizador pode ser uma aplicação Web multi-inquilino partilhada, com todos os inquilinos a acederem a um único nome de anfitrião.
- A camada média pode ser uma camada de aplicação partilhada, com filas de mensagens partilhadas.
- A camada de dados pode ser bases de dados isoladas, tabelas ou contentores de blobs.
Pode considerar a utilização de diferentes níveis de isolamento em cada camada. Deve basear a sua decisão sobre o que é partilhado e o que está isolado em muitas considerações, incluindo custo, complexidade, requisitos dos seus clientes e o número de recursos que pode implementar antes de atingir quotas e limites do Azure.
Modelos de inquilinos comuns
Depois de estabelecer os seus requisitos, avalie-os em relação a alguns modelos de inquilinos comuns e padrões de implementação correspondentes.
Implementações automatizadas de inquilino único
Num modelo de implementação de inquilino único automatizado, implementa um conjunto dedicado de infraestrutura para cada inquilino, conforme mostrado neste exemplo:
A sua aplicação é responsável por iniciar e coordenar a implementação dos recursos de cada inquilino. Normalmente, as soluções que utilizam este modelo utilizam a infraestrutura como código (IaC) ou as APIs de Resource Manager do Azure extensivamente. Poderá utilizar esta abordagem quando precisar de aprovisionar infraestruturas completamente separadas para cada um dos seus clientes. Considere o padrão de Selos de Implementação quando planear a sua implementação.
Benefícios: Uma das principais vantagens desta abordagem é que os dados de cada inquilino estão isolados, o que reduz o risco de fuga acidental. Esta salvaguarda pode ser importante para alguns clientes que têm uma sobrecarga de conformidade regulamentar elevada. Além disso, é pouco provável que os inquilinos afetem o desempenho do sistema uns dos outros, um problema que por vezes é chamado de problema de vizinho ruidoso . Atualizações e as alterações podem ser implementadas progressivamente nos inquilinos, o que reduz a probabilidade de uma falha em todo o sistema.
Riscos: Se utilizar esta abordagem, a eficiência dos custos é baixa porque não partilha a infraestrutura entre os seus inquilinos. Se um único inquilino exigir um determinado custo de infraestrutura, 100 inquilinos provavelmente necessitam de 100 vezes esse custo. Além disso, a manutenção contínua (como a aplicação de novas configurações ou atualizações de software) será provavelmente morosa. Considere automatizar os seus processos operacionais e considere aplicar alterações progressivamente através dos seus ambientes. Também deve considerar outras operações de implementação cruzada, como relatórios e análises em todo o seu património. Da mesma forma, certifique-se de que planeia como pode consultar e manipular dados em várias implementações.
Implementações totalmente multi-inquilino
No extremo oposto, pode considerar uma implementação totalmente multi-inquilino, onde todos os componentes são partilhados. Tem apenas um conjunto de infraestruturas para implementar e manter e todos os inquilinos utilizam-no, conforme mostrado no diagrama seguinte:
Benefícios: Este modelo é apelativo porque a operação de uma solução que tem componentes partilhados é menos dispendiosa. Mesmo que precise de implementar escalões mais elevados ou SKUs de recursos, o custo geral da implementação é, muitas vezes, ainda inferior ao custo de um conjunto de recursos de inquilino único. Além disso, se um utilizador ou inquilino precisar de mover os respetivos dados para outro inquilino, poderá conseguir atualizar identificadores e chaves de inquilino e poderá não ter de migrar dados entre duas implementações separadas.
Riscos:
Certifique-se de que separa os dados de cada inquilino e não divulga dados entre inquilinos. Poderá ter de gerir os dados de fragmentação. Além disso, poderá ter de se preocupar com os efeitos que os inquilinos individuais podem ter no sistema geral. Por exemplo, se um inquilino grande tentar efetuar uma consulta ou operação intensiva, poderá afetar outros inquilinos.
Determine como controlar e associar os custos do Azure aos inquilinos, caso o faça é importante para si.
A manutenção pode ser mais simples com uma única implementação, porque só tem de atualizar um conjunto de recursos. No entanto, muitas vezes também é mais arriscado, porque as alterações podem afetar toda a sua base de clientes.
Também poderá ter de considerar o dimensionamento. É mais provável que atinja os limites de dimensionamento de recursos do Azure quando tiver um conjunto partilhado de infraestrutura. Por exemplo, se utilizar uma conta de armazenamento como parte da sua solução, à medida que o dimensionamento aumenta, o número de pedidos para essa conta de armazenamento poderá atingir o limite do que a conta de armazenamento pode processar. Para evitar atingir um limite de quota de recursos, pode considerar implementar várias instâncias dos seus recursos (por exemplo, vários clusters do AKS ou contas de armazenamento). Pode até considerar distribuir os inquilinos pelos recursos que implementa em várias subscrições do Azure.
É provável que exista um limite para até que ponto pode dimensionar uma única implementação e os custos de o fazer podem aumentar de forma não linear. Por exemplo, se tiver uma única base de dados partilhada, quando é executada em grande escala, poderá esgotar o débito e precisar de pagar cada vez mais pelo aumento do débito para acompanhar a sua procura.
Implementações particionadas verticalmente
Não tem de escolher um dos extremos destas escalas. Em vez disso, pode considerar a criação de partições verticais dos seus inquilinos ao seguir esta abordagem:
- Utilize uma combinação de implementações de inquilino único e multi-inquilino. Por exemplo, pode ter a maioria dos escalões de dados e aplicações dos seus clientes em infraestruturas multi-inquilino, mas implementar infraestruturas de inquilino único para clientes que necessitem de um maior desempenho ou isolamento de dados.
- Implemente várias instâncias da sua solução geograficamente e mapeie cada inquilino para uma implementação específica. Esta abordagem é particularmente eficaz quando tem inquilinos em diferentes geografias.
Eis um exemplo que ilustra uma implementação partilhada para alguns inquilinos e uma implementação de inquilino único para outro:
Benefícios: Uma vez que ainda está a partilhar a infraestrutura, pode obter alguns dos benefícios de custos da utilização de implementações multi-inquilino partilhadas. Pode implementar recursos partilhados mais baratos para determinados clientes, como clientes que estão a avaliar o seu serviço com uma avaliação. Pode até faturar aos clientes uma taxa mais elevada para utilizar uma implementação de inquilino único, recuperando assim alguns dos seus custos.
Riscos: Provavelmente, a base de código terá de ser concebida para suportar implementações multi-inquilino e de inquilino único. Se planear permitir a migração entre infraestruturas, tem de considerar como migrar os clientes de uma implementação multi-inquilino para a sua própria implementação de inquilino único. Também precisa de saber quais dos seus inquilinos estão em cada implementação, para que possa comunicar informações sobre problemas de sistema ou atualizações aos clientes relevantes.
Implementações particionadas horizontalmente
Também pode considerar a criação de partições horizontais das suas implementações. Numa implementação horizontal, tem alguns componentes partilhados, mas mantém outros componentes com implementações de inquilino único. Por exemplo, pode criar uma única camada de aplicação e, em seguida, implementar bases de dados individuais para cada inquilino, conforme mostrado neste diagrama:
Benefícios: As implementações particionadas horizontalmente podem ajudá-lo a mitigar um problema de vizinho ruidoso, se identificar que a maior parte da carga no sistema é causada por componentes específicos que pode implementar separadamente para cada inquilino. Por exemplo, as bases de dados podem absorver a maior parte da carga do sistema, uma vez que a carga da consulta é elevada. Se um único inquilino enviar um grande número de pedidos para a sua solução, o desempenho de uma base de dados poderá ser afetado negativamente, mas as bases de dados de outros inquilinos (e componentes partilhados, como a camada de aplicação) continuam a não ser afetadas.
Riscos: Com uma implementação particionada horizontalmente, ainda tem de considerar a implementação e gestão automatizadas dos seus componentes, especialmente os componentes utilizados por um único inquilino.
Testar o modelo de isolamento
Independentemente do modelo de isolamento que escolher, certifique-se de que testa a sua solução para verificar se os dados de um inquilino não são acidentalmente vazados para outro e que quaisquer efeitos de vizinho ruidosos são aceitáveis. Considere utilizar o Azure Chaos Studio para introduzir deliberadamente falhas que simulam falhas no mundo real e verificar a resiliência da sua solução mesmo quando os componentes estão a funcionar corretamente.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Autor principal:
- John Downs | Engenheiro Principal de Clientes, FastTrack para o Azure
Outros contribuidores:
- Chad Kittel | Engenheiro de Software Principal
- Paolo Salvatori | Engenheiro Principal de Clientes, FastTrack para o Azure
- Arsen Vladimirskiy | Engenheiro Principal de Clientes, FastTrack para o Azure
Para ver perfis do LinkedIn não públicos, inicie sessão no LinkedIn.
Passos seguintes
Considere o ciclo de vida dos seus inquilinos