Práticas recomendadas para o Serviço de Aplicativo do Azure

Artigo
01/10/2024

Este artigo resume as práticas recomendadas para usar o Serviço de Aplicativo do Azure.

Colocalização

Uma solução do Serviço de Aplicativo do Azure consiste em um aplicativo Web e um banco de dados ou conta de armazenamento para armazenar conteúdo ou dados. Quando estes recursos se encontram em regiões diferentes, a situação pode ter os seguintes efeitos:

Maior latência na comunicação entre recursos
Encargos monetários para transferência de dados de saída entre regiões, conforme observado na página de preços do Azure

O colocation é melhor para os recursos do Azure que compõem uma solução. Ao criar recursos, verifique se eles estão na mesma região do Azure, a menos que você tenha motivos comerciais ou de design específicos para que eles não estejam. Você pode mover um aplicativo do Serviço de Aplicativo para a mesma região do banco de dados usando o recurso de clonagem do Serviço de Aplicativo disponível nos planos do Serviço de Aplicativo Premium.

Fixação do certificado

A fixação de certificados é uma prática na qual um aplicativo permite apenas uma lista específica de autoridades de certificação (CAs) aceitáveis, chaves públicas, impressões digitais ou qualquer parte da hierarquia de certificados.

Os aplicativos nunca devem ter uma dependência rígida ou fixar no certificado TLS curinga (*.azurewebsites.net) padrão. O Serviço de Aplicativo é uma plataforma como serviço (PaaS), portanto, esse certificado pode ser alternado a qualquer momento. Se o serviço girar o certificado TLS curinga padrão, os aplicativos fixados em certificado interromperão e interromperão a conectividade de aplicativos codificados para um conjunto específico de atributos de certificado. A periodicidade com que o certificado é rodado também não é garantida porque a frequência de rotação pode mudar a qualquer momento.

Os aplicativos que dependem da fixação de certificados também não devem ter uma dependência rígida de um certificado gerenciado pelo Serviço de Aplicativo. Os certificados gerenciados do Serviço de Aplicativo podem ser alternados a qualquer momento, levando a problemas semelhantes para aplicativos que dependem de propriedades de certificado estáveis. É uma prática recomendada fornecer um certificado TLS personalizado para aplicativos que dependem da fixação de certificados.

Se seu aplicativo precisar confiar no comportamento de fixação de certificado, recomendamos que você adicione um domínio personalizado a um aplicativo Web e forneça um certificado TLS personalizado para o domínio. O aplicativo pode então confiar no certificado TLS personalizado para fixação de certificado.

Recursos de memória

Quando as recomendações de monitoramento ou serviço indicarem que um aplicativo consome mais memória do que o esperado, considere o recurso de recuperação automática do Serviço de Aplicativo. Você pode configurar a recuperação automática usando web.config.

Uma das opções para o recurso de recuperação automática é executar ações personalizadas com base em um limite de memória. As ações vão desde notificações por e-mail até investigação via despejo de memória e mitigação no local por meio da reciclagem do processo de trabalho.

Recursos da CPU

Quando as recomendações de monitoramento ou serviço indicarem que um aplicativo consome mais CPU do que o esperado ou que enfrenta picos repetidos de CPU, considere aumentar ou expandir o plano do Serviço de Aplicativo. Se o seu aplicativo tiver monitoração de estado, a expansão é a única opção. Se seu aplicativo for sem monitoração de estado, o dimensionamento oferece mais flexibilidade e maior potencial de escala.

Para obter mais informações sobre o dimensionamento do Serviço de Aplicativo e as opções de dimensionamento automático, consulte Dimensionar um aplicativo no Serviço de Aplicativo do Azure.

Recursos de soquete

Uma razão comum para esgotar as conexões TCP de saída é o uso de bibliotecas de cliente que não reutilizam conexões TCP ou que não usam um protocolo de nível superior, como HTTP keep-alive.

Analise a documentação de cada biblioteca à qual os aplicativos do seu plano do Serviço de Aplicativo fazem referência. Certifique-se de que as bibliotecas sejam configuradas ou acessadas em seu código para reutilização eficiente de conexões de saída. Siga também as orientações de documentação da biblioteca para a criação e liberação ou limpeza adequadas para evitar vazamentos de conexões. Enquanto essas investigações em bibliotecas de clientes estão em andamento, você pode reduzir o impacto dimensionando para várias instâncias.

Solicitações HTTP de nó.js e de saída

Quando você está trabalhando com Node.js e muitas solicitações HTTP de saída, lidar com HTTP keep-alive é importante. Você pode usar o pacote agentkeepalivenpm para facilitar o seu código.

Sempre manipule a http resposta, mesmo que você não faça nada no manipulador. Se você não manipular a resposta corretamente, seu aplicativo acabará ficando preso porque não há mais soquetes disponíveis.

Aqui está um exemplo de como lidar com a resposta quando você está trabalhando com o http pacote ou https :

