Modelos de locatário para uma solução multilocatário

Há muitas maneiras de considerar como trabalhar com locatários em sua solução. Sua abordagem depende se e como você compartilha recursos entre seus locatários. Intuitivamente, talvez você queira evitar o compartilhamento de recursos, mas essa abordagem rapidamente se torna cara à medida que sua empresa é dimensionada e você integra mais locatários.

Ao considerar os vários modelos de multilocação, é útil considerar primeiro como você define os locatários para a sua organização, quais são os seus motivadores de negócios e como você planeja escalar a sua solução. Este artigo fornece diretrizes para ajudar os tomadores de decisões técnicas a avaliar 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 ou quem recebe seus serviços. Há dois modelos comuns:

• Negócios para empresas (B2B): Se seus clientes forem outras organizações, você provavelmente mapeará seus locatários para esses clientes. No entanto, considere se seus clientes têm divisões, como equipes ou departamentos, e se eles têm presença em vários países ou 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 seu serviço para que ele possa manter seus ambientes de desenvolvimento e produção separados um do outro. Um único locatário normalmente tem vários usuários. Por exemplo, todos os funcionários do cliente são usuários em um único locatário.

• B2C (negócios para consumidor): Se os clientes forem 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 os seguintes tipos de locatários:

• Se seus locatários forem pessoas ou famílias individuais, talvez seja necessário considerar como lidar com dados pessoais e sobre as leis de soberania de dados em cada jurisdição que você atende.

• Se seus locatários forem empresas, talvez seja necessário estar atento aos requisitos de seus clientes para conformidade regulatória e o isolamento de seus dados. Verifique se você atende a um SLO (objetivo de nível de serviço) especificado, como tempo de atividade ou disponibilidade de serviço.

Decidir 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 as seguintes perguntas:

• Objetivos de negócios: Considere se a redução do custo para cada locatário ou a maximização da experiência de locatário se alinha mais de perto com as metas estratégicas.

• Conformidade: Considere se os clientes aceitarão todas as formas de multitenância. Como cada modelo de multilocação afeta seus requisitos de conformidade ou os requisitos de conformidade de seus clientes?

• Escala: Considere se uma solução de locatário único pode ser escalada para suas aspirações futuras de crescimento.

• Automação: Considere o tamanho da sua equipe de operações e quanto do gerenciamento de infraestrutura você pode automatizar.

• SLAs (contratos de nível de serviço): Considere se os clientes esperam que você cumpra SLAs, ou se você tem SLOs (objetivos de nível de serviço) que você visa.

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ê terá que manter uma frota grande e crescente de instâncias de recursos. A implantação de recursos individuais do Azure para cada cliente provavelmente é 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 ser aplicados e os custos operacionais para implantar e reconfigurar esses recursos aumentam 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 se deve distinguir entre locatários lógicos e implantações.

Por exemplo, considere um serviço de streaming de música. Inicialmente, você pode criar uma solução que possa lidar facilmente com milhares ou até dezenas de milhares de usuários. No entanto, à medida que sua organização continua a crescer, você pode descobrir que precisa duplicar sua solução ou alguns de seus componentes para dimensionar para a nova demanda do cliente. Para realizar essa tarefa, você precisa determinar como atribuir clientes específicos a instâncias específicas da sua solução. Você pode atribuir clientes aleatoriamente, geograficamente ou preenchendo uma única instância e iniciando outra instância, também conhecida como empacotamento de compartimentos. No entanto, você provavelmente precisa manter um registro de seus clientes e da infraestrutura em que residem seus dados e aplicativos para que você possa rotear o tráfego para o local correto. Neste exemplo, você pode representar cada cliente como um locatário separado e mapear usuários para a implantação que contém seus dados. Essa abordagem cria uma relação de um para muitos entre locatários e implantações, e você pode mover locatários entre implantações a seu critério.

Por outro lado, considere uma empresa que cria software de nuvem para escritórios de advocacia. Seus clientes podem insistir em ter sua própria infraestrutura dedicada para manter a conformidade com os requisitos regulamentares. 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 os locatários têm suas próprias implantações dedicadas, eles têm sua própria infraestrutura, portanto, pode ser menos importante que seu código considere 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 cliente específico, é necessário mapeá-la para a implementação que contém os dados desse cliente, como mostrado no diagrama seguinte.

