Aplicativo Web de várias regiões altamente disponível

Este exemplo de arquitetura se baseia na arquitetura de exemplo de aplicativo Web básico e a estende para mostrar:

• Práticas comprovadas para melhorar a escalabilidade e o desempenho em um aplicativo Web do Serviço de Aplicativo do Azure
• Saiba como executar um aplicativo do Serviço de Aplicativo do Azure em várias regiões para obter alta disponibilidade.

Arquitetura

Baixe um Arquivo Visio dessa arquitetura.

Workflow

Esse fluxo de trabalho inclui os aspectos de várias regiões da arquitetura e utiliza o aplicativo Web básico.

• Regiões primárias e secundárias. Essa arquitetura usa duas regiões para obter alta disponibilidade. O aplicativo está implantado em cada região. Durante as operações normais, o tráfego de rede é roteado para a região primária. Se a região primária ficar indisponível, o tráfego será roteado para a região secundária.
• Front Door. O Azure Front Door é o balanceador de carga recomendado para implementações de várias regiões. Ele se integra ao WAF (Firewall de Aplicativo Web) como proteção contra explorações comuns e usa a funcionalidade de cache de conteúdo nativo do Front Door. Nessa arquitetura, o Front Door é configurado para roteamento prioritário, que envia todo o tráfego para a região primária, a menos que se torne indisponível. Se a região primária se tornar indisponível, o Front Door roteará todo o tráfego para a região secundária.
• Replicação geográfica de Contas de Armazenamento, Banco de Dados SQL e/ou Azure Cosmos DB.

Componentes

Principais tecnologias usadas para implementar essa arquitetura:

• O Microsoft Entra ID é um serviço de gerenciamento de identidade e acesso baseado em nuvem que permite aos funcionários acessar aplicativos em nuvem desenvolvidos para sua organização.
• O DNS do Azure é um serviço de hospedagem para domínios DNS, fornecendo resolução de nomes usando a infraestrutura do Microsoft Azure. Ao hospedar seus domínios no Azure, você pode gerenciar seus registros DNS usando as mesmas credenciais, APIs, ferramentas e cobrança que seus outros serviços do Azure. Para usar um nome de domínio personalizado (como contoso.com), crie registros DNS que mapeiem o nome de domínio personalizado para o endereço IP. Para obter mais informações, consulte Configurar um nome de domínio personalizado no Serviço de Aplicativo do Azure.
• A Rede de Distribuição de Conteúdo do Azure é uma solução global para entrega de conteúdo de largura de banda alta, armazenando-o em cache em nós dispostos fisicamente de forma estratégica em todo o mundo.
• O Azure Front Door é um balanceador de carga de camada 7. Nessa arquitetura, ele roteia as solicitações HTTP para o front-end da web. Front door também fornece um firewall do aplicativo Web (WAF) que protege o aplicativo contra vulnerabilidades e explorações comuns. O Front Door também é usado para uma solução de Rede de Entrega de Conteúdo (CDN) neste projeto.
• O Azure AppService é uma plataforma totalmente gerenciada para criar e implantar aplicativos de nuvem. Ele permite definir um conjunto de recursos de computação para um aplicativo Web executar, implantar aplicativos Web e configurar slots de implantação.
• Os Aplicativos de Função do Azure podem ser usados para executar tarefas em segundo plano. As funções são invocadas por um gatilho, como um evento de temporizador ou uma mensagem sendo colocada na fila. Para tarefas com estado de longa execução, use Funções Duráveis.
• O Armazenamento do Azure é uma solução de armazenamento em nuvem para cenários modernos de armazenamento de dados, oferecendo armazenamento altamente disponível, extremamente escalonável, durável e seguro para vários objetos de dados na nuvem.
• O Cache do Azure para Redis é um serviço de cache de alto desempenho que fornece um armazenamento de dados na memória para agilizar a recuperação de dados, com base no cache Redis de implementação de código aberto.
• O Banco de Dados SQL do Azure é um banco de dados como serviço relacional na nuvem. O Banco de Dados SQL compartilha a sua base de código com o mecanismo do banco de dados do Microsoft SQL Server.
• O Azure Cosmos DB é um banco de dados distribuído de forma global, totalmente gerenciado, de baixa latência, multimodelo e com várias APIs de consulta para gerenciar dados em grande escala.
• É possível usar o Azure Cognitive Search para adicionar funcionalidade de pesquisa como sugestões de pesquisa, pesquisa difusa e pesquisa específica de idioma. O Azure Search normalmente é usado junto com outro armazenamento de dados, especialmente se o armazenamento de dados primário exigir consistência estrita. Nessa abordagem, armazene dados autoritativos em outro armazenamento de dados e o índice de pesquisa no Azure Search. O Azure Search também pode ser usado para consolidar um único índice de pesquisa de vários armazenamentos de dados.

