O Azure fornece muitas opções para organizar seus recursos. Em uma solução multilocatário, há compensações específicas a serem consideradas quando você planeja sua estratégia de organização de recursos. Neste artigo, analisamos dois elementos principais da organização de seus recursos do Azure: isolamento de locatário e expansão em vários recursos. Também descrevemos como trabalhar com os limites de recursos e cotas do Azure e como dimensionar sua solução além desses limites.
Principais considerações e requisitos
Requisitos de isolamento do locatário
Ao implantar uma solução multilocatária no Azure, você precisa decidir se dedica recursos a cada locatário ou compartilha recursos entre vários locatários. Ao longo das abordagens de multilocação e das seções de orientação específica de serviços desta série, descrevemos as opções e compensações para muitas categorias de recursos. Em geral, há uma gama de opções para o isolamento do inquilino. Analise os modelos de locação a serem considerados para uma solução multilocatária para obter mais orientações sobre como decidir sobre seu modelo de isolamento.
Escala
A maioria dos recursos do Azure, bem como grupos de recursos e assinaturas, impõe limites que podem afetar sua capacidade de escala. Talvez seja necessário considerar a expansão ou a embalagem de compartimentos para atender ao número planejado de locatários ou à carga planejada do sistema.
Se você sabe com certeza que não crescerá para um grande número de inquilinos ou para uma carga alta, não faça uma engenharia excessiva do seu plano de expansão. Mas se você planeja que sua solução cresça, considere cuidadosamente seu plano de expansão. Certifique-se de arquitetar a escala, seguindo as orientações neste artigo.
Se você tiver um processo de implantação automatizado e precisar dimensionar entre recursos, determine como implantará e atribuirá locatários em várias instâncias de recursos. Por exemplo, como você detetará que está se aproximando do número de locatários que podem ser atribuídos a um recurso específico? Você planeja implantar novos recursos a tempo para quando precisar deles? Ou você implantará um pool de recursos com antecedência para que eles estejam prontos para serem usados quando você precisar deles?
Gorjeta
Nos estágios iniciais de design e desenvolvimento, você pode não optar por implementar um processo de expansão automatizado. Você ainda deve considerar e documentar claramente os processos necessários para escalar à medida que cresce.
Também é importante evitar fazer suposições em seu código e configuração, o que pode limitar sua capacidade de escala. Por exemplo, talvez seja necessário expandir para várias contas de armazenamento. Certifique-se de que sua camada de aplicativo não assuma que ela se conecta apenas a uma única conta de armazenamento para todos os locatários.
Abordagens e padrões a considerar
Isolamento de inquilinos
Os recursos do Azure são implantados e gerenciados por meio de uma hierarquia. A maioria dos recursos é implantada em grupos de recursos, que estão contidos em assinaturas. Os grupos de gerenciamento agrupam logicamente as assinaturas. Todas essas camadas hierárquicas estão associadas a um locatário do Microsoft Entra.
Ao determinar como implantar recursos para cada locatário, você pode isolar em diferentes níveis na hierarquia. Cada opção é válida para certos tipos de soluções multilocatárias e vem com benefícios e compensações. Também é comum combinar abordagens, usando diferentes modelos de isolamento para diferentes componentes de uma solução.
Isolamento dentro de um recurso compartilhado
Você pode optar por compartilhar um recurso do Azure entre vários locatários e executar todas as suas cargas de trabalho em uma única instância. Reveja as orientações específicas do serviço para os serviços do Azure que utiliza para compreender quaisquer considerações ou opções específicas que possam ser importantes.
Ao executar instâncias únicas de um recurso, você precisa considerar quaisquer limites de serviço, limites de assinatura ou cotas que possam ser alcançados à medida que você dimensiona. Por exemplo, há um número máximo de nós suportados por um cluster do Serviço Kubernetes do Azure (AKS) e há um limite superior no número de transações por segundo suportadas por uma conta de armazenamento. Considere como você será dimensionado para vários recursos compartilhados à medida que se aproximar desses limites.
Você também precisa garantir que o código do aplicativo esteja totalmente ciente da multilocação e que restrinja o acesso aos dados de um locatário específico.
Como ilustração da abordagem de recursos compartilhados, suponha que a Contoso esteja criando um aplicativo SaaS multilocatário que inclua um aplicativo Web, um banco de dados e uma conta de armazenamento. Eles podem decidir implantar recursos compartilhados e usariam esses recursos para atender a todos os seus clientes. No diagrama a seguir, um único conjunto de recursos é compartilhado por todos os clientes.
Separar recursos em um grupo de recursos
Você também pode implantar recursos dedicados para cada locatário. Você pode implantar uma cópia inteira da sua solução para um único locatário. Ou, você pode compartilhar alguns componentes entre locatários e implantar outros componentes que são dedicados a um locatário específico.
Recomendamos que você use grupos de recursos para gerenciar recursos com o mesmo ciclo de vida. Em alguns sistemas multilocatário, faz sentido implantar recursos para vários locatários em um único grupo de recursos ou em um conjunto de grupos de recursos.
É importante que você considere como implantar e gerenciar esses recursos, incluindo se a implantação de recursos específicos do locatário é iniciada pelo pipeline de implantação ou pelo aplicativo. Você também precisa determinar como identificará claramente que recursos específicos se relacionam a locatários específicos. Considere usar uma estratégia clara de convenção de nomenclatura, tags de recursos ou um banco de dados de catálogo de locatário.
É uma boa prática usar grupos de recursos separados para os recursos que você compartilha entre vários locatários e os recursos que você implanta para locatários individuais. No entanto, para alguns recursos, o Azure limita o número de recursos de um único tipo que podem ser implantados em um grupo de recursos. Esse limite significa que você pode precisar escalar em vários grupos de recursos à medida que cresce.
Suponha que a Contoso tenha três clientes: Adventure Works, Fabrikam e Tailwind. Eles podem optar por compartilhar o aplicativo Web e a conta de armazenamento entre os três clientes e, em seguida, implantar bancos de dados individuais para cada locatário. No diagrama a seguir, cada cliente recebe um grupo de recursos que contém recursos compartilhados e um grupo de recursos que contém um banco de dados.
Separar grupos de recursos em uma assinatura
Ao implantar um conjunto de recursos para cada locatário, considere o uso de grupos de recursos específicos do locatário dedicado. Por exemplo, quando você segue o padrão Selos de Implantação, cada carimbo deve ser implantado em seu próprio grupo de recursos. Você pode considerar a implantação de vários grupos de recursos específicos do locatário em uma assinatura compartilhada do Azure, o que permite configurar facilmente políticas e regras de controle de acesso.
Você pode optar por criar um conjunto de grupos de recursos para cada locatário e também grupos de recursos compartilhados para quaisquer recursos compartilhados.
Ao implantar grupos de recursos específicos do locatário em assinaturas compartilhadas, esteja ciente do número máximo de grupos de recursos em cada assinatura e de outros limites de nível de assinatura que se aplicam aos recursos implantados. À medida que se aproxima desses limites, talvez seja necessário dimensionar em várias assinaturas.
Em nosso exemplo, a Contoso pode optar por implantar um selo para cada um de seus clientes e colocar os carimbos em grupos de recursos dedicados em uma única assinatura. No diagrama a seguir, uma assinatura, que contém três grupos de recursos, é criada para cada cliente.
Subscrições separadas
Ao implantar assinaturas específicas do locatário, você pode isolar completamente os recursos específicos do locatário. Além disso, como a maioria das cotas e limites se aplicam a uma assinatura, o uso de uma assinatura separada por locatário garante que cada locatário tenha pleno uso de todas as cotas aplicáveis. Para alguns tipos de conta de cobrança do Azure, você pode criar assinaturas programaticamente. Você também pode usar as reservas do Azure e o plano de economia do Azure para computação entre assinaturas.
Fazer com que você esteja ciente do número de assinaturas que você pode criar. O número máximo de subscrições pode diferir, dependendo da sua relação comercial com a Microsoft ou com um parceiro Microsoft, por exemplo, se tiver um contrato empresarial.
No entanto, pode ser mais difícil solicitar aumentos de cota quando você trabalha com um grande número de assinaturas. A API de cota fornece uma interface programática para alguns tipos de recursos. No entanto, para muitos tipos de recursos, os aumentos de cota devem ser solicitados iniciando um caso de suporte. Também pode ser difícil trabalhar com contratos de suporte do Azure e casos de suporte, quando você trabalha com muitas assinaturas.
Considere agrupar suas assinaturas específicas do locatário em uma hierarquia de grupo de gerenciamento, para permitir o gerenciamento fácil de regras e políticas de controle de acesso.
Por exemplo, suponha que a Contoso decidiu criar assinaturas separadas do Azure para cada um de seus três clientes, conforme mostrado no diagrama a seguir. Cada assinatura contém um grupo de recursos, com o conjunto completo de recursos para esse cliente.
Cada assinatura contém um grupo de recursos, com o conjunto completo de recursos para esse cliente.
Eles usam um grupo de gerenciamento para simplificar o gerenciamento de suas assinaturas. Ao incluir a Produção no nome do grupo de gestão, podem distinguir claramente os inquilinos de produção dos inquilinos não produtores ou de teste. Os locatários que não são de produção teriam diferentes regras e políticas de controle de acesso do Azure aplicadas.
Todas as suas subscrições estão associadas a um único inquilino do Microsoft Entra. Usar um único locatário do Microsoft Entra significa que as identidades da equipe da Contoso, incluindo usuários e entidades de serviço, podem ser usadas em todo o seu patrimônio do Azure.
Assinaturas separadas em locatários separados do Microsoft Entra
Também é possível criar manualmente locatários individuais do Microsoft Entra para cada um dos seus locatários ou implantar seus recursos em assinaturas dentro dos locatários do Microsoft Entra de seus clientes. No entanto, trabalhar com vários locatários do Microsoft Entra torna mais difícil autenticar, gerenciar atribuições de função, aplicar políticas globais e executar muitas outras operações de gerenciamento.
Aviso
Desaconselhamos a criação de vários locatários do Microsoft Entra para a maioria das soluções multilocatário. Trabalhar entre locatários do Microsoft Entra introduz complexidade extra e reduz sua capacidade de dimensionar e gerenciar seus recursos. Normalmente, essa abordagem é usada apenas por provedores de serviços gerenciados (MSPs), que operam ambientes do Azure em nome de seus clientes.
Um único locatário do Microsoft Entra pode ser usado por várias assinaturas separadas e recursos do Azure. Antes de fazer um esforço para implantar vários locatários do Microsoft Entra, considere se há outras abordagens que possam atingir seus objetivos.
Em situações em que você precisa gerenciar recursos do Azure em assinaturas vinculadas a vários locatários do Microsoft Entra, considere usar o Azure Lighthouse para ajudar a gerenciar seus recursos entre seus locatários do Microsoft Entra.
Por exemplo, a Contoso poderia criar locatários separados do Microsoft Entra e assinaturas separadas do Azure para cada um de seus clientes, conforme mostrado no diagrama a seguir.
Um locatário do Microsoft Entra é configurado para cada um dos locatários da Contoso, que contém uma assinatura e os recursos necessários. O Azure Lighthouse está conectado a cada locatário do Microsoft Entra.
Embalagem do caixote do lixo
Independentemente do seu modelo de isolamento de recursos, é importante considerar quando e como sua solução será expandida em vários recursos. Talvez seja necessário dimensionar seus recursos, à medida que a carga no sistema aumenta ou à medida que o número de locatários aumenta. Considere a embalagem de compartimentos para implantar um número ideal de recursos para suas necessidades.
Gorjeta
Em muitas soluções, é mais fácil dimensionar todo o conjunto de recursos em conjunto, em vez de dimensionar os recursos individualmente. Considere seguir o padrão de Carimbos de Implantação.
Limites de recursos
Os recursos do Azure têm limites e cotas que devem ser considerados em seu planejamento de solução. Por exemplo, os recursos podem suportar um número máximo de solicitações simultâneas ou definições de configuração específicas do locatário.
A maneira como você configura e usa cada recurso também afeta a escalabilidade desse recurso. Por exemplo, dada uma certa quantidade de recursos de computação, seu aplicativo pode responder com êxito a um número definido de transações por segundo. Além desse ponto, talvez seja necessário dimensionar. O teste de desempenho ajuda você a identificar o ponto em que seus recursos não atendem mais às suas necessidades.
Nota
O princípio de dimensionamento para vários recursos se aplica mesmo quando você trabalha com serviços que oferecem suporte a várias instâncias.
Por exemplo, o Serviço de Aplicativo do Azure oferece suporte à expansão do número de instâncias do seu plano, mas há limites para até onde você pode dimensionar um único plano. Em um aplicativo multilocatário de alta escala, você pode exceder esses limites e precisar implantar recursos adicionais do Serviço de Aplicativo para corresponder ao seu crescimento.
Quando partilha alguns dos seus recursos entre inquilinos, deve primeiro determinar o número de inquilinos que o recurso suporta, quando está configurado de acordo com os seus requisitos. Em seguida, implante quantos recursos forem necessários para atender ao número total de locatários.
Por exemplo, suponha que você implante um Gateway de Aplicativo do Azure como parte de uma solução SaaS multilocatário. Você revisa o design do aplicativo, testa o desempenho do gateway de aplicativo sob carga e revisa sua configuração. Em seguida, você determina que um único recurso de gateway de aplicativo pode ser compartilhado entre 100 clientes. De acordo com o plano de crescimento da sua organização, você espera integrar 150 clientes em seu primeiro ano, portanto, precisa planejar a implantação de vários gateways de aplicativos para atender à carga esperada.
No diagrama anterior, há dois gateways de aplicativo. O primeiro gateway é dedicado aos clientes de 1 a 100, e o segundo é dedicado aos clientes de 101 a 200.
Grupo de recursos e limites de subscrição
Quer trabalhe com recursos partilhados ou dedicados, é importante ter em conta os limites. O Azure limita o número de recursos que podem ser implantados em um grupo de recursos e em uma assinatura do Azure. À medida que se aproxima desses limites, você precisa planejar a escala em vários grupos de recursos ou assinaturas.
Por exemplo, suponha que você implante um gateway de aplicativo dedicado, para cada um de seus clientes, em um grupo de recursos compartilhados. Para alguns recursos, o Azure dá suporte à implantação de até 800 recursos do mesmo tipo em um único grupo de recursos. Portanto, quando você atingir esse limite, precisará implantar quaisquer novos gateways de aplicativos em outro grupo de recursos. No diagrama a seguir, há dois grupos de recursos. Cada grupo de recursos contém 800 gateways de aplicativos.
Locatários do pacote Bin em grupos de recursos e assinaturas
Você também pode aplicar o conceito de empacotamento de compartimento entre recursos, grupos de recursos e assinaturas. Por exemplo, quando você tem um pequeno número de locatários, pode implantar um único recurso e compartilhá-lo entre todos os seus locatários. O diagrama a seguir mostra o empacotamento de compartimentos em um único recurso.
À medida que você cresce, pode se aproximar do limite de capacidade para um único recurso e expandir para vários (R) recursos. O diagrama a seguir mostra o empacotamento de compartimentos em vários recursos.
Com o tempo, você pode atingir o limite do número de recursos em um único grupo de recursos e, em seguida, implantar vários (R) recursos em vários (G) grupos de recursos. O diagrama a seguir mostra o empacotamento de compartimentos em vários recursos, em vários grupos de recursos.
E à medida que você cresce ainda mais, você pode implantar em várias assinaturas (S), cada uma contendo vários (G) grupos de recursos com vários (R) recursos. O diagrama a seguir mostra o empacotamento de compartimentos em vários recursos, em vários grupos de recursos e assinaturas.
Ao planejar sua estratégia de expansão, você pode dimensionar para um número extremamente grande de locatários e manter um alto nível de carga.
Etiquetas
As tags de recursos permitem que você adicione metadados personalizados aos seus recursos do Azure, o que pode ser útil para gerenciamento e controle de custos. Para obter mais detalhes, consulte Alocar custos usando tags de recursos.
Antipadrões a evitar
- Não planejar a escala. Certifique-se de ter uma compreensão clara dos limites dos recursos que você implantará e quais limites podem se tornar importantes, à medida que sua carga ou número de locatários aumenta. Planeje como você implantará recursos adicionais à medida que dimensiona e teste o plano.
- Não planejando bin pack. Mesmo que você não precise crescer imediatamente, planeje dimensionar seus recursos do Azure em vários recursos, grupos de recursos e assinaturas ao longo do tempo. Evite fazer suposições no código do seu aplicativo, como a existência de um único recurso quando você pode precisar dimensionar para vários recursos no futuro.
- Dimensionamento de muitos recursos individuais. Se você tiver uma topologia de recursos complexa, pode ser difícil dimensionar componentes individuais, um a um. Muitas vezes, é mais simples dimensionar sua solução como uma unidade, seguindo o padrão de Selos de Implantação.
- Implantação de recursos isolados para cada locatário, quando não necessário. Em muitas soluções, é mais econômico e eficiente implantar recursos compartilhados para vários locatários.
- Usando locatários separados do Microsoft Entra. Em geral, não é aconselhável provisionar vários locatários do Microsoft Entra. O gerenciamento de recursos entre locatários do Microsoft Entra é complexo. É mais simples dimensionar entre assinaturas vinculadas a um único locatário do Microsoft Entra.
- Arquitetura excessiva quando você não precisa dimensionar. Em algumas soluções, você sabe com certeza que nunca crescerá além de um certo nível de escala. Nesses cenários, não há necessidade de criar uma lógica de dimensionamento complexa. No entanto, se sua organização planeja crescer, você precisará estar preparado para escalar — potencialmente a curto prazo.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Autor principal:
- John Downs - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
Outros contribuidores:
- Jason Beck - Brasil | Engenheiro de Clientes Sênior, FastTrack for Azure
- Bohdan Cherchyk - Brasil | Engenheiro de Clientes Sênior, FastTrack for Azure
- Laura Nicolas - Brasil | Engenheiro de Clientes Sênior, FastTrack for Azure
- Arsen Vladimirskiy - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
- Joshua Waddell - Brasil | Engenheiro de Clientes Sênior, FastTrack for Azure
Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.