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 criar facilmente cargas de trabalho de computação sem servidor e controladas por eventos. Ambos os serviços são usados com frequência em soluções multilocatário.
Recursos do Serviço de Aplicativo do Azure e do Azure Functions que dão suporte à multilocação
O Serviço de Aplicativo do Azure e o Azure Functions incluem muitos recursos que dão suporte à multilocação.
Nomes de domínio personalizados
O Serviço de Aplicativo do Azure permite usar o DNS curinga e adicionar seus próprios certificados TLS curinga. Ao usar subdomínios específicos do locatário, os certificados DNS e TLS curinga permitem dimensionar facilmente a 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, é possível ter um grande número de nomes de domínio personalizados que precisam ser adicionados ao seu aplicativo. Pode se tornar complicado gerenciar muitos nomes de domínio personalizados, especialmente quando eles exigem certificados TLS individuais. O Serviço de Aplicativo fornece certificados TLS gerenciados, o que reduz o trabalho necessário quando se lida 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 WAF (firewall do aplicativo Web) e cache de borda e fornece outras otimizações de desempenho. É possível reconfigurar facilmente os fluxos de tráfego para direcionar o tráfego para diferentes back-ends, com base na alteração de requisitos técnicos ou comerciais.
Ao usar o Azure Front Door com um aplicativo multilocatário, é possível usá-lo para gerenciar nomes de domínio personalizados e para encerrar conexões TLS. O aplicativo Serviço de Aplicativo é então configurado com um único nome do host e todo o tráfego flui por esse aplicativo, o que ajuda a evitar o gerenciamento de nomes de domínio personalizados em vários lugares.
Como no exemplo acima, o Azure Front Door pode ser configurado para modificar o Host cabeçalho da solicitação. O Host cabeçalho original enviado pelo cliente é propagado através do X-Forwarded-Host cabeçalho e o código do aplicativo pode usar esse cabeçalho para mapear a solicitação para o locatário correto.
Aviso
Se o aplicativo enviar cookies ou respostas de redirecionamento, será preciso tomar cuidados especiais. Alterações nos Host cabeçalhos da solicitação podem invalidar essas respostas. Para obter mais informações, confira a melhor prática de preservação do nome do host.
Você pode usar pontos de extremidade privados ou restrições de acesso do Serviço de Aplicativo para garantir que o tráfego tenha fluido pelo 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ário.
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 as seguintes condições são atendidas:
- A solicitação contém um token.
- O token é válido.
- A solicitação é autorizada.
Se qualquer uma 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 se conectar.
Se seus locatários usarem o Microsoft Entra ID como 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, os tokens dele sejam validados e aceitos.
Também é possível integrar o Serviço de Aplicativo do Azure ao Azure AD B2C para a autenticação de consumidores.
Para obter 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ário do Microsoft Entra
Restrições de acesso
É possível restringir o tráfego para seu aplicativo usando restrições de acesso. Elas podem ser usadas 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 atento ao número máximo de regras de restrição de acesso. Por exemplo, se for preciso criar uma regra de restrição de acesso para cada locatário, você poderá exceder o número máximo de regras permitidas. Se for preciso 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, é preciso tomar uma decisão sobre o nível de isolamento que você deseja usar. Veja os modelos de locação a serem considerados para uma solução multilocatário e as diretrizes fornecidas nas abordagens arquitetônicas para computação em soluções multilocatário, para ajuda para 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 atento aos 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, a hospedagem e o aplicativo também são separados, mas existem opções de hospedagem adicionais disponíveis para hospedagem elástica, nas quais o Azure Functions gerencia o dimensionamento para você. Para simplificar, nos referimos à infraestrutura de hospedagem como um plano ao longo deste artigo pois 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 | Aplicativos compartilhados | Aplicativos por locatário com planos compartilhados | Planos por locatário |
|---|---|---|---|
| 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 | Alto. Cada locatário pode ter sua própria configuração |
| Isolamento de desempenho | Baixo | Médio-baixo. Potencialmente sujeito a problemas de vizinhos barulhentos | Alto |
| Complexidade da implantação | Baixo | Médio | Alto |
| Complexidade operacional | Baixa | Alto | Alto |
| Custo de recurso | Baixo | Baixo-alto, dependendo do aplicativo | Alto |
| Cenário de exemplo | Grande solução multilocatário com uma camada de aplicativo compartilhada | Migre aplicativos que não estejam cientes da locação para o Azure e obtenha alguma economia | Nível de aplicativo de locatário único |
Aplicativos compartilhados
Você pode implantar um aplicativo compartilhado em um único plano e usar esse aplicativo para todos os seus locatários.
Essa tende a ser a opção mais econômica e requer a menor sobrecarga operacional visto que há menos recursos para gerenciar. É possível dimensionar o plano geral com base na carga ou na demanda e todos os locatários compartilhando o plano se beneficiarão do aumento da capacidade.
É importante estar atento às 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 multilocação.
Aplicativos por locatário com planos compartilhados
Também é possível 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 custo: ao compartilhar sua infraestrutura de hospedagem, geralmente é possível reduzir os custos gerais por locatário.
- Separação da configuração: cada aplicativo de 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 aplicados.
- Separação das atualizações: os binários de aplicativo de cada locatário podem ser atualizados independentemente dos 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.
Observação
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 nos quais é preciso ter várias versões do aplicativo em execução por um curto período de tempo, como implantações azul-verde e uma estratégia de distribuição canário.
Planos por locatário
O nível mais forte de isolamento é implantar um plano dedicado para um locatário. Esse plano dedicado garante que o locatário faça uso total 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, ela também tem um custo mais alto visto que os recursos não são compartilhados com vários locatários. Além disso, é preciso considerar o número máximo de planos que podem ser implantados em um único grupo de recursos do Azure.
Hospedar 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ífico e das opções de dimensionamento necessárias.
Seja qual for a plataforma usada para hospedar a API, considere usar o Gerenciamento de API do Azure na frente do 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 a determinação do identificador de locatário de uma declaração de token ou outros metadados de solicitação.
- Roteamento de solicitações para back-ends de API diferentes, que podem ser baseadas no identificador de locatário da solicitação. Isso pode ser útil quando você hospeda vários carimbos de implantação, com os próprios aplicativos de API independentes, mas precisa ter uma única URL de API para todas as solicitações.
Rede e multilocação
Endereços IP
Muitos aplicativos multilocatários precisam se conectar às redes locais dos locatários para enviar dados.
Se for preciso enviar o 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 usar um Gateway da NAT. Para obter mais informações sobre como usar o Gateway da NAT em soluções multilocatário, consulte Considerações sobre o Gateway da NAT do Azure para multilocação. O Serviço de Aplicativo fornece diretrizes sobre como se integrar a um Gateway da NAT.
Se não for preciso um endereço IP de saída estático, mas for preciso verificar ocasionalmente o endereço IP que seu aplicativo usa para o tráfego de saída, você pode consultar os endereços IP atuais da implantação do Serviço de Aplicativo.
Cotas
Como o Serviço de Aplicativo é um serviço multilocatário, é preciso tomar cuidado com o uso de recursos compartilhados. A rede é uma área na qual é preciso prestar atenção especial, pois há limites que afetam como o aplicativo pode funcionar com conexões de rede de entrada e saída, incluindo limites de SNAT (conversão de endereços de rede de origem) e porta TCP.
Se o aplicativo se conectar a um grande número de bancos de dados ou serviços externos, ele poderá correr o risco de esgotamento da porta SNAT. Em geral, o esgotamento da porta SNAT indica que o código não está reutilizando corretamente conexões TCP e, mesmo em uma solução multilocatário, é preciso se garantir de seguir 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 com 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 o uso de uma das seguintes opções:
- Implantar o Gateway da NAT para aumentar o número de portas SNAT disponíveis para o aplicativo usar. Para obter mais informações sobre como usar o Gateway da NAT em soluções multilocatário, consulte Considerações sobre o Gateway da NAT do Azure para multilocação.
- Usar pontos de extremidade de serviço ao se conectar aos serviços do Azure para ignorar os limites do balanceador de carga.
Mesmo com esses controles em vigor, é possível se aproximar dos limites com um grande número de locatários, portanto, você deve planejar dimensionar para planos do Serviço de Aplicativo adicionais ou carimbos de implantação.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Autor principal:
- John Downs | Engenheiro de software principal
Outros colaboradores:
- Thiago Almeida | Gerente de programa principal, Azure Functions
- Arsen Vladimirskiy | Engenheiro principal de atendimento ao cliente, FastTrack for Azure
Para ver perfis não públicos do LinkedIn, entre no LinkedIn.
Próximas etapas
Examine os Recursos para arquitetos e desenvolvedores de soluções multilocatário.