Detalhes do cenário

Há várias abordagens gerais para alcançar alta disponibilidade em várias regiões:

• Ativo/Passivo com espera ativa: o tráfego vai para uma região, enquanto o outro aguarda em espera ativa. A espera ativa significa que o Serviço de Aplicativo na região secundária está alocado e sempre em execução.

• Ativo/Passivo com espera passiva: o tráfego vai para uma região, enquanto o outro aguarda em espera passiva. Espera passiva significa que o Serviço de Aplicativo na região secundária não é alocado até ser necessário para o failover. Essa abordagem custa menos para ser executada, mas geralmente leva mais tempo para ficar online durante uma falha.

• Ativo/Ativo: ambas as regiões ficam ativas e a carga das solicitações é balanceada entre elas. Se uma região ficar indisponível, ela será retirada da rotação.

Esta referência se concentra em ativo/passivo com espera ativa. Para obter informações sobre como criar soluções que usam as outras abordagens, consulte Abordagens de aplicativo do Serviço de Aplicativo de várias regiões para recuperação de desastre.

Possíveis casos de uso

Esses casos de uso podem se beneficiar de uma implantação de várias regiões:

• Projetar um plano de continuidade dos negócios e recuperação de desastre para aplicativos LoB.

• Implantar aplicativos de missão crítica executados no Windows ou Linux.

• Melhorar a experiência do usuário ao manter aplicativos disponíveis.

Recomendações

Seus requisitos podem ser diferentes dos requisitos da arquitetura descrita aqui. Use as recomendações nesta seção como um ponto inicial.

Emparelhamento regional

Muitas regiões do Azure são emparelhadas com outra região dentro da mesma geografia. Algumas regiões não têm uma região emparelhada. Para saber mais sobre pares regionais, consulte Continuidade dos negócios e recuperação de desastres (BCDR): Regiões Emparelhadas do Azure.

Se sua região primária tiver um par, considere usar a região emparelhada como sua região secundária (por exemplo, Leste dos EUA 2 e EUA Central). Os benefícios disso incluem:

• Se houver uma interrupção ampla, a prioridade será recuperar pelo menos uma região em cada par.
• As atualizações planejadas do sistema do Azure são distribuídas em regiões emparelhadas sequencialmente para minimizar o possível tempo de inatividade.
• Na maioria dos casos, pares regionais residem na mesma geografia para atender aos requisitos de residência de dados.

Se sua região primária não tiver um par, considere os seguintes fatores ao selecionar uma região secundária:

• Minimize a latência selecionando regiões geograficamente próximas aos usuários.
• Atenda aos seus requisitos de residência de dados selecionando regiões que estão em regiões geográficas nas quais você pode armazenar e processar dados.

Se suas regiões estiverem emparelhadas ou não, verifique se ambas as regiões dão suporte a todos os serviços do Azure necessários para seu aplicativo. Confira Serviços por região.

Grupos de recursos

