Modelos de arrendamento para uma solução multilocatária

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, você pode querer evitar compartilhar recursos, mas essa abordagem rapidamente se torna cara à medida que sua empresa se expande e você integra mais locatários.

Quando você considera os vários modelos de multilocação, é útil primeiro considerar como você define locatários para sua organização, quais são seus drivers de negócios e como você planeja dimensionar sua solução. Este artigo fornece orientações para ajudar os tomadores de decisão técnica a avaliar os modelos de locação e suas compensações.

Definir um inquilino

Você precisa primeiro definir um locatário para sua organização. Considere quem é o seu cliente ou quem recebe os seus serviços. Existem dois modelos comuns:

• Empresa a empresa (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 estão presentes 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 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 dentro de um único locatário.

• Empresa a consumidor (B2C): 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 possam precisar acessar e gerenciar seus dados juntos. Por exemplo, um serviço de streaming de música pode oferecer 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 algumas das coisas que você precisa considerar ou enfatizar ao arquitetar sua solução. Por exemplo, considere os seguintes tipos de inquilinos:

• Se os seus inquilinos forem pessoas individuais ou famílias, poderá ter de considerar a forma como lida com os dados pessoais e sobre as leis de soberania de dados em cada jurisdição que serve.

• Se os seus inquilinos forem empresas, poderá ter de estar atento aos requisitos dos seus clientes em matéria de conformidade regulamentar e ao isolamento dos seus dados. Certifique-se de atender a um SLO (objetivo de nível de serviço) especificado, como tempo de atividade ou disponibilidade de serviço.

Decida qual modelo usar

Escolher um modelo de arrendamento não é apenas uma decisão técnica. É também uma decisão comercial. Você precisa considerar as seguintes perguntas:

• Objetivos de negócio: Considere se a redução do custo para cada inquilino ou a maximização da experiência do inquilino está mais alinhada com os objetivos estratégicos.

• Conformidade: Considere se seus clientes aceitarão todas as formas de multilocação. 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 dimensionada de acordo com suas aspirações de crescimento futuro.

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

• Contratos de nível de serviço (SLAs): Considere se os seus clientes esperam que cumpra os SLAs, ou se tem SLOs que são o seu alvo.

Se você espera que sua empresa seja dimensionada para um grande número de clientes, é 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 entre vários locatários, cotas e 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, convém considerar o uso de 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 pode ser apropriada, mesmo que seja mais cara.

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 achar que precisa duplicar sua solução ou alguns de seus componentes para dimensionar de acordo com 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, em seguida, iniciando outra instância, uma técnica também conhecida como empacotamento em bins. No entanto, você provavelmente precisa manter um registro de seus clientes e da infraestrutura onde seus dados e aplicativos residem para que você possa rotear seu 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 um-para-muitos entre locatários e implantações, e você pode mover locatários entre implantações a seu critério.

Em contrapartida, considere uma empresa que cria software em 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, você precisa 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 é aplicado. Quando vários locatários compartilham uma única implantação (um conjunto de infraestrutura), você normalmente confia no código do aplicativo e em 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 as suas próprias implementações dedicadas, têm a sua própria infraestrutura, logo, poderá ser menos importante para o seu código levar em conta um ambiente multi-inquilino.

Às vezes, as implantações são chamadas de superlocatários ou carimbos.

Ao receber uma solicitação para um inquilino específico, precisa mapeá-la para a instância de serviço que contém os dados desse inquilino, conforme mostrado no diagrama a seguir.

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

Para obter mais informações, consulte Mapear solicitações para locatários.

Isolamento de inquilinos

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

• Ter uma única infraestrutura compartilhada que inclui instâncias separadas do seu aplicativo e bancos de dados separados para cada locatário.

• Partilhar alguns recursos comuns, mas manter outros recursos separados para cada inquilino.

• Manter os dados numa infraestrutura física separada. Na nuvem, essa configuração pode exigir recursos separados do Azure para cada locatário. Em cenários extremos, ele pode até exigir que você implante uma infraestrutura física separada usando hosts dedicados.

Em vez de ver o isolamento como uma propriedade discreta, considere-o um espectro. Você pode implantar componentes de sua arquitetura que são mais isolados ou menos isolados do que outros componentes na mesma arquitetura, dependendo de suas necessidades. O diagrama a seguir 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 bases de dados separadas. 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 aspetos da 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 sólida para sua estratégia de identidade e precisa considerar a identidade do locatário e do usuário em seu processo de autorização.

• Custo: Vários inquilinos podem utilizar a infraestrutura partilhada, pelo que é menos dispendiosa.

• Desempenho: Se você compartilhar a infraestrutura, o desempenho do seu sistema poderá se degradar à medida que mais clientes a usarem, porque os recursos podem 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 pode resultar em uma interrupção para todos os seus locatários.

• Capacidade de resposta às necessidades individuais do inquilino: Ao implantar uma infraestrutura dedicada a um locatário, talvez seja possível adaptar a configuração dos recursos aos requisitos desse locatário específico. Você pode até considerar esse recurso 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 disponíveis para isolamento. Por exemplo, considere uma arquitetura de solução de três camadas:

• Sua camada de interface do usuário pode ser um aplicativo Web multilocatário compartilhado. Todos os seus inquilinos acedem a um único hostname.

• 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 isolados, tabelas ou contêineres de blob.

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, os requisitos de seus clientes e o número de recursos que você pode implantar antes de atingir as cotas e limites do Azure.

Modelos comuns de arrendamento

Depois de estabelecer seus 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 automatizado de implantação de locatário único, você implanta um conjunto dedicado de infraestrutura para cada locatário, conforme mostrado no exemplo a seguir:

O diagrama está dividido em três secções, uma para o Inquilino A, uma para o Inquilino B e uma para o Inquilino C. Uma seta aponta do Locatário A para uma caixa chamada 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 chamada Implantação B. Essa caixa contém um servidor Web para o inquilino B. Outra seta aponta do Locatário C para uma caixa chamada 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 de seus clientes. Considere o uso do padrão Carimbos de Implantação ao planejar sua 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 salvaguarda pode ser importante para os clientes que têm alta sobrecarga de conformidade regulamentar. 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 . As atualizações e alterações podem ser implementadas 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 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 seus processos operacionais e considere aplicar mudanças progressivamente em 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árias

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 o usam, conforme mostrado no diagrama a seguir:

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 os locatários A, B e C.

Benefícios: Esse modelo é atraente porque operar uma solução que tenha componentes compartilhados é menos dispendioso do que usar recursos individuais para cada locatário. Mesmo que você precise implantar camadas mais altas ou SKUs de recursos para levar em conta o aumento da carga, o custo geral de implantação geralmente 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 seja possível atualizar identificadores e chaves de locatário e talvez não seja necessário migrar dados entre duas implantações separadas.

Riscos:

• Certifique-se de separar os dados de cada locatário e não vaze dados entre os locatários. Talvez seja necessário gerenciar dados de fragmentação. Também pode ser necessário 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 controlar 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 só precisa atualizar um conjunto de recursos. No entanto, também é muitas vezes mais arriscado porque as alterações podem afetar toda a sua base de clientes.

• Também pode ser necessário considerar a escala. É mais provável que você atinja os limites de escala de recursos do Azure quando tiver um conjunto compartilhado de infraestrutura. Por exemplo, se você usar uma conta de armazenamento como parte de sua solução, à medida que sua escala aumentar, o número de solicitações para essa conta de armazenamento poderá atingir o limite do que a conta de armazenamento pode lidar. 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 AKS ou contas de armazenamento. Você pode até considerar distribuir seus locatários entre os recursos que você implanta 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 de forma não linear. Por exemplo, se tiver um único banco de dados partilhado operado em grande escala, poderá esgotar a sua capacidade e precisará de pagar cada vez mais pelo aumento da capacidade para acompanhar a sua procura.

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 e camadas de aplicativos de seus clientes em infraestruturas multilocatário, mas 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.

Aqui está 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 Cliente A e do Cliente B para uma caixa rotulada Implantação 1. Essa caixa contém um servidor Web para os inquilinos A e B. Outra seta aponta do Locatário C para uma caixa chamada 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, pode obter alguns dos benefícios de custo do uso de implantações multilocatárias compartilhadas. Você pode implantar recursos compartilhados menos dispendiosos para clientes específicos, como clientes que estão a avaliar o seu serviço usando um teste. Você pode até cobrar dos clientes uma taxa mais alta para usar uma implantação de locatário único, o que ajuda a recuperar alguns de seus custos.

Riscos: Sua base de código precisa ser projetada para oferecer suporte a implantações multilocatárias e de locatário único. Se você planeja permitir a migração entre implantações, precisa considerar como migrar clientes de uma implantação multilocatária para sua própria implantação de locatário único. Você também precisa saber quais de seus locatários estão em cada implantação para que possa comunicar informações sobre problemas do sistema ou atualizações aos 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 compartilhado pelos locatários A, B e C.

Benefícios: Implantações particionadas horizontalmente podem ajudá-lo a mitigar um problema de vizinho barulhento. Se você identificar que componentes específicos causam a maior parte da carga em seu sistema, 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 para sua solução, o desempenho de um banco de dados poderá ser afetado negativamente, mas os bancos de dados e componentes compartilhados de outros locatários, como a camada de aplicativo, permanecerão inalterados.

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

Teste seu modelo de isolamento

Seja qual for o modelo de isolamento escolhido, certifique-se de testar a sua solução para verificar se os dados de um inquilino não são vazados acidentalmente para outro e se quaisquer resultados de interferências de vizinhança 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 sua solução, mesmo quando os componentes estão funcionando mal.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Autor principal:

• John Downs | Engenheiro de Software Principal, Azure Patterns & Practices

Outros contribuidores:

• Chad Kittel | Engenheiro de Software Principal, Azure Patterns & Practices
• Paolo Salvatori | Engenheiro de Clientes Principal, FastTrack for Azure
• Arsen Vladimirskiy | Engenheiro de Clientes Principal, FastTrack for Azure

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Próximo passo

Considere o ciclo de vida dos seus inquilinos.