O Serviço de Aplicativo do Azure é uma poderosa plataforma de hospedagem de aplicativos Web. O Azure Functions, criado com base na infraestrutura do Serviço de Aplicativo, permite que você crie facilmente cargas de trabalho de computação sem servidor e orientadas a eventos. Ambos os serviços são frequentemente usados em soluções multilocatário.
Recursos do Serviço de Aplicativo do Azure e do Azure Functions que oferecem suporte à multilocação
O Serviço de Aplicativo do Azure e o Azure Functions incluem muitos recursos que oferecem suporte à multilocação.
Nomes de domínio personalizados
O Serviço de Aplicativo do Azure permite que você use DNS curinga e adicione seus próprios certificados TLS curinga. Quando você usa subdomínios específicos do locatário, os certificados DNS e TLS curinga permitem que você dimensione facilmente sua solução para um grande número de locatários, sem exigir uma reconfiguração manual para cada novo locatário.
Ao usar nomes de domínio personalizados específicos do locatário, você pode ter um grande número de nomes de domínio personalizados que precisam ser adicionados ao seu aplicativo. Pode tornar-se complicado gerir muitos nomes de domínio personalizados, especialmente quando requerem certificados TLS individuais. O Serviço de Aplicativo fornece certificados TLS gerenciados, o que reduz o trabalho necessário quando você trabalha com domínios personalizados. No entanto, há limites a serem considerados, como quantos domínios personalizados podem ser aplicados a um único aplicativo.
Integração com o Azure Front Door
O Serviço de Aplicativo e o Azure Functions podem se integrar ao Azure Front Door, para atuar como o componente voltado para a Internet da sua solução. O Azure Front Door permite adicionar um firewall de aplicativo Web (WAF) e cache de borda, além de fornecer outras otimizações de desempenho. Você pode facilmente reconfigurar seus fluxos de tráfego para direcionar o tráfego para diferentes backends, com base em requisitos comerciais ou técnicos em mudança.
Ao usar o Azure Front Door com um aplicativo multilocatário, você pode usá-lo para gerenciar seus nomes de domínio personalizados e encerrar suas conexões TLS. Seu aplicativo do Serviço de Aplicativo é configurado com um único nome de host e todo o tráfego flui para esse aplicativo, o que ajuda a evitar o gerenciamento de nomes de domínio personalizados em vários locais.
Como no exemplo acima, o Azure Front Door pode ser configurado para modificar o cabeçalho da Host solicitação. O cabeçalho original Host enviado pelo cliente é propagado através do cabeçalho, e o código do X-Forwarded-Host aplicativo pode usar esse cabeçalho para mapear a solicitação para o locatário correto.
Aviso
Se o seu aplicativo enviar cookies ou respostas de redirecionamento, você precisa ter um cuidado especial. Alterações nos cabeçalhos Host da solicitação podem invalidar essas respostas. Para obter mais informações, consulte a prática recomendada de preservação de nome de host.
Você pode usar pontos de extremidade privados ou restrições de acesso ao Serviço de Aplicativo para garantir que o tráfego tenha fluído pela Front Door antes de chegar ao seu aplicativo.
Para obter mais informações sobre como usar o Azure Front Door em uma solução multilocatário, consulte Usar o Azure Front Door em uma solução multilocatária
Autenticação e autorização
O Serviço de Aplicativo do Azure pode validar tokens de autenticação em nome do seu aplicativo. Quando o Serviço de Aplicativo recebe uma solicitação, ele verifica se cada uma das seguintes condições é atendida:
- A solicitação contém um token.
- O token é válido.
- O pedido é autorizado.
Se alguma das condições não for atendida, o Serviço de Aplicativo poderá bloquear a solicitação ou redirecionar o usuário para seu provedor de identidade para que ele possa entrar.
Se seus locatários usarem a ID do Microsoft Entra como seu sistema de identidade, você poderá configurar o Serviço de Aplicativo do Azure para usar o ponto de extremidade /common para validar tokens de usuário. Isso garante que, independentemente do locatário do Microsoft Entra do usuário, seus tokens sejam validados e aceitos.
Você também pode integrar o Serviço de Aplicativo do Azure ao Azure AD B2C para autenticação de consumidores.
Mais informações:
- Autorização do Serviço de Aplicativo
- Configurar a autenticação em um aplicativo Web de exemplo usando o Azure AD B2C
- Trabalhando com identidades multilocatárias do Microsoft Entra
Restrições de acesso
Você pode restringir o tráfego para seu aplicativo usando restrições de acesso. Eles podem ser usados para especificar os intervalos de endereços IP ou as redes virtuais que têm permissão para se conectar ao aplicativo.
Ao trabalhar com uma solução multilocatário, esteja ciente do número máximo de regras de restrição de acesso. Por exemplo, se você precisar criar uma regra de restrição de acesso para cada locatário, poderá exceder o número máximo de regras permitidas. Se você precisar de um número maior de regras, considere implantar um proxy reverso como o Azure Front Door.
Modelos de isolamento
Ao trabalhar com um sistema multilocatário usando o Serviço de Aplicativo do Azure ou o Azure Functions, você precisa tomar uma decisão sobre o nível de isolamento que deseja usar. Consulte os modelos de locação a serem considerados para uma solução multilocatária e as orientações fornecidas nas abordagens arquitetônicas para computação em soluções multilocatário, para ajudá-lo a selecionar o melhor modelo de isolamento para seu cenário.
Ao trabalhar com o Serviço de Aplicativo do Azure e o Azure Functions, você deve estar ciente dos seguintes conceitos principais:
- No Serviço de Aplicativo do Azure, um plano representa sua infraestrutura de hospedagem. Um aplicativo representa um único aplicativo em execução nessa infraestrutura. Você pode implantar vários aplicativos em um único plano.
- No Azure Functions, sua hospedagem e seu aplicativo também são separados, mas você tem opções de hospedagem adicionais disponíveis para hospedagem elástica, onde o Azure Functions gerencia o dimensionamento para você. Para simplificar, nos referimos à infraestrutura de hospedagem como um plano ao longo deste artigo, porque os princípios descritos aqui se aplicam ao Serviço de Aplicativo e ao Azure Functions, independentemente do modelo de hospedagem usado.
A tabela a seguir resume as diferenças entre os principais modelos de isolamento de locação para o Serviço de Aplicativo do Azure e o Azure Functions:
| Consideração | Aplicações partilhadas | Aplicações por inquilino com planos partilhados | Planos por inquilino |
|---|---|---|---|
| Isolamento de configuração | Baixo | Média. As configurações no nível do aplicativo são dedicadas ao locatário, as configurações no nível do plano são compartilhadas | Elevada. Cada locatário pode ter sua própria configuração |
| Isolamento de desempenho | Baixo | Baixo-médio. Potencialmente sujeito a problemas de vizinhos barulhentos | Alto |
| Complexidade da implantação | Baixo | Médio | Alto |
| Complexidade operacional | Baixa | Alta | Alto |
| Custo dos recursos | Baixo | Baixo-alto dependendo da aplicação | Alto |
| Cenário de exemplo | Solução multilocatária grande com uma camada de aplicativo compartilhada | Migre aplicativos que não estão cientes da locação para o Azure enquanto ganha alguma eficiência de custos | Camada de aplicativo de locatário único |
Aplicações partilhadas
Você pode implantar um aplicativo compartilhado em um único plano e usar o aplicativo compartilhado para todos os seus locatários.
Esta tende a ser a opção mais eficiente em termos de custos e requer a menor sobrecarga operacional porque há menos recursos para gerir. Você pode dimensionar o plano geral com base na carga ou demanda, e todos os locatários que compartilham o plano se beneficiarão do aumento da capacidade.
É importante estar ciente das cotas e limites do Serviço de Aplicativo, como o número máximo de domínios personalizados que podem ser adicionados a um único aplicativo e o número máximo de instâncias de um plano que podem ser provisionadas.
Para poder usar esse modelo, o código do aplicativo deve ter reconhecimento de multilocação.
Aplicações por inquilino com planos partilhados
Você também pode optar por compartilhar seu plano entre vários locatários, mas implantar aplicativos separados para cada locatário. Isso fornece isolamento lógico entre cada locatário e essa abordagem oferece as seguintes vantagens:
- Eficiência de custos: Ao compartilhar sua infraestrutura de hospedagem, você geralmente pode reduzir seus custos gerais por locatário.
- Separação de configuração: o aplicativo de cada locatário pode ter seu próprio nome de domínio, certificado TLS, restrições de acesso e políticas de autorização de token aplicadas.
- Separação de atualizações: os binários de aplicativos de cada locatário podem ser atualizados independentemente de outros aplicativos no mesmo plano.
No entanto, como os recursos de computação do plano são compartilhados, os aplicativos podem estar sujeitos ao problema do vizinho barulhento. Além disso, há limites para quantos aplicativos podem ser implantados em um único plano.
Nota
Não use slots de implantação para locatários diferentes. Os slots não fornecem isolamento de recursos. Eles são projetados para cenários de implantação quando você precisa ter várias versões do seu aplicativo em execução por um curto período de tempo, como implantações azul-verde e uma estratégia de distribuição canária.
Planos por inquilino
O nível mais forte de isolamento é implantar um plano dedicado para um locatário. Esse plano dedicado garante que o locatário tenha pleno uso de todos os recursos do servidor alocados para esse plano.
Essa abordagem permite dimensionar sua solução para fornecer isolamento de desempenho para cada locatário e evitar o problema do vizinho barulhento. No entanto, também tem um custo mais elevado porque os recursos não são partilhados com vários inquilinos. Além disso, você precisa considerar o número máximo de planos que podem ser implantados em um único grupo de recursos do Azure.
Host APIs
Você pode hospedar APIs no Serviço de Aplicativo do Azure e no Azure Functions. Sua escolha de plataforma dependerá do conjunto de recursos específicos e das opções de dimensionamento de que você precisa.
Seja qual for a plataforma usada para hospedar sua API, considere usar o Gerenciamento de API do Azure na frente do seu aplicativo de API. O Gerenciamento de API fornece muitos recursos que podem ser úteis para soluções multilocatário, incluindo o seguinte:
- Um ponto centralizado para toda a autenticação. Isso pode incluir determinar o identificador do locatário a partir de uma declaração de token ou outros metadados de solicitação.
- Roteamento de solicitações para diferentes back-ends de API, que podem ser baseados no identificador de locatário da solicitação. Isso pode ser útil quando você hospeda vários carimbos de implantação, com seus próprios aplicativos de API independentes, mas você precisa ter uma única URL de API para todas as solicitações.
Networking e multilocação
Endereços IP
Muitos aplicativos multilocatários precisam se conectar às redes locais dos locatários para enviar dados.
Se você precisar enviar tráfego de saída de um endereço IP estático conhecido ou de um conjunto de endereços IP estáticos conhecidos, considere o uso de um gateway NAT. Para obter mais informações sobre como usar o Gateway NAT em soluções multilocatário, consulte Considerações sobre o Gateway NAT do Azure para multilocação. O Serviço de Aplicativo fornece orientação sobre como integrar com um Gateway NAT.
Se você não precisar de um endereço IP de saída estático, mas precisar verificar ocasionalmente o endereço IP que seu aplicativo usa para o tráfego de saída, poderá consultar os endereços IP atuais da implantação do Serviço de Aplicativo.
Quotas
Como o Serviço de Aplicativo é, em si, um serviço multilocatário, você precisa tomar cuidado com a forma como usa os recursos compartilhados. A rede é uma área à qual você precisa prestar especial atenção, porque há limites que afetam como seu aplicativo pode trabalhar com conexões de rede de entrada e saída, incluindo conversão de endereços de rede de origem (SNAT) e limites de porta TCP.
Se seu aplicativo se conectar a um grande número de bancos de dados ou serviços externos, seu aplicativo pode estar em risco de esgotamento da porta SNAT. Em geral, o esgotamento da porta SNAT indica que seu código não está reutilizando corretamente conexões TCP e, mesmo em uma solução multilocatário, você deve garantir que segue as práticas recomendadas para reutilizar conexões.
No entanto, em algumas soluções multilocatário, o número de conexões de saída para endereços IP distintos pode resultar em esgotamento da porta SNAT, mesmo quando você segue boas práticas de codificação. Nesses cenários, considere uma das seguintes opções:
- Implante o NAT Gateway para aumentar o número de portas SNAT disponíveis para uso do seu aplicativo. Para obter mais informações sobre como usar o Gateway NAT em soluções multilocatário, consulte Considerações sobre o Gateway NAT do Azure para multilocação.
- Use pontos de extremidade de serviço quando se conectar aos serviços do Azure para ignorar os limites do balanceador de carga.
Mesmo com esses controles em vigor, você pode abordar limites com um grande número de locatários, portanto, deve planejar dimensionar para planos adicionais do Serviço de Aplicativo ou carimbos de implantação.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Autor principal:
- John Downs - Brasil | Engenheiro de Software Principal
Outros contribuidores:
- Thiago Almeida - Brasil | Gestor de Programa Principal, Azure Functions
- 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
Recursos de revisão para arquitetos e desenvolvedores de soluções multilocatário.