Considere colocar a região primária, a região secundária e o Front Door em grupos de recursos separados. Esta alocação permite gerenciar os recursos implantados para cada região como uma única coleção.

Aplicativos do Serviço de Aplicativo

É recomendável criar o aplicativo Web e a API web como aplicativos separados do Serviço de Aplicativo. Esse design permite que você o execute em planos de Serviço de Aplicativo separados, portanto eles podem ser dimensionados de forma independente. Se você não precisar desse nível de escalabilidade inicialmente, poderá implantar os aplicativos no mesmo plano e movê-los para planos separados posteriormente, se necessário.

Configuração do Front Door

Roteamento. O Front Door dá suporte a vários mecanismos de roteamento. Para o cenário descrito neste artigo, use o roteamento prioritário. Com essa configuração, o Front Door envia todas as solicitações para a região primária, a menos que o ponto de extremidade para essa região fique inacessível. Nesse ponto, ele automaticamente faz failover para a região secundária. Defina o pool de origem com valores de prioridade distintos, sendo 1 para a região ativa e 2 ou superior para a região em espera ou passiva.

Investigação de integridade. O Front Door usa uma investigação HTTP para monitorar a disponibilidade de cada back-end. A investigação fornece ao Front Door um teste aprovado/reprovado para realizar o failover para a região secundária. Ele funciona com o envio de uma solicitação para um caminho de URL especificado. Se ele obtiver uma resposta não 200 dentro de um período de tempo limite, o teste falhará. Você pode configurar a frequência de investigação de integridade, o número de exemplos necessários para avaliação e o número de exemplos com êxito requisitados para que a origem seja marcada como íntegra. Se o Front Door marcar a origem como degradada, ele fará failover para a outra origem. Para obter detalhes, confira Investigações de Integridade.

Como prática recomendada, crie um caminho de investigação de integridade na origem do aplicativo que relate a integridade geral do aplicativo. O ponto de extremidade deve verificar dependências críticas, como aplicativos do Serviço de Aplicativo, a fila de armazenamento e o Banco de Dados SQL. Caso contrário, a investigação poderá relatar uma origem íntegra quando, na verdade, partes essenciais do aplicativo estejam com falha. Por outro lado, não use a investigação de integridade para verificar os serviços de baixa prioridade. Por exemplo, se um serviço de email ficar inativo, o aplicativo poderá mudar para um segundo provedor ou apenas enviar emails mais tarde. Para obter mais discussões sobre esse padrão de design, confira Padrão de Monitoramento de Ponto de Extremidade de Integridade.

Proteger as origens da internet é parte essencial da implementação de um aplicativo acessível publicamente. Consulte a Implementação de entrada segura de rede para conhecer os padrões de design e implementação recomendados pela Microsoft para proteger as comunicações de entrada do seu aplicativo com o Front Door.

CDN. Use a funcionalidade CDN nativa do Front Door para armazenar em cache conteúdo estático. A principal vantagem de uma CDN é reduzir a latência para os usuários, porque o conteúdo é armazenado em cache em um servidor de borda geograficamente próximo do usuário. A CDN também pode reduzir a carga no aplicativo, porque esse tráfego não está sendo tratado pelo aplicativo. O Front Door também oferece aceleração dinâmica de sites, permitindo que você ofereça uma melhor experiência geral do usuário para seu aplicativo Web do que seria disponibilizado apenas com cache de conteúdo estático.

Banco de Dados SQL

Use a replicação geográfica ativa e grupos de failover automático para tornar seus bancos de dados resilientes. A replicação geográfica ativa permite replicar seus bancos de dados da região primária em uma ou mais (até quatro) outras regiões. Os grupos de failover automático se baseiam na replicação geográfica ativa, permitindo que você faça failover para um banco de dados secundário sem alterações de código em seus aplicativos. É possível executar failovers manual ou automaticamente, de acordo com as definições de política criadas por você. Para usar grupos de failover automático, configure suas cadeias de conexão com a cadeia de conexão de failover criada automaticamente para o grupo de failover, em vez das cadeias de conexão dos bancos de dados individuais.