const request = https.request(options, function(response) {
    response.on('data', function() { /* do nothing */ });
});

Se você estiver executando seu aplicativo do Serviço de Aplicativo em uma máquina Linux que tenha vários núcleos, outra prática recomendada é usar PM2 para iniciar vários processos .js nó para executar seu aplicativo. Você pode fazer isso especificando um comando de inicialização para seu contêiner.

Por exemplo, use este comando para iniciar quatro instâncias:

pm2 start /home/site/wwwroot/app.js --no-daemon -i 4

Backup de aplicativos

Os backups geralmente são executados de forma programada e exigem acesso ao armazenamento (para a saída dos arquivos de backup) e bancos de dados (para copiar e ler o conteúdo a ser incluído no backup). O resultado da falha no acesso a qualquer um desses recursos é uma falha de backup consistente.

Os dois motivos mais comuns pelos quais o backup do aplicativo falha são as configurações de armazenamento inválidas e a configuração inválida do banco de dados. Essas falhas geralmente acontecem após alterações nos recursos de armazenamento ou banco de dados, ou após alterações nas credenciais de acesso a esses recursos. Por exemplo, as credenciais podem ser atualizadas para o banco de dados selecionado nas configurações de backup.

Quando ocorrerem falhas de backup, revise os resultados mais recentes para entender que tipo de falha está acontecendo. Para falhas de acesso ao armazenamento, revise e atualize as configurações de armazenamento na configuração de backup. Para falhas de acesso ao banco de dados, revise e atualize suas cadeias de conexão como parte das configurações do aplicativo. Em seguida, prossiga para atualizar a configuração de backup para incluir corretamente os bancos de dados necessários.

Para obter mais informações sobre backups de aplicativos, consulte Fazer backup e restaurar seu aplicativo no Serviço de Aplicativo do Azure.

Aplicações em Node.js

A configuração padrão do Serviço de Aplicativo do Azure para aplicativos Node.js destina-se a melhor atender às necessidades dos aplicativos mais comuns. Se você quiser personalizar a configuração padrão para seu aplicativo Node.js para melhorar o desempenho ou otimizar o uso de recursos para CPU, memória ou recursos de rede, consulte Práticas recomendadas e guia de solução de problemas para aplicativos Node no Serviço de Aplicativo do Azure. Esse artigo descreve as configurações do iisnode que você pode precisar configurar para seu aplicativo Node.js. Ele também explica como resolver cenários ou problemas com seu aplicativo.

Dispositivos IoT

Você pode melhorar seu ambiente ao executar dispositivos de Internet das Coisas (IoT) conectados ao Serviço de Aplicativo.

Uma prática comum com dispositivos IoT é a fixação de certificados. Para evitar qualquer tempo de inatividade imprevisto devido a alterações nos certificados gerenciados do serviço, você nunca deve fixar certificados no certificado padrão *.azurewebsites.net ou em um certificado gerenciado pelo Serviço de Aplicativo. Se o seu sistema precisar confiar no comportamento de fixação de certificado, recomendamos que você adicione um domínio personalizado a um aplicativo Web e forneça um certificado TLS personalizado para o domínio. O aplicativo pode então confiar no certificado TLS personalizado para fixação de certificado. Para obter mais informações, consulte a seção de fixação de certificado deste artigo.

Para aumentar a resiliência em seu ambiente, não confie em um único ponto de extremidade para todos os seus dispositivos. Hospede seus aplicativos Web em pelo menos duas regiões para evitar um único ponto de falha e esteja pronto para failover de tráfego.

No Serviço de Aplicativo, você pode adicionar domínios personalizados idênticos a vários aplicativos Web, desde que esses aplicativos Web estejam hospedados em regiões diferentes. Esse recurso garante que, se você precisar fixar certificados, também poderá fixar no certificado TLS personalizado fornecido.

Outra opção é usar um balanceador de carga na frente dos aplicativos Web, como o Azure Front Door ou o Azure Traffic Manager, para garantir alta disponibilidade para seus aplicativos Web. Para obter mais informações, consulte Guia de início rápido: criar uma instância do Front Door para um aplicativo Web global altamente disponível ou Controlando o tráfego do Serviço de Aplicativo do Azure com o Gerenciador de Tráfego do Azure.

Próximos passos

Para obter práticas recomendadas acionáveis específicas para seu recurso, use o diagnóstico do Serviço de Aplicativo:

Aceda à sua aplicação Web no portal do Azure.
Abra o diagnóstico do Serviço de Aplicativo selecionando Diagnosticar e resolver problemas no painel esquerdo.
Selecione o bloco Práticas recomendadas .
Selecione Práticas recomendadas para disponibilidade e desempenho ou Práticas recomendadas para configuração ideal para exibir o estado atual do seu aplicativo em relação a essas práticas recomendadas.

Você também pode usar este link para abrir diretamente o diagnóstico do Serviço de Aplicativo para seu recurso: https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot.