Há muitas maneiras de considerar como trabalhar com locatários em sua solução. A sua escolha de abordagem depende muito de saber se e como partilha recursos entre os seus inquilinos. 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 levar em conta 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
Primeiro, você precisa definir um locatário para sua organização. Considere quem é o seu cliente. Por outras palavras, a quem presta os seus serviços? Existem dois modelos comuns:
- Empresa a empresa (B2B). Se seus clientes forem outras organizações, é 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 estão presentes 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 seu serviço para que 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 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 estes tipos de inquilinos:
- Se os seus inquilinos forem pessoas ou famílias individuais, poderá ter de estar particularmente preocupado com a forma como trata os dados pessoais e com as leis de soberania de dados dentro de cada jurisdição que serve.
- Se seus locatários forem empresas, talvez seja necessário estar atento aos requisitos de conformidade regulatória de seus clientes, ao isolamento de seus dados 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?
Escolher um modelo de arrendamento não é apenas uma decisão técnica. É também uma decisão comercial. Você precisa considerar perguntas como estas:
- Quais são os seus objetivos de negócio?
- Os 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?
- Uma solução de inquilino único será dimensionada para suas aspirações futuras de crescimento?
- Qual é o tamanho da sua equipe de operações e quanto do seu gerenciamento de infraestrutura você pode automatizar?
- Seus clientes esperam que você cumpra os contratos de nível de serviço (SLAs) ou você tem SLOs que você está almejando?
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 será insustentável, a menos que você provisione e use uma assinatura dedicada para cada locatário. Quando partilha a mesma subscrição do Azure entre vários inquilinos, as quotas e limites de recursos do Azure podem começar a aplicar-se e os custos operacionais para implementar e reconfigurar estes recursos aumentam com 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 o que o locatário significa para sua solução específica e 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 você continua a crescer, pode achar que precisa duplicar sua solução ou alguns de seus componentes para dimensionar para a nova demanda do cliente. Isso significa que você precisa determinar como atribuir clientes específicos a instâncias específicas da sua solução. Você pode atribuir clientes aleatoriamente, ou geograficamente, ou preenchendo uma única instância e, em seguida, iniciando outra (embalagem de lixo). No entanto, você provavelmente precisa manter um registro de seus clientes e em qual infraestrutura seus dados e aplicativos estão disponíveis para que você possa rotear seu tráfego para a infraestrutura correta. Neste exemplo, você pode representar cada cliente como um locatário separado e, em seguida, 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 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 seus padrões de conformidade. 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 você tem locatários com suas próprias implantações dedicadas, eles têm sua própria infraestrutura, portanto, pode ser menos importante para seu código estar ciente de que está operando em um ambiente multilocatário.
Às vezes, as implantações são chamadas de superlocatários ou carimbos.
Ao receber uma solicitação para um locatário específico, você precisa mapeá-la para a implantação que contém os dados desse locatário, conforme mostrado aqui:
Para saber mais, consulte Mapear solicitações para locatários.
Isolamento de inquilinos
Uma das maiores considerações no design de uma arquitetura multilocatária é 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 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 situações extremas, isso pode até significar a implantação de uma infraestrutura física separada usando hosts dedicados.
Em vez de pensar no isolamento como uma propriedade discreta, você deve pensar nele como estando em um contínuo. Você pode implantar componentes de sua arquitetura que são mais ou menos isolados do que outros componentes na mesma arquitetura, dependendo de seus requisitos. O diagrama a seguir demonstra um contínuo de isolamento:
O nível de isolamento afeta muitos aspetos da sua arquitetura, incluindo os seguintes:
- Segurança. Se você compartilhar infraestrutura entre vários locatários, precisará ter cuidado especial 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. A infraestrutura partilhada pode ser utilizada por vários inquilinos, pelo que é menos dispendiosa.
- Desempenho. Se você compartilhar a infraestrutura, o desempenho do seu sistema poderá ser prejudicado à medida que mais clientes a usarem, porque os recursos poderão ser consumidos mais rapidamente. Os problemas de desempenho podem ser exacerbados por locatários com padrões de uso incomuns.
- 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 dos inquilinos. 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, permitindo 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, com todos os seus locatários acessando um único 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 isolados, tabelas ou contêineres de blob.
Você pode considerar o uso de diferentes níveis de isolamento em cada camada. Você deve basear sua decisão sobre o que é compartilhado e o que está isolado em muitas considerações, incluindo custo, complexidade, 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 de implantação automatizada de locatário único, você implanta um conjunto dedicado de infraestrutura para cada locatário, conforme 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 usam a infraestrutura como código (IaC) 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 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, um problema que às vezes é chamado de 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 é baixa, porque você não compartilha a infraestrutura entre seus locatários. Se um único locatário exigir um determinado custo de infraestrutura, 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) provavelmente 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. Da mesma forma, certifique-se de planejar 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ário, onde 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:
Benefícios: Este 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 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. 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 controlar e associar seus custos do Azure aos locatários, se isso for importante para você.
A manutenção pode ser mais simples com uma única implantação, porque você 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 considerar a implantação de um pool de várias instâncias de seus recursos (por exemplo, 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 fazê-lo podem aumentar de forma não linear. Por exemplo, se você tiver um único banco de dados compartilhado, quando executar em escala muito alta, poderá esgotar sua taxa de transferência e precisará pagar cada vez mais por uma taxa de transferência maior para acompanhar sua demanda.
Implantações particionadas verticalmente
Você não precisa escolher um dos extremos dessas escalas. Em vez disso, você pode considerar 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 aplicativos de seus clientes em infraestruturas multilocatário, 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 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:
Benefícios: Como você ainda está compartilhando 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 mais baratos para determinados clientes, como clientes que estão avaliando seu serviço com uma avaliação. 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 dos seus custos.
Riscos: Sua base de código precisa ser projetada para dar 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 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 única camada de aplicativo e, em seguida, implantar bancos de dados individuais para cada locatário, conforme mostrado neste diagrama:
Benefícios: Implantações particionadas horizontalmente podem ajudá-lo a mitigar um problema de vizinho barulhento: se você identificar que a maior parte da carga em seu sistema é causada por componentes específicos, 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 de outros locatários (e componentes compartilhados, 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 usados por um único locatário.
Teste seu modelo de isolamento
Seja qual for o modelo de isolamento escolhido, certifique-se de testar sua solução para verificar se os dados de um locatário não são vazados acidentalmente para outro e se quaisquer efeitos de vizinhos barulhentos 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
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Autor principal:
- John Downs - Brasil | Engenheiro de Software Principal
Outros contribuidores:
- Chade Kittel - Brasil | Engenheiro de Software Principal
- Paolo Salvatori - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
- Arsen Vladimirskiy - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.
Próximos passos
Considere o ciclo de vida dos seus inquilinos