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

Esta arquitetura de exemplo é baseada 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
• 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 aborda os aspectos de várias regiões da arquitetura e se baseia no 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 (Web Application Firewall) para proteger 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 fique indisponível. Se a região primária ficar indisponível, o Front Door roteia 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 que os funcionários acessem 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 mapeiam 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 Entrega de Conteúdo do Azure é uma solução global para fornecer conteúdo de alta largura de banda, armazenando-o em cache em nós físicos estrategicamente posicionados 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. 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 em 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, massivamente escalável, durável e seguro para uma variedade de objetos de dados na nuvem.
• O Cache Redis do Azure é um serviço de cache de alto desempenho que fornece um armazenamento de dados na memória para recuperação mais rápida 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 relacional como serviço 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 globalmente, totalmente gerenciado, de baixa latência, multimodelo e multi API de consulta para gerenciar dados em grande escala.
• A Pesquisa Cognitiva do Azure pode ser usada 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. O modo de espera ativo significa que o Serviço de Aplicativo na região secundária está alocado e está sempre em execução.

• Ativo/Passivo com espera passiva: o tráfego vai para uma região, enquanto o outro aguarda em espera passiva. O modo de espera frio significa que o Serviço de Aplicativo na região secundária não é alocado até que seja necessário para 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.

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 de negócios e recuperação de desastres para aplicativos LoB.

• Implante aplicativos de missão crítica que são executados no Windows ou Linux.

• Melhore a experiência do usuário mantendo os 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

Cada região do Azure é emparelhada com outra na mesma área geográfica. Em geral, escolha regiões do mesmo par regional (por exemplo, Leste dos EUA 2 e EUA Central). Os benefícios disso incluem:

• Se houver uma interrupção ampla, a recuperação de pelo menos uma região de cada par é priorizada.
• 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.

No entanto, 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. Para saber mais sobre pares regionais, consulte Continuidade dos negócios e recuperação de desastres (BCDR): Regiões Emparelhadas do Azure.

Grupos de recursos

Considere colocar a região primária, a região secundária e a porta de entrada em grupos de recursos separados. Essa alocação permite gerenciar os recursos implantados em 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 diferentes, 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 um teste HTTPS 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 da sonda de integridade, o número de amostras necessárias para avaliação e o número de amostras bem-sucedidas necessárias para que a origem seja marcada como íntegra. Se a Front Door marcar a origem como degradada, ela passará para a outra origem. Para obter detalhes, confira Investigações de Integridade.

Como prática recomendada, crie um caminho de teste 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, o teste pode relatar uma origem íntegra quando partes críticas do aplicativo estão realmente falhando. 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 é uma parte crítica da implementação de um aplicativo acessível publicamente. Consulte a Implementação de entrada segura de rede para saber mais sobre 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ê proporcione uma melhor experiência geral do usuário para seu aplicativo Web do que estaria disponível apenas com cache de conteúdo estático.

Banco de Dados SQL

Use a replicação geográfica ativa e os 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. Os failovers podem ser executados manualmente ou automaticamente, de acordo com as definições de política que você criar. Para usar grupos de failover automático, você precisará configurar 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, você poderá 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 é suportado 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ó devem ser realizados quando você julgar necessário. Esse requisito é definido pelo plano de recuperação de desastres da sua organização e você deve considerar as implicações conforme descrito na seção Considerações abaixo.

Se houver uma interrupção ou desastre regional, a equipe de 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 nenhuma 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 quais dados estão sendo 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 determinada data e hora são replicados
• Somente blobs de bloco correspondentes a um determinado 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, no entanto, 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 se beneficiar da 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 paralisações de data center. Se houver um desastre generalizado afetando vários data centers, o recurso de recuperação de desastres geográficos incluído na camada premium pode ajudá-lo a se recuperar. 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

Na Pesquisa Cognitiva, a disponibilidade é alcançada por meio de várias réplicas, enquanto a continuidade de negócios e a recuperação de desastres (BCDR) são alcançadas 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 as Zonas de Disponibilidade com a Pesquisa Cognitiva do Azure adicionando duas ou mais réplicas ao seu 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 Redis do Azure

Embora todas as camadas do Cache do Azure para Redis ofereçam replicação padrão para alta disponibilidade, a camada Premium ou Enterprise é recomendada para fornecer um nível mais alto de resiliência e capacidade de recuperação. Analise a Alta disponibilidade e a recuperação de desastres 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 qual camada é a mais adequada para sua infraestrutura.

Considerações

Essas 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 de tempo (geralmente cerca de 20 a 60 segundos) em que os clientes não conseguem acessar o aplicativo. A duração é afetada pelos seguintes fatores:

• Frequência de investigações de integridade. Quanto mais frequentemente as sondas de saúde são enviadas, mais rápido o Front Door pode detectar o tempo de inatividade ou a origem voltando saudável.
• Configuração de tamanho de exemplo. Essa configuração controla quantas amostras são necessárias para que o teste 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 seu 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 combinam 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 (Recovery Point Objective, objetivo de ponto de recuperação) e o RTO (Recovery Time Objective, objetivo de tempo de recuperação) estimado para o Banco de Dados SQL estão documentados em Visão geral da 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. Bancos de dados de área restrita, teste e desenvolvimento geralmente não são recomendados para replicação.

Azure Cosmos DB

O RPO e o RTO (Recovery Time Objective, objetivo de tempo de recuperação) do 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 multimestre ou um RPO de 0 para forte consistência com mestre único. Para saber mais sobre os níveis de consistência do Azure Cosmos DB, consulte Níveis de consistência e durabilidade de dados no Azure Cosmos DB.

Armazenamento

O armazenamento RA-GRS fornece armazenamento durável, mas é importante considerar 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, alguma perda de dados deverá ser antecipada se as alterações na conta principal não tiverem sido 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 objetivo de tempo de recuperação (RTO) de acordo: 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. Tentar um failback para a região primária sem um planejamento cuidadoso é arriscado. 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, em seguida, dar tempo suficiente para permitir que as contas sejam sincronizadas.

• Falhas transitórias, como uma interrupção de rede, não desencadearão 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 os pré-requisitos e as advertências para a documentação de 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. Como tal, 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 os pontos importantes a serem considerados e a documentação de considerações sobre recuperação de desastres.

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 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?

Compartilhamento de recursos entre origens (CORS) Se você criar um site e uma API da Web como aplicativos separados, o site não poderá fazer chamadas AJAX do lado do cliente para a API, 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 a Criptografia de Dados Transparente se precisar 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 Azure Private Link para 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 é alterado 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.

Os aplicativos sem estado configurados para dimensionamento automático são mais econômicos do que os aplicativos com monitoração de 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 armazenamento 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.

Funções Considere colocar um aplicativo de função em um plano dedicado do Serviço de Aplicativo 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 acesso aos dados dos serviços de origem e transferência 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 diminui 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. É cobrada uma taxa fixa para a quantidade total de armazenamento (GBs) consumida para dados e os índices de uma determinada hora.

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 e é uma extensão da diretriz 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 é projetar sua infraestrutura de aplicativos para ser altamente disponível, de forma otimizada em várias regiões geográficas, como ilustra esse design.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

• Arvind Boggaram Pandurangaiah Setty - Brasil | Consultor Sênior

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

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