O diagrama é dividido em três seções principais: locatários, sua solução, ID do locatário e ID da implantação. As setas apontam dos locatários A, B, C e D para uma caixa rotulada como 'mapeamento de locatários' na seção de solução. Essa seção também inclui um servidor Web e um banco de dados para a implantação 1 e a implantação 2. Outra seta aponta da caixa de mapeamento do locatário para a seção que contém os IDs do locatário e da implantação. Os locatários A e B têm ID de implantação 1, e os locatários C e D têm ID de implantação 2.

Para obter mais informações, consulte Solicitações de mapa para locatários.

Isolamento de locatário

Uma das maiores considerações no design de arquitetura multilocatário é o nível de isolamento que cada locatário precisa. O isolamento pode se referir às seguintes configurações:

• Ter uma única infraestrutura compartilhada que inclua 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 cenários extremos, pode até exigir que você implante uma infraestrutura física separada usando hosts dedicados.

Em vez de exibir o isolamento como uma propriedade discreta, considere-o um espectro. Você pode implantar componentes de sua arquitetura mais isolados ou menos isolados do que outros componentes na mesma arquitetura, dependendo de suas necessidades. O seguinte diagrama demonstra um contínuo de isolamento:

O diagrama mostra uma seta de totalmente isolado (nada compartilhado) para totalmente compartilhado (tudo compartilhado). No lado totalmente isolado, as caixas azuis contêm computação separada, bancos de dados separados, rede separada e nomes de domínio separados. No meio da seta, as caixas verdes contêm computação compartilhada, rede compartilhada e nomes de domínio compartilhados. Uma caixa azul contém bancos de dados separados. No lado totalmente compartilhado, as caixas verdes contêm computação compartilhada, banco de dados compartilhado, rede compartilhada e nomes de domínio compartilhados.

O nível de isolamento afeta muitos aspectos de sua arquitetura:

• Segurança: Se você compartilhar a infraestrutura entre vários locatários, tome cuidado para não acessar dados de um locatário quando 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.

• Custar: Vários locatários podem usar a infraestrutura compartilhada, portanto, ela é mais barata.

• Desempenho: Se você compartilhar a infraestrutura, o desempenho do sistema poderá diminuir à medida que mais clientes a usarem, pois os recursos poderão ser consumidos mais rapidamente. Locatários que têm padrões de uso incomuns podem piorar os problemas de desempenho.

• Fiabilidade: Se você usar um único conjunto de infraestrutura compartilhada, um problema com um componente poderá resultar em uma interrupção para todos os seus locatários.

• Capacidade de resposta às necessidades individuais do locatário: Ao implantar uma infraestrutura dedicada a um locatário, você poderá adaptar a configuração dos recursos aos requisitos desse locatário específico. Você pode até considerar essa funcionalidade em seu modelo de preços para permitir 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 de usuário pode ser um aplicativo da Web compartilhado e multilocatário. Todos os locatários acessam um único nome de host.

• Sua camada intermediária pode ser uma camada de aplicativo compartilhada que tem filas de mensagens compartilhadas.

• Sua camada de dados pode ser bancos de dados isolados, tabelas ou contêineres de blobs.

Você pode usar diferentes níveis de isolamento para cada camada. Você deve basear sua decisão sobre o que compartilhar e o que isolar em vários fatores, incluindo custo, complexidade, requisitos de seus clientes e o número de recursos que você pode implantar antes de atingir cotas e 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, conforme mostrado no exemplo a seguir:

O diagrama é dividido em três seções: uma para o Locatário A, uma para o Locatário B e outra para o Locatário C. Uma seta aponta do Locatário A para uma caixa rotulada Implantação A. Essa caixa contém um servidor web para o Locatário A. Outra seta aponta do Locatário B para uma caixa rotulada Implantação B. Essa caixa contém um servidor web para o Locatário B. Outra seta aponta do Locatário C para uma caixa rotulada Implantação C. Essa caixa contém um servidor web para o Locatário C.

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 usam a infraestrutura como código ou as APIs do Azure Resource Manager extensivamente. 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 proteção pode ser importante para os 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, também conhecido como o problema do 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 custo será baixa porque você não compartilha a infraestrutura entre seus locatários. Se um único locatário exigir um custo de infraestrutura específico, 100 locatários provavelmente exigirão 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, pode ser 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. Planeje como você pode 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ária na qual 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:

Neste diagrama, as setas apontam de caixas rotuladas como Locatário A, Locatário B e Locatário C para uma caixa rotulada como recursos compartilhados. Essa caixa contém um servidor Web para locatários A, B e C.