Azure Cosmos DB

O Azure Cosmos DB dá suporte à replicação geográfica entre regiões no padrão ativo-ativo com várias regiões de gravação. Como alternativa, você pode designar uma região como a região gravável e outras como réplicas somente leitura. Se houver uma interrupção regional, será possível fazer failover selecionando outra região para ser a região de gravação. O SDK do cliente envia automaticamente solicitações de gravação para a região de gravação atual, portanto você não precisa atualizar a configuração do cliente após um failover. Para obter mais informações, confira Distribuição de dados global com o Azure Cosmos DB.

Armazenamento

Para o Armazenamento do Azure, use RA-GRS armazenamento com redundância geográfica com acesso de leitura. Com o armazenamento de RA-GRS, os dados são replicados para uma região secundária. Você tem acesso somente leitura aos dados na região secundária por meio de um ponto de extremidade separado. O failover iniciado pelo usuário para a região secundária tem suporte para contas de armazenamento replicadas geograficamente. Iniciar um failover de conta de armazenamento atualiza automaticamente os registros DNS para tornar a conta de armazenamento secundária a nova conta de armazenamento principal. Os failovers só deverão ser realizados quando você considerar necessário. Esse requisito é definido pelo plano de recuperação de desastre da sua organização e você deve considerar as implicações conforme descrito na seção Considerações a seguir.

Se houver uma interrupção ou desastre regional, a equipe do Armazenamento do Azure poderá decidir executar um failover geográfico para a região secundária. Para esses tipos de failovers, não é necessária uma ação do cliente. O failback para a região primária também é gerenciado pela equipe de armazenamento do Azure nesses casos.

Em alguns casos, a replicação de objetos para blobs de bloco será uma solução de replicação suficiente para sua carga de trabalho. Esse recurso de replicação permite copiar blobs de blocos individuais da conta de armazenamento principal para uma conta de armazenamento na região secundária. Os benefícios dessa abordagem são um controle granular sobre os dados replicados. Você pode definir uma política de replicação para um controle mais granular dos tipos de blobs de bloco que são replicados. Exemplos de definições de política incluem, mas não estão limitados a:

• Somente os blobs de bloco adicionados após a criação da política são replicados
• Somente os blobs de bloco adicionados após uma data e uma hora específicas são replicados
• Somente blobs de bloco correspondentes a um certo prefixo são replicados.

O armazenamento em fila é referenciado como uma opção de mensagens alternativa ao Barramento de Serviço do Azure para esse cenário. No entanto, se você usar o armazenamento em fila para sua solução de mensagens, as diretrizes fornecidas acima em relação à replicação geográfica se aplicarão aqui, pois o armazenamento em fila reside em contas de armazenamento. É importante entender, contudo, que as mensagens não são replicadas para a região secundária e seu estado é indissociável da região.

Barramento de Serviço do Azure

Para aproveitar a maior resiliência oferecida pelo Barramento de Serviço do Azure, use a camada premium para seus namespaces. A camada premium faz uso de zonas de disponibilidade, o que torna seus namespaces resilientes a interrupções de datacenter. Se houver um desastre generalizado afetando vários datacenters, o recurso de recuperação de desastres geográficos incluído na camada premium poderá ajudá-lo na recuperação. O recurso de recuperação de desastres geográficos garante que toda a configuração de um namespace (filas, tópicos, assinaturas e filtros) seja replicada continuamente de um namespace primário para um namespace secundário quando emparelhado. Ele permite que você inicie uma movimentação de failover única do primário para o secundário a qualquer momento. A movimentação de failover reapontará para o namespace secundário o nome do alias escolhido para o namespace e, depois, interromperá o emparelhamento. O failover é quase instantâneo depois de iniciado.

