Há muitas maneiras de considerar como trabalhar com locatários em sua solução. Sua escolha de abordagem depende significativamente de se e como você compartilha recursos entre seus locatários. De maneira intuitiva, talvez você queira evitar o compartilhamento de recursos, mas essa abordagem rapidamente se torna cara, à medida que seus negócios se expandem e você integra cada vez mais locatários.
Ao considerar os vários modelos de multilocação, será útil primeiro levar em conta como você define os locatários para sua organização, quais são seus fatores comerciais e como você planeja dimensionar sua solução. Este artigo fornece orientação para ajudar os tomadores de decisão técnica a avaliar os modelos de locação e suas compensações.
Definir um locatário
Primeiro, você precisa definir um locatário para sua organização. Considere quem é seu cliente. Em outras palavras, para quem você está fornecendo serviços? Há dois modelos comuns:
- B2B (entre empresas). Se seus clientes forem outras organizações, será provável que você mapeie seus locatários para esses clientes. No entanto, considere se seus clientes têm divisões (equipes ou departamentos) e se eles têm presença em vários países/regiões. Talvez seja necessário mapear um único cliente para vários locatários, se houver requisitos diferentes para esses subgrupos. Da mesma forma, um cliente pode querer manter duas instâncias do serviço, para que ele possa manter seus ambientes de desenvolvimento e produção separados um do outro. Geralmente, um único locatário tem vários usuários. Por exemplo, todos os funcionários do cliente são usuários em um único locatário.
- B2C (entre empresa e consumidor). Se seus clientes são consumidores, geralmente é mais complicado relacionar clientes, locatários e usuários. Em alguns cenários, cada consumidor pode ser um locatário separado. No entanto, considere se sua solução pode ser usada por famílias, grupos de amigos, clubes, associações ou outros grupos que talvez precisem acessar e gerenciar seus dados juntos. Por exemplo, um serviço de streaming de música pode dar suporte a usuários individuais e famílias e pode tratar cada um desses tipos de conta de forma diferente, quando os separa em locatários.
Sua definição de locatário afeta alguns fatores a serem considerados ou enfatizados quando você arquiteta sua solução. Por exemplo, considere estes tipos de locatários:
- Se os locatários forem pessoas ou famílias, talvez seja necessário se preocupar particularmente com a forma como você lida com os dados pessoais e com as leis de soberania de dados em cada jurisdição que você atua.
- Se os locatários forem empresas, talvez seja necessário estar atento aos requisitos dos clientes em relação à conformidade regulatória, ao isolamento dos dados deles e à garantia de que você atenda a um SLO (objetivo de nível de serviço) especificado, como tempo de atividade ou disponibilidade de serviço.
Como você decide qual modelo usar?
Selecionar um modelo de locação não é apenas uma decisão técnica. É também uma decisão comercial. Você precisa considerar questões como as seguintes:
- Quais são seus objetivos de negócios?
- Seus clientes aceitarão todas as formas de multilocação? Como cada modelo multilocatário afeta seus requisitos de conformidade ou os requisitos de conformidade de seus clientes?
- Uma solução de locatário único será dimensionada de acordo com suas aspirações futuras de crescimento?
- Qual é o tamanho da sua equipe de operações e quanto do gerenciamento de infraestrutura você pode automatizar?
- Seus clientes esperam que você atenda aos SLAs (Contratos de Nível de Serviço) ou você tem SLOs em vista?
Se você espera que sua empresa seja dimensionada para um grande número de clientes, será muito importante implantar uma infraestrutura compartilhada. Caso contrário, você precisará manter uma grande e crescente instâncias de recursos. A implantação de recursos individuais do Azure para cada cliente provavelmente será insustentável, a menos que você provisione e use uma assinatura dedicada para cada locatário. Quando você compartilha a mesma assinatura do Azure em vários locatários, as cotas e os limites de recursos do Azure podem começar a ser aplicados e os custos operacionais para implantar e reconfigurar esses recursos aumentarão a cada novo cliente.
Por outro lado, se você espera que sua empresa tenha apenas alguns clientes, talvez deseje considerar usar recursos de locatário único dedicados a cada cliente. Além disso, se os requisitos de isolamento dos clientes forem altos, uma abordagem de infraestrutura de locatário único poderá ser apropriada mesmo que isso seja mais caro.
Locatários e implantações
Em seguida, você precisa determinar o que um locatário significa para sua solução específica e se você deve distinguir entre locatários lógicos e implantações.
Por exemplo, considere um serviço de streaming de música. No princípio, você pode criar uma solução que lide facilmente com milhares (ou até dezenas de milhares) de usuários. No entanto, à medida que os negócios se expandem, você pode descobrir que precisa duplicar sua solução ou alguns dos componentes dela, a fim de dimensionar de acordo com a nova demanda de clientes. Isso significa que você precisará determinar como atribuir clientes específicos a instâncias específicas da sua solução. Você pode atribuir clientes de maneira aleatória, geográfica ou preenchendo uma instância única para, depois, iniciar outra (empacotamento de compartimentos). No entanto, você provavelmente precisará manter um registro de seus clientes e em qual infraestrutura os dados e aplicativos deles estão disponíveis, para que você possa rotear o tráfego para a infraestrutura correta. Neste exemplo, você pode representar cada cliente como um locatário separado e mapear os usuários para a implantação que contém seus dados. Você tem um mapeamento um para muitos entre locatários e implantações e pode mover locatários entre implantações a seu próprio critério.
Por outro lado, considere uma empresa que cria software de nuvem para escritórios de advocacia. Seus clientes podem insistir em ter uma infraestrutura dedicada para manter os padrões de conformidade. Portanto, é preciso estar preparado para implantar e gerenciar muitas instâncias diferentes da sua solução, desde o início. Neste exemplo, uma implantação sempre contém um único locatário e um locatário é mapeado para sua própria implantação dedicada.
Uma diferença fundamental entre locatários e implantações é como o isolamento é imposto. Quando vários locatários compartilham uma única implantação (um conjunto de infraestrutura), você normalmente depende do código do aplicativo e de um identificador de locatário que está em um banco de dados para manter os dados de cada locatário separados. Quando você tem locatários com suas próprias implantações dedicadas, eles têm a própria infraestrutura, portanto pode ser menos importante que seu código esteja ciente de que ele está operando em um ambiente multilocatário.
Às vezes, as implantações são chamadas de superlocatários ou selos.
Quando você recebe uma solicitação para um locatário específico, é necessário mapeá-la para a implantação que contém os dados desse locatário, conforme mostrado abaixo:
Para saber mais, consulte Mapear solicitações para locatários.
Isolamento de locatário
Uma das maiores considerações no design de uma arquitetura multilocatário é o nível de isolamento que cada locatário precisa. O isolamento pode significar coisas diferentes:
- Ter uma única infraestrutura compartilhada, com instâncias separadas do aplicativo e bancos de dados separados para cada locatário.
- Compartilhar alguns recursos comuns, mas manter outros recursos separados para cada locatário.
- Manter dados em uma infraestrutura física separada. Na nuvem, essa configuração pode requerer recursos separados do Azure para cada locatário. Em situações extremas, isso pode até significar a implantação de uma infraestrutura física separada usando-se hosts dedicados.
Em vez de pensar no isolamento como uma propriedade discreta, você deve pensar nele como algo em evolução. Você pode implantar componentes de sua arquitetura mais ou menos isolados do que outros componentes na mesma arquitetura, dependendo de seus requisitos. O seguinte diagrama demonstra um contínuo de isolamento:
O nível de isolamento afeta muitos aspectos da arquitetura, incluindo o seguinte:
- Segurança. Se você compartilhar a infraestrutura entre vários locatários, precisará ter um cuidado especial para não acessar dados de um locatário ao retornar respostas para outro. Você precisa de uma base forte para sua estratégia de identidade e considerar a identidade do locatário e do usuário no processo de autorização.
- Custo. Como a infraestrutura compartilhada pode ser usada por vários locatários, ela é mais barata.
- Desempenho. Se você compartilhar a infraestrutura, o desempenho do sistema poderá sofrer à medida que mais clientes passarem a usá-la, já que os recursos poderão ser consumidos mais rapidamente. Os problemas de desempenho podem ser agravados por locatários com padrões de uso incomuns.
- Confiabilidade. Se você usar um conjunto único de infraestrutura compartilhada, um problema com um componente poderá resultar em uma interrupção para todos os locatários.
- Capacidade de resposta às necessidades de locatários individuais. Quando você implanta a infraestrutura dedicada a um locatário, é possível adaptar a configuração dos recursos para os requisitos desse locatário específico. Você até pode considerar essa capacidade no modelo de preços, permitindo que os clientes paguem mais por implantações isoladas.
A arquitetura da solução pode influenciar as opções que você tem disponíveis para isolamento. Por exemplo, considere uma arquitetura da solução de três camadas:
- Sua camada de interface do usuário pode ser um aplicativo Web multilocatário compartilhado, com todos os locatários acessando um só nome de host.
- Sua camada intermediária pode ser uma camada de aplicativo compartilhada, com filas de mensagens compartilhadas.
- Sua camada de dados pode ser bancos de dados, tabelas ou contêineres de blobs isolados.
Você pode considerar usar diferentes níveis de isolamento em cada camada. Sua decisão sobre o que é compartilhado e o que é isolado deverá ser baseada em muitas considerações, incluindo custo, complexidade, requisitos dos clientes e o número de recursos que você pode implantar antes de atingir as cotas e os limites do Azure.
Modelos comuns de locação
Depois de estabelecer os requisitos, avalie-os em relação a alguns modelos comuns de locação e padrões de implantação correspondentes.
Implantações automatizadas de locatário único
Em um modelo de implantação de locatário único automatizado, você implanta um conjunto dedicado de infraestrutura para cada locatário, como mostrado neste exemplo:
Seu aplicativo é responsável por iniciar e coordenar a implantação dos recursos de cada locatário. Normalmente, as soluções que usam esse modelo fazem uso extensivo da IaC (infraestrutura como código) ou das APIs do Azure Resource Manager. Você pode usar essa abordagem quando precisar provisionar infraestruturas totalmente separadas para cada um dos clientes. Considere usar o padrão de Selos de Implantação quando você planejar a implantação.
Benefícios: um dos principais benefícios dessa abordagem é que os dados de cada locatário são isolados, o que reduz o risco de vazamento acidental. Essa medida de segurança pode ser importante para alguns clientes que têm alta sobrecarga de conformidade regulatória. Além disso, é improvável que os locatários afetem o desempenho do sistema uns dos outros, o que às vezes é chamado de problema de vizinho barulhento. Atualizações e alterações podem ser distribuídas progressivamente entre locatários, o que reduz a probabilidade de uma interrupção em todo o sistema.
Riscos: se você usar essa abordagem, a eficiência de custos será baixa, porque você não compartilhará a infraestrutura entre seus locatários. Se um locatário exigir um determinado custo de infraestrutura, é provável que 100 locatários exijam 100 vezes esse custo. Além disso, é provável que a manutenção contínua (como a aplicação de novas atualizações de configuração ou de software) seja demorada. Considere automatizar os processos operacionais e aplicar as alterações progressivamente por meio de seus ambientes. Você também deve considerar outras operações de implantação cruzada, como relatórios e análises em toda a frota. Da mesma forma, planeje como consultar e manipular dados em várias implantações.
Implantações totalmente multilocatário
No extremo oposto, você pode considerar uma implantação totalmente multilocatário, em que todos os componentes são compartilhados. Você tem apenas um conjunto de infraestrutura para implantar e manter, e todos os locatários a usam, como mostrado no seguinte diagrama:
Benefícios: esse modelo é atraente porque operar uma solução que tem componentes compartilhados é menos dispendioso do que usar recursos individuais para cada locatário. Mesmo que você precise implantar camadas ou SKUs de recursos na conta para a carga elevada, o custo geral da implantação muitas vezes ainda é menor do que o custo de um conjunto de recursos de locatário único. Além disso, se um usuário ou locatário precisar mover seus dados para outro locatário, talvez você possa atualizar identificadores e chaves de locatário e não precise migrar dados entre duas implantações separadas.
Riscos:
Certifique-se de separar dados para cada locatário, bem como de não vazar dados entre os locatários. Talvez seja necessário gerenciar dados de fragmentação. Além disso, talvez seja necessário se preocupar com os efeitos que locatários individuais podem ter no sistema geral. Por exemplo, se um locatário grande tentar executar uma consulta ou operação pesada, isso poderá afetar outros locatários.
Determine como rastrear e associar os custos do Azure aos locatários se isso for importante para você.
A manutenção pode ser mais simples com uma só implantação, pois você apenas precisa atualizar um conjunto de recursos. No entanto, isso também é geralmente mais arriscado, já que as alterações podem afetar toda a sua base de clientes.
Talvez você também precise considerar a escala. É mais provável que você atinja os limites da escala dos recursos do Azure ao ter um conjunto compartilhado de infraestrutura. Por exemplo, se você usar uma conta de armazenamento como parte de sua solução, à medida que a escala aumentar, o número de solicitações para essa conta de armazenamento poderá atingir o limite do que a conta de armazenamento pode manipular. Para evitar atingir o limite de cota de recursos, você pode considerar a implantação de um pool de várias instâncias de recursos (por exemplo, vários clusters do AKS ou várias contas de armazenamento). Você pode até mesmo considerar a distribuição dos locatários entre os recursos implantados em várias assinaturas do Azure.
É provável que haja um limite de dimensionamento de uma implantação, e os custos de fazê-lo podem aumentar de maneira não linear. Por exemplo, se você tiver um banco de dados compartilhado único, ao executar em uma escala muito alta, poderá esgotar a taxa de transferência e precisar pagar cada vez mais pelo aumento da taxa de transferência, para atender à demanda.
Implantações particionadas verticalmente
Você não precisa escolher um dos extremos dessas escalas. Em vez disso, considere o particionamento vertical de seus locatários adotando esta abordagem:
- Use uma combinação de implantações de locatário único e multilocatário. Por exemplo, você pode ter a maioria dos dados e camadas de aplicativo dos clientes em infraestruturas multilocatários, mas implantar infraestruturas de locatário único para clientes que exigem maior desempenho ou isolamento de dados.
- Implante várias instâncias de sua solução geograficamente e mapeie cada locatário para uma implantação específica. Essa abordagem é particularmente eficaz quando você tem locatários em diferentes localizações geográficas.
Confira um exemplo que ilustra uma implantação compartilhada para alguns locatários e uma implantação de locatário único para outro:
Benefícios: como você ainda está compartilhando parte da infraestrutura, pode obter alguns dos benefícios de custo do uso de implantações multilocatárias compartilhadas. Você pode implantar recursos compartilhados mais baratos para determinados clientes, como clientes que estão testando o seu serviço em uma avaliação gratuita. Você pode até mesmo cobrar dos clientes uma taxa mais alta para usar uma implantação de locatário único, o que ajuda a recuperar alguns custos.
Riscos: sua base de código precisa ser projetada para dar suporte a implantações multilocatários e de locatários únicos. Se você planeja permitir a migração entre implantações, será necessário considerar como migrar clientes de uma implantação multilocatário para a implantação própria de locatário único. Você também precisa saber quais de seus locatários estão em cada implantação, para que você possa comunicar informações sobre problemas do sistema ou atualizações para os clientes relevantes.
Implantações particionadas horizontalmente
Você também pode considerar o particionamento horizontal de suas implantações. Em uma implantação horizontal, você tem alguns componentes compartilhados, mas mantém outros componentes com implantações de locatário único. Por exemplo, você pode criar uma camada de aplicativo única e, depois, implantar bancos de dados individuais para cada locatário, como mostrado neste diagrama:
Benefícios: implantações particionadas horizontalmente poderão ajudar a atenuar um problema de vizinho barulhento: se você identificar que a maior parte da carga em seu sistema se deve a componentes específicos, poderá implantar os componentes separadamente para cada locatário. Por exemplo, seus bancos de dados podem absorver a maior parte da carga do sistema, pois a carga de consulta é alta. Se um locatário enviar uma grande quantidade de solicitações para sua solução, o desempenho de um banco de dados poderá ser afetado negativamente, mas os bancos de dados de outros locatários (e os componentes compartilhados, como a camada de aplicativo) permanecerão inalterados.
Riscos: com uma implantação particionada horizontalmente, você ainda precisa considerar a implantação automatizada e o gerenciamento de seus componentes, em especial os componentes usados por um locatário individual.
Teste o modelo de isolamento
Seja qual for o modelo de isolamento selecionado, teste a solução para verificar se os dados de um locatário não são vazados acidentalmente para outro e se os efeitos de vizinho barulhento são aceitáveis. Considere usar o Azure Chaos Studio para introduzir deliberadamente falhas que simulam interrupções do mundo real e verificar a resiliência da solução mesmo quando os componentes estão com defeito.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Autor principal:
- John Downs | Engenheiro de software principal
Outros colaboradores:
- Chad Kittel | Engenheiro de Software Principal
- Paolo Salvatori | Engenheiro de Cliente Principal, FastTrack for Azure
- Arsen Vladimirskiy | Engenheiro de Cliente Principal, FastTrack for Azure
Para ver perfis não públicos do LinkedIn, entre no LinkedIn.
Próximas etapas
Considere o ciclo de vida dos locatários.