Benefícios: Esse modelo é atraente porque operar uma solução com componentes compartilhados é mais barato 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, você poderá atualizar identificadores de locatário e chaves e talvez 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. Talvez você também precise considerar 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 acompanhar e associar seus custos do Azure aos locatários, se essas informações forem importantes para você.

• Você pode simplificar a manutenção usando uma única implantação porque você só precisa atualizar um conjunto de recursos. No entanto, também geralmente é mais arriscado porque 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 um limite de cota de recursos, você pode implantar um pool de várias instâncias de seus recursos, como vários clusters do AKS ou contas de armazenamento. Você pode até mesmo considerar a distribuição dos locatários entre os recursos implantados em várias assinaturas do Azure.

• Provavelmente há um limite para o quão longe você pode dimensionar uma única implantação, e os custos de dimensionamento podem aumentar não linearmente. Por exemplo, se você tiver um banco de dados compartilhado único operando em alta escala, poderá esgotar sua largura de banda e precisar pagar cada vez mais pelo aumento da largura de banda para atender à sua demanda.

Implantações particionadas verticalmente

Você não precisa escolher um dos extremos dessas escalas. Em vez disso, você pode particionar verticalmente seus locatários seguindo a seguinte abordagem:

• Use uma combinação de implantações de locatário único e multilocatário. Por exemplo, você pode ter a maioria dos dados de seus clientes e camadas de aplicativo em infraestruturas multilocatários, mas você implanta 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 é eficaz quando você tem locatários em diferentes geografias.

Confira um exemplo que ilustra uma implantação compartilhada para alguns locatários e uma implantação de locatário único para outro:

Neste diagrama, as setas apontam do Inquilino A e do Inquilino B para uma caixa rotulada como Deployment 1. Essa caixa contém um servidor Web para locatários A e B. Outra seta aponta do Locatário C para uma caixa rotulada Implantação 2. Essa caixa contém um servidor Web para o Locatário C.

Benefícios: Como você ainda compartilha parte de sua infraestrutura, você pode obter alguns dos benefícios de custo do uso de implantações multilocatários compartilhadas. Você pode implantar recursos compartilhados mais baratos para clientes específicos, como clientes que estão avaliando seu serviço com uma versão de avaliação. Você pode até mesmo cobrar dos clientes uma taxa mais alta para usar uma implantação de locatário único, o que o ajuda a recuperar alguns dos seus custos.

Riscos: sua base de código precisa ser projetada para dar suporte a implantações multilocatária 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 dos seus locatários estão em cada implantação para poder comunicar informações sobre problemas do sistema ou atualizações para os clientes relevantes.

Implantações particionadas horizontalmente

Você também pode particionar horizontalmente 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 única camada de aplicativo e, em seguida, implantar bancos de dados individuais para cada locatário, conforme mostrado neste diagrama:

Neste diagrama, as setas apontam de caixas rotuladas como Locatário A, Locatário B e Locatário C para uma caixa que contém um servidor Web que locatários A, B e C compartilham.

Benefícios: Implantações particionadas horizontalmente podem ajudá-lo a atenuar um problema de vizinho barulhento. Se você identificar que componentes específicos causam a maior parte da carga em seu sistema, você poderá implantar componentes separados para cada locatário. Por exemplo, seus bancos de dados podem absorver a maior parte da carga do sistema porque a carga de consulta é alta. Se um único locatário enviar um grande número de solicitações à sua solução, a performance de um banco de dados poderá ser afetada negativamente, mas os bancos de dados de outros locatários e os componentes compartilhados, como a camada de aplicativos, não serão afetados.

Riscos: Com uma implantação particionada horizontalmente, você ainda precisa considerar a implantação automatizada e o gerenciamento de seus componentes, especialmente os componentes que um único locatário usa.

Teste o modelo de isolamento

Qualquer que seja o modelo de isolamento escolhido, certifique-se de testar sua solução para verificar se os dados de um locatário não vazaram acidentalmente para outro e se qualquer resultado de vizinho barulhento é aceitável. 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.

Contribuidores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autor principal:

• John Downs | Principal Engenheiro de Software, Padrões do Azure & Práticas

Outros colaboradores:

• Chad Kittel | Principal Engenheiro de Software, Padrões do Azure & Práticas
• Paolo Salvatori | Engenheiro de Cliente Principal, FastTrack for Azure
• Arsen Vladimirskiy | Engenheiro principal de atendimento ao cliente, FastTrack for Azure

Para ver perfis não públicos no LinkedIn, entre no LinkedIn.

Próxima etapa

Considere o ciclo de vida de seus locatários.