Azure Cognitive Search

No Cognitive Search, a disponibilidade é atingida usando várias réplicas, enquanto a continuidade dos negócios e a BCDR (recuperação de desastre) é atingida por meio de vários serviços de pesquisa.

No Cognitive Search, as réplicas são cópias do seu índice. Ter várias réplicas permite que o Azure Cognitive Search faça reinicializações e manutenção do computador em uma réplica, enquanto a execução da consulta continua em outras réplicas. Para obter mais informações sobre como adicionar réplicas, consulte Adicionar ou reduzir réplicas e partições.

Você pode utilizar Zonas de Disponibilidade com a Pesquisa Cognitiva do Azure, adicionando duas ou mais réplicas ao serviço de pesquisa. Cada réplica será colocada em uma zona de disponibilidade diferente dentro da região.

Para obter considerações sobre BCDR, consulte a documentação Vários serviços em regiões geográficas separadas.

Cache do Azure para Redis

Embora todas as camadas do Cache do Azure para Redis ofereçam replicação padrão para alta disponibilidade, a camada Premium ou Enterprise é recomendável para fornecer um nível mais alto de resiliência e capacidade de recuperação. Analise a Alta disponibilidade e recuperação de desastre para obter uma lista completa de recursos e opções de resiliência e capacidade de recuperação para esses níveis. Seus requisitos de negócios determinarão a camada mais adequada para sua infraestrutura.

Considerações

Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Confiabilidade

A confiabilidade garante que seu aplicativo possa cumprir os compromissos que você assume com seus clientes. Para obter mais informações, confira Visão geral do pilar de confiabilidade. Considere esses pontos ao projetar para alta disponibilidade entre regiões.

Porta da frente do Azure

O Azure Front Door fará failover automaticamente se a região principal ficar indisponível. Quando o Front Door faz failover, há um período (em geral, de 20 a 60 segundos) em que os clientes não podem acessar o aplicativo. A duração é afetada pelos seguintes fatores:

• Frequência de investigações de integridade. Quanto maior a frequência de envio das investigações de integridade, mais rápido o Front Door poderá detectar o tempo de inatividade ou a origem para voltar a ficar íntegro.
• Configuração de tamanho de exemplo. Essa configuração controla quantos exemplos são necessários para que a investigação de integridade detecte que a origem primária se tornou inacessível. Se esse valor for muito baixo, você poderá obter falsos positivos de problemas intermitentes.

O Front Door é um possível ponto de falha no sistema. Se o serviço falhar, os clientes não poderão acessar o aplicativo durante o tempo de inatividade. Examine o SLA (contrato de nível de serviço) do Front Door e determine se usar apenas o Front Door atende aos seus requisitos de negócios para alta disponibilidade. Caso contrário, considere adicionar outra solução de gerenciamento de tráfego como um fallback. Caso o serviço do Front Door falhe, altere os registros CNAME (nome canônico) no DNS para apontar para outro serviço de gerenciamento de tráfego. Esta etapa deve ser executada manualmente e seu aplicativo estará indisponível até que as alterações de DNS sejam propagadas.

As camadas Standard e Premium do Azure Front Door associam os recursos do Azure Front Door (clássico), do Azure CDN Standard da Microsoft (clássico) e do Azure WAF em uma única plataforma. Usar o Azure Front Door Standard ou Premium reduz os pontos de falha e permite controle, monitoramento e segurança aprimorados. Para obter mais informações, consulte Visão geral da camada do Azure Front Door.

Banco de Dados SQL

O RPO (objetivo de ponto de recuperação) e o RTO (tempo de recuperação estimado) para o Banco de Dados SQL estão documentados na Visão geral de continuidade de negócios com o Banco de Dados SQL do Azure.

Lembre-se de que a replicação geográfica ativa efetivamente dobra o custo de cada banco de dados replicado. Em geral, bancos de dados de área restrita, teste e desenvolvimento não são recomendados para replicação.

Azure Cosmos DB

O RPO e o RTO (objetivo de tempo de recuperação) para o Azure Cosmos DB são configuráveis por meio dos níveis de consistência usados, que fornecem compensações entre disponibilidade, durabilidade de dados e taxa de transferência. O Azure Cosmos DB fornece um RTO mínimo de 0 para um nível de consistência relaxado com vários mestres ou um RPO de 0 para consistência forte com um único mestre. Para saber mais sobre os níveis de consistência do Azure Cosmos DB, confira Níveis de consistência e durabilidade de dados no Azure Cosmos DB.

Armazenamento

O armazenamento RA-GRS é durável, mas convém incluir os seguintes fatores ao considerar a execução de um failover:

• Antecipar a perda de dados: a replicação de dados para a região secundária é executada de forma assíncrona. Portanto, se um failover geográfico for executado, preveja perda de dados se as alterações na conta principal não forem totalmente sincronizadas com a conta secundária. Você pode verificar a propriedade Última Hora de Sincronização da conta de armazenamento secundária para ver a última vez que os dados da região primária foram gravados com êxito na região secundária.

• Planeje seu RTO (objetivo de tempo de recuperação) em conformidade: o failover para a região secundária normalmente leva cerca de uma hora, portanto, seu plano de recuperação de desastres deve levar essas informações em consideração ao calcular seus parâmetros RTO.

• Planeje seu failback cuidadosamente: é importante entender que, quando uma conta de armazenamento faz failover, os dados na conta principal original são perdidos. É arriscado tentar um failback para a região primária sem um planejamento cuidadoso. Após a conclusão do failover, o novo primário - na região de failover - será configurado para LRS (armazenamento localmente redundante). Você deve reconfigurá-lo manualmente como armazenamento replicado geograficamente para iniciar a replicação para a região primária e, depois, dar tempo suficiente para permitir que as contas sejam sincronizadas.

• Falhas transitórias, como uma interrupção da rede, não disparam um failover de armazenamento. Projete seu aplicativo para ser resiliente a falhas transitórias. As opções de mitigação incluem:

  • Ler de uma região secundária.
  • Alternar temporariamente para outra conta de armazenamento para novas operações de gravação (por exemplo, para colocar mensagens na fila).
  • Copiar dados da região secundária para outra conta de armazenamento.
  • Fornecer funcionalidade reduzida até a conclusão do failback do sistema.

Para obter mais informações, consulte O que fazer se ocorrer uma interrupção do Armazenamento do Azure.

Consulte a documentação pré-requisitos e advertências para replicação de objeto para obter considerações ao usar a replicação de objeto para blobs de bloco.

Barramento de Serviço do Azure

É importante entender que o recurso de recuperação de desastres geográficos incluído na camada premium do Barramento de Serviço do Azure permite a continuidade instantânea das operações com a mesma configuração. No entanto, ele não replica as mensagens mantidas em filas ou assinaturas de tópicos ou filas de mensagens mortas. Assim, uma estratégia de mitigação é necessária para garantir um failover suave para a região secundária. Para obter uma descrição detalhada de outras considerações e estratégias de mitigação, consulte a documentação de pontos importantes a serem considerados e considerações sobre recuperação de desastre.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira Visão geral do pilar de segurança.

Restringir o tráfego de entrada Configure o aplicativo para aceitar o tráfego somente do Front Door. Isso garante que todo o tráfego passe pelo WAF antes de chegar ao aplicativo. Para obter mais informações, confira Como bloquear o acesso ao meu back-end no Azure Front Door?

CORS (Compartilhamento de Recursos entre Origens) Se você criar um site e a CORS Web como aplicativos separados, o site não poderá fazer chamadas API no lado do cliente para a AJAX, a menos que você habilite o CORS.

Os Serviços de Aplicativos têm suporte interno para o CORS, sem precisar escrever nenhum código de aplicativo. Consulte Consumir um aplicativo de API do JavaScript usando CORS. Adicione o site à lista de origens permitidas para API.

Criptografia do Banco de Dados SQL Use Transparent Data Encryption se você precisa criptografar dados em repouso no banco de dados. Esse recurso executa criptografia em tempo real e descriptografia de um banco de dados inteiro (incluindo backups e arquivos de log de transações) e não requer alterações no aplicativo. A criptografia causa certa latência, portanto, é uma prática recomendada separar os dados que devem ser protegidos em seu próprio banco de dados e habilitar a criptografia apenas para ele.

Identidade Ao definir identidades para os componentes dessa arquitetura, use identidades gerenciadas pelo sistema sempre que possível para reduzir a necessidade de gerenciar credenciais e os riscos inerentes ao gerenciamento de credenciais. Onde não for possível usar identidades gerenciadas pelo sistema, certifique-se de que cada identidade gerenciada pelo usuário exista em apenas uma região e nunca seja compartilhada entre os limites da região.

Firewalls de serviço Ao configurar os firewalls de serviço para os componentes, certifique-se de que apenas os serviços locais de região tenham acesso aos serviços e que os serviços só permitam conexões de saída, o que é explicitamente necessário para a replicação e a funcionalidade do aplicativo. Considere usar o Link Privado do Azure para ter maior controle e segmentação. Para obter mais informações sobre como proteger aplicativos Web, consulte Aplicativo Web com redundância de zona altamente disponível de linha de base.

Otimização de custo

A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

Cache Use o cache para reduzir a carga em servidores que fornecem conteúdo que não muda com frequência. Cada ciclo de renderização de uma página pode afetar o custo porque consome computação, memória e largura de banda. Esses custos podem ser reduzidos significativamente usando o cache, especialmente para serviços de conteúdo estático, como aplicativos JavaScript de página única e conteúdo de streaming de mídia.

Se o seu aplicativo tiver conteúdo estático, use CDN para diminuir a carga nos servidores front-end. Para dados que não são alterados com frequência, use o Cache do Azure para Redis.

Estado Aplicativos sem estado configurados para dimensionamento automático são mais econômicos do que aplicativos com estado. Para um aplicativo ASP.NET que usa o estado de sessão, armazene-o na memória com o Cache do Azure para Redis. Para obter mais informações, confira Provedor de estado de sessão ASP.NET para o Cache do Azure para Redis. Outra opção é usar o Azure Cosmos DB como um repositório de estado de back-end por meio de um provedor de estado de sessão. Confira Usar o Azure Cosmos DB como um estado de sessão de ASP.NET e um provedor de cache.

Functions Considere colocar um aplicativo de funções em um plano de Serviço de Aplicativo dedicado para que as tarefas em segundo plano não sejam executadas nas mesmas instâncias que lidam com solicitações HTTP. Se as tarefas em segundo plano forem executadas de maneira intermitente, considere o uso de um plano de consumo, que é cobrado com base na quantidade de execuções e recursos usados, e não por hora.

Para obter mais informações, confira a seção de custo em Estrutura Bem Projetada do Microsoft Azure.

Use a calculadora de preços para estimar os custos. Essas recomendações nesta seção podem ajudá-lo a reduzir o custo.

Porta da frente do Azure

A cobrança do Azure Front Door tem três camadas de preços: transferências de dados de saída, transferências de dados de entrada e regras de roteamento. Para obter mais informações, confira Preços do Azure Front Door. O gráfico de preços não inclui o custo de acessar dados dos serviços de origem e transferir para o Front Door. Esses custos são cobrados com base nos preços de transferência de dados descritos em Detalhes de preços de largura de banda.

Azure Cosmos DB

Há dois fatores que determinam os preços do Azure Cosmos DB:

• A taxa de transferência provisionada ou RU/s (Unidades de Solicitação por segundo).

  Há dois tipos de taxa de transferência que podem ser provisionados no Azure Cosmos DB, padrão e dimensionamento automático. A taxa de transferência padrão aloca os recursos necessários para garantir as RU/s especificadas. Para dimensionamento automático, você provisiona a taxa de transferência máxima e o Azure Cosmos DB aumenta ou reduz instantaneamente dependendo da carga, com um mínimo de 10% da taxa de transferência máxima de dimensionamento automático. A taxa de transferência padrão é cobrada pela taxa de transferência provisionada por hora. A taxa de transferência de dimensionamento automático é cobrada pela taxa de transferência máxima consumida por hora.

• Armazenamento consumido. Você será cobrado uma taxa fixa para a quantidade total de armazenamento (GBs) consumida em dados e para os índices de uma hora específica.

Para obter mais informações, confira a seção de custo em Estrutura Bem Projetada do Microsoft Azure.

Eficiência de desempenho

Um grande benefício do Serviço de Aplicativo do Azure é a capacidade de dimensionar o aplicativo com base na carga. Aqui estão algumas considerações para ter em mente ao planejar dimensionar seu aplicativo.

Aplicativo de Serviço de Aplicativo

Se sua solução inclui vários aplicativos do Serviço de Aplicativo, considere implantá-los em planos de Serviço de Aplicativo separados. Essa abordagem permite redimensioná-los independentemente por serem executados em instâncias separadas.

Banco de Dados SQL

Aumente a escalabilidade de um banco de dados SQL fragmentando o banco de dados. Fragmentação refere-se ao particionamento horizontal do banco de dados. A fragmentação permite escalar horizontalmente o banco de dados usando as ferramentas de Banco de Dados Elástico. As possíveis vantagens da fragmentação são:

• Melhor taxa de transferência de transações.
• Consultas podem ser executadas mais rapidamente em um subconjunto dos dados.

Porta da frente do Azure

O Front Door pode realizar o descarregamento de SSL e também reduz o número total de conexões TCP com o aplicativo Web de back-end. Isso melhora a escalabilidade porque o aplicativo Web gerencia um volume menor de handshakes SSL e conexões TCP. Esses ganhos de desempenho se aplicam mesmo se você encaminhar as solicitações para o aplicativo Web como HTTPS, devido ao alto nível de reutilização da conexão.

Azure Search

O Azure Search remove a sobrecarga de execução de pesquisas de dados complexas de armazenamento de dados primário, podendo ser dimensionado para lidar com a carga. Consulte Dimensionar os níveis de recursos para cargas de trabalho de consulta e indexação no Azure Search.

Excelência operacional

A excelência operacional refere-se aos processos operacionais que implantam um aplicativo e o mantêm em execução na produção. Ela é uma extensão da orientação Well-Architected Framework Reliability. Esta orientação fornece uma visão geral detalhada da arquitetura de resiliência em sua estrutura de aplicativos para garantir que suas cargas de trabalho estejam disponíveis e possam se recuperar de falhas em qualquer escala. Um princípio básico dessa abordagem é criar sua infraestrutura de aplicativos para ser altamente disponível, de forma otimizada em várias regiões geográficas, como ilustra esse design.

Próximas etapas

• Mergulhe em Azure Front Door - métodos de roteamento de tráfego

• Criar investigações de integridade que relatam a integridade geral do aplicativo com base nos padrões de monitoramento de ponto de extremidade

• Habilitar grupos de failover automático do SQL do Azure

• Garanta a continuidade dos negócios e recuperação de desastre usando as Regiões Emparelhadas do Azure

Recursos relacionados

• O aplicativo de N camadas de várias regiões é um cenário semelhante. Ele mostra um aplicativo de N camadas em execução em várias regiões do Azure

• Princípios de design para aplicativos do Azure